Building an Android Application in One Week

While I have decided to keep Track and Field Clipboard closed source, I will reveal a little bit about how I created it. I keep all of my source code for all of my projects in a Subversion repository. Since I always strive to create the highest qualify software, this is definitely a powerful tool. It also provides a great way to keep backups of my code secure. As a data geek, I also appreciate all of the information that is captured by using a version control system. I used StatSVN to generate a report based on the repository.

As you can see from the chart below, I began coding on Monday May 30,2011. The majority of the code was written in the first three days of the project. This work mostly consisted of building the model that was use to represent the field events and participants. This code would have likely taken longer to create if I did not include the Simple XML third party library. Unlike the XML serialization capabilities built into .NET and C#, Java has no built in way to quickly and easily serialize objects into XML. While I could have used binary serialization, that had the possibility of causing problems in the future.

Using the Simple library was so quick and easy, I will likely use it in some other Java based applications that require some trivial XML parsing capabilities. The most attractive feature of Simple is the fact that it is very small. The APK for Track and Field Clipboard is only 156k, which has the library bundled with it. Other libraries were in the multiple megabyte range by themselves.

Android provides a variety of ways to store data persistently. I settled on using files and not an SQLite database to dramatically simplify the process. The process involves writing and reading the serialized object's XML to and from a file. Initial testing on this approach was very promising. The file was read using an AsyncTask and then the appropriate Activity was launched. Since all of the manipulations to the object were being performed in a single activity, this approach worked perfectly. When the activity was paused, another AsyncTask was dispatched to save the object back to the file so nothing would be lost. While I did have some performance issues, it turned out those were primarily cause by having the debugger attached to my device.

The weekly activity graph for this project is very interesting since the project is only a week old. The number of commits peaked and then fell indicating that the application was starting to stabilize. Since the project was a straight forward application there were very few stumbling blocks that I encountered during the process.

At the moment, I am currently between the end of my college career and the start of my first full time job. This means I have had several weeks (and still have several weeks more) where I can decided how to spend my time. Unlike many geeks, I am not a night person. I tend to wake up fairly early and do not stay up late into the morning hours. I have code commits as early as 9 AM and they only go as late as 2 PM. The drop in the number of commits in the later hours is likely when I was hungry and tended to take a break from coding. My lunch breaks were obviously much shorter. The graph reveals my peek productivity times: after lunch and before I go to bed.

This is obviously a very new project and I am confident that there are still a number of bugs in the code. There are also some simple features that did not make it into the initial release. Spending the past week creating this application has been my form of relaxing. Learning how to write an application that targets Honeycomb was definitely worth my time and effort.