[This is part of the Android Diary.] Being a disorderly list of impressions taken away from a couple of weeks of development.
Some of these might be useful in giving non-Androiders a feeling for it; others are specific gripes about minutiae of the toolkit.
Are there ever a lot of re-draw events! I used an
on top of the map to draw the lines-and-circles representing a feed, and its
draw method would get called dozens or hundreds of times during
any human interaction with the map.
Which means that if you’re going to do anything expensive in there, you need to think carefully about avoiding useless work. The good news is that the implementation seems fast enough to be forgiving of a moderate amount of probably-unnecessary re-drawing.
In fact, the whole toolkit seems relatively forgiving, by contrast with some other GUI frameworks I could name. A case in point: when someone zooms the map, I redraw the feed picture; if they’ve zoomed in, some of the points are probably no longer visible. I don’t even check, I just draw ’em all, and connect ’em up, and the software seems untroubled and unslowed by all these way-off-screen graphics calls.
It’s not RGB, it’s ARGB. You can slap in arbitrary alpha-channel values and everything just works. Semitransparency adds visual appeal to apps at a level that doesn’t seem reasonable.
So, the Eclipse plugin lets you apply the Eclipse debugger to your code
while it’s running. Feaugh. Maybe I’m just not smart enough to use it
properly, but sure ’nuff, here it is nearly thirty years into my programming
career and I’m still debugging with print statements; in this case
System.err.println(), which pipes beautifully through
tools/adb logcat on my Mac command line.
At a deep level, debugging with print statements is superior to all other approaches. Which is good, because we seem to be stuck with it.
My first exposure to Eclipse in some years left me pretty bored. The fit & finish could sure use some work. Mind you, maybe the Android plug-in isn’t Eclipse’s most appealing face.
The emulator (on a 2007 MacBook) and the actual USB-connected phone are similar in performance. Unless your testing requires you to type some text in or click accurately; in which case the emulator wins big-time.
As one of the original XML perpetrators, I’ve felt vaguely guilty for some years in the presence of Java-heads, who experience XML config files as the software equivalent of waterboarding. My first hands-on experience has made me wonder; Android has you write little XML fragments to configure UI components, and it seems fairly appropriate and painless. Either this is an unusually benign example of the practice, or those Java folks are wimping out.
On Android, the way you route between screens and applications is via Activities and Intents. Which turns out to work pretty well, and to be URI-centric, and I like it. And, I just wrote an app whose primary input is a URI, which ought to fit in nicely.
Which obviously needs to be fixed.
The Android guys clearly bent over backward to make it easy to write an app that displays a map, there’s a pre-cooked Activity/View package that just does the right thing, although you need some extra jiggery-pokery if you want the standard zoom controls to work.
[Update: The rest of this paragraph was filled with a complaint about
how it’s hard to deal with touch events when you’ve drawn on a map.
I was wrong: the right answer is to use
Overlay objects as
By the way, I only take the time to gripe about things that I think matter.