AD IX: Five Programmer’s Notes

[This is part of the Android Diary.] I’ve done a bunch more polishing on my little demo-ware Feed Mapper; it even handles errors. Plus I’ve started sketching in the other half, the thing that might turn it into more than a demo and drive some Cloud biz for my employer. Time for some more give-the-feel-of-Android dispatches from the coalface.

Coding in Java · This is the first serious Java code I’ve written in years, the years I spent becoming increasingly fascinated with dynamic languages in general, and in particular the technology and culture of Ruby.

During this time, I’ve become increasingly negative about the use of Java for building applications (as opposed to infrastructure). But I have to say that I’ve been finding this experience (mostly) cozy and comfy; less irritating than I expected. I’m not 100% clear on why this is, but here are some theories.

Maybe it’s that I’m keenly aware that on a CPU and amp-hour starved device, the code has to be damn tight and damn compact. I’m totally willing, most times, to pay the Ruby performance tax in a Web app running on a big multi-core server... but this is different.

After a few years of Ruby, you can actually feel how tightly the pieces of a Java program fit together, in the way the IDE Just Knows what the possible methods you can call are at any point, including the potential arguments, and most times can make a pretty intelligent guess which is most likely.

Maybe it’s because Android seems (based on my limited experience) to be well-designed and well-thought-through, with a refreshing lack of Factory Factory Factory instances or architecture astronautics.

But still, I miss Ruby. For example, the app needs to fetch, parse, and extract data from feeds. For fetching, it uses Apache HttpClient, which gets the job done but is hardly direct in its approach. And for working with the feeds I was back in bad old Java-SE-DOM land; gag me with a DocumentBuilderFactory.newInstance().

This has made me awfully nostalgic for Ruby’s Net::HTTP and REXML, which I promise to be more polite about from here on in.

I could have written what I’ve written with a lot less code in Ruby. So I look forward to JRuby and Jython showing up on Android.

Error Handling · It’s easy!

Partly that’s because the simple, linear flow from screen to screen that you want on a teeny little screen like this anyhow; partly it’s the result of Android’s sensible model of having Activities hand off to one another.

So when something goes wrong, I launch another Activity that displays an error message, and exit. That activity in turn dispatches back to the front page of the app.

Use the Source, Luke! · Android’s big (more on that later) and it can be kind of tricky figuring out the simplest and best way to accomplish what you’re doing. Fortunately it comes with a lot of sample code, and then if you want, you can download all the source code; I find this particularly useful in figuring out how to wrangle the XML for the UI. I’ve been doing a lot of grepping through this stuff for methods and tags and attributes.

More Developer-friendliness · Maybe this is a minor point, but illustrative I think. If you want to download and build Android, there are quite a few hoops to jump through. Less than for Linux or Apache or (especially) Mozilla, but still nontrivial. The instructions are clear and fluff-free and highlight all the gotchas that might get ya. Obviously written by people whose memory was fresh after having done it themselves.

Preferences · Any nontrivial application needs preferences and settings. The piece I’m about to start implementing is entirely useless without a few. So I sketched them in over the last couple of days. And Android’s preference-management stuff is super-slick. (Mind you, as I pointed out, I’m kinda behind the times on GUI stuff; maybe Cocoa and Gnome and so on have this nut nicely cracked too).

It’s Big! · The size of Android, once you start poking around inside, is pretty mind-boggling. This is nice because it means that for most things you want to do, there’s an API there to do them. But there’s a problem: You can do a whole lot of trudging through a maze of twisty little JavaDoc passages, all different, to figure out how you ought to do something.

Example: I had stupidly been capturing touch events from a top-level Activity, because I couldn’t figure out how to subclass its MapView. I spent a whole day figuring out how to inflate a custom MapView for the MapActivity before I eventually noticed that the bottom-level Overlay where I was drawing had its own onTap method. So I did it that way and told the world, and the next morning Androider Dan Morrill Twittered back Why not ItemizedOverlay? Well, because I hadn’t found it. (Mind you, I’m not convinced that it would have been better; but the point stands.)

Another example: On a preferences screen I was building today, there’s a place where I want them to fill in a number. So I wanted to find a way to filter incoming keystrokes and reject anything non-numeric. Oddly, EditTextPreference doesn’t seem to have this. But it wraps EditText which inherits from TextView which has setFilters() which takes an InputFilter which turns out to be just the ticket.

And now what’s going to happen is, someone is going to read this and put up their hand and say “What about ConstrainedNumericEntryWidget, doofus?” (I’ve already found DigitsKeyListener but not figured out how to put it to work yet).

Anyhow, what Android really needs are a lot more cookbooks bulging with how-to-do-this examples. But still, it’s not bad at all when I can start from scratch and put together a preferences-management screen for several subtly-interdependent preferences over a weekend, in between child-care and the NFL playoffs.

---

---

Contributions

---