Commence the blah.
I would like to use this post to discuss the methods presented in the article on Android presenters and how to save their state in the application via the Android Loader framework. You can find the post on Medium about this, here.
Over this past weekend I attempted to use this solution to handle saving the state of presenters in PadLock. At the end of these trials I have found a couple of points why I would advocate for, and against preserving Presenters in this way, and most importantly, why I ultimately would not recommend this method.
The pro of this method is the fact that because Loaders are preserved between orientation changes and cleaned up after the lifecycle ends, you do not have to worry about leaking the view that the presenter is attached to or manually clean up the presenter yourself.
I would address this by stating that you should be keeping a Weak Reference to your view in the presenter, not a strong one, which would automatically unbind the presenter from your View whenever it would normally be cleaned up.
The major cons I see in this method of preserving your Presenters through a custom Loader implementation, is that if you wish to use your presenter, it is only guaranteed available in all cases after onStart() in your Activities, and onResume() in your Fragments. While the presenter is available in onStart() for the first time it is used in Fragments, it is not guaranteed at any onStart() call thereafter, making the first guaranteed time in Fragments onResume(). By using Loaders, you sacrifice doing any important work relating to your presenter in onCreate(), onDestroy(), and other areas of the lifecycle that it is not guaranteed to be available. In my opinion, it is not very useful to have the presenter be managed in the lifecycle if it cannot be used for more than half of the Activity/Fragment lifecycle anyway.
To compound onto what I see as the major con to this approach, the ability for the Loader to preserve state is currently broken making it not worth your time at this point. Note that even if the Loader were to be fixed in the future, the above con still stands as my main reason for not advocating this method. Loaders also deliver results on orientation change twice by design, making using them to preserve state effectively a bit of a hack around as well.
Because of the various issues which surround the use of Loaders for preserving Presenter state, I currently take an approach which relies on a headless retained fragment to save arbitrary objects into a SparseArray. This approach is ugly and will need to be manually written into each onSaveInstanceState(), but the FragmentManager will automatically clean itself up once its activity lifecycle has ended. This allows me to avoid using retained fragments that are associated with views, and only use a retained fragment in my headless data holding instance. I do not mind the calls to onSaveInstanceState() all too much, as the lifecycle should be handled entirely by the view anyway, and Android already provides us this call to do so. While this does prevent saving data in any Child sub-Fragments, you should not be using those anyway.
It is not a good approach. But it lets me at least use the full lifecycle of the Activity/Fragment while not having to worry about preserving the Presenters I need. I find it better than an in-memory cache because it is automatically associated and destroyed with its Activity, where as you would have to manually manage an in-memory singleton cache yourself.
========================
Follow pyamsoft around the Web for updates and announcements about the newest applications!
Like what I do?
Send me an email at: pyam.soft@gmail.com
Or find me online at: https://pyamsoft.blogspot.com
Follow my FaceBook Page
Follow my Google+ Page
=========================