An Android application (the Android project that makes up an Android application) consists primarily of Activity and Service classes and also an xml manifest. In addition, the project contains a ‘res’ (resources) folder which consists of the images (‘res/drawable’), views (‘res/layout’) and strings/styles/colors/arrays/etc (‘res/values’) used within the application and a ‘gen’ folder that contains a static (auto-generated) R class providing design time access to the resources in the ‘res’ folder. We describe below the manifest, and then the Activity and Service components.
Application Manifest
An application’s manifest is an xml file defining the structure and metadata of the application and its components, i.e. its activities and services. The manifest contains only one ‘application’ node which acts as a container to specify the application’s components (i.e. ‘activity’ and ‘service’ nodes). A component must be registered in the manifest in order to be used in the application.
Activity
An activity represents a screen and is the base class for the application’s visual, interactive components. Every screen in an application will extend the Activity class.
When a new Activity starts during the running of an application, the current foreground screen is moved to the top of the ‘Activity stack’. If the user navigates back using the back button, or the foreground Activity is closed, the next Activity on the stack moves up and becomes active.
Android provides a series of event handlers that are fired and for the programmer to take care of an Activity’s transitioning through its different possible lifetimes (‘full’, ‘visible’, ‘active’) and states within those lifetimes (‘active’, ‘paused’, ‘stopped’, ‘inactive’), e.g. onCreate(Bundle), onRestoreInstanceState(Bundle), onStart(), onRestart(), onResume(), onSaveInstanceState(Bundle), onPause(), onStop(), onDestroy(). These methods are to be overridden by the programmer to perform the tasks desired of the activity as it passes through its different lifetimes/states.
Some of the key user interface classes that an activity will make use of are as follows:
- View: An Activity uses a View to form a graphical user interface that displays information and responds to user actions. It is the visual component (layout) of an activity and may itself consist of (sub-) views as well as controls/widgets. Views can be defined in code but preferably are defined in xml and stored in the project’s ‘res’ folder. In the latter case, the user interface elements within the view’s definition are given identifier attributes to get access to them in code (via the R class).
- Menu: Each activity can specify its own Activity menu that’s displayed when the device’s menu button is pressed. A Menu as such offers a way to expose additional functions of an Activity without sacrificing screen space. To define a menu for an Activity, the Activity’s onCreateOptionsMenu(Menu) method is overridden. This method is triggered the first time an Activity’s menu is displayed.
- Dialogs: A Dialog is a floating window that is constructed entirely within an Activity and which partially obscures from view the Activity that launched it.
Another key class that an Activity will make use of is an Intent, which is used for the transitioning between Activities. It is a message-passing mechanism that declares the intent for an action to be performed. Whilst not the only use for Intents, the most common use is indeed to start, stop and transition between the Activities within an application. The startActivity(Intent) method of the Activity class is used for this purpose and the Intent passed in either explicitly specifies the class to open or includes an action that the target should perform. An Activity started in this way is independent of its parent and will not provide any feedback when it closes. The startActivityForResult(Intent, int) method of the Activity class is an alternative method to start a sub-activity which is inherently connected to its parent.
Service
Services are the invisible workers of an application. Service components perform tasks that run in the background and which do not require a user interface, such as updating data sources and visible Activities, and triggering notifications. They’re used to perform regular processing that needs to continue even when an application’s Activities aren’t active or visible.
(Essay written as a tw hour timed test for the boss at work. Didn’t get time to look at: Bundles, Contexts, Content Providers; Broadcast Receivers; Data Storage, Retrieval and Sharing; Maps etc)
