As part of a university course, I’ve spent the past few weeks programming an Android app for location-based alarms and sound profile changing. It’s not a novel idea, but it seemed like a reasonable medium between ease-of-implementation (not requiring an external database or more than one phone for testing) and actual utility and I didn’t really have any better ideas.¹

For my development environment I chose Eclipse because that’s what the course lecturer recommended and what seemed easiest. Not being entirely unable to fiddle with my dev environment, I installed Eclim and spent my development switching between embedded GVims and the Eclipse Java editor based on flippant changes of disposal toward the mouse.

I have never been the biggest fan of Java. The last time I touched it was in second year undergrad when we had to use it for a data structures and sorting algorithms course, so my strongest mental association with it is “why do we have to write these linked list things instead of just saying lst = [] like in Python?” And they’ve only relatively recently added support for strings (err Strings) in switch statements.²

So it’s perhaps darkly appropriate that the most substantial project I’ve worked on (bar Game Maker games) thus far has been written in Java. The race is on to develop something bigger in another language as quickly as possible before I start being called a “Java developer” and wake up one morning trapped in an AbstractHelperClassFactory, bound by a rope made of the commas in a DecimalFormatter object using the South African locale.³

Development was a frenzy of learning new things and copying code from Stack Overflow answers – i.e. recomposition. I initially had some vague ideas about how activities and fragments in a very high level sort of way, but it’s impossible to truly understand anything in programming until you sit down and actually work with it.

The Android SDK is what you might call overengineered. Doing even the most straightforward tasks seems to require at least six classes, three of them anonymous and two abstract. And if you want to support a broad range of versions of the operating systems it gets even worse, and your code becomes a tangled mess of FragmentActivities and SupportManagers.

Here’s a great example of what Android development is like: Google decided that in the new version of the Google Maps API, getMyLocation() should be deprecated in favour of making the developer to get the user’s location from the Android location service, or in other words implement the backend of getMyLocation themself. Now, I’m sure it wasn’t a lightly made decision to do that and I can see how it would might save resources and so on, but it’s the last thing you want to have to deal with when it’s approaching one in the morning and you just want to display the user’s bloody location on the damn map.

Another thing that baffled me was the hard-coded IDs for elements in the XML layout files (basically templates for organising what the different screens in the app should look like). For a long time I was reusing layout files for multiple fragments (e.g. the “New/Existing” page for Alarms and Profile Rules) under the impression that that was proper practice. It was only rather later that I started pressing buttons willy-nilly and discovered I’d registered and an event listener for the Existing Alarms button on a button I was reusing as the Existing Rules button, with obvious effects.

I was very tempted at times to just use Game Maker Studio, given that I have the Android module and everything. If it weren’t for the sad fact that location/GPS integration is only scheduled for the next big release, and that the course exam was going to be in Java, I probably would have.

After mucking with layout files and data source objects, I have a new appreciation for the simplicity of GM, my first programming environment, where an object is a thing that you make in one place and then put on the screen and that has all its event listeners defined within itself.

Of course, with a GUI-based RAD tool you lose out on the power to create very dynamic, changeable and modularly developed apps. And with something like Game Maker Studio there’s the problem of having to come up with your own versions of tabs and textfields that simply won’t have the same look and feel of most Android apps, but it might be worth that to get away from getSupportFragmentManager() casting errors. Although you’d also be getting away from easy integration of Google’s beautiful radial time picker.

And you can forget about sane object hierarchies and pre-Industrial Revolution languages⁴ should you need heavy integration with other apps and the phone itself. Then you’re trapped in a failure to inflate layout exception, which I imagine to be very much like my childhood fear of being stuck in a jumping castle while it deflated.

Even for all this complaining, I ultimately don’t regret the time spent developing my app, although I did miss out on a lot of sleep this past week. I felt that creative drive to just work and work and get it done and create something that I haven’t really felt since the last time I was really seriously working on a game, and it made me realise how much I miss having that feeling in general.

The app that came out was alright, though not very pretty nor entirely functional in some key areas. I think I might even do it again when I can find the time – I’ve got another idea or two for apps, and it seems like it would be waste to not ever use what I’ve worked so hard to learn ever again.

But I’d definitely chose GMS for a game. I can’t even imagine trying to implement a game engine on top of a SupportLayoutManagerFragmentActivityView.