I have spent my summer working as a Research Assistant in the Intelligent Social Systems Lab at University College London. Most of my time was spent not actually researching things, but building an Android app for a research study. Having never done Android (or any flavour of mobile development, for that matter), I wanted to share some thoughts about my journey, from complete beginner to reasonable working proficiency. With the codebase for the app reaching north of 20,000 lines, I feel prepared to make some comments about the dev process and tooling of the environment.
In the very beginning, I spent a significant amount of time going through the official tutorials, in order to understand the basic building blocks and patterns of Android apps. I found them very concise, well-organised, and providing (unbeknownst to me at the time) solutions to most problems I would encounter. However, this can have certain disadvantages: there is a lot of unexplained "magic" happening behind the scenes, which can prove problematic when trying to extend or modify these examples.
One of the problems on which I spent a few hours on in my first week was a mysterious crash when testing the app on an older Android device. The app would, only on this device, crash seemingly randomly when starting up, or when returning to it from the background. A Singleton object I was using was inexplicably being nulled. After profiling the memory usage, it became rather obvious: the app was getting evicted out of memory. With only 768MB of RAM on the device, it should have been obvious to me from the very beginning. I decided to store the object in a Bundle, and restore it when the relevant Activity is resumed.
UI & Material Design
I am relatively mediocre at UI design, so I do not feel particularly qualified to assess the Android toolkit. However, I felt it was incredibly easy to design a decent-looking UI without much skill. The opinionated nature of the material design principles meant some of the difficult decisions were already made for me. The XML-declared layouts are similar enough to development on modern client-side web frameworks (e.g., AngularJS), so I presume any web developer would find working with these relatively straightforward.
I feel like the Android platform encourages brittle code structure to a certain extent. It is extremely easy to tightly couple view and business logic elements, leading to maintanability problems. Using the traditional MVC pattern renders the controller untestable, since it is tightly coupled to the Android APIs. A better approach I came across is MVVM, which is nicely explained in this article.
Some of the libraries I used to improve code reuse and cut down boilerplate were:
- Dagger2 - dependency injection à la JSR303
- ButterKnife - cutting on boilerplate for binding UI elements
- Retrolambda - nice backport of Java8 lambda expressions, compatible with older platforms
Fragments & Activities
One of the things I disliked was the ambiguity between the roles of activities & fragments. For more complex usage scenarios, I have found myself needing to use a nested fragment and managing the logic of switching between views manually. This has resulted in significant bloat in parts of the codebase for the app. To a large extent, it seems like the jury is still out on this one.
Despite some of the disadvantages I mentioned, I really liked:
- the homogeneity of the environment, contrasted to web development, where there are thousand of choices for literally anything. However, I presume it can get rather tedious the more projects you do, since you are stuck with Java (and Kotlin, not too long from now).
- the tooling. I am a big fan of JetBrains' products, and I think Google made the right choice with Android Studio. The environment is very pleasant to work with.
- having to be careful about memory footprint, something which I did not have to worry about at all in the (mostly) back-end systems I developed so far. Having lots of multimedia content getting passed around becomes challenging.
I'll certainly be coming back to Android development. There is something really exciting about plugging in the cable and seeing your app run on the device.