Developing for Android

I'm frankly surprised that it's taken me so long to get around to making a post of this flavor, but here we are.  Unless you've been living under a rock for the last 10 or so years, you know that Android is the dominant player in the mobile operating system landscape.  Because Android is "open" (sometimes to its own detriment) and capable of running on so many different types of devices, its usage numbers tower over those of iOS.

So what of the prospects of easy, enjoyable development?  I took a brief look at iOS a few years back, and unless things have changed dramatically over the last few years, it's bleak.  It's a very opinionated ecosystem.  I was thrilled at the prospect of Swift when it was announced.  It was initially a very lightweight, terse and flexible language.  I read the entire spec over the course of a few days and couldn't wait to tear into a slew of side projects.  But it became clear to me over the course of a few short weeks that Apple's initial vision wouldn't stick.  The average iOS developer was more than comfortable with the quirks of Objective-C and the ingrained history of Xcode.  Today, Swift looks like a chimera of the original vision and the angular oddity of Objective-C, and Xcode is as opaque and user-unfriendly as ever.  As I mentioned in my earlier entry, JetBrains offered AppCode, which was much more comfortable for me initially, but was clearly losing to Xcode in the game of catch-up.

Now, as for Android, its development prospects seemed to have one major advantage out of the gates.  The default development tool is Android Studio, an IDE created by none other than JetBrains and based on the much-loved IntelliJ environment.  You can also simply use IntelliJ, as it includes all of the Android plugins.  

Android Studio/IntelliJ's simulator

In typical JetBrains fashion, the boilerplate work of laying down the foundation for your app is handled by the IDE.  You can pick from a number of templates to bootstrap the project, and it takes care of generating not only the dependency management (via Gradle), but also setting up the basic stubs, allowing you to immediately run your app via the emulator.  You can also easily download whichever flavor of Android you need.  Bear in mind that these are rather large, and downloading all of the revisions would fill up even the largest hard drive in no time.  

On the surface, developing for Android is a snap.  Once Gradle has pulled down all of your dependencies, you can start the emulator of your choice and boot up/restart your app in seconds.  When it gets down to the nuts and bolts of the actual development, however, I find myself to be a little less impressed.  I've shared my foray into Android land on my GitHub.  It's a pretty vanilla application, using some of the basic components to build a basic experience.

I've mentioned on a few previous occasions that Android has adopted Kotlin as a "native" language, and indeed as its language of the future.  It's probably a wise move given that Oracle and Alphabet/Google are competitors in many ways.  As I've delved deeper into it, I'd say I'm conflicted about Kotlin.  It seems like it's often different for the sake of being different, and it doesn't lend itself to easy adoption coming from a Java background.  I do appreciate its built-in nod to mutability/immutability, and it lifted its closure/lambda syntax directly from Groovy (which is always a plus for me).  But the language can seem unwieldy at times.  For better or worse, it is always going to result in less code than its Java equivalent, but it can be at the expense of clearly capturing the developer's intentions.  Fortunately, this isn't a huge issue with the app that I developed.  The logic is simple, and the flow of things should be pretty clear.

I'd say my main gripe with my development exercise is the default dependence upon XML.  For those of us that have been in the game for a minute, it's easy to recall when XML was the only game in town.  At the time, it was a revelation: it allowed a plain-text representation of any data structure you could think of.  Then JSON came along and ushered in a new era.  The fact that XML is so pervasive in Android development speaks to how long the platform has been around.  Mind you, it's clear to me that Android is undergoing a rapid evolution even as I type this: I don't think that XML will be the way of the future.  But the reality is that it's still the path of least resistance, and in my readings, it's still the most popular way of designing layouts.

A simple XML layout

IntelliJ's visual layout/widget editor

Fortunately, as you can see above, IntelliJ takes some of the guesswork out of how your components/layouts will look.  I still found myself daunted by the tedium of tweaking the XML, setting up the right namespaces and staying ahead of the ruddy trail of deprecations (there are thousands of them).  The sad reality is that it's not an easy ecosystem to jump into, especially at this point.  I would have expected the adoption of Kotlin to have come along with a renewed effort to draw new developers into the fold. 

When I finally got to the point that I had a working application, I looked back and realized that there actually wasn't a whole lot to building something simple, and potentially immediately useful.  It's just a matter of knowing where to look, what to use and how to navigate the common design patterns.  I wouldn't say that Android adheres to my understanding of a standard MVC pattern, but it's not too far off from that.  Google offers a handful of "starter" tutorials, that can be incredibly helpful but I also found to be a little bit incomplete.  I would have loved to have a cloneable repo.  There are a few generous souls that have offered turnkey projects for experimentation, in various states of currentness and working condition.  It's my hope that my little project offers a springboard to the curious. 

Where do we go from here?  I'm still not convinced that going the native route is best.  I plan on delving into React Native next.  Not only does React Native allow a somewhat agnostic approach to developing mobile apps, but it does so within the framework of React's familiar component-based design, using the tried-and-true JavaScript language.  I will report back with my findings. 

Until next time.