Presenter persistence (questions, not an issue)

[mylesbennett]

I wanted to use the same principle as you have used for persisting Presenter objects to persist other objects. There is a couple of things in your code that I don't understand which I hoped you could explain.

• In PresenterLifecycleDelegate#getPresenter you use a Bundle set in onRestoreInstanceState to restore the Presenter in the event that it is null. Under what circumstances would the Presenter ever be null at this point? It appears that the Presenter gets set by the code below this, via the first onResume, then doesn't get cleared until the last onDestroy.

• That same Bundle is derived from the onRestoreInstanceState bundle parameter from the OS. In this method you marshall it then unmarshall it. This seems a bit redundant. Why do you do that?

Thanks for the great library!

rgds, Myles

[konmik]

Hi, it checks for null because there is no guarantee that it is not null. For example there is View lifecycle, sometimes you get onRestore after onAttachedToWindow

[konmik]

the bundle is being marshalled and back because there can be some mutable data in it and when you alter it after it was put into the bundle it can lead to really hard to debug issues on restoration.