Android application structure

An Android application is very different in its internal structure when compared to applications on other platforms, in even the simplest details. Most platforms see their applications as monolithic systems with a fixed entry point. When the entry point returns or exits, the platform assumes that the application has finished running. On Android, an application may have several different entry points for the user, and others for the system. Each entry point has a different type, and different ways for the system to reach it (called intent filters). The most important part of an application from the user perspective is its activities. These (as the name suggests) are supposed to represent an action that the user will take with the application, such as the following:

• List my emails
• Compose an email
• Edit a contact

Each Activity is a non-abstract class extending the Activity class (or any descendant of Activity), and registers itself and its intent filters in the application manifest file. Here's an example of how the manifest entry for an Activity that can view and edit contacts might look:

<activity android:name=".ContactActivity">
 <intent-filter>
   <!-- Appear in the launcher screen as the main entry point of the application -->
   <action android:name="android.intent.action.MAIN" />
   <category android:name="android.intent.category.LAUNCHER" />
 </intent-filter>
 <intent-filter>
   <!-- Handle requests to VIEW Uris with a mime-type of 'data/contact' -->
   <action android:name="android.intent.action.VIEW" />
   <data android:mimeType="data/contact"/>
 </intent-filter>
 <intent-filter>
   <!-- Handle requests to EDIT Uris with a mime-type of 'data/contact' -->
   <action android:name="android.intent.action.EDIT" />
   <data android:mimeType="data/contact"/>
 </intent-filter>
</activity>

The application manifest file (always named as AndroidManifest.xml) is how the Android system knows what components your application has, and how to reach each of them. It also contains information such as the permissions your application will need from the user, and which versions of the Android system the application will run on.

Each Activity is typically intended to do a single thing from the user's perspective, but this is not always the case. In the preceding case, there are three possible intent filters, each of which telling the system something different about the ContactActivity class:

• The first one tells the system that ContactActivity should have its icon displayed on the launcher screens, effectively making it the main entry point of the application
• The second tells the system that ContactActivity can be used to VIEW content with a mime-type of "data/contact"
• The third tells the system that ContactActivity can also be used to EDIT content with the "data/contact" mime-type

The system resolves Activity classes through Intents. Each Intent specifies how and what the application would like to do on behalf of the user, and the system uses the information to find a matching intent-filter somewhere in the system. However, you won't typically add intent-filters to all of your Activity entries; you'll launch most by specifying the class directly within your application. Intent-filters are normally used to implement abstract inter-application interactions for example, when an application needs to "open a web page for browsing," the system can automatically launch the user's preferred web browser.

An Activity will generally have a primary layout file defined as an XML resource. These layout resource files are generally not standalone, but will make use of other resources and even other layout files.

Keep your activities simple! Avoid loading too much behavior into a single Activity class, and try and keep it bound to a single layout (and its variants, such as "landscape"). At worst, allow multiple behaviors with common layout widgets (for example, a single Activity to view, or edit a single contact). We'll go through some techniques for this in Chapter 4, Composing User Interfaces.

The resource system in Android needs some special attention, as it allows for multiple files to collaborate together to create complex behavior out of simple components. At its heart, the resource system selects the most appropriate of each resource when it is requested (including from inside other resources). This not only allows you to create screen layouts for portrait and landscape mode, but allows you to do the same for dimensions, text, colors, or any other resource. Consider the following example:

<!-- res/values/dimens.xml -->
<dimen name="grid_spacer1">8dp</dimen>

The above dimension resource can now be used in layout resource files by name:

<!-- res/layouts/my_layout.xml -->
<LinearLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:layout_margin="@dimen/grid_spacer1">

Using this sort of technique, you can adjust layouts for different screen sizes by simply changing the distance measurements used to space and size the widgets, rather than having to define completely new screen layouts.

It's a good idea to try and be generic with resources such as dimensions and colors. This will help keep your user interface consistent for your users.
Consistent user interfaces are often more important than trying to innovate. The less mental effort your user needs to understand your application, the more they can engage with it.