A Developer's Perspective and Experience

Android: The Story So Far


Brett Kromkamp shares a developer’s experience on the tidal wave of mobile computing.

When I think back on the last twelve to eighteen months of Android and everything surrounding Android I am just astonished at how far Google’s mobile OS and platform has come in what is a relatively short period of time.

When Android was launched in September 2008 (if my memory serves me correctly), I barely took any notice. I admit now that at the time I thought it was one of the Google engineers’ “20 percent time” projects and would, in all likelihood, not survive its first year. Obviously, we all know now that it was a mistake to underestimate Google’s intentions for their mobile platform.

However, even though I initially disregarded Android when it was launched by Google, one year later, in September or October of 2009, it became apparent, based on the number and quality of new devices that were being launched, that Android was going to take off big time and it required no real leap of faith to see that mobile computing (in all its possible forms) was going to outright dominate this field of software development for the foreseeable future. Mobile computing is going to be big… really, really BIG.

So, Android’s popularity has seen unprecedented growth over the last year. It has gone from a minor mobile platform hardly worth consideration, to either the second or third (depending on who you listen to) biggest Smartphone platform in terms of operating system share. For example, Gartner has claimed that Android has become the No. 2 worldwide mobile OS in 2010 and will be fighting for the top spot by no later than 2012 or 2013. Furthermore, the global mobile market will continue to see substantial growth figures for the foreseeable future and I expect that there will be room for several players. This is not a one-horse race. Apple’s iOS, Google’s Android, RIM’s new QNX OS (to be used in the forthcoming PlayBook) and even Microsoft’s Windows 7 Phone OS will all have a place at the table. And let’s not forget Nokia. A lot of developers I speak to seem to have forgotten all about the mobile giant because of the tech-press’ almost exclusive focus on the looming, epic battle for mobile dominance between Apple and Google. However, Nokia is a force to be reckoned with and, in my opinion, their MeeGo project has a lot of technical merit. Let’s see if they can come up with the required (consumer and developer) marketing strategy to ensure their platform’s relevance.

Perhaps, out of all of the current mobile platforms, Microsoft’s Windows 7 Phone OS could be the one that eventually falls by the wayside. It could be a case of “too little, too late” for Microsoft. However, if anything, tech history has shown that it is foolish to count Microsoft out too early in the game. They obviously have deep enough pockets to continue to invest in their platform. I also believe that for the first time Microsoft is really committed to their mobile platform. They have come to realize that it is a strategically vital part of their product portfolio in its own right and not just a simple extension of their desktop OS.

However, for a technology to survive, especially a consumer-facing technology, it has to be completely aligned with (and, to a certain degree, even drive) consumer trends. Currently, the hot trend (with Apple’s iPad leading the way) is the tablet paradigm. Google’s response to the tablet trend was the development of Android 3.0 (codename Honeycomb), which in their own words “is a new version of the Android platform that is designed from the ground up for devices with larger screen sizes, particularly tablets” making for very interesting times ahead of us with regards to the competition between Apple and Android in the tablet space.

Personally, I am very excited about Android 3.0. Just like the iPad allowed developers to really go to town in terms of exciting new apps which really take advantage of the bigger screen, the same holds true for Android 3.0 tablets. Obviously, Honeycomb adds several new features that specifically contribute to an enhanced user experience, including (but not limited to)

• Fragments – a new framework component that will enable both a richer and more interactive UI.

• Drag and drop functionality.

• Enhanced animation framework.

• Extended UI framework and new “holographic” UI theme.

• Hardware accelerated 2D graphics and a new 3D graphics engine.

• Support for multi-core processor architectures.

Furthermore, additional functionality includes a new digital rights management (DRM) framework which will open the door to companies like Netflix adopting Android as a content delivery platform.

So, with all of the current innovation taking place within the mobile space by so many different companies, as a mobile developer you are faced with several competing platforms and you have a finite amount of time to learn and (truly) master one. Which one do you pick? Like always, it depends on several factors and I’ll list the ones that I considered when deciding which platform to start developing for:

• Current development-related skill-set and experience.

• The platform’s commercial viability in combination with your financial motives.

