Welcome to part 4 of this review of the Pluralsight course Android for .NET Developers: 2 Building Apps with Android Studio by Jim Wilson
Jim has over 30 years of software engineering experience, with the past 15 years heavily focused on creating mobile device and location-based solutions. He has co-founded multiple software-related startups and has served in a consulting role at several more.
After nearly a decade as a Microsoft Device Application Development MVP, Jim now focuses on developing Android and iOS device applications. Jim’s passion is mentoring software developers. He blogs at hedgehogjim.wordpress.com.
This is the second course in a series of four courses which Jim has created for Pluralsight. I have also reviewed his first course which is Android For .NET Developers 1: Getting Started. If you are completely new to Android you should begin there. But if you have some previous experience with Android Development you can start here.
Activity Lifecycle
Mobile Resource Challenge
Because mobile devices have much less resources than a laptop or desktop PC, Android must manage what little resources a device has very carefully.
Most of all, Android must minimize power usage to conserve battery power as much as it can.
Traditional Resource Management
Jim explains that traditional resource management tends to hold onto resources.
Moving Beyond Processes and Threads
Instead, Android manages resources at the component level.
An Activity’s right to resources is tied to user interaction and when a user moves to another Activity, the old Activity loses it’s right to use the CPU. It may also lose memory resources.
Android Resource Management
In the lesson Jim explains how Android manages resources in a sophisticated way.
When a new Activity is created, Android takes care of starting the process, giving it a thread etc. Old activites lose access to the CPU, and when memory resources get scarce their memory allocations are also removed.
The old Activity is notified that it’s resources are being deallocated and there is no way for the activity to override this directive. Android still knows what was there and can reproduce the activity if the user goes back to it.
Android can also detect when there is a process within no active components. When this is the case it will tear-down that process.
It stores the history of all the screens that the user has moved through, and when the user taps the back button, it moves backwards through the stack.
Activity States
Activity State Callback Methods
Demo: Activity State Callback Methods
Device Orientation and State
Demo: Manage State of Activity Views
Jim says this is a bad thing and a good thing.
A bad thing because we need to ensure we have all the proper state management in our activities.
A good thing because it gives us an easy way to confirm state management is fully in place.
We see a simple app that doesn’t work correctly when the orientation changes. Jim explains the changes needed for the state to be saved and recreated on change of orientation.
We update onSaveInstanceState to save the state we need. We also update onCreate to check if there is state to restore and invoke a new method restoreStore to do that when needed.
At the end of this lesson, we see the application crashes!
Demo: Manage State of Activity Fields
Jim explains that anything we manage as a class level variable inside of an activity is torn down and recreated.
We see that Android Studio can automatically create a getter for us. We can use this getter to retrieve our state for us.
Demo: Views with Self-Managing State
Jim says some views know how to persist state on their own! He chooses a third radio button in a radio button list, and its state is remembered when the orientation changes.
Zombie Code Kill 