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