Tuesday, May 25, 2010

Identifying and refactoring - Inversion Of Control

In my new position, I am now working on a large team of developers (15 in all). This team is working to complete a single product that has been designed using a Service Oriented Architecture. I have some insights into that design as well, however, in this post I thought I would show an example of how to identify and refactor to a design pattern, and why I feel this is a good thing for the project in the long term.

One of the hardest things about design patterns is recognizing when to use them and when not to. I have seen so many architects apply patterns for patterns sake, making code more complex, and making it HARDER to apply patterns where they are truly needed. I've also seen lots of code that isn't refactored to design patterns, and it COULD be made much easier to maintain and understand if it were changed. The code I will be talking about today is of the latter type. I've been writing Unit tests against the codebase at my new position. This has given me an opportunity to review the code. In order to protect the IP of the company I work for, the samples below have been changed. They represent the structure of some of the code, but are entirely unrelated to what my company does.

First, let me describe the general design of the code as it stands. In this instance, we have a method that takes an Enumeration argument. The method then calls the getInstance method of a Factory, and gets the proper implementation of an Interface. The getInstance method also takes an Enumeration. Finally, the code uses a case statement that tests the Enumeration value and uses the interface to set the values of different member variables in the class.  Here is the sample code that would implement this design:

The Container.  This is the class where our execution starts.  We call setMapValue and pass it a Type enum.

  1 package com.arciszewski.staterefactor; 
  2 import com.arciszewski.staterefactor.Type; 
  3 import java.util.Map; 
  5 public class Container {
  6     private Map<String,String> map1; 
  7     private Map<String,String> map2; 
  8     private Map<String,String> map3; 
 10     public void setMapValue(Type type) {
 12         ITypeInterface intf = TypeFactory.getInstance(type); 
 14         switch(type) { 
 15             case ONE : 
 16                 map1 = intf.getMap(); 
 17                 return; 
 18             case TWO :
 19                 map2 = intf.getMap(); 
 20                 return; 
 21             case THREE : 
 22                 map3 = intf.getMap(); 
 23                 return; 
 24             default : 
 25                 return; 
 28         } 
 31     } 
 33     public Map<String, String> getMap1() { 
 34         return map1; 
 35     } 
 37     public void setMap1(Map<String, String> map1) {
 38         this.map1 = map1; 
 39     } 
 41     public Map<String, String> getMap2() { 
 42         return map2; 
 43     } 
 45     public void setMap2(Map<String, String> map2) {
 46         this.map2 = map2; 
 47     } 
 49     public Map<String, String> getMap3() { 
 50         return map3; 
 51     } 
 53     public void setMap3(Map<String, String> map3) {
 54         this.map3 = map3; 
 55     } 
 57 } 

This is the Factory that creates ITypeIntf concrete classes.  For now there is only one implementation for type.ONE.

  1 package com.arciszewski.staterefactor; 
  3 public class TypeFactory {
  5     public static ITypeInterface getInstance(Type type) {
  7         ITypeInterface typeIntf = null; 
  8         if(type.ONE == type) { 
  9           return new  TypeImplOne();  
 10         } if(type.TWO == type) { 
 12         } if(type.THREE == type) { 
 14         } 
 15         return null; 
 16     } 
 18 }

The Enum.  Not much to say here.

  1 package com.arciszewski.staterefactor; 
  3 public enum Type { 
  4     ONE, TWO, THREE; 
  5 }

The Interface that defines getMap.

  1 package com.arciszewski.staterefactor; 
  3 import java.util.Map; 
  5 public interface ITypeInterface {
  7     public Map<String, String> getMap(); 
  8 }

An implementation class. Kept simple for discussion.

  1 package com.arciszewski.staterefactor; 
  3 import java.util.HashMap; 
  4 import java.util.Map; 
  6 public class TypeImplOne implements ITypeInterface {
  8     @Override 
  9     public Map<String, String> getMap() { 
 10         //Do something like get data from a DB. 
 11         return new HashMap<String, String>();
 12     } 
 14 }

