Revisiting Android Development

A long while back, I wrote an article which amounted to “the android sdk sucks.” Since then i’ve had quite a few comments about it, so I’ve devicded to re-evaluate Android Development.

The platform

Since 2009, android had gone through 3 major releases. There are literally hundreds of devices you can target, stuck running everything from 1.6 to 4.1.

In a way this is similar to PC development. You have literally no idea what sort of hardware or OS people are going to run your software on.

Thankfully nowadays Android has a fairly sophisticated set of options for specifying minimum hardware requirements in the application manifest. Starting with version 3 there are also vast improvements in support for different screen sizes and resolutions.

Unless you are doing something incredibly weird or want to support absolutely every device, hardware diversity is the least of your problems with the current SDK.

The SDK

The Android SDK is heavily influenced by what I like to refer to as the “Java mindset”. When developing an app expect to be dealing with lots of XML files, complex Java abstractions, and strange tools.

It’s also quite large (though not as large as the iOS SDK) - I easily spent an hour downloading both the base SDK and the extra packages for eclipse development.

Eclipse is still the recommended IDE for development, though you can still run all of the tools from a terminal if you find it completely intolerable.

IDE

The only major improvement I noticed with the current eclipse plugin is that the GUI builder has greatly improved. Honestly, I now feel as if I could implement a proper GUI with it.

Emulator

The Android Emulator, your only way of accurately testing an app without buying a real device, is still sadly quite slow. After turning on GPU emulation (which is oddly disabled by default), performance improves slightly though it still feels quite laggy. If I was going to do Android development professionally I would definitely get a real device.

Documentation has improved by miles. There are a lot more useful examples of how to do things, and the documentation for classes has greatly improved. I can actually follow it and not screw up.

Last time I mentioned the documentation for writing OpenGL Applications was a bit lacklusture. I can safely say this is no longer the case - there are now useful examples, both in the examples and the actual class documentation. Not to mention, OpenGL support on devices has definitely improved miles.

If your codebase relies heavily on C, Android provides a Native Development Kit (NDK). I haven’t looked much into this, as the process to use it seems fairly overly complicated and doesn’t appear to be integrated well with eclipse.

The Android SDK is of course not the only way to develop for Android. There are also solutions such as Mono for Android and Unity. I haven’t used any of these, but I have heard good things about them.

To Conclude

Both the Android SDK and Ecosystem have definitely improved by miles since the last time I looked at them. In a way, Android has matured.

While the SDK is still a bit rough around the edges, I think if you get used to it, you should be able to make some good apps with it.

Maybe i’ll be developing some Android apps in the future…