Problem description
When adding the resume event to Ti.Android.currentActivity, the resume is not called when the app is resumed. This works well in SDK 3.1.3
Steps to reproduce
1. Use the code below
2. Run the app on Android
3. Hit the home button on the device
4. Restore the app: no alert is shown
Code to reproduce
Ti.Android.currentActivity.addEventListener('resume', function(e) {
alert("resumed");
});
var win = Ti.UI.createWindow({
backgroundColor: 'white'
});
win.open();
Note
The same code and steps work fine on SDK 3.1.3
Currently, on windows it's possible to set win.activity.onCreateOptionsMenu = some function even before the win.open() call, and indeed this function will be called at the right time. So why not use a similar mechanism for the rest of the lifecycle events, instead of activity.addEventListener which is unavailable prior to the open event, which is too late for many of the events? Adding to this confusion is that for TabGroups, the open event is not too late to install the event listeners (and also setting tabGroup.activity.onCreateOptionsMenu prior to open will not work either....) To be honest, I don't think this should wait until after 3.3.0 - these are major issues.
See pull request: https://github.com/appcelerator/titanium_mobile/pull/5701 See test application below. Explanation: 1. Added onCreate, onStart, onResume, onRestart, onPause, onStop, and onDestroy properties to the tab group or window activity property. 2. For Window, you must set these properties prior to window.open() called. 3. For TabGroup, you can set these only after the open event (it's unfortunate that the two APIs are different in this, but that's outside the scope of this PR). 4. These callbacks are better than the events, since they're called synchronously, thus more reliable. Plus it makes more sense if onCreateOptionsMenu, onPrepareOptionsMenu, etc are using the same mechanism. 5. The pull request did not modify the event handling. These can still be used as before - but they're *BUGGY* for windows, as noted. 6. I recommend the lifecycle events be deprecated. The user can always fire events in javascript from the callbacks, if desired. 7. Docs for this TBD - pending Appcelerator approval of this PR.
And please - accept this for 3.3.0, this issue is a real pain...
Please note that the PR does not modify any existing APIs,and thus is completely safe to integrate for 3.3.0
Regarding the original testcase posted in the ticket, this is due to the Android window re-architecture done as part of TIMOB-13796. All windows by default are now heavyweight windows (hosted by their own activities). To get the same behavior as 3.1.3 in 3.2.X releases add the following property to tiapp.xml
Setting this property will open windows hosted by the root activity which is what the currentActivity variable points to in the sample posted. Note that this property has no effect in 3.3.0 and later releases since support for light weight windows has been dropped. So opening the window will pause the root activity and backgrounding and foregrounding the app once the window is open only causes the window activity to send out events (the root activity remains paused).
@Vishal: this ticket should be changed to "Activity.create, start, resume, restart don't work", and that's what the PR fixes. You can try the test case in my comment with the PR and you will see in doesn't work for Windows (just of course change the onCreate etc callbacks to "addEventListener"). If you addEventListener prior to Window open event the app will crash, and if you add it after the Window open you will miss some of events. This is actually very critical. Referring to 3.3.0+ of course.
Are there any updates on this? I'm having similar problems trying to listen for pause & resume events on the tabGroup activity.
@Vishal, @Ingo, please merge the pull request, it works fine for me on 3.3.0, and Window activity events are outright broken without it. @Terry Morgan: try hooking the TabGroup activity events after the TabGroup open event. That should still work. It's Window Activity events that are hosed for now.
PR updated to use async callbacks, please merge for master and 3.3.1, thanks.
Filed TIDOC-1788 for updating the doc. Resolved this ticket as Fixed.
Marked as resolved and fixed but still not merged for 3_3_X. I'm sure it can be merged automatically for that branch as well.
3_3_X PR: https://github.com/appcelerator/titanium_mobile/pull/5934
Verified the fix. The onCreate, onStart, onResume, onRestart, onPause, onStop, and onDestroy properties work as expected. Closing. Environment: Appc Studio : 3.4.0.201408051600 Ti SDK : 3.4.0.v20140815142514 Mac OSX : 10.8.5 Alloy : 1.5.0-dev CLI - 3.4.0-dev Code Processor: 1.1.1 Nexus 5 - android 4.4.4
Please update the fix for this with this small but important fix: https://github.com/appcelerator/titanium_mobile/pull/6160 This makes the lifecycle calls synchronous. Explanation: Strange things happen if the Android Activity lifecycle calls (onCreate, onResume, onCreateOptionsMenu, etc. ) are async: the calls into Javascript happen much later than they should - sometimes disastrously later. For example, if a window is created and opened as the screen is locked, Android will quickly cycle through create, start, resume, pause, stop - and I have seen window.activity.onResume, onCreateOptionsMenu etc called after the activity was stopped! This of course creates issues if the code tries to do something with the activity when the activity's state is inappropriate for the action. This should be merged into master as well as 3_4_X
This module requires the new PR for this ticket: https://github.com/mokesmokes/titanium-android-facebook
Looks like there has been a regression for this ticket? Just tried converting from
$.win.activity.onResume = ...
toTi.Android.currentActivity.addEventListener("resume", ...)
and while the former works just fine, the second one doesn't.Read the latest docs. Use the onResume property on the Activity, not the event listener.
In that case, the documentation at http://docs.appcelerator.com/titanium/latest/#!/api/Titanium.Android.Activity should probably be updated to also not mention
addEventListener
in the example code.Yup, however note that the list of properties and events is indeed correct.