Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-24747] Android: new tasks are created upon opening a custom URL scheme

GitHub Issuen/a
TypeBug
PriorityCritical
StatusClosed
ResolutionDone
Resolution Date2018-08-03T17:16:48.000+0000
Affected Version/sRelease 6.1.0
Fix Version/sn/a
ComponentsAndroid
Labelsandroid, intents, url-scheme
ReporterCreative
AssigneeGary Mathews
Created2017-05-30T12:11:51.000+0000
Updated2019-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.

Comments

  1. Joren Vos 2018-02-20

    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" and singleInstance but it didn't work as expected. Is it possible to take a look at this functionality?
  2. Josh Lambert 2018-02-21

    Bump. I need this also in two different projects. Happy to help anyway I can.
  3. Gary Mathews 2018-03-09

    [~jvos] [~zettageek] Have you tried defining the property:
       <property name="intent-filter-new-task" type="bool">true</property>
       
    In your tiapp.xml?
  4. Joren Vos 2018-03-12

  5. Joshua Quick 2018-03-13

    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.
  6. Joren Vos 2018-03-13

    Today, thanks to a reply in TiSlack, I was looking for an alternative using intents. I tried following workaround: *+App A+*
                   var intent = Ti.Android.createIntent({
                       className: com.example.appb.AppBActivity,
                       packageName: com.exaple.appb,
                       type: 'text/plain',
                       action: Ti.Android.ACTION_MAIN
                   });
       
                   intent.addFlags(Ti.Android.FLAG_ACTIVITY_CLEAR_TOP);
                   intent.addFlags(Ti.Android.FLAG_ACTIVITY_NEW_TASK);
       
                   intent.addCategory(Ti.Android.CATEGORY_LAUNCHER);
       
                   intent.putExtra("URL", url);
       
                   Ti.Android.currentActivity.startActivity(intent);
       
    *+App B+*
                   var intent = Ti.Android.createIntent({
                       className: com.example.appa.AppAActivity,
                       packageName: com.exaple.appa,
                       type: 'text/plain',
                       action: Ti.Android.ACTION_MAIN
                   });
       
                   intent.addFlags(Ti.Android.FLAG_ACTIVITY_CLEAR_TOP);
                   intent.addFlags(Ti.Android.FLAG_ACTIVITY_NEW_TASK);
       
                   intent.addCategory(Ti.Android.CATEGORY_LAUNCHER);
       
                   intent.putExtra("URL", url);
       
                   Ti.Android.currentActivity.startActivity(intent);
       
    This in both app's Alloy.js:
           Ti.Android.currentActivity.onResume = function() {
              console.error(Ti.Android.currentActivity.intent.getStringExtra("URL"));
           };
       
    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...
  7. Joren Vos 2018-03-21

    Please any update or workaround?
  8. Creative 2018-03-21

    You might get somewhere with hyperloop, but then again this suits native code better
  9. Joshua Quick 2018-05-09

    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 FLAG_ACTIVITY_CLEAR_TOP. This gives the appears that the app is restarting.

    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.
  10. Joshua Quick 2019-01-11

    This issue has been resolved in Titanium 8.0.0. Please see: [TIMOB-26075]

JSON Source