Android 5 : Activities

Android 5: Activities Kirk Scott

Introduction • The title of this set of overheads is something of a misnomer • It is not easy to encompass the contents of the unit in a single word, so for lack of a better alternative, the word describing a central concept was chosen

This set of overheads covers more background on the overall structure of Android apps • The earlier examples were very simple and focused on the basic nuts and bolts • The new background includes higher level concepts

The overheads then take up another example app from the tutorials • This is a repetitive, cyclical approach rather than an everything at once approach • Parts of the new example will repeat the basics • The new example will also include and illustrate the new, higher level concepts

This is a list of the sections of this set of overheads: • 5.1 Contexts • 5.2 Activities • 5.3 Fragments • 5.4 Intents • 5.5 Services • 5.6 The Android Manifest File • 5.7 The Third Example

5.1 Contexts

The Android API contains a class named Context, android.content.Context • Any Android app does have a context, but in simple apps the context may not appear explicitly in the code • In a very broad and non-technical sense, an app’s context is the container, or access point for all of the “things” that belong to that app

The “things” accessible through the context include resources belonging to the app, like files or allocated devices • The “things” also include services which the app makes use of • Services will be discussed further in a subsequent section

For the time being, if you recall the boxes within boxes development analogy for programming, you can think of the context as being the biggest of the boxes containing components related to an app

Contexts and Activities • There is also one more thing to understand about the context up front—which also depends on something which hasn’t been fully discussed yet • In the hierarchy of Android classes, there is an Activity class • The Activity class is the topic of the next section • In a certain sense, the idea of an activity is the basic building block of all apps—that’s why it’s the title for these overheads

A key idea behind apps is that they can consist of multiple activities • So another way of describing the context is that it is the common container or access point for all of the different activities belonging to a single app

Finally, the Activity class is related to the Context class in the Android API inheritance hierarchy • The Activity class is a subclass of the Context class • That means that for any given app, its context will actually exist as an instance of the Activity class • This works because the subclass “is a kind of” the superclass

We have seen examples with a single activity • When MyEchoAppis run, for example, MainActivity is brought into existence • It is an activity, an instance of a subclass of Context • Because it’s a single activity app, it is its own context • If the app contained other activities, the main activity would also be the context for those other activities

Using the Context in Order to Understand What it is • We don’t need to use the app context yet, but in order to better understand the concept of the context and the overall structure of apps, it’s useful to see how the context can be used • In general, it can be used to acquire information about the app, or handles on things belonging to the app, within the app code itself

In order to use the context, first you have to retrieve a reference to it • Here is a call on the implicit parameter that would appear in the code for ActivityMain.java, which retrieves the app context: • Context myContext = getApplicationContext();

These are some of the things, more specifically, that you can access and manage through the context: • Application resources, such as strings, graphics files, etc. • Other directories and files belonging to the application, including SQLite databases • Application permissions, preferences, and services

Because MainActivity is an instance of a subclass of Context, you can call context methods directly on the implicit parameter • These are some of the methods: • getResources() • getSharedPreferences() • getAssets()

Recall that if you declare a string in strings.xml, successful compilation will result in handle for the string in R.java • Here is an example of acquiring access to an app resource within app code by using a context method: • String greeting = getResources().getString(R.string.hello);

Summary of Contexts • In summary, even though we don’t have a particular practical use for the context yet, it is important to understand the concept: • The context is the central organizing principle underlying app development

5.2 Activities • As already stated, activities are the basic building blocks of apps • From the top-down perspective, the context is central • But from a bottom-up perspective, the activity is central • As we’ll see, there is another layer under activities, fragments, but it is the activity that is regarded as the basic concept, not the fragment

Screens and Activities • Even if you haven’t designed and built multi-screen applications yet, as a user, you’re familiar with applications that transition from one screen to another • An easy initial way to understand how an app may consist of multiple activities is that each screen may be coded as a separate activity

Darcey and Conder provide a small example • Consider a game which consists of the following screens: • Startup or splash • Main menu • Game play • High scores • Help/about • A hierarchy chart of the corresponding activities is shown on the following overhead

Activities are more than just screens in an application • Activities are tied up with the idea of multiprocessing • Multiple applications may be in the run state on a device at a given time • Each application may consist of multiple activities

Out of all of the activities of all of the running applications, only one activity can be in the foreground at a time • This is the activity that’s visible on the screen • Other activities may be in various states in the background, some running, some not • The Android operating system has to manage all of the activities

