Android Fundamentals: Picking App Components

When you're new to a platform, deciding what components to use to build a solution can be challenging. There are often many ways to solve a problem or design a solution. Some methods may be easier on a particular platform while other methods may be more familiar to you.

In this series, we will start with a simple concept for an application. The application itself is not unlike something a hobbyist or researcher might want to build. Readers will likely find some of the application components familiar while other components will be new.

Step 0: Getting Started

This tutorial assumes you have a basic understanding of Android and Java, that you have all of the Android tools installed and working, and that you are comfortable with loading and testing applications on an Android device. We'll be using the barometer hardware sensor in this application. If you don't have a device with this sensor, you can substitute with another, similar sensor, for testing purposes, but the results or usefulness may not be equivalent.

Step 1: Application Concept

Data logging is a common task in field research. It's not uncommon to wish to log climate data, such as temperature, humidity, or pressure data for further study. So, that's what this application will do.

In short, the application will:

Regularly check the pressure sensor
Record the data to some sort of persistent storage
Provide a means to display historical data
Share the data externally somehow

Let's look at each more closely and what Android components we will use to achieve these application features.

Step 2: Using Sensors

Most Android devices have at least some hardware sensors. Some devices have a barometer, so we'll start by using that sensor. To monitor device sensors, we'll need to use the SensorManager class.

We obviously don't want the application running in the foreground the entire time we're logging, especially since we may only grab the data once an hour or so. Therefore, we'll use an Android service and background processing to check the sensor and store the data on a regular schedule.

Step 3: Persistent Storage

A hobbyist might be inclined to simply write lines of data to a text file using regular Java file APIs, put the file on the SD card, and read it on a computer. While that is certainly feasible, there are better methods on Android, especially when it comes to displaying the data in an user friendly way.

One method we could use is to create a content provider to read and store the data in a consistent fashion. Content providers are best backed by an underlying SQLite database.

Once your data is accessible through a content provider, displaying the data using data adapters and related user interface elements is much easier.

Step 4: Displaying Data Conveniently

When it comes to displaying data, again you’ve got many options. The hobbyist hacking out a fast solution may just load their text file into a text control and call it a day. But we know Android can do better, so we aren't going to do it that way. Instead, we'll draw the data within the application in a ListView control. We'll do this using a CursorAdapter from the content provider we've already created.

We don't have to stop there. We could also create a home screen widget that displays recent pressure readings using a StackView control. If you're familiar with API Level 11 and higher devices, the YouTube widget is an example of a StackView control; essentially, it's a deck of cards. It's also the closest replacement available to Live Folders, which have been deprecated.

Step 5: Sharing Data

Data stored on a mobile device, especially for research purposes, is not particularly useful. This data needs to get sent off somewhere for further study. There are several ways of approaching this problem. The hobbyist might just grab their text file off the device while connected via USB. We can do much more than that, however.

The data could be uploaded to a server regularly. This is useful for remote applications, such as a device mounted in a tree deep in the Amazon, or some other situation where the physical device access isn't particularly easy. On the other hand, if the device is always in the user’s hands, a manual sharing option could be added to format the data in whatever way needed, then shared through the sharing intent for any supporting applications like email clients to pick up. Furthermore, the app could respond to push notifications, or other remote commands, to send data to wherever it's needed when requested.

Our app keeps things simple (it is simple, remember?) and implements the share intent since we are building an app, not a server.

Conclusion

There are many ways to design an Android application. For our simple hobbyist/research application, we've chosen to follow standard controls and methods on Android. This provides for better, reusable code, should the application need to be used for other purposes or should the initial goals change. Yet the application still leverages the features of the platform that make Android so powerful, such as content providers, intents, and access to underlying sensor data. We'll build this application over several tutorials, focusing on the major parts outlined above.

About the Authors

Mobile developers Lauren Darcey and Shane Conder have coauthored several books on Android development: an in-depth programming book entitled Android Wireless Application Development (now in it's third edition as a two-volume set) and Sams Teach Yourself Android Application Development in 24 Hours. When not writing, they spend their time developing mobile software at their company and providing consulting services. They can be reached at via email to [email protected], via their blog at androidbook.blogspot.com, and on Twitter @androidwireless.