Looking at this code, you'd probably say that the developers did some things right.  They designed to interfaces, they are using a creational pattern, and the code is pretty clean and easy to read.  I tend to agree, except when it comes to that ugly switch statement.  Here are my issues with the switch statement:

  1. Developers have to remember the return statement, or we will have NULL implementations when we shouldn't
  2. Developers will be tempted to add more logic to the case statements that are Type specific.  As these add up, the clarity of the code falls
  3. We're already verifying the type in the Factory, so this code is checking the Type value twice when it doesn't have to.
  4. Container needs to be aware of the different implementations of ITypeIntf.  Why should it need to?  Now we've added a dependency we don't need.

There is a change we can make that will improve this code.  Let's change the ITypeInterface to take a Container object in its argument list.  Then we can set the value in the method and the case statement is no longer needed.  This is a classic IOC technique.  Here is what the code looks like after the refactoring.

The new Container. Notice, there is no switch statement. None is needed. the IMPLEMENTATION of the ITypeIntf knows which attribute it needs to set. Also note that Container doesn't need to know anything about the implementation that the Factory returns.

  1 package com.arciszewski.staterefactor; 
  2 import com.arciszewski.staterefactor.Type; 
  3 import java.util.Map; 
  5 public class Container {
  6     private Map<String,String> map1; 
  7     private Map<String,String> map2; 
  8     private Map<String,String> map3; 
 10     public void setMapValue(Type type) {
 11         ITypeInterface intf = TypeFactory.getInstance(type); 
 12         intf.setMapValue(this); 
 13     } 
 15     public Map<String, String> getMap1() { 
 16         return map1; 
 17     } 
 19     public void setMap1(Map<String, String> map1) {
 20         this.map1 = map1; 
 21     } 
 23     public Map<String, String> getMap2() { 
 24         return map2; 
 25     } 
 27     public void setMap2(Map<String, String> map2) {
 28         this.map2 = map2; 
 29     } 
 31     public Map<String, String> getMap3() { 
 32         return map3; 
 33     } 
 35     public void setMap3(Map<String, String> map3) {
 36         this.map3 = map3; 
 37     } 
 40 }

The new interface. The interface definition was changed to return void and to make the name descriptive of what it does now.

  1 package com.arciszewski.staterefactor; 
  3 public interface ITypeInterface {
  5     public void setMapValue(Container container);
  6 }

The new implementation. Notice that the new implementation now has a dependency on Container. That's OK in my mind, since the interface is intended to work on Container. Here's what we gained, though. Now ALL the logic for this condition is in ONE place. Container will never need to be changed, even if a new implementation is defined (For instance, an implementation that will set ALL the map attribute values.)

  1 package com.arciszewski.staterefactor; 
  3 import java.util.HashMap; 
  5 public class TypeImplOne implements ITypeInterface {
  6     // Changed the name, too. getMap no longer describes this function, but
  7     // setMapValue does. 
  8     @Override 
  9     public void setMapValue(Container container) {
 10         // Do something like get data from a DB. 
 11         container.setMap1(new HashMap<String, String>());
 12     } 
 14 }

So what pattern does this conform to? It looks a bit like a State or Strategy pattern. It also looks a bit like a Command pattern. Which would you say it is?

Sunday, May 23, 2010

Android Application Part 6 - SQLLite Database

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

In my previous post, I walked through the scaffolding for the ListService, which will query a REST Web service and sync data locally.  Of course, the code was just the implementation to allow the service to run in a new Thread.  Today I am going to start implementing the storage part of the application.  Android has a a SQLLite. Database.  The OS makes it available through a service.  It even comes packaged with a SQLLiteOpenHelper class.  The implementation for this one is rather easy.  Here I've modified the sample presented on the Android Developer Site.  First I'll show you the code, then I'll talk through what its doing.   

package com.arciszewski.family.shopping.db;

import android.content.Context;
import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;
import android.database.sqlite.SQLiteDatabase.CursorFactory;

