search

konmik / nucleus

Nucleus is an Android library, which utilizes the Model-View-Presenter pattern to properly connect background tasks with visual parts of an application.
MIT License
1.98k stars 253 forks source link

Confusion about restartables and the Activity lifecycle #141

Open jrobinson3k1 opened 7 years ago

jrobinson3k1 commented 7 years ago

I'm either confused on the wording of the Javadocs, or restartable is not behaving how I would expect. I'm using restartableLatestCache, which from dissecting the Javadocs indicates that it will emit the last onNext value each time it is started, plus any new onNext values if they are emitted in the future. A restartable will re-subscribe after a "process restart". I'm unsure exactly what entails a process restart, but I assumed that meant when an activity is being recreated for whatever reason.

However, a simple pause/resume of the activity via backgrounding the app and bringing it back to the foreground triggers the restartable to fire off its cached value without a subsequent call to start. I didn't think that would qualify as a "process restart".

So if someone would be so kind, could you explain to me if this is working as intended, and if so, qualify what a "process restart" means so I know what behavior to expect in the future? How could I achieve a "latestCache"-like result, but only if the Activity has been re-created (destroy/create)?

konmik commented 7 years ago

Hi, have you seen this explanation?

https://github.com/konmik/nucleus/wiki/Restartables

jrobinson3k1 commented 7 years ago

That is helpful for understanding the differences between first, latestCache, and replay. My confusion is with understanding why an Activity pause/resume is re-emitting its cached value. After further inspection, I see that takeView() occurs during onResume() and dropView() occurs during onPause(). I'm not clear in what advantages are gained by attaching to these particular lifecycles, as the view has not been destroyed or reconfigured, it's just hidden.

I have found a way to get it to work as I would expect by moving presenterDelegate.onDropView() to onDestroy() and presenterDelegate.onResume() to onCreate(). But since I'm unsure of the design decision for using pause/resume over create/destroy, I'm not sure if I'm potentially breaking functionality by making this move.

konmik commented 7 years ago

onDestroy is not guaranteed to be called