SE4S701 Mobile Application Development The Android App Lifecycle It’s not just start and stop..... User Interface Controls Palette: Spinners, Pickers, Toasts, Buttons,... Non-Palette: Dialogs, Menus, Notifications

Lifecycle Basics Each App runs in its own process. Each activity of an App is run in the App’s process. Processes are started and stopped as needed to run an apps components. Processes may be killed to reclaim needed resources. Killed Apps may be restored to their last state when requested by the user Process 1 Process 2 Process 3 Process 4 App 1 Activity 1 Activity 2 Activity 3 App 2 Activity 1 Activity 2 Activity 3 App 3 Activity 1 Activity 2 Activity 3 App 4 Activity 1 Activity 2 Activity 3 running stopped killed restored Source: http://developer.android.com/training/basics/activity-lifecycle/index.html

Management Most management of the life cycle is done automatically by the system via the Activity Stack. The Activity class has the following method callbacks to help you manage the App: onCreate() onStart() onResume() onPause() onStop() onRestart() onDestroy() You @Override these method inherited from: AppCompatActivity.Java, which inherited them from: FragmentActivity.java, which inherited them from: Activity.java

OO Recap: ‘Overriding’ et al. Overriding vs. Overloading vs. Polymorphism Overriding A method of a super class (parent) is overridden when it is re-written in the sub-class (child) using the same formal parameter list and return type. Overloading Several methods in the same class have the same name but different formal parameter lists or return type. Polymorphism Several methods in different classes have identical formal parameter lists and return types but do different (but equivalent) things.

Management In Code, for example: Why? In Code, for example: If not overriden, the inherited behaviour is applied (i.e. the default) @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // always call superclass first setContentView(R.layout.activity_main); btnNext=(Button)findViewById(R.id.btnNext); btnNext.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { Intent intent=new Intent(MainActivity.this, Main2Activity.class); startActivity(intent); } }); } @Override protected void onStop() { // What to do when App stopped }

‘Override’ in Code In previous versions of Android just ’Activity’ public class MainActivity extends AppCompatActivity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // The activity is being created. } protected void onStart() { super.onStart(); // The activity is about to become visible. protected void onResume() { super.onResume(); // The activity has become visible (it is now "resumed"). protected void onPause() { super.onPause(); // Another activity is taking focus (this activity is about to be "paused"). protected void onStop() { super.onStop(); // The activity is no longer visible (it is now "stopped") protected void onDestroy() { super.onDestroy(); // The activity is about to be destroyed. } In previous versions of Android just ’Activity’

Lifecycle: Overview A simplified illustration of the Activity lifecycle Depending on the complexity of your App, you may not need to implement all of the lifecycle methods.  onWhatever() App states Transitions

onCreate() Called when the Activity is first created. This is where you should do all of your normal static set up — create views, bind data to lists, etc. This method is passed a Bundle object containing the Activity's previous state, if that state was captured (see Saving Activity State, later). Always followed by onStart().

onStart() Called just before the Activity becomes visible to the user. Followed by onResume() if the Activity comes to the foreground, or onStop() if it becomes hidden.