public class FamilyListOpenHelper extends SQLiteOpenHelper {

private static final int DATABASE_VERSION = 1;
private static final String FAMILY_LIST_TABLE_NAME = "familyList.db";

public FamilyListOpenHelper(Context context) {
this(context, null);

public FamilyListOpenHelper(Context context, CursorFactory factory) {

public void onCreate(SQLiteDatabase db) {

public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
// TODO Auto-generated method stub


So what is this code doing? First, I've defined which version of the DB this is:


I like this feature of Android. They have built-in support for upgrading. You'll notice, I have not implemented the onUpgrade method, that is because I have no need for it yet. But when I come out with version 2.0, I will have the opportunity to perform upgrade operations.

Next, I define the table names and create SQL for the List and Item tables.


Finally, I've implemented a constructor that will always open the Family List Database and return it to the caller. That's it. And that is pretty easy my friends. Of course, I'm not making this available as a service to other applications, which is slightly more complex.

Next, I'll implement some querying and saving.

Sunday, May 16, 2010

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;
03 import android.app.Service;
04 import android.content.Intent;
05 import android.os.IBinder;
06 import android.util.Log;
08 public class ListService extends Service {
09   private RunnableListService runnableListService;
10   @Override
11   public IBinder onBind(Intent arg0) {
13     return null;
14   }
16   @Override
17   public void onCreate() {
18     super.onCreate();
19     Log.i("BAA""created");
20   }
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   }
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 }


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 = "";
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   }
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...
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   }
36   public static synchronized void setRunning(boolean runnnig) {
37     RunnableListService.running = running; 
38   };
40   public static synchronized boolean getRunning() {
41     return RunnableListService.running;
42   }
44   public void setContinueRunning(boolean continueRunning) {
45     this.continueRunning = continueRunning;
46   }
48 }

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...

Sunday, May 9, 2010

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

Thursday, May 6, 2010

Android Application Part 3 - UML

This post is part 3 of a series.  Click here to go to part 2.

Before I go into the actual UML for this application, I first have to talk about my opinion regarding things like UML Diagrams, Sequence Diagrams, State Diagrams, Activity Diagrams and Object Diagrams.  As Software Engineers, we differ from other Engineers in a major way.  The only thing we produce that is a COMPLETE representation of the systems we build is the code.  In no other engineering endeavor is the completed product also the description of that product.

Based on this knowledge, it is my belief that all the diagrams and drawings and 'design' aides we use to build software are there not to completely document a system.  On the contrary, attempts to completely document a system using these tools is rather counter-productive.  So what are they supposed to be used for?  I like to think of all these diagrams and pictures as tools to be used for the following purposes:

  • To allow the Software Engineer to organize his thoughts about the system, and aide in his decisions regarding the design.
  • To provide a way to describe a PART of a system that may be important or complicated at a high leve
  • To allow the view of a system at a higher, abstract level, without the details, to allow for a broad analysis of a system
That's it.  That's all.  That's what all these things are good for.  I know the very next question people will ask - What if we really need to understand the details?  What if we need to KNOW what the system is doing?  Well, there is only one reliable way for someone to know what a software system is doing - GO READ THE CODE!

So, when I produce UML, State or Sequence diagrams, I typically omit a lot of detail.  I intend for these things to convey limited messages and present limited data because they are simply tools of transition, there to help in the final build of the system.  Now I will get off my soapbox and present to you the simple designs for my app.


As you can see from the UML, this is a pretty simple object model.  We'll see if I need something more complex later, but this appears to be the basic outline for what I need. 

Notice that I added some auditable information to the Items.  I figured you would want to know who and when an item was added, removed, updated, etc.   

To the right, you will see my DAO UML diagram.  As you can see, I have declared a Dao interface that uses generics.  Each subclass will implement the generic type for its Type of object. I also chose to use a DaoFactory to create my objects.  You'll notice that I have not represented all the relationships, return types, arguments, etc, that would make this UML complete.  Isn't this version much less cluttered, though?  And isn't my intent straight forward?

I intend to use GWT for my Web site, so I have a set of RPC services that will extend RemoteServiceServlet.  As you can see, there is nothing magical here.  It is implied that each of these services will use the corresponding DAO associated with them.  I could add those relations to this UML, but I think it just adds complexity.

I am going to refrain from building the UML for the visual components of this system.  Why?  For one, the diagrams get pretty complicated pretty fast.  And two, because I already have plenty of diagrams showing the 'guts' of my system. 

The Sequence Diagram

I will demonstrate one sequence diagram that is representative of this design.  Most actions in this system will follow this pattern:

The first thing I want to point out about the sequence diagram, is that it is rather hard to model the AsyncCallback used by GWT RPC.  I supposed I can add a call to the AsyncCallback constructor from UserServiceAsyc, and fit the model that way, but this is another scenario where that tends to obscure the intent rather than enlighten it.  Instead, I just put a comment that the GWT magic is omitted.  I hope that other developers looking at this would be familiar with GWT.