Let’s take a look at the above factors, starting with the first one: obviously, each platform has its own specific tool-chain comprised of programming language(s), development environments, and so forth that you will need to become familiar with before you can commence developing for said platform.

For example, when it comes to iOS-development you are looking at Xcode and Objective-C for your development environment and programming language, respectively. If you have already developed for Mac OS X it probably will not be a major hurdle to start developing iOS apps. Likewise, with Android it’s all about Eclipse (and now also IntelliJ IDEA with version 10 of the IDE) and Java. So, if you have any kind of experience with Java and the Eclipse IDE you might be more inclined to start developing Android apps. And finally, for Windows 7 Phone apps, your weapons of choice are going to be Microsoft’s Visual Studio and C# (and Silverlight). So, depending on your current skill-set you might want to choose to develop for a mobile platform that doesn’t require you to learn a completely new set of tools, languages and development environments.

However, for a lot of (independent) developers, their attention will have been drawn to mobile development by the press’ tendency to focus on the financial success stories of some of the (primarily, Apple App Store) developers. Inevitably, when you read stories of developers that have made a substantial sum of money with what, in hindsight, seem to be relatively simple apps, you think to yourself “I could have done that.” Clearly, as a developer, there is definite value in adding mobile development skills to your tool belt. The trend is obvious and irreversible; that is, more and more people (and eventually, the vast majority) will want to both access content and interact with web-based services from their mobile devices. Companies will need to ensure that they can take advantage of this phenomenon and hence we will see a tangible increase in the demand for developers with mobile development skills and experience.

However, I personally believe that you are doing yourself a disservice if you exclusively focus on the potential financial rewards of mobile development. Financial motives will, without doubt, be a factor, but I think it makes more sense to have a combination of goals that you will want to pursue when deciding on which platform to develop for. Let’s be honest: mobile development is just plain cool. I haven’t been this excited about a development-related technology since Ruby on Rails was released back in 2005. The reason for this excitement being that, from a development point of view, the possibilities are practically endless. Useful mobile apps really have the potential to become a big part of people’s lives. So much so that in less than five years time we will not be able to imagine how we managed without our mobile phones and the accompanying applications that we have installed on them.

So, once you have decided on a platform, you need to actually start developing. My choice of platform was Android.

I was already familiar with Java development and getting the (Eclipse-based) Android development environment up and running was very straight-forward. Furthermore, I could develop Android with any host OS. That is, in order to develop for iOS you need to have a Mac box at your disposal. Likewise with Windows 7 Phone OS, you are forced to do your development on a Windows box. Not so with Android because of its Java underpinnings. My preferred OS is Ubuntu and Android development on Ubuntu is an absolute joy.

