A layman’s experience in Android app development

keep-calm-and-fix-crashes-1To learn Android development, this has been in my new year’s resolutions for the last couple of years. Never achieved. You can’t blame that I wasn’t serious. I paid for the book and the online course, not to mention glimpsing into some free online resources. I installed the Eclipse+SDK, I installed Android Studio. I followed some chapters, like project setup, like different layouts. I am even a converted Android phone user (and a happy one).

Being a full-time iOS developer and family commitment were two of my biggest excuses for not achieving this goal.

Now I have a new theory – I (and many people) can’t just quickly gain a new skill without being put under pressure. It’s like making running a marathon one of your new year’s resolutions but never being able to do that, because what? you’ve never signed up a marathon race!

speaking of running my first marathon, here is a short video recap

k, back to the topic. so thanks to the new gig, I got to maintain an android app codebase (as well as its equivalent iOS part, which is way less challenging, of course). What I am facing is to fix some weird Android crashes, which I couldn’t reproduce on my own dev environment. Mind you, the app is in production with a large active user base, and I was under pressure to reduce the crash rate asap.

No time for textbook, I immediately jumped in and started smashing the code…debugging the code I mean. With merely more than a month,  though the crashes hadn’t been totally eliminated, I finally got my head around this Android madness and wanted to share a thing or two:

  1. Android Studio as an IDE is more enjoyable to use than Xcode, so enjoyable that I want to talk my boss into purchasing an enterprise license for App Code, an Xcode alternative which is also backboned by IntelliJ IDEA. Easier refactoring, method/var usage check, and code optimising hints are among many reasons why I prefer Android Studio and App Code.
  2. Build.gradle file is like a combo of info.plist and Podfile, where you define product version/build number, third-party libs though you don’t need to run external command line to update your pods, the “Sync Project” does the job (and syncing project is VERY slow).
  3. Releasing APK seems to be a lot easier than releasing IPA, no matter ad-hoc distribution or store release. Although Apple has been trying to streamline the iOS app provisioning since Xcode 5, many iOS books still have a dedicated chapter on this topic.
  4. Being able to check Android SDK implementation is a huge plus, though honestly I don’t read the implementation very often, just feeling by saying so makes me sound like a pro
  5. Using XML layout files has a bit of learning curve at the beginning, but pays off in the long run. I would say this UI programming paradigm was well thought through since day one Google introduced Android SDK, as they anticipated the great variety of device screen sizes. On the other hand, storyboard, auto-layout, and size classes, to me, they’ve been introduced to put out fire rather than to solve the problem fundamentally.
  6. ListView in Android, as the counterpart of UITableView in iOS, is way maturer. It doesn’t even ask me the heights of my every single cells! (yeah, iOS 8 can do that too, I heard that, after so many years, after so many hours wasted of calculating the freaking cell height)
  7. The Android Studio debugger tool is more convenient than Xcode debugger, can virtually add any thing to Watch (no need to “po xxx” in the console). In case of app crashing, the console output often contains the source code line that throws the exception, and you can click on the line to jump to the right source code.
  8. Thanks to the x86 image, Android simulator is not that slow to boot up, Genymotion can be even faster. Nevertheless, in terms of our day-to-day business (code-run-test-code-run-…), using Android simulator can’t beat iOS emulator.
  9. to be extended once I notice anything interesting


Big big lesson learned: activity/fragment lifecycle matters

The data objects stored in the activity/fragment (they are similar to UIViewController and UIView, but not exactly), either created during the activity/fragment lifecycle, or passed in from another activity/fragment, you DO NOT take the assumption that those objects can live forever, as their owner the activity/fragment may not live forever.

Activity/fragment get deconstructed and re-created time from time, basically because of Configuration Change, or of insufficient heap memory, or of other reasons. So always ask yourself, next time this onCreate() method is called, can the data objects referred in the method be reliably accessed? In a short period of time, I learned to deal with this, we can use:

  1. serialisable objects
  2. parcelable objects
  3. global vars across application or a singleton (hugely debated on stackoverflow)

My current approach is 1 + 3, as implementing parcelable is non-trivial tasks even with IDE plugin. As I said, many crashes I’ve been trying to solve are related to this. By the moment I’m writing this blog, I’m still trying to solve some persistent crashes. I may later write another blog to summaries this. As I’m still new to this Android dev, any suggestions and corrections are welcomed.

So the mantra is, as seen on the title image, keep calm and fix Android crashes.

Edit on 3 July 2015: according to this article Don’t Store Data in the Application Object, saving global objects in Application is not safe as well.