Android programming : Exploring sensors

Sensors are one of the the things that make mobile development different, and interesting, from the programming of our desktop computers. Modern mobile devices with their combined capabilities of communicating, imaging and sensing surrounding environment looks more like a pocket version of a artificial satellite than a desktop computer. This is why, after initial hello-worlding, the first thing I've been looking for in the 'net has been how to read sensors in an Android application. I got several examples like here, all showing how to read a single sensor. I decided so to make more interesting these basic examples in order to build a simple user interface able to discover and read available sensors on a device.

The user interface design

After reading about sensors on Android worked I refined my idea on how the user interface: a selector (also known as spinner) on the top filled with available sensors list, some details on the selected sensor just under the selector and sensors values updating on the bottom.

User interfaces (activities) layout is defined, in Android programming, trough a XML file. Eclipse Android development plug-in provides a handy graphical user interface to arrange activity layout. It worked for me well enough even if I went to manual XML editing a couple of times just to make things a little faster. Eclipse plug-in also provide a lot of useful warnings, to a beginner like me, like reminding not to place hard-coded strings in your interface. By the way here is, at last, my interface definition.

 

Making it live …

My sensor exploring application is going to do a handful of basic operations:

• Initialize properly and get the list of available sensors
• React to spinner selection and prepare to listen data from selected sensor
• Listen sensor data changes and display them
• Close nicely when stopped or paused

Android sensors are all handled by the SensorManager class a event listener can be attached to it in order to run code on sensor changes. So my activity will implement the SensorEventListener interface and attach itself to sensor manager. On a similar way the same activity class will implement the OnItemSelectedListener class that, attached to the spinner object, will allow my code to react to the control selection changes.

I know that a class doing all it's not the better design, it's a well known anti-pattern to be honest, but this is a demo code and I'm not going to maintain it.

I made some private fields for SensorManager, some UI elements and a list of discovered sensors:

at the activity creation the private fields are initialized and the spinner is filled with the list of available sensors

when an item on the spinner is selected the class is registered to read changes from the matching sensor.

when the application is suspended, or paused, the listener is unregistered in order to prevent the application from checking sensors, and consuming battery, if not visible.

Last but not least when sensor values change the grid view control is updated

and here is how the application looks like ...

Conclusions

I'm new to Android programming but the concepts that lie behind it are far from being new. Many frameworks use XML to define the GUI layout and anybody had a minimal experience with Java Swing knows the use of listeners to handle events. So programming Android has not been to me a so new experience. The real challenge in Android (or generally speaking mobile) development if the application design phase when you have to keep in mind the different way people interact with mobile devices and the many different device your application could run on.