Standardizing Android development

When I first started working with Android development, I was confused to no end.

I wasn’t confused not necessarily due to the Android framework, writing Java, and whatnot, but mostly due to lack of documentation on the standard practices when it comes to building Android apps. This might have a little bit to do with the fact that I was coming from the Ruby on Rails ecosystem, where the “convention over configuration” paradigm reigns supreme.

For example, in Ruby on Rails, if I want to query the database, there’s ActiveRecord that comes with the framework. If I wanted to send mails, there’s ActionMailer. If I want to run background jobs, there’s ActiveJob. If I want to <insert whatever a typical web application should do here>, there’s… you get my point. The thing is, Ruby on Rails came with standard ways of implementing the majority of what your typical web application should be able to do out of the box.

In Android, there was no such ecosystem built into the framework. The course I took on Android development had the students manually making HTTP requests to request data from the API, writing raw SQL queries to cache and query the local SQLite database, and so forth. However, as we all know that in the real world, no one develops applications this way. Rather than writing raw queries, we use ORMs to make our lives easier. And rather than coming up with our own ways to manage network requests, we tend to use libraries to set up our API calls simple to make.

In an ideal world (or at least in my ideal world), all these features would be baked into the Android framework. Anyone new to Android development will have the ORM, API mapping libraries, and other components needed to build apps out of the box. Instead, what we have to do today is utilize third party libraries to fill in the holes that the Android SDK doesn’t.

Third party libraries are great. I believe that having a plethora of third party open source libraries is part of what makes a great community. Ruby on Rails for example has open source gems written by individual contributors (or companies) for just about anything you can think of. This is not to say that Android doesn’t either, but the problem in the Android world is that because a lot of these functionality has to be provided via third party libraries instead of by Google, lots of new developers have to spend time picking which libraries they should use.

For example, what do you use if you need an ORM? Do you go with GreenDAO, SugarORM, or Realm? If you need an easy way to display images, do you use Glide, Picasso, or some other library? Thankfully, some of these choices become obvious quickly because the Android community have decided on which libraries to use in most projects. For example, Retrofit is the default go-to for setting up API calls. However, for types of libraries like ORMs, the choice isn’t as clear.

This problem isn’t just unique to the lack of default libraries provided by Google. It applies even in how Android apps are structured. In many full stack web application frameworks, when you start a new project, you’re given a default folder structure for where to put your models, controllers, views, and etc. In Android development, you get nothing. Literally nothing, with the exception of your assets. Every Android project that I’ve worked on had different folder structures, and it always took me some time to adjust to the codebase’s organization and become productive. Contrast this to something like Ruby on Rails, where it’s reasonable for a new developer to start committing new code within the first hour or two of project setup thanks to its convention over configuration paradigm.

When it comes to the folder organization/structure of the codebase, the Android community have tried to alleviate this problem via promoting certain architectural patterns like MVP (Model-View-Presenter). The problem with this is that everyone has a slight different way of implementing these patterns, thus leading to further fragmentation.

Some people might say that this is a good thing. That developers are given the freedom to pick and choose what libraries they want to use and how to go about structuring their codebase. While this argument has some merit, I have to disagree in that it unnecessarily raises the barrier to entry for new aspiring Android developers. Frankly, I think it also decreases overall productivity for the entire Android community. Every time I jump into a new codebase and I see some new library or architectural pattern, folder structure, and etc that I’m not familiar with, I go, “Ugh, now I have to spend time and mental energy figuring out this developer’s brain thought process rather than solving the actual problem on hand”.

One could argue that the amount of mental energy needed to absorb how a new codebase is structured or even choosing which library to use is miniscule. Perhaps they are insignificant individually, especially for simple things like choosing a library to display circular images, but all these are decisions that you have to make. And the energy spent making these tiny decisions eventually add up over time. This is mental energy that could have spent actually building the app or fixing bugs.

There have been recent efforts by the Android team to standardize this by releasing Android components. There have been many blog posts about Android components like Room, LiveData, and etc. In fact, I was listening to an episode of the Android Developers Backstage podcast (episode link and the hosts talk about this exact problem where there’s a lack of standardization and conventions in the Android development world and Android components is the Android team’s effort and addressing this very issue.

These component libraries by Google are still in their early stages and I believe that it’ll take some time for a lot of older Android apps to start integrating these into their codebase. As for me, I’m excited by the notion that one day, I’ll never have to think about problems that aren’t directly related to domain problem of the app that I’m working on. Just think about it. Being able to jump into a project and immediately knowing where everything is based on the community’s conventions and being productive right away. Sounds great to me.