Agile and Android, Part 2: Introducing AwesomeApp

In the second of this series of blogposts where we attempt to show you how to build an Android app using Agile best practises, we shall introduce the example application we shall use for the rest of this series. This post shall lay the ground for the rest of the series by describing the example application we shall be working on for the rest of this series. 

We shall be describing this as a series of user stories because here in Cloudy Towers, we like Agile software development enough to fetishise it (not literally; we know fetishes can be unhealthy!). We cannot stop waxing eloquent about how agile allows us to focus on business value and continuous delivery, about how the sight of a wallboard can be nigh orgasmic... right, I’d better stop. Suffice to say that this is entirely representative of how we go about gathering requirements from our customers at the start of a development project.

Note: To understand more about epics and user stories, do take a look at Scott W. Ambler's excellent blogpost.

Our client is called Awesome Logistics Inc. Awesome Logistics wishes to build an Android application that monitor their AWS resources on the cloud called Awesome App (sorry, I’m not very creative). However, this is besides the point. For the purposes of this demonstration, let us consider a single epic.

As a user of Awesome App, I want to be authenticated on to the application so that unauthorised users cannot wreak havoc on our Amazon resources.

This epic is then split into the following stories

1. As a user of Awesome App, I want to log in to the system using my Google Apps ID so that I do not have to remember multiple passwords*.
2. As a user of Awesome App, I want to receive a warning if my Google Apps username or password are invalid.
3. As a user of Awesome App, I should not be able to log in in the absence of an Internet connection so that I do not waste my time trying to log in.
4. As a user of Awesome App, I do not want to log in again after I have logged in once so that I am not repeatedly prompted for my password.

In the rest of this series, we shall go through creating and mavenizing the project,  implementing our stories with Behaviour Driven Development using Robotium, and mocking on Android using android-mock.

*Please note that an alternative approach to use Google Apps authentication on Android is to use the Android AccountManager class, and this is often better for most users. However, for pedagogical purposes, we shall not take this approach.