Skip to content
 

The Android SDK – a quick run-down of the features and quirks involved in developing android applications

Firstly, in comparison to most other big tech companies google are great at helping developers get the most out of their APIs and software development kits. They obviously try quite hard to make developing applications using their technologies as straightforward as possible. However some of the features they do implement such as virtual testing environments, while clever, actually tend not to really be that helpful and often slightly buggy too.

Nevertheless I found it very easy to get started developing android apps using their developer site. The SDK and associated Eclipse plug-in they provide makes creating a new project from their template extremely easy and thankfully the template project is very minimal. This is definite boon as it can be extremely frustrating chopping out all the rubbish some Eclipse plug-in developers add to their template projects. As far as I’m concerned I always want to start more or less from scratch with this sort of thing.

With that said there is a certain app development pattern that you simply have to follow because of the way in which android apps get packaged and deployed on mobile devices. Therefore there are some concepts developers must familiarise themselves with and get used to because there is no alternative.

If you’ve used GWT you’ll notice there are some similarities in the SDK style. The Android SDK does try to do a bit too much for you: it generates the resources (‘R’) class on the fly for the purposes of updating Eclipse’s auto complete facility and to avoid IDE compiler errors. Which on one hand is a good thing, but I think that this, in combination with other automatic actions it carries out under the covers while your writing code, contribute to the fact that it seems somewhat buggy. Anyone who regularly uses Eclipse will know that from time to time it gets itself into a state of confusion, not surprising when you consider that it is constantly compiling code as you’re writing it to pick up compiler errors on the fly.

Also provided with the SDK is the facility to test your apps on virtual android devices. This is a very useful feature but occasionally you will find it gets itself into a state where you have to close the virtual device and start it again. This does take some time and I actually found it quicker to build the apps using Apache Ant and copying it across to a physical device connected by USB. This brings up some additional points  - the USB debugging feature was not possible with my device as the number of drivers for different platforms is fairly limited. But in actual fact its probably a more useful and realistic test to simply copy your apps (using the debug .apk which you can build with the ant ‘debug’ task) to the device and install them and run them properly.

I should probably mention that the supplied ‘tools’ which live in the SDK directory where you extracted the SDK to, include a useful tool called ‘android’ which allows you to generate an empty project. This allows you to edit and build runnable .apk files without using the Eclipse plug-in and indeed in any other IDE you may choose. Building the project is possible as mentioned using the Apache Ant script which the android task generates for you. This ability to generate a bare-bones buildable project is probably the most useful feature of the SDK in my opinion. Other platform tool developers could do well to follow this example, I know of plenty of open source projects that could certainly benefit from such a feature as much of the learning curve is often just getting everything organised so you can run anything at all.

I think this would be a convenient point to break my analysis of android development platform until I get a bit more used to it. Apart from anything else, I need to reboot my machine because Eclipse has become well and truly stressed out by the whole thing! Still its all good fun…

Leave a Reply