What?

This article is mostly about my personal frustration for mobile phone application development.

My knowledge about the subject is actually quite limited. I have only developed for Nokia (Maemo/Meego/Symbian using Qt/QtQuick) and Android. As for the languages, I have used following on mobile platforms: C++, JavaScript, Java and python (not counting XML etc used for layouts and such). But in general everybody I know who has been developing something on some mobile phone platform, has been more or less frustrated on their platform. Even and especially iPhone.  The problem might have been example the language, the complexity of creating anything on screen, publishing your work into the manufacturers application store, getting network traffic working, getting JSON working, my personal favourite: creating a simple list with customized item layout… This list goes on.

Android

Android development, relatively speaking, is easy. You install Eclipse, add android plugins and (if you have one) connect your android phone. Your first Hello World -application comes without much sweating. You can test and debug it in simulator or your actual real world android phone. You get debug output printed into console quite nicely, though this logcat-debug system has proven to cause some trouble now and then.

Everything is easy as long as you keep your application tiny and simple. After and a while, when your application starts growing, things start getting worse. Especially, when you decide that the looks of a generic Android phone UI is horrifying (which it is) and that you might want your application to be appealing not only for those most geeky nerds, this platform gets very frustrating. Making nice customized complex application is just something that Java was not meant for. Atleast if you want to do it with some ease.

In general, androids style system is a very good one compared to many others I have tried now and then. You can design your layouts in smaller pieces and include those pieces into your main layouts, your lists can easily have custom styled items, you can create custom drawables/effects with xml, you can customize button states with few lines of xml and so on. The possibilities seem quite endless.

But still, there is much missing, much ruined by Java etc. Example dividing your view into smaller pieces is very hard. The easiest aproach is to just write everything inside a single class which extends as an android Activity. One activity is kind of a one window, sub-activity is like a popup window and so on. After a while, when you have your http request handlers, maybe few tabs inside a ViewFlipper, buttons and more buttons and many other user inputs and user outputs, you start thinking: “where the hell am I gonna put all the code that makes the application actually do something without writing it all in the same class because I fucking can’t divide my code with any ease into several classes because the fucking Java makes it so hard fucking fucker”. Oh wait, I can, but then I would have to write those classes inside that one I want to divide into smaller pieces? “Screw you guys I’m going home”.

Ok, so normal android application consists of about three things in major. Layouts, drawables and the code.  With layouts you define where things are on the screen, with drawables you define what they look and with code you define what they do and how they change their appearance with or without user interaction. The code I would like to divide into smaller pieces so that in example a list, a button and an input box would share one class to handle their functionality. Good example is a search something -application. But, because of android’s Activity context, this gets very hard. It is possible but just god damn hard. Or maybe I’ve misread some tutorial badly? And my co-worker too?

Android activity defines a single context which is used to access it’s resources. If you divide your code into several classes like in last example, you end up creating some method for delivering that context to the subclass and some other methods for that class for notifying the überclass that the subclass has something to say, change, do, notify, whatever. We have developed two commercial applications so far for android devices and we haven’t figured out how to do this well. So we write most of the code into that single class and it looks beautifull, as you can image.

Whole another style to do this would be using more than one activity, but then there comes even bigger problems plus you cannot actually divide very many things that way.

Nokia

Fuck. About this I could write a small book. Maybe a novel. But now I have no time.