Anda di halaman 1dari 4

3/4/2014

Removing the pain points from Android development

Endless While Loop (/)


Removing the pain points from Android development
February 24, 2014 Ive been doing a lot of Android development over the past year or so and Ive gradually accumulated a handful opinions about what I think sucks the most about it. Overall I think its 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.

http://endlesswhileloop.com/programming/android/2014/02/24/removing-the-pain-points-from-android-development.html?utm_source=TapFame&utm_camp

1/4

3/4/2014

Removing the pain points from Android development

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 (https://github.com/square/mortar) that does just that. Mortar gives you a very simple interface for creating view controllers (or presenters as they call them). I havent 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. Its 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 Nuriks Muzei (http://www.muzei.co/) and DashClock (https://play.google.com/store/apps/details? id=net.nurik.roman.dashclock&hl=en) are both great examples of this). However, its 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 (http://developer.android.com/reference/android/os/Bundle. html) and manually pulled out and validated when the activity starts. Gross. The same problem applies to

http://endlesswhileloop.com/programming/android/2014/02/24/removing-the-pain-points-from-android-development.html?utm_source=TapFame&utm_camp

2/4

3/4/2014

Removing the pain points from Android development

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 (https://github.com/square/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:
f l o w . g o T o ( n e wT r a c k ( a l b u m I d ,p o s i t i o n ) ) ;

Proper unit-testing This one baffles me the most. Googles 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. Thats an insane amount of time and makes TDD impossible. An obvious solution would be to run the tests on the JVM. Robolectric (https://github.com/robolectric/robolectric) makes this pretty easy, but its extremely difficult to setup with the new Gradle-based build system. Its slowly getting better, but it still requires lots of hacky Gradle scripts (https://gist.github.com/mfremont/9073002). It would be great to see Google come up with an official, easy to use solution.
http://endlesswhileloop.com/programming/android/2014/02/24/removing-the-pain-points-from-android-development.html?utm_source=TapFame&utm_camp 3/4

3/4/2014

Removing the pain points from Android development

Another solution to this problem is to keep any non-Android specific code in a separate Java project.
Tony Cosentini - about (/) / @tonyc (http://twitter.com/tonyc) / email (mailto:tony@endlesswhileloop.com)

http://endlesswhileloop.com/programming/android/2014/02/24/removing-the-pain-points-from-android-development.html?utm_source=TapFame&utm_camp

4/4

Anda mungkin juga menyukai