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:
Get rid of 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:
- 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).
- 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.)
- 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().
- 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.
- 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.