Anyway, with regards to actual Android development, what has my experience been so far? How did I go about learning the platform and where are the potential pain points? Your first port of call has to be the Android Developers ( website. Before you do anything else, read (and understand) the Application Fundamentals section in the Dev Guide. If you take any piece of advice away from this article, it would have to be this. Once you have a bird’s eye overview and understanding of the Android software stack you can move on to installing the SDK in conjunction with Eclipse. Again, your friend here is the Dev Guide. All in all, Google’s Android developer documentation and accompanying blog are an excellent source of development-related information.

Once you have Eclipse (or IntelliJ IDEA 10) and the Android SDK installed, the next step is to start looking at some of the samples that are part of the SDK. Import them into your IDE, tweak, compile and run them; they will provide you with a lot of insight into various aspects of the OS and will potentially give you ideas for your own apps.

What’s next? I think every developer has their own version of the “Hello World” program; a program that is the first one that you implement with each new programming language and/or platform that you are learning. In this case, the problem space of your Hello World program has to be small enough to allow you to only focus on Android development while still including sufficient elements to make for both an interesting and valid learning experience.

Once you have finalized your Hello World app it is time to move on to your first serious development project. In my case, the first app of any real substance is NotesMappr, a note taking app with semantic features. For all intents and purposes, NotesMappr is a typical (non-game) Android app in the sense that it is comprised of various activities that incorporate several (relatively complicated) widgets like the AutoCompleteTextView widget, the ListView widget and the Expandable-ListView widget. I recommend that you read the development documentation for these widgets carefully and examine the accompanying examples. Furthermore, ensure that you have a proper understanding of the BaseAdapter class and some of its subclasses like ArrayAdapter, CursorAdapter and Simple-CursorAdapter all of which are purposed towards binding a specific type of data and display.

An additional concept to master with regards to Android development is data storage, specifically content providers. Content providers are the only way to share data across applications (for security reasons, I expect). This includes Google’s own Android applications like Contacts and subsequently, access to the phone owner’s list of contacts is only possible by means of (existing) content providers. Furthermore, implementing a content provider will allow you to integrate your application with the rest of the OS, specifically with Search and the Live Folders feature (which is a real-time view of a content provider). Getting to grips with Android’s content providers (and the accompanying concept of content resolvers) and the SQLite-based backing store API is essential, in this respect.

Next item on your list of Android development topics to master is (multi) threading. Android’s UI toolkit is not thread-safe. What this means is that you should not manipulate the UI from any thread but the (main) UI thread. I can confirm that failing to do so will result in some spectacular stack traces. But it is vital that you keep the UI thread unblocked otherwise you risk the infamous Application Not Responding (ANR) dialog. The Android OS will display the ANR dialog if an application does not respond to an input event within five seconds. What does all this mean to you, the developer? In simple terms, if you have a long-running operation involving, for example, network access or computationally expensive calculations, simply spawn a worker thread in which said operations should be performed and periodically communicate back to the main UI thread by means of a Handler. For reference sake, a Handler object allows you to post results from a (worker) thread back to the UI thread to update the views on the UI thread as needed; this is a standard pattern of multi-threaded programming on Android.

Finally, developing mobile applications poses a series of User eXperience (UX) challenges. Why? First of all, the small screen and secondly, specifically with regards to mobile phones (perhaps not so much so with tablets), the potentially less than ideal situations in which mobile apps can be used; such as, on a busy bus or while standing in a queue in the supermarket or bank. These factors absolutely dictate the design of the application from a UX point-of-view. Consequently, for many types of mobile apps, it makes sense to adopt a so-called hub-and-spoke interface: a UI that contains several discrete tasks that are all reachable from one central screen (the hub); however, the individual screens of the app (the spokes) are not directly navigable from one to another. This arrangement works very well for mobile apps, since it narrows the user’s focus to a small set of choices at any given time, preventing (user) errors due to a simpler and (hopefully) more intuitive interface. Obviously, it depends on the kind of app that you are developing as, for example, the typical calculator app will, in all likelihood, not require a hub-and-spoke UI. Mobile apps require a different mindset when it comes to designing effective and user-friendly interfaces for which there is no straightforward mapping of design patterns from conventional web and desktop applications to mobile apps.

In summary, with regards to actual Android development, the key is to ensure that you have a proper understanding of the system’s principal components and how they relate to one another. Mobile development in general and Android in particular, require a different way of thinking on behalf of the developer, specifically, with regards to UX and the accompanying user interface. Nevertheless, due to Android’s use of the Java language and its reliance on the Java ecosystem, those developers with a Java background will definitely not find themselves out of their depth.

So, there you have it. The tidal wave of mobile computing is upon us. The pace of innovation taking place within the mobile space is absolutely phenomenal. And make no mistake… although we have touched upon Android version Three Point Zero in this article, what we have seen up until now within the mobile industry can be considered to be no more than a mere dress rehearsal. The actual play is about to start and Android is poised to be the star performer.

After graduating from both Hogeschool Holland (in The Netherlands) and Wolverhampton University (UK) in 1995 with a BA (Hons.) degree in Business Administration and Marketing - an Erasmus ( study - Brett Kromkamp started working for a local software company, developing applications specifically aimed at the tourist industry (with Borland Delphi). In 2004, he accepted a position within the Resort Properties Group as a Software Developer. Initially, he focused exclusively on web development until 2008 when he became Team Leader for both the Web team and Desktop team within the company's IT Department. In 2009 he became Head of Software Development within the group. Designing and developing software is his passion and in 2010 he decided to focus, in his spare time, on building his own mISV: PolishedCode (

Inline Feedbacks
View all comments