Designing and building an android application pt 1

For me, getting my processes down is perhaps the hardest part when learning new platforms, new languages, etc. I dont Expect everyone to follow how I design and build applications from the ground up, but usually I just see how other people do things and adapt what I like, toss out what I dont.

For the purposes of this demonstration my intent is to build a package tracking application for my countless shipped packages.

A million dollar app from a 2c Idea

While I've historically had a pretty big opposition to super detailed rigid specifications, building even an informal requirements document and some use cases can help you consolidate ideas, prioritize features, and get an idea of what you MIGHT like the app to look like.

I usually start out by building a simple list of requirements, and end up with something like the following...

1. Track Packages
2. Client Server Architecture
3. Notification of status changes

Now we need to start drilling into each item better....

1. Track Packages 
1. Enter in a Package tracking number to add it to list of tracked packages
2. Display list of tracked packages (respected shipping company icons as well), and status. We'll also need the ability to manage the packages, so perhaps simple inline delete button
3. Details view with all package details. 
2. Client Server Architecture
1. Most tracking services have limits on calls to their API, so we want to buffer these through a server and control the actual hits against ups.com etc.
2. Packages to track, and their statuses will be stored on the phone as well. 
3. Notification of status changes
1. Periodically poll server for updates and send notification update
2. Eventually implement cloud to device messaging to handle push notifications

For now I'll leave it at that, and brainstorm the UI a bit. I highly recommend Balsamiq Mockups (http://www.balsamiq.com/) for mocking it up. Some of the UI bits are iphone specific, but translate pretty evenly even for android apps. About 10 minutes and I came up with the following.







Anyway, now I've got a pretty good idea of where I am going without going to nuts with the prototyping, the rigid specification, or overly presumptive UI.

Next time, we'll start looking at the structure of the projects.

UNTIL NEXT TIME!