By the way, my favorite modelling tool is called, Violet.  It is completely free.  It's simple, but makes for a rather quick and easy way to build your models so that you can get your thoughts together and start coding.

Next: We'll get into some coding. FINALLY!

Wednesday, May 5, 2010

Android Application Part 2

This post is part 2 of a series.  Click here to go to part 1.

In my first post, I outlined the 3 major components of the system I am thinking about - Web site, Web service, and Android app.  At first I thought I would dive right into programming the Android application, but then I realized that I was about to make the same mistake my business users make.  I was about to develop something without first thinking through the use-cases I wanted to accommodate.   So, this post is going to deal with the use-cases I will be developing.

First let's talk about the Web site.  Here are the use cases I want available for my first revision:

  • Allow a user to set up a new account
  • Allow a user to set up a new 'Family' (or group)
  • Allow a user to send invitations to other users to sign up/join the group
  • Allow a user to add a list to the Family
  • Allow a user to add an item to a list
  • Allow a user to mark an item as purchased
  • Allow a user to mark an item as needed again
Of course, I can think of about a dozen more use cases, but I am going to limit this first build to just those 7. Now lets talk about the Android application.  Here is what I want it to do:

  • Periodically poll the server for lists
  • Synchronize the local list with the server and save it (rules for conflicts?)
  • Allow a user to view lists
  • Allow a user to mark an item as purchased
  • Allow a user to mark an item as needed again
  • Allow a user to force a sync (He may want to do this right before entering a store)
Given the functionality on the Android application, I believe the needs of the Web service become apparent
  • Provide a service to allow a user to sync the lists from his groups
Now that I look at that, I believe this is going to be a bit more work than I thought, but not too bad.  I can see that there are many more use cases for the Web application than I thought, and many fewer for the Web service.  

Next: Let's do some UML and Sequence diagrams.

Tuesday, May 4, 2010

Android Application Attempt 2

Now that my classes have finished, I am going to attempt an Android application again.  My first idea was a 'my friends' application.  It appears that Google has beat me to it.  Thanks, Latitude.

I have a second idea.  This application I call, 'Family Shopping List'.  The idea is to store a common list, say a grocery list, online, and sync it to all the family accounts tied to the list.  This way, my wife can add milk to the list, and I can pick it up on the way home.  The reason this can't be strictly an online application is simple - Cellular service is often non-existent in grocery stores.  What we can do is sync the lists while we do have service, and show the list we have when we are offline.  So, here is a basic description of the very high-level design of 'Family List'.

  • Server application - A Web site with the ability to set up a new account, view lists, send invites to users.  Accesses a backend database where all information is stored
  • Web Service - Published interface that allows clients to interact with the server.  
  • Client - Android application that communicates to the server.  This application will also have a local data store that mimics some of the tables on the server
That's it in a nutshell.  For my next post I will be going over the basic design of the application. 

Sunday, May 2, 2010

Android Development - So Easy Yet Not So Easy

I have recently started playing around with Android.  Given the success of the Droid, Droid Eris, and what looks like a phone from Google, the NexusOne, I figure the Android is going to be either the number one or number 2 development platform for mobile devices.  In either case, I want to be able to write apps for my Droid, which, I love.
So this week I have attempted to start development.  I have read through the online documentation, which, in typical Google fashion, is fairly complete and detailed. The Android Developer Guide includes step by step instructions for installation of the SDK, Eclipse Plugin, and samples to get you programming quickly.
Of course, nothing is perfect.  So here are a couple of issues with the tools.
  • It appears that sometimes changed resources don’t get updated when the emulator is re-launched.  Even though I’ve set the flag to Wipe User Data.
  • I can get one version of the Google Maps sample to run correctly but not another.  It seems that the Sample Tutorial on the Web site doesn’t work for 2.0 or 2.0.1 emulators on my machine, but the sample bundled with the toolkits do.  To be honest, it appears that the only difference is WHERE the MapView is instantiated, but I am still a noob at this, so I am probably mistaken
Is this going to be enough to cause me to give up?  Heck no.  Even though these two items are frustrating, the toolkit is still well put together and I expect to be building apps in no time.  My next posts will detail the building of an app.