Learning Android (or, not)

Wednesday night some friends and I sat down armed with our G1s and laptops to write some code for Android. If you haven’t looked at Android yet, it’s got this whole Java framework you get to learn on top of your rusty Java. It’s been about two years since I even looked at any Java, and most of my evening was spent trying to convince Eclipse and SDK to play nicely together on my computer.

Since Android is so deeply seated in its own framework even though it’s Java you can’t just throw any old Java application on it and expect it to run. This seems a little contrary to Java’s big cross-platform compatibility promise. But since I’ve always found that to be a horrible lie anyway, I don’t really care. So I’m learning Android, and it looks a lot like Java.

The Android SDK includes an Android emulator so you can play with it even if you don’t own an Android phone, and while it’s dog slow to boot it works pretty well. You can set which version of the OS you want to run (1.5 is supposedly coming out this month), although damned if I know how; I just followed the instructions in the Hello World tutorial.

I have to say that this is the longest process from start to Hello World I’ve ever gone through. And that’s my main beef with Java. It seems like every project has 1000 classes and I spend half my time on a wild goose chase trying to figure out what a given line of code is doing. This is exactly the sort of thing I can’t stand about highly OO PHP projects like Magento. Even doing simple stuff feels really really bloated. With Android you can hello world in your code, but really what you’re supposed to do is load your strings up in an XML file, and then load the layout into another XML file, and then some depths of the framework I haven’t read up on magically know to throw this on the screen. Ugh. Maybe this is something I’d appreciate if I did much GUI programming in other languages?

Anyway, so we got through Hello World, and then I lost patience with both Eclipse and the Android framework. I closed Eclipse, and when I restarted it had apparently forgotten all about the Android SDK. I’m sure this is due to some error on my part, but given that it took me 20 minutes to convince Eclipse to install the SDK the first time I didn’t feel like doing it again.

The XML file for your gui is kinda neat, but the documentation is not particularly well laid out. After setting up my little sample XML file with attributes like “layout_width” and “layout_height” I naturally wanted to know what other attributes I could play with. Can I make it pink? Can I make the text an inch tall? The answer to all these things is of course “yes” but first you have to find the list of available attributes, and then you have to figure out what class you’re dealing with (TextView in this case) and then you have to find out all of its parent classes, and then compare all thath against the documentation which you can really only sanely traverse with CTRL+F because apparently they didn’t feel like organizing things with nice hyperlinks.

I’m sure that the Android documentation is totally fine for someone who is used to working with Java frameworks, but frankly I avoid most frameworks at all costs. This might be because I work mostly with PHP, and in PHP a framework is just one more slow broken thing you have to debug. So I’ll keep plugging away at Android, but it’s going to take a lot more reading than I have the patience for this week.

3 thoughts on “Learning Android (or, not)”

  1. I’ve just started looking at android, so I’m not sure exactly how it’ll fall out, but I don’t think the class bloat issue is 100% true. I’m a huge fan of CakePHP, and while there are a few times where you need to go look for where something is, the reliance on convention and the strong walls between the model, view, and controller make it much easier to figure out where things are.


  2. Maybe this is me being grumpy, but it always seems that OOP is overkill for 90% of applications. Phone app programming is a great example of this. Imagine how many more handy programs would be out there if you didn’t have to deal with the pain of OOP for simple things like inputting some text from the user, doing some math, and outputting the results. Maybe four lines if you used did procedural programming. With Java? Madness.


  3. I agree that Java’s OOP structure is a pain, But I really don’t think it has to be. It really comes from coherence of design, which from my brief overview of it of Java seems to be lacking.

Leave a Reply

Your email address will not be published. Required fields are marked *