[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
Overlayon top of the map to draw the lines-and-circles representing a feed, and itsdrawmethod 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 throughtools/adb logcaton 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 I suppose it does, until you try to write a UI for it. Typing in URIs sucks, and it sucks especially via the constricted input bandwidth of a pocket-sized device. So, you might wonder, where do URIs come from, naturally? They come from browsers, that’s where they come from. So the way I really want to launch my app is to have a web page with a link in it saying “Map this feed!” Except, there’s no way to launch an Android Activity from the Android browser, i.e. via JavaScript.
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
Overlayobjects as described here.]
By the way, I only take the time to gripe about things that I think matter.
Contributions
Comment feed for ongoing:
From: Jeff Hodges (Jan 04 2009, at 21:55)
For #8, you might want to talk to the guys at nitobi who are working on PhoneGap (http://phonegap.com). They are doing some pretty cool things with their cross-mobile device javascript stuff.
[link]
From: Stan Dyck (Jan 04 2009, at 22:12)
Boy am I with you on point number 4. I'm glad to find that I'm not the only one. I've always wondered whether my inability to find much use for debuggers was some sort of defect or (heaven forfend!) a sign of my age.
[link]
From: David Harrison (Jan 05 2009, at 00:10)
RE #7 the use of XML in new Java frameworks has come a long way. Android is a good example of how XML can be applied in a restrained and practical manner. Just be thankful you don't have to work with JBoss, Spring, Hibernate and JSF on a daily basis. A few days of this will make you appreciate that Java guys weren't wimping out, XML when used inappropriately (or without implied defaults) can be a real time and mental black hole :-)
[link]
From: Dominic Cooney (Jan 05 2009, at 00:44)
On point 8--that there's no way to activate an intent from a web page with JavaScript--look at declaring URL data in your activity's intent filter. This is how, for example, browsing to a video on youtube.com pops up the context menu which lets you activates the YouTube application instead.
[link]
From: Jacek (Jan 05 2009, at 00:47)
Being probably a younger programmer (started commercially in 2000), I've also predominantly used print statements; but I find myself using the debugger when really zooming in on a confusing problematic area. It may also be that I write confusing code, though; I'm not really a good programmer.
[link]
From: David Carver (Jan 05 2009, at 06:20)
There are a series of blog posts about the Eclipse Debugger that might help you out.
http://eclipser-blog.blogspot.com/2008/12/eclipse-debugger-part-i.html
[link]
From: Martin Probst (Jan 05 2009, at 07:03)
About the XML configuration stuff:
In my experience, the XML usage in Android seems very reasonable. Everybody hates glueing together GUIs with e.g. Swing, and markup languages really work a lotter better for that. So, reasonable XML use case.
The thing people complain about is when framework developers start thinking: "lets move the programming to XML, it's so much - eh - more dynamic, or something!". Typical Spring configuration is indeed programming, with global variables, types that fit together, data containers (yes, they have support for hash maps and lists), and so on. Bad idea. And the use case for it - different component combinations without any Java code changed - just doesn't justify this. The only thing I want changed is the actual configuration, and that's usually a 5 line jdbc.properties.
I guess there would be a lot less people complaining about how bad Java is if we had a tool chain that's less of a PITA.
[link]
From: Nathan (Jan 05 2009, at 08:20)
I'm a fan of gdb. The learning curve was surprisingly low and if I want to inspect a value I don't have to recompile with a custom print statement, I can just print it out. That said, I'm a C programmer so I don't know if there's a Java equivalent.
[link]
From: Bill de hÓra (Jan 05 2009, at 08:55)
"At a deep level, debugging with print statements is superior to all other approaches."
Funny, Java is not a language for which I find that true. Probably something to do with recompilation and/or threads.
[link]
From: Dan Fabulich (Jan 05 2009, at 13:37)
Android would have been better designed if each Activity had a URI. Ideally you could search your phone for resources just by doing a Google search. (Just like you can search the web AND your hard drive using Google Desktop Search.)
Also, here's another vote recommending PhoneGap. It's a beautiful solution to a thorny problem. I just wish it would get baked into the Android SDK as an official development path!
[link]