Android 6: Activities

1. Android 6: Activities Kirk Scott

5. 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 • For lack of a better alternative, Activities, the word describing a central concept in the unit, was chosen

6. 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 of Android development • The overheads then take up another example app from the tutorials

7. Parts of the new example will repeat the basics • Parts of the new example will also include and illustrate the new, higher level concepts • This is a repetitive, cyclical approach rather than an everything at once approach

8. It also turns out that some of the important concepts talked about in this unit do not appear in the example • What you get now is an introduction to those concepts • Examples applying them will come in later units

9. This is a list of the sections in this set of overheads: • 6.1 Overview • 6.2 Contexts • 6.3 Activities • 6.4 Fragments (we won’t use this yet) • 6.5 Intents • 6.6 Services (we won’t use this yet) • 6.7 The Android Manifest File • 6.8 The Example

10. 6.1 Overview

11. This overview section shows a UML diagram of certain classes in the Android API • This is followed by snippets taken from the Android API documentation for the important classes included in the diagram • The following sections of the unit expand on this and explain in greater detail

12. The UML diagram on the following overhead includes certain key classes • The classes ContextWrapperand ContextThemeWrapper are part of the diagram because they are part of the inheritance hierarchy, but their contents are of no interest • The diagram also includes MainActivity, a class provided by a programmer, not by the Android API

14. These are the classes of interest in the diagram: • Context • Activity • Fragment • Intent • Service • Application • Bundle • MainActivity

15. The following overheads contain the Class Overview (or the beginning of the Class Overview) documentation for the classes of interest in the Android API • A few comments are inserted for some of the classes

16. It won’t be possible to understand everything in the API documentation • Vocabulary and ideas will be introduced • Explanations will follow in the succeeding sections

17. The Context Class • Interface to global information about an application environment. • This is an abstract class whose implementation is provided by the Android system. • It allows access to application-specific resources and classes, as well as up-calls for application-level operations such as launching activities, broadcasting and receiving intents, etc.

18. The Activity Class • An activity is a single, focused thing that the user can do. • Almost all activities interact with the user, so the Activity class takes care of creating a window for you in which you can place your UI with setContentView(View). • While activities are often presented to the user as full-screen windows, they can also be used in other ways: as floating windows (via a theme with windowIsFloating set) or embedded inside of another activity (using ActivityGroup).

19. There are two methods almost all subclasses of Activity will implement: • onCreate(Bundle) is where you initialize your activity. • Most importantly, here you will usually call setContentView(int) with a layout resource defining your UI, and using findViewById(int) to retrieve the widgets in that UI that you need to interact with programmatically.

20. onPause() is where you deal with the user leaving your activity. • Most importantly, any changes made by the user should at this point be committed (usually to the ContentProvider holding the data). • To be of use with Context.startActivity(), all activity classes must have a corresponding <activity> declaration in their package's AndroidManifest.xml.

21. The Fragment Class • A Fragment is a piece of an application's user interface or behavior that can be placed in an Activity. • Interaction with fragments is done through FragmentManager, which can be obtained via Activity.getFragmentManager() and Fragment.getFragmentManager().

22. The Fragment class can be used many ways to achieve a wide variety of results. • In its core, it represents a particular operation or interface that is running within a larger Activity. • A Fragment is closely tied to the Activity it is in, and can not be used apart from one.

23. Though Fragment defines its own lifecycle, that lifecycle is dependent on its activity: • if the activity is stopped, no fragments inside of it can be started; • when the activity is destroyed, all fragments will be destroyed.

24. All subclasses of Fragment must include a public empty constructor. • The framework will often re-instantiate a fragment class when needed, in particular during state restore, and needs to be able to find this constructor to instantiate it. • If the empty constructor is not available, a runtime exception will occur in some cases during state restore.

25. The Intent Class • An intent is an abstract description of an operation to be performed. • It can be used with startActivity to launch an Activity, broadcastIntent to send it to any interested BroadcastReceiver components, and startService(Intent) or bindService(Intent, ServiceConnection, int) to communicate with a background Service.

