MAP524/DPS924 Lecture 3

Android Development Building Blocks (Components)

This week we're looking at the primary components used for building an Android app. We're finally starting to write code. But first we'll need an overview of:

• Application Manifest: XML based file that the application outlines the activities, services, broadcast receivers, data providers and permissions that make up the complete application. Used to also hold some information that's now in build.gradle.
• Activity: see below.
• Intent: a messaging object you can use to request an action from another app component. One of the primary ways to do IPC on Android. See overview on Android developers.
• Broadcast Receiver: Enable applications to receive intents that are broadcast by the system or by other applications. See ths BroadcastReceiver tutorial.
• Service: 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. We'll also look at them more closely after the break.
• Event handling: See this nice Android Event Handling tutorial
  • Event Listener: a class specialized that contains a single callback method.
  • Event Handler: the actual method that handles the event.
  • Easiest way (if available) is to register the event handler via the layout xml file.
• Layout: We'll look at several types of layouts in detail next week.
• Fragment: created using an XML layout file that looks like a sub-layout and behaves like a sub-activity. We'll look at fragments next week.
• Content Provider: One way for an application to provide access to data it holds. It's one form of IPC usually used for more standard types of data. See a list of tutorials at the bottom of this page. We'll also look at them more closely after the break.
• Menu: Used to be a critical part of any android application until the menu button's been removed from Android tablets and later phones. Now is still used but isn't as prevalent.
• Resource: an additional file and static content that your code uses, such as bitmaps, layout definitions, user interface strings, animation instructions, and more.
• Notification: a news channel that alerts the user to important events as they happen or a log that chronicles events while the user is not paying attention. See the developer guide.
• Settings and Shared Preferences: display (Settings) and store (Shared Preferences) simple configuration data (strings, numbers) for your application.
• R.java: A dynamically-generated class named R containing references to resources.

Activity

An actifity is kind of like a screen, and kind of like an application, but is actually something in between. Every application with a user interface needs at least one activity that will display the layout for one screen.

Then an application may choose to start more activities. The following diagram is the reason for many, many crashes of apps on the Android Market because it's so complicated:

Because Android tries to save as much battery power as possible - it puts applications to sleep all the time, and sometimes even kills them alltogether.

Making sure that your user experience is still nice despite that you need to navigate the diagram above to figure out when to load, unload, save, reload both data and the state of the UI.

IDs

IDs are used as a way to connect the elements defined in XML with your java source code. In XML for nearly every element you can specify an "id" attribute. For exmaple:

<Button android:id="@+id/my_button"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/my_button_text"/>

You will rarely if ever change the "@+id/" prefix, but after the slash you can set whatever ID you like. Normally you want something that will describe what that element is and does, for example "sendEmailNowBtn". Otherwise your code will be harder to read ("what my_button, they're all my buttons).

To get a reference to the button in your Java code you use findViewById() with a cast. In this example:

Button myButton = (Button) findViewById(R.id.my_button);

findViewById looks up the element by ID (my_button). Remember the R class is automatically generated based on your XML files.

The return is a View, but we know it's a button so we'll cast it to Button. Without a case you'd only be able to use te View methods on the button. Button is obviously a subclass of View.