My Android Toolbox
★
Most of the people who have done server side Java development are approaching Android the same way. Android is Java, right? So where is my dependency injection? How can I configure things with annotations? How can I unit test? How can I just include my usual 400 libraries or my favorite JVM language with giant dependencies? Turns out programming for an embedded device is different. You do not use dependency injection and program against interfaces because performance and lazy loading are everything. You test most parts in context (using Instrumentation) and yes, configuration is done in XML(thankfully, resources at least get translated into classes). Also, library size and speed matter (so most JVM languages like Scala, even after the proguard treatment, are unfortunately out of question). And finally, you will feel the pain of not having (less noisy) closures in java more than in server side development, thanks to Android’s callback-centric design.
That all being said, there are things you can do to improve your development environment, so here is a list of tools that I found particularly useful.
Rapt
What gave me the idea to look into source generation was Duby which is the only JVM language without a runtime. Essentially it generates java source files and while Duby is great, I wanted to use Java. Then it just hit me: during the first wave of the closure debate, Bruce Chapman presented a solution which was based on the idea that one could generate the boilerplate code for SAM creation via annotation processors. So I gave it a try. Unfortunately, the version attached to the article did not work with eclipse 3.5, so as a good open source citizen, I went ahead, forked the project, retrofitted changes from various versions and cooked a release. Let’s see it in action
What’s happening here is that rapt is generating SAM types for call() and foo() and make them available in the same package (the generated class files’ naming convention is SAM type+”s”). The @As.Additional parameter is used to pass extra fields.
It’s worth mentioning two things a) it’s type safe: adding unnecessary non @As.Additional parameters will result in an error, highlighted by eclipse b) generated source is kept in your generated source folder and it’s updated incrementally upon save. Finally, you can also see another rapt feature which is generating multiline strings from comments.
library size: 20K (compile time dependency only)
Jedi Java
Jedi Java is using exactly the same technique but it’s focusing on collection access.
you can find more examples here
library size:141k
VDT-XML
There are various ways to parse XML on Android, the problem is almost all of these solutions are fairly slow. Enter VTD-XML which is a new and very fast XML parser library.
here is an example on how to parse an RSS feed:
library size (light version): 66K
UPDATE:
re: Xml Parsing, the XmlPullParser is silly fast on Android. @crazybob re-wrote it to create almost no objects, so you don’t get hit by hardly any GC. This is what the Google teams were using when I spoke to them at IO. Here is an example.
Html Helper
One of the common tasks while developing for Android is to call HTML based services and even though the low level APIs and apache HtmlClient are there, they are cumbersome to use. Thankfully there are a few single-class wrappers out there (for example this) that can simplify your client code:
IO and File Helper
The other area where a wrapper can help a lot is IO (and more specifically dealing with files). The example below is using Romain Guy’s IOUtilities and a small FileUtility
PowerMock
Finally, using PowerMock one can easily test otherwise untestable code. The example below shows how to bypass a constructor:
