You’ve got your Xamarin Forms (or native Android/iOS) application up and running and now you need to start thinking about what happens when your application hibernates.
An application can go into hibernation (or sleep mode) and then resume at some point. The OS hibernates an application in response to events, such as power off or lock screen but also if it’s running low on memory. Therefore, so that our application “places nicely” on the OS, we need to think about how we will persist state and restore state during this hibernation phases.
Let’s look at the various methods in Xamarin Forms for handling different aspects of the application’s life cycle…
Xamarin Forms
Initialization/Starting
By default a Xamarin Forms application will create an OnInitialized method which is basically where the InitializeComponent method is called. It’s a good place to set up any initialization for your UI elements etc.
Assuming we’re starting our application from cold (i.e. first start) Then the following lifecycle methods are called in order
- OnInitialized
- OnStart
According to the App Lifecycle documentation “On Android, the OnStart method will be called on rotation as well as when the application first starts, if the main activity lacks ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation in the [Activity()] attribute”.
So OnInitialized remains the best place to set defaults up, but OnStart may be the best place to make any UI changes based upon orientation etc.
Entering sleep mode
If the device goes into sleep mode (we can simulate easily by hitting the power button on our emulator or device). The following is called
- OnSleep
This is our opportunity to persist state from the device so that when we resume the application it’ll appear in the same state as when it went into sleep mode.
There’s various ways to achieve this, if we’re using a pure MVVM approach with Prism (for example) we might use the EventAggregator to send a sleep message to all listening view models etc., which would then persist their data, or maybe we hold a cache (or similar) as a single data store and we persist this. Whichever way we go, the intention is that everything that is required to get the application back to the state pre-sleep, needs persisting. This also includes things such as which view (in a multiple view application) is displayed along with things like the view stack – well you get the idea, it depends how far you want to go to recreate the state of your application.
Note: another useful way to deal with view model data etc. is to actually persist it automatically when it changes, I don’t mean for every change of an entry control, but for example if you get data from a service, then you might store this in a cache and persist at the same time – obviously it depends on your specific scenarios and design.
Resuming from sleep mode
When an application is resumed, the following is called
- OnResume
At this point we need to read any persisted data, hydrate our data/view models with this previously stored data and then get the application back into the state it was when it went into sleep mode. As mentioned for OnSleep, this includes any changes to the UI to put the correct view in place. Basically the user should not even realise that the application was, essentially, closed and restarted.
To test OnResume we simply click the power button on the emulator or unlock the device at which point OnResume will be called.
References
Xamarin.Forms App Lifecycle
Android Activity Lifecycle
UIApplicationDelegate Class