Confusion about restartables and the Activity lifecycle

[jrobinson3k1]

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]

Hi, have you seen this explanation?

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

[jrobinson3k1]

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]

onDestroy is not guaranteed to be called