Mobile application life-cycle Android vs iOS vs Xamarin.Forms
Lifecycle. One of the most common recruitment questions. No matter what technology you work with this is something that should be well known and understood.
It's good to know how application behaves, what it is allowed depending on its state and when to react on specific lifecycle events.
In mobile world lifecycle is even more complicated because there is no 1 answer but 3 in this case: Android. iOS. Xamarin.Forms. I use also Xamarin.iOS event names in my diagrams, but the sequence is the same.
Lifecycle is the definition when your application have access to resources and when react on state change.
For mobile the biggest priority is what user can see and interacts with, so active application have priority in using system resources. System has limited pool of resources, so applications running in background (not visible to user) is limited by system in how much resources can it use and also system decides when application needs to release all resources (be closed/killed/end of its execution time). The given time of execution can be to short to perform all needed operations so application needs to be prepared for being closed much earlier.
Operating systems works in similar manner.
Those four points will be considered in my diagrams.
Diagrams are the meat here, I won't explain it very closesly so please read the diagrams.
Let's look at Android lifecycle.
It is explained in details here.
In android the application is represented by Activity. All events take place on activity level. Activity is an application and in the same time it's a view available for user.
Let's look at iOS.
In Apple ecosystem this is a little bit different. Application lifecycle (described in details here)
is specific to application level, there is another set of methods on controller lever (I will describe controller lifecycle in futher post).
Android and iOS are very simmilar. There is one difference that you can spot below. The diffrence is that iOS on cold starting application skipps event WillEnterForeground.
Creating framework there are decisions to make. When we have two sets of methods that are very similar but not always we can create subset of methods or create interface with all methods but not all will be called always (on each platform).
Xamarin.Forms chooses the subset.
You can see it in Android method OnStateChanged (github repo)
and in iOS in each lifecycle method (github repo).
Is it good? Is it bad? It just is as it is. It's Xamarin.Forms way.
For sure it's more structurized each state change has it's own method.
But application must be prepared that it will be suspended and killed in the same event OnStop.
It's good to know how application behaves, what it is allowed depending on its state and when to react on specific lifecycle events.
In mobile world lifecycle is even more complicated because there is no 1 answer but 3 in this case: Android. iOS. Xamarin.Forms. I use also Xamarin.iOS event names in my diagrams, but the sequence is the same.
Lifecycle is the definition when your application have access to resources and when react on state change.
For mobile the biggest priority is what user can see and interacts with, so active application have priority in using system resources. System has limited pool of resources, so applications running in background (not visible to user) is limited by system in how much resources can it use and also system decides when application needs to release all resources (be closed/killed/end of its execution time). The given time of execution can be to short to perform all needed operations so application needs to be prepared for being closed much earlier.
Operating systems works in similar manner.
- User takes action to start application, system obey the command and takes actions to start application
Starting application - Application after some internal events is running and is responsive to user interaction
Application is active in Foreground - Responding to events like switching application, or answering call, our application is send to background
Application is inactive in Background - If system requires resources (low memory, battery saving or others) it can decided to release application resources with mean kill application.
Application is closedWhen user returns to application it is resumed or started all over again (if it was killed).
Those four points will be considered in my diagrams.
Diagrams are the meat here, I won't explain it very closesly so please read the diagrams.
Let's look at Android lifecycle.
It is explained in details here.
In android the application is represented by Activity. All events take place on activity level. Activity is an application and in the same time it's a view available for user.
Let's look at iOS.
In Apple ecosystem this is a little bit different. Application lifecycle (described in details here)
is specific to application level, there is another set of methods on controller lever (I will describe controller lifecycle in futher post).
Android and iOS are very simmilar. There is one difference that you can spot below. The diffrence is that iOS on cold starting application skipps event WillEnterForeground.
Creating framework there are decisions to make. When we have two sets of methods that are very similar but not always we can create subset of methods or create interface with all methods but not all will be called always (on each platform).
Xamarin.Forms chooses the subset.
You can see it in Android method OnStateChanged (github repo)
and in iOS in each lifecycle method (github repo).
Is it good? Is it bad? It just is as it is. It's Xamarin.Forms way.
For sure it's more structurized each state change has it's own method.
But application must be prepared that it will be suspended and killed in the same event OnStop.
Comments