From operating systems you may be familiar with circularly linked lists for task scheduling • You may also be familiar with the concept that during the execution of a single process, a sequence of method (or subroutine) calls is managed in a stack

Activities are managed using a stack discipline • The new activities are pushed onto the top of the stack • Only the topmost activity can run • The rest have to wait for activities above them to complete and be removed • Activities at the bottom of the stack can be destroyed if there is too much resource contention • A simple diagram of the situation is shown on the following overhead

Again, activities have lifecycles, similar to the way processes or threads have lifecycles • In other words, as the app they belong to runs, or as system resources are claimed, they enter and leave various different states

Transitions occur as the result of calls to methods • The Activity class contains these methods • You might not call the method directly on yourself • These methods tend to be used in callback sequences

Remember examples of this: • You call repaint(), which is inherited, and it calls paintComponent(), which you implemented • Or, something happens in the user interface, causing a method in a listener in your code to be called, like mouseClicked() • You may inherit the default implementations of the methods of interest, and you may override them

This is a list of the most significant of the lifecycle methods in the Activity class: • onCreate(Bundle savedInstanceState) • onStart() • onRestart() • onResume() • onPause() • onStop() • onDestroy()

The potential changes in an activity’s lifecycle can be shown in a diagram reminiscent of a state transition diagram • Such a diagram is shown on the following overhead

Activity lifecycles become important in multiple activity apps, and become even more important in environments where multiple apps are running concurrently • Eventually it may become necessary to write code to handle particular transitions gracefully

It is too soon to be concerned with the details, but one additional aspect of this can be mentioned now • Note that the onCreate() method takes a parameter • The type of the parameter is Bundle • The Bundle class is designed to hold the state of an activity

If an activity is being created for the first time, the Bundle parameter can be null • A class that extends Activity can implement (override) the onSaveInstanceState() method • When the system kills an activity, it can call this method and save the custom state into an instance of Bundle

Killing an activity is not as drastic as destroying it • Lazarus-like, a killed activity can be brought back to life with a call to onCreate() • In this case, the Bundle containing the state saved when it was killed is passed in as a parameter

5.3 Fragments • In early versions of Android, it was usually the case that one activity corresponded to one screen in the app • This is a straightforward way of dealing consistently with a world consisting of devices with small screens • However, with the advent of tablets, TV’s, and other devices in the Android world, a different model became useful

The general idea is this: • A fragment is a part of the functionality associated with a screen or part of the user interface • A fragment has to be associated with an activity • But a fragment can be associated with different activities at different times

This model makes the following possible, for example: • On a device with a small display, there is an activity which manages multiple screens, each screen with one fragment on it • On a device with s large display, there may be fewer separate screens, or even just one screen • The screen has an activity, and that activity has many different fragments on it

The design idea is illustrated on the following overhead using a music app as an example • The upper part of the figure shows how you might traverse four screens on a device with a small display • The lower figure shows how it might be convenient to just include all of the fragments on one screen with a large display

The fragment idea is encapsulated in the Fragment class in the Android API, android.app.Fragment

5.4 Intents • There is another class in the Android API, the Intent class, android.content.Intent • Intents are a critical element of the structure of a multiple-activity app • Intents are the mechanism used for transitioning between one activity and another

Certain kinds of transitions may be manageable with direct calls in one activity to start or stop another activity • In simple cases, the programmer can code calls to startActivity() and finish(), for example • A slightly more complicated version of this approach would involve calls to startActivityForResult() and onActivityResult()

However, the most flexible way to transition between activities is with intents • If you’ve had operating systems, you may see some similarities between intents and the concept of message passing • In general, you can describe the use of intents as asynchronous rather than synchronous

In other words, the use of the intent mechanism is a request to the Android system to start an activity • It is not a direct call of a method on that activity • This supports the fact that various activities are currently in existence, in various states, on the stack

Not only do intents support this form of activity management • Their flexibility comes from some additional features: • An intent may in effect be a broadcast message • In other words, it may be a request that could be satisfied by more than one activity, and the Android system can select one of several to satisfy it

An intent can also be structured as a request that can be satisfied by an activity belonging to another app • In other words, in an asynchronous way, it can be something similar to a remote procedure call • The topic of services hasn’t been covered yet, but an intent can also be structured as a request to a service provider

Android 5 : Activities