[TIMOB-26424] Android: Added Ti.App "pause" and "resume" lifecycle events
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | High |
Status | Closed |
Resolution | Done |
Resolution Date | 2018-10-29T23:12:47.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 7.5.0 |
Components | Android |
Labels | android, events, lifecycle, parity, pause, resume |
Reporter | Gary Mathews |
Assignee | Gary Mathews |
Created | 2018-10-01T17:23:01.000+0000 |
Updated | 2019-01-18T14:19:47.000+0000 |
Description
-
Ti.App
lifecycle events are not fired
Ti.App.addEventListener('resume', () => {
Ti.API.info('RESUME');
});
Ti.App.addEventListener('pause', () => {
Ti.API.info('PAUSE');
});
Here's one thing you may need to watch out for regarding "resume" and the screen-lock. If your app is in the foreground, you press the power button to turn off the screen, and then turn on the screen... the
Activity.onResume()
will get called while the screen-lock is displayed (you can't see your app yet). This is fine for most apps... unless they play music or video. Media is not expected to be resumed until after the screen-lock has been cleared. You have to use aBroadcastReceiver
to detect if the screen-lock has been cleared. Another interesting thing to watch out for is some screen-locks become transparent as you swipe them off to reveal the app underneath it. So, the app needs to update its content for the current orientation too. I notice that we have a "resume" and "resumed" event. Perhaps the "resume" can be tied toActivity.onResume()
and "resumed" tied to after the screen-lock has been swiped away?master: https://github.com/appcelerator/titanium_mobile/pull/10359
FR Passed. PR Merged.
*Closing ticket.* Fix can now be verified in SDK version
7.5.0.v20181008124804
. Test and other information can be found at: https://github.com/appcelerator/titanium_mobile/pull/10359I see this output when using the code in the PR
Why the pause/paused at the start? Is the splashscreen calling pause/resume already? And when extending the code with a button and a new window:
I'll get another pause-paused-resume-resumed when opening a new window. So the event is not app level but activity/window level? So I still have to manually check if a new window was opened or the app is in background?
I am wondering the same thing; currently the resume/pause events are also fired when opening/closing a new Window. How do I separate this from an app-level pause/resume? Thanks
Same here, this issue is not resolved yet and it's become more problematic now as the events are getting fired for all windows no matter where you add the listener in the code. Need a quick fix on this.
[~michael], [~arif], [~prashant_saini], After looking at it, I agree. The current pause/remove behavior does not work like iOS. Nor does it match Titanium's documentation. It's currently following the native Android Activity
onPause()
andonResume()
behavior, which we already have callbacks for, but ultimately app devs need the ability to detect when the app is put into the background/foreground. I've written up a ticket to have this resolved in the near future. See: [TIMOB-26746]@Joshua, thanks for the input, but seems that we are not going to have any events even in 8.0.0.GA release, isn't it? If yes, then we would appreciate if you can provide any proper work-arounds to know when the app was actually put in background without going through all the pains of checking the activity pause-resume events when app can be put in background anytime.
We're currently code freezing Titanium 8.0.0 and are only allowing show-stopper fixes. We're trying to push an RC of 8.0.0 in the near future. But I'm going to push to get this fix into 8.0.1. As for a work-around, I think the only solution is to monitor every activity your app opens and keep a count of each one that has had its
onStart
callback invoked. That's currently how it has to work natively to solve this issue as well. (Internally, we can't solve the problem via Google's newProcessLifecyleOwner
support class yet.) This "can" be solved by creating an Android module, but that's a lot of effort for something so small. But if you were to do it, it would have to do the same thing Titanium's internal "GestureModule.java" code does to start/stop its sensors in the link below (it's a small block of code). We disable sensors when backgrounded and resume sensors when brought back to the foreground. [GestureModule.java#L78](https://github.com/appcelerator/titanium_mobile/blob/master/android/modules/gesture/src/java/ti/modules/titanium/gesture/GestureModule.java#L78)[~prashant_saini] you still can use Bencoding.tools or this Hyperloop module: https://github.com/dieskim/Appcelerator.Hyperloop.appPauseResume as a work-around.