Removing the pain points from Android development
I’ve been doing a lot of Android development over the past year or so and I’ve gradually accumulated a handful opinions about what I think sucks the most about it.
Overall I think it’s getting better. The new build system and IDE are leaps and bounds better than ant and Eclipse. However, I still think there are some big issues that make it difficult to develop a polished, stable Android app.
Here are some of those issues.
Stop treating activities like view controllers
Nearly every app uses activities as if they are view controllers. However, the lifecycle of an activity is quite complex and they should be treated more as “little apps” within your app instead of individual view controllers.
Google kind of has a solution to this: fragments. Unfortunately the fragment API is just as confusing as the activity API and adds even more complexity to the problem.
My ideal solution is a simple system that just uses plain old views and a controller object to handle each screen.
Square has recently released a new library that does just that. Mortar gives you a very simple interface for creating view controllers (or presenters as they call them). I haven’t used it that much, but it seems like a step in the right direction. It would be nice to see Google acknowledge this problem.
Intents are too fragile
Intents are generally great for inter-app operability. It’s what allows you to change default apps, send and receive data from other apps (for example, accessing the Barcode Scanner app to scan QR codes), and even write plug-ins for other apps (Roman Nurik’s Muzei and DashClock are both great examples of this).
However, it’s also what apps must use internally to jump from activity to activity. This means that any parameter you want to pass to an activity needs to be serialized in a bundle and manually pulled out and validated when the activity starts. Gross. The same problem applies to fragments, you must always use an empty constructor when creating a fragment and pass in the arguments as a bundle.
Once again, Square has a much better solution for this called Flow. It allows you to break up your app into simple screens and avoids all the intent nonsense by just using simple constructors like so:
Proper unit-testing
This one baffles me the most.
Google’s official unit-testing system for Android requires you to build a special test APK that you must upload to a device in order to run any kind of unit tests. For my current project at work, this takes about two minutes to complete. That’s an insane amount of time and makes TDD impossible.
An obvious solution would be to run the tests on the JVM. Robolectric makes this pretty easy, but it’s extremely difficult to setup with the new Gradle-based build system. It’s slowly getting better, but it still requires lots of hacky Gradle scripts.
It would be great to see Google come up with an official, easy to use solution.
Another solution to this problem is to keep any non-Android specific code in a separate Java project.
Update 3/12/14: I want to clear up some things with regards to Mortar and Flow. While these libraries are both great, the point I was trying to get across was that Google should officially adopt this kind of style for handling view controllers.