Overview
The Android operating system is based on a Linux kernel and some of your existing knowledge of Linux may be transferable. If you really want to you can try to write application in C and compile them manually...
On the other hand, app development on Android typically makes use of a constrained version of Java and a fairly rigidly-defined framework. This framework insulates the developer from needing to know very much about the underlying operating system, and the use of the standard Android Studio integrated development environment (IDE) makes life even easier.
This is the approach we will be taking in this module, but first a quick overview of the anatomy of an Android app.
Four main building blocks
An Android app is a loosely-connected set of components. The components are designed to work together, but they may also consume data from other apps and can trigger behaviour in other apps too. The notion of an app in the Android environment is not as fixed as it is on other platforms. Table 1 defines the four main building blocks.
Component | Description |
---|---|
Activities | An activity more or less corresponds to a screen in your app. It provides an interface for the user to communicate with the underlying code. Only one activity can be in focus at any one time - it is the one that the user normally thinks of as running, ie the one currently occupying the screen. |
Services | A service is code with no user interface. It performs some kind of background task and may send data to an activity so that it is visible to the user. Services provide an elegant way of coping with asynchronous tasks such as network calls that would otherwise block the user interface. |
Content providers | Content providers are a layer of abstraction around structured data sources such as databases, contact lists, dictionaries, etc. They make the data in one app or process available to other apps |
Broadcast receivers | Code that listens for a particular event such as low battery or incoming SMS and sends a signal to some other component - typically a service. |
Implicit in the descriptions in Table 1 is the idea of messages that are sent from one component to another. For example, a service might send some data to an activity or a broadcast receiver might signal a service to start. In the Android environment, these messages are called intents. An intent is raised by one component, and in order to receive it, another component must declare an interest by filtering that particular type of intent out of the cloud of intents being produced by all the other apps running at the time.
The place where all of the information about an app's components comes together is a special file called the manifest. This file lists the main components and also defines the intents that each component is interested in. This basic structure is illustrated in Figure 1.
Android app overview
The remaining pages in this set of notes provide some additional summary information about certain aspects of the Android environment and also provide links to external tutorials and sources of information. You should aim to read these notes and follow up on the external links as appropriate. As you start to become familiar with the Android environment, you should aim to build up your own set of bookmarks to useful sources of information.
In the spirit of learning by doing, you can jump straight into this week's practical exercise and you will still be able to complete it and learn quite a lot about the Android environment without too much preparation. Like the other topics in this module, however, studying some of the background to the practical exercises will enable you to make better choices for your own apps.