State Singletons For Fun and Profit
So you want to be a Senior Android Developer, right? One of the first things you have to do is solve a particular problem case that is particular to the android platform.
When an application is GC’d and the user restarts that application the Android OS does not start the application with the main activity but instead starts it with the last activity that the user had focus on. Guess what happens, yup, if you had not saved your global states that particular activity states with a blank slate messing up the user experience that you are trying to convey to the user.
Would it not be nice if you could have a single SavingState class that saves your state globals integrated with the lifecycle of the activity? In that is the first step in becoming a Senior Android Developer in solving problems just like that one.
So In this little article I will show you how to do it in yoru own little application framework library so you can reuse it again and again for all your applications. I am not using Dagger at the moment to keep the article somewhat simple.
Guess what is first? Yes, we need an interface that has the two methods to hook into the Activity/Fragment lifecycles, namely saveInstanceState and restoreInstanceState. It lokks like this:
that is right from my own GWSBase library from my:
Next we have a StateSaving class which we will not implement as a singleton as we use Providder proxy and how its called in the extended application class to ensure its a singleton. As a benefit as long as you only make the first calls to your Global State placeholders in that Provider Proxy those Global State placeholders will always be singletons. That is a mouthful but that is what you have to have to get the full benefits that we want.
My state saving class:
This class will cycle through and save the globals and restore the globals. Two particulars of this class is that I am using a Providder Proxy to make it a singleton due to the way its called:
In my extendable app class I have added a method call in onCreate, initGlobalSingletons and thus over-ride that method to wire up the
And that call does two things at once. First it establishes MyExtendedBaseSavingState class as a singleton and secondly it
calls the global state classes the first time hence ensuring that they are singleton in nature.
Hold on, we are not done yet as we have the last step to ensure that the Activity or Fragment save and restore the state of our globals. In my Application Framework classes I have added an
over-rideable methods to my onSaveInstanceState and onCreate methods so that I could add stuff like this.
Thus, in my initOnSaveInstanceStateBody method we just need:
In our onCreate, its the same call as we have a already error checked to see if the bundle is null:
So what do we use those Global Singletons for? In a networked app you use them as cache objects but that is not the only use. You may need to use one of them as a global app state if your application is complicated enough. You do not have to worry about saving and restoring states of views as you get that benefit each time you extend a view or widget class.
You will see this pattern over and over again. You have a problem case that keeps occurring and know if you could integrate with the life-cycles of the application, the activity, or the fragment you could solve it.
If you are a startup and could use an android developer with best practices like this than you can contact me at fred dot grott at gmail dot com.