Uploaded image for project: 'Titanium SDK/CLI'
  1. Titanium SDK/CLI
  2. TIMOB-26075

Android: Refactor app resume and "newintent" handling

    Details

    • Story Points:
      13

      Description

      Summary:
      Titanium's app resume handling from notification, shortcuts, intent-filters, etc. is problematic. It does not always resume and instead displays a new splash-screen instance which never runs the "app.js" (appears to hang) or a dialog stating that the app needs to be restarted (which can get stuck in an infinite loop).

      The following is a list of issues that have been reported. Some are flagged closed, but they're not completely resolved:

      Recommended Solution:
      Get rid of all of the activity "restarting" code. No one likes this behavior.

      Drop support for Android bug 2373/5277 related "tiapp.xml" properties:

      In the main activity's onCreate(), we should do the following:

      1. Check if TiApplication.getRootActivity() is not null. This tells us if a pre-existing activity window is already in the background and needs to be resumed. If it doesn't exist, then go ahead and create the activity (we're done).
      2. Fetch the pre-existing root activity's intent. If we call Context.startActivity() with this intent, then it'll resume it with all of its child activity windows intact. (This is what we're missing.)
      3. Call finish() for the new activity since we don't want to spawn a new instance. Attempt to disable the activity window's animation if possible via Activity.overridePendingTransition().
      4. Have the pre-existing root activity fire a "newintent" event with the intent received by the new activity that we just finished/closed. (We must wait for the old activity task to resume first though.)

      Issues to Investigate:

      • The Activity.getIntent() can return null in rare cases (link). We need to figure out how to resume the app's activity in this case.
      • We need to double check the necessity of TiBaseActivity.isUnsupportedReLaunch(). I suspect it's handling the case where a new Java runtime and Application instance is being re-created for a pre-existing app process (the C/C++ side's static variables still remember previous application info).
      • Check how this works with launchMode "singleTop". (It is being used by some community users. Although with this change, we shouldn't need it anymore.)
      • Re-test with Titanium's "Live-View" feature and Ti.App._restart() method to make sure they don't break.

      Limitations:

      • Titanium only supports running one V8 JavaScript runtime at a time. So, multiple activity tasks cannot be supported due to this limitation. This is partly why we need to refactor the app resume behavior. (This may be fine from a portability standpoint anyways since iOS does not support this.)
      • We should avoid launchMode "singleTask" support. While it does what we want and makes an Android app work more like iOS, it comes with a huge limitation. A "singleTask" activity's child activity windows are all torn down by the Android OS after homing-out of the app and then resuming it. "singleTask" is only a viable solution if we re-architected Titanium to only support one activity and and all Ti.UI.Window objects spawned fragments instead, but this would be a major MAJOR breaking-change that is best avoided for now.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jquick Joshua Quick
                Reporter:
                jquick Joshua Quick
                Reviewer:
                Gary Mathews
              • Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Backbone Issue Sync

                  • Backbone Issue Sync is enabled for your project, but we do not have any synchronization info for this issue.

                    Git Source Code