It is really helpful for me to understand custom lifecycle-aware components as well as custom lifecycle-owner.
Crisp and to the point information.
ON_RESUME when the first activity in the app goes through these states.
This is confusing. The tutorial mentioned the above with
when the first activity in the app, actually I don’ think it is the
first activity who triggers these status, but the top most in the activity stack.
Let’s say I have two activities in my app, Activity 1 and 2. Activity is the launcher activity, and it starts the other one with some button.
This way, I think the
first activity is Activity 1.
OK. With the implementation of
ProcessLifecycleOwner described in the tutorial, Activity 1 does trigger the events, this is no problem.
And let’s start Activity 2, and put the app to background.
Then pull the app to foreground again, this time, the app doesn’t show Activity 1, instead it is Activity 2, which also triggers the
I’d suggest it could be better if with the following two points:
- The custom lifecycle owner looks confusing. Maybe a little more explanation with a more proper/useful scenario could be better, like some scenario could be a perfect fit of it, by comparing without custom lifecycle owner.
- The article doesn’t mention what if the events had happened before lifecycle observer gets registered. Will the events still be sent to the observer? For example, say some observer is interest in the ON_RESUME event, but it won’t be registered as an observer until user taps on some button. For this case, when the user taps the button and registered the observer, will the observer be triggered by ON_RESUME immediately?