Channels ▼

Al Williams

Dr. Dobb's Bloggers

At Your (Android) Service

September 18, 2014

Last time I talked about the Android manifest. If you haven't run into an Android program before, some of it might have seemed a little strange. Even though Android is essentially Java running on Linux, it has some different ideas about what constitutes a program.

The Android system is made for phones and tablets along with other tightly embedded systems. Because of these constraints, the operating system handles memory a bit differently and also how programs work.

Consider a program in Linux. You'd expect it to get kicked off by the operating system. The program might register for some events and spend a lot of time doing very little. But whether it has no windows, one window, or dozens of windows is usually of no interest to anyone else. Granted, some programs expose services using something like Dbus, but there's no obligation to do so.

Most GUI-based programming on Android centers on Activities. These correspond to user actions, and Android expects you to expose each one of them for other programs to use (to promote memory efficiency). For example, an RSS news reader might have an activity to select feeds, another to browse them, another to read news items, and an activity to set options.

If you don't have a GUI, then you are probably more interested in a service. Sometimes a service and a GUI work together. For example, you might have a service to read a sensor from a remote device, but an Activity to display the results in a graph over time.

Because Android separates programs into separate users (I mentioned that last time), it is difficult for a program with data it wants to share to allow others to access it. That's the purpose of the Content Provider — if other programs might use the sensor data collected by the service, you'd provide a Content Provider. This is effectively a database that other programs can access.

Another important component of some Android apps is the Broadcast Receiver. This allows your program to receive broadcast events that may come from the system or other applications. For example, the system might broadcast that the battery is low. A Bluetooth stack might broadcast that a device connected (or disconnected). In the hypothetical sensor application, you might actually broadcast when data is available.

Broadcasts use a sort of service description called an Intent. You also use an Intent object when you want to start another program's component. For example, another program might want your program to display the historical graph. It could send an Intent that it wants your Activity that performs that task to start.

That's key. To the user, the alien program just happens to contain a screen that looks just like yours. What an Android user thinks of as a workflow might be multiple programs. For a phone-centric example, consider a user that wants to send an e-mail containing a picture. She might start with the e-mail program's main activity and click a button to start the compose activity (still part of the e-mail program). In the To box, she clicks a button that starts the contact application, allowing a selection of recipient. Once that's done, another click in the e-mail program's compose activity starts a camera activity and returns the picture to the e-mail program, which can then send the e-mail.

As far as the user knows, the e-mail program just has a contact list and a camera, but the reality is it only asks for those services. If the user installs a different contact list manager or camera, the e-mail program will start using those instead of the original ones.

Starting another activity uses the startActivity() call or the startActivityForResult() call (if you want a result like an e-mail address or picture). Programs can also start services (startService()), call query() on content providers, and use sendBroadcast() (along with several variants) to send broadcast messages.

There is one other interesting component type you don't hear as much about in Android programming. That component is the Application. The Application component has members you can override to respond to low memory conditions, to react to configuration changes, and to get an early call as the program starts (sort of like a main function). You can also store data in it that you might need across components (for example, between different activities or services).

As you might expect, each of these components have a base class in the Android libraries. If you notice in the listings I posted from the first of these posts on Android Studio, the main class in DrDobbsBrowser.java derives from Activity:

public class DrDobbsViewer extends Activity {

If you are using Android Studio, and you need a reminder about the Activity class, put your cursor on the word "Activity", and press Control+Q (see Figure below). The same trick works for your own classes and members, with the corresponding documentation from the parent class appearing if you didn't provide any.

It is possible to write Android applications that use all the component types I mentioned. Like my example (so far), it is also possible to write an application that uses only one component. Android Studio pretty much assumes your new project will have at least one activity (and gives you many choices like tabbed activities, full screen, etc.). However, you can start with no activity if you are writing something that is purely non-activity based or you prefer to roll your own from scratch.

I'll keep looking at Android and Android Studio in the weeks ahead. Keep in mind that even if you don't have an Android device, Studio can run and debug code on an emulator, so it is easy to get started writing Android code — at least until you want to interact with real world I/O devices.

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.