6. App Initialization
Common to need to initialize things at the beginning of the App
Lifecycle
Sometimes these can take a while
Common approach is to show a loading screen
7. Pattern: App
Singleton
App Singleton Class
bool IsInitialized Property
Initialized Event
ActivityBase
Check to see if
App.Current.IsInitialized
App
public static
App()
protected - ctor
()
public static App
Current
public bool
IsInitialized
public event
Initialized
9. App Initialization After Crash
• Unhandled Exceptions will cause Android to kill the process
• AppDomain and all objects in it will be cleaned up by Mono
• Android will still attempt to launch last running activity
• If it relies on initialization, activity won’t make sense
• If activity re-launch fails, it moves backwards through the
navigation history - Painful
• Need to enable initialization on all activities
• Sometimes want to force load of launch activity
11. Unhandled Exceptions
• In other app platforms, can be handled at an App level
• AppDomain.CurrentDomain.UnhandledException +=
HandleUnhandledException;
• Trickier in Android - Will cause a “Spectacular Crash”
• Some day, this story will be better, can at least log now
• See in Android Log
13. Waiting for Async Initializations
• Sometimes app needs to wait for multiple
asynchronous inits
• e.g.: binding to more than one service
• or service + web request
• etc.
• Same pattern as before, but keep track of inits
• When all inits complete, raise Initialized event
the most important methods to override and implement are OnCreate(), OnResume(), and OnPause().
> OnCreate() - Load/inflate your UI, instantiate any controls, get references to controls in your view, wire up any local event handlers
> OnResume() - Rehydrate UI state, Wire up any external event/notification handlers, start updating UI, basically, undo ANYTHING that you do in OnPause()
> OnPause() - Remove any external event handlers, dismiss any dialogs, pause UI updates.
Why? because if the Activity is paused and then reactivated, OnResume will be the only next method. OnCreate will be called when the Activity is first Instanced, but OnResume is the only method guaranteed to be called when an activity is activated.
Cover:
> app.cs - we’re using this to provide an external update to subscribe to
MainActivity.cs
> OnCreate
> OnResume
> OnPause
> AddHandlers
> RemoveHandlers
Cover:
App.cs
> Initialized Event
> IsInitialized property
> .ctor: now takes a little while, also that it’s in a Task() because it is blocking (started from a UI thread)
Examine:
App.cs
> wire up the AppDomain.CurrentDomain.UnhandledException handler
If you have a single asynchronous initialization, it’s easy to handle. If you’re using the pattern we’ve been examining, you simply raise the App.Initialized event in the completion handler. However, sometimes you need to initialize multiple asynchronous things. For example, if you’re binding to more than one service, or you’re binding to a service and also waiting for a web request to finish, etc.
Handling this scenario is actually quite simple. We use the same pattern as before, but we extend it but keeping track of the number things that require initialization, and when we hit the threshold, that is, when all the initializations complete, we raise the Initialized event and we’re on our way.
Examine:
App.cs
> totalInitCount
> currentInitCount
> IncrementInitCount
> .ctor - service connected calls IncrementInitCount
Also
Service Binding Generics