onStart() Example Starting your application Typically will restore connections to sensors that live beyond a pause but not when the application is hidden And this? What was that again? @Override protected void onStart() {     super.onStart();  // Always call the superclass method first         // The activity is either being restarted or started for the first time     // so this is where we should make sure that GPS is enabled     LocationManager locationManager =             (LocationManager) getSystemService(Context.LOCATION_SERVICE);     boolean gpsEnabled = locationManager.isProviderEnabled(LocationManager.GPS_PROVIDER);         if (!gpsEnabled) {         // Create a dialog here that requests the user to enable GPS, and use an intent         // with the android.provider.Settings.ACTION_LOCATION_SOURCE_SETTINGS action         // to take the user to the Settings screen to enable GPS when they click "OK"     } }

onResume() Called just before the Activity starts interacting with the user. At this point the Activity is at the top of the Activity stack, with user input going to it. Always preceded by onPause().

onPause() Called when the system is about to start resuming another Activity. This method is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU time, and so on. It should do whatever it does very quickly, because the next Activity will not be resumed until onPause() returns. Followed either by onResume() if the activity returns back to the front, or by onStop() if it becomes invisible to the user.

onPause() – onResume() Example Pause callback @Override public void onPause() { super.onPause(); // Always call the superclass method first // Release the Camera because we don't need it when paused // and other activities might need to use it. if (mCamera != null) { mCamera.release() mCamera = null; } } @Override public void onResume() { super.onResume(); // Always call the superclass method first // Get the Camera instance as the activity // achieves full user focus if (mCamera == null) { // Local method to handle camera init initialiseCamera(); } } Resume callback

Callback? What’s that? Generally: any executable code that is passed as an argument to other code, which is expected to call back (execute) the argument at a given time. Application Program { Function 1 { // stuff } Function 2 { Call of an Android System Function Callback Function { Android does its bit and eventually calls the Callback Function

Callback? C Example #include <stdio.h> #include <stdlib.h> /* The calling function takes a single callback as a parameter. */ void PrintTwoNumbers(int (*numberSource)(void)) { printf("%d and %d\n", numberSource(), numberSource()); } /* A possible callback */ int overNineThousand(void) { return (rand()%1000) + 9001; /* Another possible callback. */ int meaningOfLife(void) { return 42; /* Here we call PrintTwoNumbers() with three different callbacks. */ int main(void) { PrintTwoNumbers(&rand); PrintTwoNumbers(&overNineThousand); PrintTwoNumbers(&meaningOfLife); return 0;

onStop() Called when the Activity is no longer visible to the user. This may happen because it is being destroyed, or because another Activity (either an existing one or a new one) has been resumed and is covering it. Followed either by onRestart() if the Activity is coming back to interact with the user, or by onDestroy() if this Activity is going away.

Saving App State onStop() As the system begins to stop your Activity, it calls onSaveInstanceState() so you can specify additional state data you'd like to save in case the Activity instance must be recreated. If the Activity is destroyed and the same instance must be recreated, the system passes the state data defined at (1) to both the onCreate() method (2) and the onRestoreInstanceState() method (3).

onRestart() Called after the Activity has been stopped, just prior to it being started again. Always followed by onStart()

onDestroy() Called before the Activity is destroyed. This is the final call that the Activity will receive. It could be called either because the Activity is finishing (someone called finish() on it), or because the system is temporarily destroying this instance of the Activity to save space. You can distinguish between these two scenarios with the isFinishing() method.

The Entire Lifetime onCreate() setup of the global state such as defining layout onDestroy() release all remaining resources For example: If your activity has a thread running in the background to download data from the network, it might create that thread in onCreate() and then stop the thread in onDestroy().

The Foreground Lifetime During this time, the Activity is in front of all other Activities on screen and has user input focus. An Activity can frequently transition in and out of the foreground. For example: onPause() is called when the device goes to sleep or when a dialog appears. Because this state can transition often, the code in these two methods should be fairly lightweight in order to avoid slow transitions that make the user wait.

The Visible Lifetime During this time, the user can see the Activity on-screen and interact with it. For example, onStop() is called when a new Activity starts and this one is no longer visible. Between these two methods, you can maintain resources that are needed to show the Activity to the user. For example, you can register a BroadcastReceiver in onStart() to monitor changes that impact your UI, and unregister it in onStop() when the user can no longer see what you are displaying. The system might call onStart() and onStop() multiple times during the entire lifetime of the Activity, as the Activity alternates between being visible and hidden to the user.

The Road to Application Death Once your application is not the focal form it can be killed onPause() onStop() onDestroy() These paths require the user to re-launch the application Becomes more likely further down the structure Less likely on phones with more resources

SE4S701 Mobile Application Development The Android App Lifecycle It’s not just start and stop..... User Interface Controls Palette: Spinners, Pickers, Toasts, Buttons,... Non-Palette: Dialogs, Menus, Notifications

UI Controls (API 23 Palette – earlier API have fewer and/or other Controls) = covered in labs/lectures =today’s lab

UI Controls (non- ‘Palette’ Controls) Today Toast pop-up message: Labs of next 2 weeks Alert Dialog Notification Options Menu

END OF LECTURE