Steele Bit programming & development musings by Andrew Steele

Setting up an Android development environment is not a terribly hard task, but there are several steps involved. Before I document those steps a note about the hardware I used for my forays into Android development.
Development Machine Specs

• Windows 7 64 bit
• Processor: Intel Core  Duo T9800 @ 2.93GHz 2.94GHz
• RAM: 4.00 GB

Android Platforms

• Motorola Droid
• HTC Incredible

The following steps are merely the ones that I used to develop Proximity Alerter and are definitely not the only options for setting up an Android development environment. Accounting for download and installation time the following steps should take less than 2 hours.

1. Step 1 - Android SDK & Components
   
   • Download and install the Android SDK
   • Once the SDK has been installed, you'll need to manually add the 2.1 platform and Google APIs, see Adding Android SDK Components
2. Step 2 - Phone Drivers
   
   • Download and install the Motorola Mobile Phone USB Driver
     
   • At the time of this writing I could not find an easily downloadable HTC driver but the Installing HTC Incredible Android SDK Drivers instructions provided by Andrew Westberg work.
3. Step 3 - Setup Android Devices for Debugging
   
   • On the device, go to the home screen, press MENU, select Applications > Development, then check all three options
4. Step 4 - Setup MOTODEV Studio (a fully contained Eclipse plug-in) for Android
   
   • Download and install MOTODEV Studio for Android (might require account creation)
     
   • Start MOTODEV Studio for Android, create a new workspace
   • Select: "Use an existing SDK from the file system" and point MOTODEV Studio to the location where you installed the Android SDK

At this point your Android development environment is setup and ready for the obligatory Hello, World.

I have spent the month of June recovering from a lot of travel and catching up on work. Thus far it has been an outstanding summer filled with a lot of learning. We started a new project at work which is stretching my capabilities and providing excellent learning opportunities.

In addition to work I've spent the last six weeks in a Smartphone Application Development course. The course focused on developing applications for the Android Platform. The course was taught by Ted Selker who pushed us to come up with innovative project ideas. I had some of my own but polled my social graph for additional ideas.

The best ideas are below

Service Disabler

An application that is location aware turning off features depending on location. This would have practical use for the government as even government owned portable electronic devices have restrictions inside of limited areas. This idea could be extended to the consumer market to turn off specified features/notifications when at particular locations i.e. I am at/near my desk I don't need to be notified of Twitter mentions.

Bicycle cadence measurements

Bicycle cadence measurements. This measurement could be obtained by listening for the "swoosh" of a bicycle pedal using a Bluetooth headset or by calculating a virtual cadence using the accelerometer. In either case as a cyclist I am interested in this application because I presently have no option like it.

Photo Geo-tagging

A photo geotagging application. The application would communicate with your service of choice (Flickr, Picasa, etc.) and update previously uploaded photographs with a prior recorded geotagged location. The application would be smart enough to ignore photographs where it was not on at the time of the picture being taken. This would be useful for photographers who already carry additional devices to provide similar utility.

Grocery Food Item Locations

An application that provides the location of food items based on a specified grocery list. I.e. cereal can be found on aisle 3 and produce in this section of the store. This application would provide the details of where to go in the store to get all of the items on a list and provide suggestions for available coupons. To make this truly work would require the eventual buy in from multiple grocers as keeping store layout information up to date would be difficult.

Exposure Calculator

An exposure calculator for pinhole photography. Capturing light values and displaying flash calculations to photographers. This would be of value as photographers already carry additional devices to provide such calculations.

Advanced Phone Locker

Provide the ability to lock the phone with more than a simple pin or connect the dots unlock mechanism. This application would use multiple sensors to unlock the phone. It’d be interesting to allow for audible, location, gesture, and accelerometer based unlocking. A user could create a profile combining up to two unlocking mechanisms.

Some of these are more cute than useful. I ultimately chose to write the Service Disabler application though it morphed into Proximity Alerter.

My team is in the process of transitioning our development methodology. We have never had a formally documented development process. At best our practices have been most akin to waterfall and at worst haphazard. We have succeeded in developing this way because we have been in a perpetual maintenance mode, tested relentlessly, and new development has largely been completed by small groups of developers. Over the course of the last year we have been slowly transitioning to agile practices while incorporating the interaction design philosophies espoused by Alan Cooper. As we are beginning a major redevelopment effort we felt we were finally ready to take the next evolutionary step, adopting an agile methodology, Extreme Programming (XP) and more fully utilizing Cooper’s personas.

In Extreme Programming and Inmates I argue that the use of personas can assist XP teams in generating user stories. What I do not explain is that on the morning I set that post to publish my team was gathering to do exactly that. We spent all of last Thursday in a conference room. Our meeting began at 8:30 AM with a roughly outlined agenda.

In the weeks prior to the meeting we had worked to create a cast of characters representing our identified user personas. These personas were based on the demographics and unique goals of our intended user base. At the meetings outset our intent was to identify those personas which were positive and negative. After some deliberation we identified three positive personas and nine negative personas. Of the three positive personas one was clearly primary.

Having culled our cast of characters we began a traditional brainstorming session. This brainstorming session was not like others that we have had as our discussion and ideas were focused. Knowing who we were talking about allowed us to quickly generate a valuable mind map. After a morning in a conference room we decided to take a break for lunch.

Even after the successful morning I was nervous to return from lunch. While my team had responded well to the use of personas for brainstorming I feared their unfamiliarity with user stories and some lingering tentativeness toward personas would hamper our productivity. I had visions of us sitting around a table just staring at each other.

