Android Application Part 5 - Creating the Service

This post is part 5 of a series.  Click here to go to part 4.


In my previous posts, I outlined my general design for this application.  In this post, I will review the creation of the Service class for the Android device. This class will have one purpose: Communicate with the server to sync lists.

One of the things I hadn't decided on was how to construct the Web service.  Do I want to use a SOAP style service or a REST style service? The server side for either of these is pretty well defined for me - I've written both SOAP and REST services.  The unknown is how to build these on the client side.  I did a little Web research, and here are a few of the places I've found that have some good information on these topics:

• It appears that Google isn't interested in including SOAP in the standard Android packages at this time, but there is a 3rd party library that provides this support: kSOAP. 
• Google DOES support JSON with Android packaged,  org.json.*.  I also found a handy RestClient.

Given that JSON is less verbose, and the processing will take fewer resources, I think its a better choice for a constrained device like Android.  I also like that I have a RestClient class that I can use, but I can also see what's going on easily inside it.  So, the transport protocol for my application will be JSON.

Let's talk about the code.  Below is my first attempt at creating the ListService.  It's not fully fleshed out.  This first version is written to put in the Multithreading and get a basic framework for the application.  I will next work on pulling out the data from the JSON objects and store them locally (Using the local HSQL db Android provides).  It's also clear I need to understand Intents and bindings much better before I will be able to complete the app.  Let's start with a discussion on the ListService.  This extends the Android Service class and over rides the onCreate, onStartCommand, and stopService methods.  I also added extra logging to see what's going on.

01 package com.arciszewski.family.shopping.service; 02  03 import android.app.Service; 04 import android.content.Intent; 05 import android.os.IBinder; 06 import android.util.Log; 07  08 public class ListService extends Service { 09   private RunnableListService runnableListService; 10   @Override 11   public IBinder onBind(Intent arg0) { 12      13     return null; 14   } 15  16   @Override 17   public void onCreate() { 18     super.onCreate(); 19     Log.i("BAA", "created"); 20   } 21  22   @Override 23   public int onStartCommand(Intent intent, int flags, int startId) { 24     Log.i("BAA", "starting"); 25     if(runnableListService == null) { 26       runnableListService = new RunnableListService(); 27       new Thread(runnableListService).start(); 28     } 29     return START_STICKY; 30   } 31  32   @Override 33   public boolean stopService(Intent name) { 34     Log.i("BAA", name.toString()); 35     boolean superResult =  super.stopService(name); 36     if(runnableListService != null) { 37       runnableListService.setContinueRunning(false); 38       runnableListService = null; 39     } 40     return superResult; 41   } 42 }

Java2html

The ListService does nothing but create a RunnableListService and start it in a new Thread.  It also kills the flag that keep the polling loop open when stopService is called.  Here is the RunnableService:

01 /** 02  * Class that will poll the server for changes and sleep.   03  * @author barciszewski 04  * 05  */ 06 public class RunnableListService implements Runnable { 07   private static final String SERVER_URI = "http://192.168.1.103/familyList"; 08   private static final String APP_ID = "FL1";  09   private static boolean running = false; 10   private boolean continueRunning = true; 11   @Override 12   public void run() { 13     getListFromServer(); 14   } 15    16   private void getListFromServer() { 17     //don't want to try and connect twice 18     if(!getRunning()) { 19       setRunning(true); 20       RestClient.connect(SERVER_URI); 21       //save list data to local data store... 22        23       setRunning(false); 24     } 25     while(continueRunning) { 26       try { 27         Thread.sleep(1000*60*5); 28       } catch(InterruptedException e) { 29         //do nothing 30       } 31       getListFromServer(); 32     } 33   } 34    35    36   public static synchronized void setRunning(boolean runnnig) { 37     RunnableListService.running = running;  38   }; 39    40   public static synchronized boolean getRunning() { 41     return RunnableListService.running; 42   } 43    44   public void setContinueRunning(boolean continueRunning) { 45     this.continueRunning = continueRunning; 46   } 47    48 }

Java2html

Most of the heavy lifting is not implemented yet, but this provides the structure to poll the server.  I also modified the RestClient slightly to return the JSONObject.

Next - More implementation...

Android Application Part 4 - The Activity and Service

This post is part 4 of a series.  Click Here to go to part 3.

After all of that, I am going to set aside any of the server programming and go straight to writing the Android portion of the system.  I know, I know, after all that work writing the UML for the core components, I'm just going ahead and writing an Android app anyway.  I have two good reasons for this.

Reason 1: I have never produced an Android app before, but I've written dozens of Web apps and Web services.  Therefore, the Android portion of the system is the least-known and most risky.  As a developer, I like to tackle these portions of a system first to reduce risk and get unknowns out of the way.  I believe this is a good practice, and leads to more successes in projects.

Reason 2: I WANT to program an Android app.  Especially now that I have my Droid  and my wife has her Incredible.

OK, so lets start on the Android app design.  My application will need to display a UI and run a background process to do synchronizations.  According to the Android Developers Web site, I will need two basic constructs, an Activity and a Service.  Let's explore the Activity first.  The Android developer site describes an Activity as:

An activity presents a visual user interface for one focused endeavor the user can undertake. For example, an activity might present a list of menu items users can choose from or it might display photographs along with their captions. A text messaging application might have one activity that shows a list of contacts to send messages to, a second activity to write the message to the chosen contact, and other activities to review old messages or change settings. Though they work together to form a cohesive user interface, each activity is independent of the others. Each one is implemented as a subclass of the Activity base class.

That seems pretty straight forward - An Activity is simply a UI component for a single task.  It sounds like my application will only need a couple of Activities.  One activity to show the grocery list, an activity to add a new item, and one to show the status of the sync.  A Service is defined as:

A service doesn't have a visual user interface, but rather runs in the background for an indefinite period of time. For example, a service might play background music as the user attends to other matters, or it might fetch data over the network or calculate something and provide the result to activities that need it. Each service extends the Service base class.

A prime example is a media player playing songs from a play list. The player application would probably have one or more activities that allow the user to choose songs and start playing them. However, the music playback itself would not be handled by an activity because users will expect the music to keep playing even after they leave the player and begin something different. To keep the music going, the media player activity could start a service to run in the background. The system would then keep the music playback service running even after the activity that started it leaves the screen.

It's possible to connect to (bind to) an ongoing service (and start the service if it's not already running). While connected, you can communicate with the service through an interface that the service exposes. For the music service, this interface might allow users to pause, rewind, stop, and restart the playback.

Like activities and the other components, services run in the main thread of the application process. So that they won't block other components or the user interface, they often spawn another thread for time-consuming tasks (like music playback). See Processes and Threads, later. 

From the description of a Service, it appears that my application will only have one service - the list sync.  This service should spawn a thread so it doesn't block other components or the UI.  It also appears that the service can be exposed to an Activity, so I should be able to force a sync through a UI action.

This all seems pretty simple.  Let's just do a quick UI sketch, though.  I've mocked up a header and one record to make sure I've got the screen space I'd like. 

This is a really rough mock up, but it demonstrates all I need for the list.  One form element, a check box, and three labels. 

It seems like the Android application design is going to be dictated by the platform.  An Activity and a Service are going to be my two main classes.  I think I'm going to tackle the Service first, as that is more complicated.

Next: Coding the Android Service