26. An Intent provides a facility for performing late runtime binding between the code in different applications. • Its most significant use is in the launching of activities, where it can be thought of as the glue between activities. • It is basically a passive data structure holding an abstract description of an action to be performed.

27. The Service Class • A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use. • Each service class must have a corresponding <service> declaration in its package's AndroidManifest.xml. • Services can be started with Context.startService() and Context.bindService().

28. Note that services, like other application objects, run in the main thread of their hosting process. • This means that, if your service is going to do any CPU intensive (such as MP3 playback) or blocking (such as networking) operations, it should spawn its own thread in which to do that work. • More information on this can be found in Processes and Threads. • The IntentService class is available as a standard implementation of Service that has its own thread where it schedules its work to be done.

29. The Application Class • Base class for those who need to maintain global application state. • You can provide your own implementation by specifying its name in your AndroidManifest.xml's <application> tag, which will cause that class to be instantiated for you when the process for your application/package is created. • [Comment: This is the class named Application, which holds the state of an application. But an application is an instance of the Activity class, not an instance of the Application class.]

30. The Bundle Class • A mapping from String values to various Parcelable types. • [Comment: This documentation is pretty mininal. The Bundle class is a container for holding and passing around information about activities. Not surprisingly, you won’t find the word “parcelable” in your average dictionary.]

31. The MainActivity Class • [All commentary…] • This is the class written by programmers when they are making an app • The MainActivity class extends Activity • At a fundamental level, an app is an activity

32. Activity is a subclass of Context • So also at a fundamental level, an app is also a context • The app overall can serve as a context containing multiple activities • These activities, in turn, can contain multiple fragments • (More boxes within boxes)

33. 6.2 Contexts

34. Any Android app has a context, but in simple apps the context may not appear explicitly in the code • As noted, in fact, an app is a context • 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

35. 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

36. 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

37. Contexts and Activities • An app is a context • But an app is also an activity • 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

38. 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

39. The Activity class is a subclass of the Context class • That means that for any given app, its context will actually come into existence as an instance of the Activity class • It also means that every activity is a context, and as such, can contain other activities • Again, this is a case of boxes within boxes

40. We have seen example apps with a single activity • When MyEchoAppis run, for example, MainActivity is brought into existence • Due to the inheritance hierarchy, MainActivity is both an Activity and a Context • At the end of this unit, a new example will be given which contains multiple activities

41. Making Use of 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

42. Within a piece of code it is possible to acquire a reference to the context of the current process • This is sort of a “Who am I?” type call with respect to context • This call on the implicit parameter that could appear in the code for ActivityMain.java, would retrieve the app context: • Context myContext = getApplicationContext();

43. These are some of the things 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

44. Typically, you don’t have to execute the previous “Who am I?” call • MainActivity is a subclass of Context, so you can call context methods directly on the implicit parameter in the code for MainActivity • These are some of the context methods: • getResources() • getSharedPreferences() • getAssets()

45. Using getResources() • Defining a view in a layout results in an id in R.java • In earlier examples we saw that you can acquire a handle on such a resource • This is an example of such a call: • TextView cup = (TextView) findViewById(R.id.textView1);

46. Defining a String resource in strings.xml also results in a string definition in R.java • You can access a resource like this through the context by calling getResources() and calling a method on that • Here is an example of such a call • String greeting = getResources().getString(R.string.hello); • Notice that this doesn’t return an id, it returns an actual string • This allows you to directly access the String “Hello World”, which belongs to the app and is defined in strings.xml, in the code for your app

47. Summary of Contexts • The context of an app is the broadest container for the components of an app • You may call getApplicationContext() and get a direct reference to the context, or you may call methods like getResources() directly on the implicit parameter of an app • Either way, in the body of the code, you can then call additional methods which will return components of the app

48. 6.3 Activities • Activities are the basic building blocks of apps • If the context denotes a container, then an activity denotes function • Activities can be further subdivided into fragments

49. Screens and Activities • Apps more complicated than the examples given so far can have multiple screens • A simple multiple screen app can be coded by having a different activity for each screen • The Darceyand Conderbook provides a small example that illustrates this idea, which will be presetned on the following overheads

50. Consider a game which consists of the following screens: • Startup or splash • Main menu • Game play • High scores • Help/about