The development process of my Android app

I received a request from one of my readers, who wanted details on the development process of my Fake Dawn app. I wrote them a response and the mail has become quite consistent, so I decided to post it also on my blog, because it is a nice summary of what was going on in my head before and during the app development.

Fake Dawn Preferences Screen

Hello Eli,

thanks for your interest in my project. I read from your blog that you are writing a research on Android development, especially the birth of an app and what makes it special and successful in the end. I’m going to give you some details about the development of my Fake Dawn app, and I hope that they will be useful and insightful for your paper.

I am a software developer with a strong link to the Open Source world: all of my personal computers have Linux installed (Debian), and almost all of the tools that I use are free open source software (FOSS). “Every good work of software starts by scratching a developer’s personal itch.” and that’s what happened in my case. One of the most difficult moments in my day is waking up: I get startled by (or angry at) the alarm almost every morning, and that often impacts a consistent portion of my day. Most people know about sleep cycles and deep sleep, and one of the reasons people wake up badly is that they were in deep sleep when the alarm rang. I read somewhere about the effects of ambient light (especially light as blue as the sky) in pulling people out of deep sleep gently, just like dawn woke up our ancestors when there was no electricity or work hours. I wanted an alarm that could do this artificially, and the tool that I felt was most able to perform this job was my Samsung Galaxy I. I also wanted to try to develop an Android app for quite some time, and this seemed to be a reasonably simple project for a beginner. I had very few experience on Java development, but I have a good background in C#, and many concepts and software patterns can be applied to both of them. So I started the project.

I read the official Android developer documentation and guides and installed Eclipse and Android SDK on my Debian desktop. I wrote the classic “Hello World” app, which became the “sandbox” for my development. I then needed to decide the name of my app. I know the name is important in many ways, but I did not want to think too much about it, so I chose “Fake Dawn” as it’s short and simple. I believe it’s not the best name I could have chosen, for example I don’t know which combination of “Fake/Artificial/Electronic/Soft/… Dawn/Sunrise/Alarm/Wakeup/…” is more suitable/friendly. I decided that my app would be open source and free, because I didn’t want to gain money for something that I’m still not good at, and because my code would live as an example for all the others developers like me. I created an Eclipse project and I linked it to a GitHub repository for version control. I chose git because it’s very powerful (think about the Linux kernel development) and I wanted to try it on a realistic development process.

I needed to decide what API version to use. Google offers an informative chart about the number of devices with a particular Android version . This was very useful because I knew in a pinch that if I chose the Gingerbread API then I would leave out only about 15% of all Android devices (at the time). I decided to go for it and maybe later extend the support to lower versions.

The fact that I created a template project gave me the foundation to build my app upon, thus overcoming the “writer’s block” of a blank page. I had to plan the interface on this “Activity” baseline. I decided the principles to follow were simplicity and minimalism, for many reasons: it would lead to less buggy software, the app would be ready earlier and it would be simpler to use. So, the alarm that shines the ambient light would simply be a single-color solid screen, with just a digital clock. I decided that the color would be customizable, because I didn’t want to force the blue light on everyone.

First I wrote an interface that lets the user customize the alarm. I chose the default stuff like the TimePicker and radio buttons, but on the way I realized that I wanted something different, that could visualize what was going to happen. My app needs to set 4 important moments: the moment when the light start to rise, the moment when the light is maximum and keeps that way, the moment when the sound starts to play and the moment when the sound is at its maximum volume. I wanted to display the progression of the two, and so I thought about the “slider” interface that lets you move two pins and shows a gradient that represents the intensity of the light/sound. I built this control from scratch and the result is crude but I think it’s quite effective.

After testing this app personally for about a month, I decided that it was ready to be published. I needed access to the Google Android Market (now called Play), and to do so Google asks for a small once-in-a-lifetime fee. Then you have a dashboard where you can add your apps, and upload the packages (apk) of each app. The process is sufficiently straightforward, from exporting and signing the apk with Eclipse, to uploading the apk to the Developer Console, writing descriptions and uploading screenshots. Everything is documented on the official guide.

Once the app was published, I “advertised” it on my blog (shown also on LinkedIn) and on Reddit, so that I could have a decent number of installations to have some feedback. The feedback comes from comments, crash reports and talks with friends. The crash reports were very useful because they show in detail the stack that caused the crash. In order to keep track of the bugs I used the Google code issue list. From the crash details I submitted the bugs myself, and then I corrected them. Google code has a nice feature that lets you link issue numbers with commits and vice-versa, so that you can know which commit intends to fix which issue.

While searching for other open source Android apps to get examples and inspiration from, I discovered F-Droid. It’s an alternative market that collects open source apps, assures that they are really open source by recompiling the project and generating the apks, and then distributes them with an app that works in parallel with Google Play. Since my app is open source I wanted to put it in this repository, so I read the F-Droid documentation and guides (as explained in this blog post). I understood that it’s based on configuration files that automate the task of retrieving, compiling and publising the app, and I had the ability to write these configuration files myself. So I cloned F-Droid data repository, added the Fake Dawn configuration and submit a “pull request”. The F-Droid developers pulled my change and fixed it for me, and in a matter of hours my app was in the F-Droid repository. F-Droid has also an automatic check that detects when an app has been tagged in their public source repository, controls if the version has changed and updates its own repository with the new apk. Thanks to this functionality I can now almost forget that my app is also on F-Droid, I just need to create a tag in the repository when I publish a new version.

One thing that I should have done before, in retrospect, is using a testing framework. I’m starting to add it around my app, but it would have been better if I had done it from the beginning: the app would have been published later but I would have felt confident about the stability of the software, given that it could be installed on many different devices and by many different users.

The next steps of my development are kept in the issue list, supposedly but not necessarily in order of priority. The main areas will be solving bugs, improving reliability, improving usability and widening the user base.

[…]

Happy writing and best regards,
Francesco

Tagged: android, app, development, f-droid, fake dawn, git, google, java, open source software, testing

Posted in: Software