To my great pleasure I discovered that my fears were unfounded. The team adapted to creating user stories quite readily. We had the same experience that we had had in the morning in that the personas focused our discussion and allowed us to zero in on who a particular story was for. We turned on music and laughed our way through the remainder of the afternoon.

At our meetings conclusion we found that we had generated over a hundred user stories. Many more than we can complete in several iterations. I am happy to report that using personas in conjunction with story cards has thus far been a resounding success.

Story cards and use cases are both mechanisms for documenting user goals. Story cards are part of the agile software methodology Extreme Programming (XP). Use cases are part of the more formal Unified Process (UP) methodology. The two approaches share similarities but differ in their application. It is these differences that make one method more appropriate than the other depending on the type of project.

Story cards are user goals written in the form of two to three sentence stories on index cards. A story card contains enough information for the customer and developer to understand the story’s intent and estimate its implementation difficulty. In contrast, there are three use case “dressing” levels. A “briefly dressed” use case does not differ greatly from a story card in the amount of information documented. A “casually dressed” use case captures additional information but is not as detailed as a “fully dressed” use case-- a highly detailed document including pre/post conditions, alternative paths, and exception handling.

While story cards and briefly dressed use cases resemble each other in the amount of information documented, their function differs. Briefly dressed use cases are essentially placeholders for future fully dressed use cases. Fully dressed use cases are the final result of many customer and developer implementation conversations. While not every use case must be fully dressed before development begins, generally no development work towards implementing a particular use case begins until that use case is fully dressed. Conversely, story cards act as a conversation starter allowing programmers to begin development while still engaging the customer for implementation details. Establishment of user acceptance criteria for the story cards occurs during these conversations. From these criteria developers are able to create automated user acceptance tests. Automated user acceptance tests are a code form of the formal written documentation in a fully dressed use case.

XP story cards enable concurrent conversations during development, while UP use cases enable preemptive conversations prior to development. The difference between preemptive or concurrent conversations goes to the heart of the differences between agile and formal development methodologies. Agile methodologies and XP in particular attempt to engage the customer throughout a project’s development lifecycle. Story cards are a means to continuously engage the customer while developing a product. Formal methodologies like UP primarily focus on detailed documentation before implementation work begins. A fully dressed use case attempts to detail all possible usage outcomes creating a blueprint for a developer to work from.

Whether story cards or use cases are more appropriate for a particular project depends on whether an agile or formal methodology is most appropriate for the project. Projects that are life critical, require a very high degree of precision, or the development team is highly distributed will benefit from the use of fully dressed use cases and a formal methodology. Projects that allow for repetitive iterations, have a low fault tolerance, and lend themselves to close developer/stakeholder collaboration will benefit from the use of story cards and an agile methodology.

Much like agile and formal methodologies, story cards and use cases have advantages based on the type of project under development. Developers should be aware that while they may prefer one methodology over another, project requirements may determine which methodology is more appropriate.

In The Inmates are Running the Asylum Alan Cooper makes a compelling argument for interaction design which Cooper contends requires thorough exploration and documentation before any programming begins. Kent Beck in Extreme Programming Explained describes that the methodology uses a pull development model which specifies stories in detail immediately before implementation. When juxtaposed these two assertions seem contrary but upon reflection can be made complementary.

At their core agile methodologies like Extreme Programming (XP) emphasize creating good products, not just good programs. This distinction while subtle is important. By embracing the external input of customers, users, managers, and stakeholders XP practitioners acknowledge that a product is more than just a program comprised of features. Cooper similarly believes that a successful product is not just a feature compilation arguing that achieved goals, not features, compel users. Cooper’s advocacy for goal driven design leads to his suggestion of utilizing personas-- hypothetical archetypes of actual users. In XP projects developers can use personas as stand-ins for onsite customers. Personas allow XP teams to vet features through the lens of accomplishing a persona’s goals.

XP developers document external input in the form of user stories. An XP user story is a mechanism which estimates and describes units of customer-visible functionality. In his Agile 2008 Conference keynote, Cooper contends that creating user stories is arguably an agile programmers’ weakest skill and is an interaction designers’ strongest one. Cooper goes on to conclude that while agile methodologies like XP bring outsiders into the software construction process it is interaction design that makes the contributions of outsiders effective and useful. Simply stated, XP puts developers and stakeholders in direct collaboration while Cooper advocates placing an interaction designer in-between stakeholders and developers. Utilizing an interaction designer in conjunction with an XP team seems reasonable; allowing developers to focus on technical problems and interaction designers to focus on human factors. XP programmers can take Cooper’s advice by investing time to fully frame user stories, which ultimately speeds up programming and reduces costs.

Both Beck and Cooper are advocates of an iterative process. In Chapter 3: Wasting Money Cooper warns against using iterative product delivery as a means of product refinement. Later he declares that “getting to the right product is always a matter of iterating” (Cooper p240). What Cooper does not stress in Inmates but does so in his keynote at the Agile 2008 Conference is where the iterative process should take place. Cooper believes it is folly to iterate where customers are subject to abuse by those iterations and instead urges iteration during the design and engineering phases. While Beck urges that in an XP project the product should be in a releasable state at an iteration’s conclusion, he does not suggest that it must be released.

Incorporating Cooper's goal driven design with Beck's XP practices improves software product development. Beck acknowledges that there is no litmus test for certifying a development team extreme and Cooper is ultimately a proponent for the tenets of agile methodologies. While at first glance Beck and Cooper may seem to be in conflict regarding iterative software development, in reality they both offer valuable suggestions which should be leveraged. It is therefore up to an agile development team to incorporate the suggestions of each practice in a sustainable and effective way.