[TIMOB-24747] Android: new tasks are created upon opening a custom URL scheme
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Done |
Resolution Date | 2018-08-03T17:16:48.000+0000 |
Affected Version/s | Release 6.1.0 |
Fix Version/s | n/a |
Components | Android |
Labels | android, intents, url-scheme |
Reporter | Creative |
Assignee | Gary Mathews |
Created | 2017-05-30T12:11:51.000+0000 |
Updated | 2019-01-11T03:41:25.000+0000 |
Description
I am not providing a testcase here since i think its time that Appcelerator brings forward a working testcase for the custom URL schemes because there have been so many broken examples.
There have been various issues created and (supposedly) fixed in JIRA, like TIMOB-15253, TIMOB-20490 and TIMOB-20459, but issues still seem to exist in the current build (6.1.0.GA as of speaking).
Please provide:
- The absolute minimum setup for _tiapp.xml_ in order to start receiving intents through custom URL schemes
- The usage and workings of "intent-filter-new-task" versus "android:launchMode".
- Test this case with the app being "resumed" from background and "newly created".
If this can be created into a page for the Titanium Documentation than that would be great.
The end result should feature an application that is always a single instance, that is:
- Opening an intent from the browser like _Link_ should +always+ re-use the existing instance if there is one. If not, it should open a new instance.
- A splash screen should only be shown when the app is completely shut down.
- In absolutely no case should there be multiple instances of the same app. In my tests i've come across multiple instances of the app after opening a custom URL. I was able to identify this due to the logging of events.
By looking at the comments of the TIMOB's mentioned above and by my own experience, I know there are still bugs regarding this functionality. Issues seem to be closed for sake of progression rather than actually fixing the issue.
Any progress on this issue? We are currently experiencing issues with URL-schemes. We currently have two apps. The first app opens the second app in order to request a token. The second app generates the token and gives this token back to the first app. The setup is simple. I followed the instructions from Fokke (fokkezb.nl/2013/08/26/url-schemes-for-ios-and-android-1/) and it's working fine for iOS, I am able to open both apps and pass data, but on Android, we're dealing with an issue. When the second app is already open, the first app starts the second app another time, but in it's own app container. That's unwanted behaviour because I want to be navigated to the second app instead of opening a new instance. In some other cases, tapping "back" in the second app makes me go back to the splash screen etc.. We tried playing around with
android:launchMode="singleTask"
andsingleInstance
but it didn't work as expected. Is it possible to take a look at this functionality?Bump. I need this also in two different projects. Happy to help anyway I can.
[~jvos] [~zettageek] Have you tried defining the property:
In your tiapp.xml?
Right. Setting the "intent-filter-new-task" to true means it'll create a new task instance. This is also Android's default behavior. We don't currently support launchMode "singleTask", but even if we did, the consequence of this setting is that it'll tear down all of the top most windows (aka: Android activities) you've created and display the root window. In our case, the splash screen window. Unfortunately, this is also by Google's design. There is no launchMode setting that 100% replicates iOS' behavior.
Today, thanks to a reply in TiSlack, I was looking for an alternative using intents. I tried following workaround: *+App A+*
*+App B+*
This in both app's Alloy.js:
Using these intents, I'm able to open App B from App A. Both apps have a button to switch to the other app. (Example setup) Unfortunately, following flow results in strange behaviour: 1. App A opens App B, I can see URL in the console.error-logging 2. App B opens App A, I can see URL in the console.error-logging 3. Navigate to another activity in App A (for example, Activity 2), close the original first activity 4. Close Activity 2, open Activity 1 4. App A Activity 1 (same as in step 1) opens App B, I can see URL in the console.error-logging 5. App B opens App A, but no console logging visible I see that the Ti.Android.currentActivity.onResume is added on TiRootActivity: TiRootActivity: (main) [0,0] checkpoint, on root activity resume [ERROR] null For me, I tried a lot of other solutions: addEventListener on different events (newintent, onIntent), getActivity on the current window... I even tried startActivityForResult and I see that the callback is invoked directly, even when the second app isn't fully opened yet...
Please any update or workaround?
You might get somewhere with hyperloop, but then again this suits native code better
Just to be clear here, there is no way to resume the Android app via an intent like how it works on iOS. Not in JavaScript. Not in Java code. If this is what you're after, then this is not an option. From a design standpoint, this is the downside of using Android activities for child windows. An intent is used to display a specific activity window and if you point it to the launcher activity (which is what you would normally do), then your only options in native code are:
Create a new UI task, which gives the appears of a new app instance. This is commonly done on Android. This is what our "intent-filter-new-task" tiapp.xml property enables.
Set up the intent to tear down the background UI task and create a new one via
The launch mode "singleTask" (which you should *NOT* use in Titanium) is only a viable option when your Android app is NOT using activities for child windows. Because the consequence of this setting natively is that it tears down all child activities to display the root activity when resuming the background app. This won't match iOS' behave either. The "singleTask" option can only be rigged to work similar to iOS is if the app only uses 1 activity and displays child windows via fragments instead. This is not something Titanium supports because it would be a huge HUGE breaking change. I get the feeling that you're after iOS like behavior here. Unfortunately, it isn't possible. The 2 solutions you were using ("intent-filter-new-task" or "FLAG_ACTIVITY_CLEAR_TOP") are your only options.FLAG_ACTIVITY_CLEAR_TOP
. This gives the appears that the app is restarting.This issue has been resolved in Titanium 8.0.0. Please see: [TIMOB-26075]