When I first started looking at the Android OS, I saw some things that I really liked and a few that I didn't like very much at all. The first thing that gave me pause was that it was a Java-based programming environment—not C++. At that point I had not written any production level Java code; I knew I wouldn't be able to use my C++ skills and didn't like the idea of giving up the control and power that C++ provides. Oh, well! At least Android had an object oriented API. What really interested me was the system of Intents. It is great that you can request the OS to provide an Activity to perform some function, and if there is more than one potential provider, then the user is offered options to pick the one they like best.
After looking over the OS documentation, I thought the OS had real potential. As luck would have it, the first Android phone was coming to my mobile carrier. I preordered a G1 and it arrived in late October of 2008. Now the problem was finding time to write some applications. At the time I was working full time with a long commute and running a business, so time was tight. The best I could do was a few hours every other weekend, but I did manage to write several small applications that tested different aspects of the OS. My full time commitment ended in January of 2011 and my hope was to find enough time between paid jobs to write some distribution-worthy applications.
Knowing that I was going to be able to spend some time working on Android applications during 2011, I decided that I should attend Google I/O. After seeing the videos of previous events, it seemed like the chance to see the talks firsthand, ask questions, and maybe get some additional hardware to use as a development target were more than enough incentive to make the trip to San Francisco. But wait, there’s more! As it turns out a friend of mine had also been dabbling in Android development. We talked and he also expressed interest in going to Google I/O, so we hatched a plan. We would fly out for the conference and then our significant others would join us after the conference for some time on the town.
The registration process for Google I/O is simple, you register online when the registration process opens. The problem is the extraordinarily high demand to register resulted in the registration page being unreliable during the registration process. I got to the checkout process and was unable to complete the transaction. When I backed up a few steps the page claimed the registration was closed because the conference was sold out. My friend had nearly the same experience and was also not able to register.
About a week later, my friend received an email stating that his registration was not complete but Google was holding a spot for him. Unfortunately, no such email landed in my inbox, so I resigned myself to the fact that I would be watching the live streams from home.
About four weeks after my failed registration, I heard that Google had set aside 100 spots at Google I/O for developers in 10 different development areas. Lucky for me, one of those areas was Android! The spots would go to the top ten entries in a programming challenge that would be open nationwide. All I knew was that the competition would consist of two rounds with the top two hundred scores from round one moving on to round two. Round one was a rapid question and answer session and round two was a programming challenge.
On March 16 at 12:00 PM EST the competition opened to all interested in participating. The first round consisted of six questions with a maximum of thirty minutes to answer. At 1:42 PM I received an email notifying me that I had made it to round 2 with the following directions:
Congratulations! You have qualified for Round II of the Android challenge. Starting from now, you will have until 9:00 A.M. PDT on March 17 to complete the following coding challenge.
Android Countdown to Google I/O
Make an Android app to get developers jazzed for I/O by filling the screen with the bouncing-balls countdown clock on the front of the Google I/O 2011 site. It has to be an APK (Android Package), and no fair using WebView. We'll give preference to smaller APKs over larger ones; show us how to do a lot with a little. Extra credit for bouncing bugdroids or other creative flourishes!
This meant that the round 2 contestants had 22 hours and 18 minutes to create an application from scratch and submit it to Google. I had seen the bouncing ball Web page and thought it was captivating to watch but did not give any real thought to how I would write an application to do the same, so it really was starting from scratch.
With less than a day to complete the application some developers would say there is no time to develop a specification and would just start coding from the seat of their pants. The reason good development starts with a specification is not because there is time for it but because there isn’t time for not doing a specification. The plan was simple. Make a class that represents a digit by balls that form 13 segments. By drawing the correct segments in an “on” color, a digit is formed. When the value of the digit changes some segments will transition from an “on” state to an “off” state and the class needs to return the positions of those balls. The positions of the balls that turn “off” are then used as positions on objects that are controlled by the physics engine that I would also have to write.
Following this simple plan I felt that I could create an application that closely replicated the bouncing-balls countdown clock and have the tools in place to add extras or reuse the digits in other products. By 11:54 PM I had the digits working, the physics engine controlling the bouncing balls, and the digits lay out in one row in landscape and four rows while in portrait mode. Then at 1:05 AM on the 17th I completed code that included the accelerometer influence on the balls while bouncing.
Kind of odd, isn’t it? Declaring time to within a minute for code that I wrote more than two months ago! Remember, this was very time sensitive development. Any loss of code or sneaky bug could derail my chances to win, so I used version control for the project. To get the times for this article I just looked at the git repository.
After the 1:05 AM check in I got a few hours of sleep. On the morning of the 17th, I refined some of the code and started to add some simple preferences. At about 10:00 AM I felt good about the application and decided to abandon adding configuration interfaces and submit the application as is. At 10:29 AM on the 17th I emailed my entry one hour and a half early.
I felt pretty good about the entry that I submitted. It was a good replica of the Web page and had a couple of extras, but I did not have any Android experience that I could incorporate into the application to save time or add real flare. On April 4th, I got an email from Google notifying me that I was one of the winners. My friend and I went from having a plan to go to Google I/O, to neither one of us able to register, to my friend being registered and going, to both going as originally planned!
From my prospective the most important lesson is that good development practices are applicable to any project, be it one developer on a one day project or a team of developers on a multi-year project.