We have been doing quite a bit of Android development over the last year and a half at Pivotal Labs. Over time we have compiled a set of go-to tools, and libraries, and configuration settings that help make our development process as productive as possible. We are excited to publish two open source projects, each with the goal of helping new Android development projects hit the ground running: Android IntelliJ Starter and Android CI.
Android IntelliJ Starter
Android IntelliJ Starter (github project here) is a “template” IntelliJ 10.5 project created to bootstrap Android development in IntelliJ. Our goal: start test-driving your new Android project within minutes, not hours (or days) using the Robolectric framework for testing and Robojuice framework for dependency-injection. In addition to the starter application and unit tests many other supporting libraries are provided, including C2DM push notification libraries with a stubbed-out, documented C2DM implementation class.
Android IntelliJ Starter represents hard earned configuration knowledge as well: getting all these tools to work seamlessly in IntelliJ and on the command line using
ant is no small feat. We’ve even provided instructions on how to remove the extra tools and libraries — configuration by deletion.
Android CI (github project here) is intended to bootstrap Android continuous integration using Jenkins-CI (formerly Hudson). This project is a stripped-down version of Jenkins’ configuration directory, which is
~/.jenkins by default.
Android CI ships with one preconfigured job: running tests and building .apks for Android IntelliJ Starter. If your project starts as a clone or fork of Android IntelliJ Starter then Android CI’s configuration will work well for you with only a few simple changes.
Help Us Improve
At Pivotal Labs we are committed to making Android development as productive as possible. We will add more functionality to both projects over time and we encourage others to fork, enhance, send us pull requests, and to use the Issues tab on each Github project’s page to notify us of problems so we can fix them promptly.
Most of our Android projects are using great-expectations, which brings Jasmine-style test assertions. Thanks, Xian, for writing this!
Robolectric Enhancements — Stay Tuned
We have a bunch of Robolectric enhancements, including the ability to wire up
BroadcastReceivers by just declaring them in
AndroidManifest.xml. We’ll have to put some pull-requests together soon.
Roboguice uses Robolectric!
We use Roboguice on most of our Android projects for dependency injection. We discovered that Roboguice is using Robolectric for unit testing. Awesome!
Un-shadowed Method Warnings!
In response to yesterday’s question about Un-shadowed Method Warnings, Pivot Tyler points out that you can turn these on by calling
On two workstations every unit test was failing with the following error:
// …many levels of stack trace, finally:
Caused by: com.xtremelabs.robolectric.bytecode.IgnorableClassNotFoundException: msg because of javassist.NotFoundException: android.content.DialogInterface$OnShowListener
Cause: there was an old
tmp/cached-robolectric-classes.jar that was causing these errors and our tests ran successfully after deleting it. That’s two answers from Pivot Tyler!
Don’t DDOS Yourself With Your Own App
The Bump Android team wrote an article about a good idea gone wrong. Moral of the story: not all devices behave the same, and this might cripple your servers rather than the devices.
Robolectric Google Group
Join it, contribute, and learn about unit testing your Android apps.
We’re trying an experiment: since we currently have several Android projects at Pivotal Labs, and Android development and testing is hard, we are going to post to the blog the tips, tricks, gotchas, and conundrums we find.
Emulator and Orientation
Android will destroy and recreate activities upon screen orientation change. One way to prevent this is to set
android:configChanges="orientation" in your
AndroidManifest.xml (article here):
This prevents android from calling
onCreate() on a device, but not within the emulator; annoyingly, the Activity is still recreated within the emulator.
Un-shadowed Method Warnings?
Once again we spent about 15 minutes debugging a failing unit test only to find that there was no Robolectric implementation/shadow for one of the Android methods under test (
ArrayAdapter#insert in our case). I would be nice to have a “warning mode” where Robolectric would log warning for all un-shadowed methods. I wish we knew the guys who wrote Robolectric…