AD X: Grumbledroid

[This is part of the Android Diary.] There’s a pattern in this tribe where you put “droid” on the end of, well, everything. Thus this title; herewith another set of hands-on notes, this with a sort of grumbly tone.

Community · I’ve previously written that one of the nicest things about Android is the community, as evidenced by my continued success in simple Web searches turning up working-code solutions to my programming problems.

But the central Android Developers list over on Google groups, well, it’s not that great. There are a few insiders who try hard and do good work, but there’s a high volume of truly clueless questions that could have been answered by eight seconds’ recourse to that little search window in the top right corner of every bloody application you use.

I’ve been able to pitch in and help a couple of people with just-outta-n00b queries, but I’ve never got a question answered usefully myself. Not sure what can be done about it.

Gmail · Since this is billed as the “Google Phone”, it’s amusing that I’ve entirely stopped using the built-in Gmail app. It’s slow and klunky and a bandwidth hog and burns huge amounts of (the very limited) storage space. I suspect it of using IMap under the covers.

This isn’t a real problem, because Gmail over the browser works just fine and dandy, even over dog-slow Edge networking. The whole bloody point of Gmail is that it’s Web mail, isn’t it?

Content Provider · The first piece of Android (as opposed to Java SE) code that has really gotten up my nose is android.content.ContentProvider. It’s the official way for apps to provide data arbitrary other apps. It’s addressed via a URI, which is good and the data is given an Internet Media Type, which is also good.

Only the way they use the URIs is pretty, um, idiosyncratic, and then there’s this problem that a ContentProvider is expected to accept and act on arbitrary SQL “WHERE” clauses. Which means that in practice it’s going to be tough to implement with anything but SQL. And anyhow, passing around chunks of WHERE makes me nervous.

Also, I tried to implement one and failed; it compiled and deployed just fine, but any app that tried to use it said:
failed to find provider info
I couldn’t find a word of documentation as to how it actually works, and in particular couldn’t find out where the other app was looking and what I might be doing wrong.

Now, I’m pretty sure I could have by reading the Android source code, which has already helped me a couple of times. And after bashing my head against this for a couple of days I realized I didn’t really need a ContentProvider anyhow. But still, irritating.

GPS · The GPS on the G1 is very 1.0. It’s kind of slow and sometimes wrong and won’t sync up with the satellite unless you have a lot of open sky above you, not including fog or tree branches or low-flying aetherial spirits.

Also, the information on how to program it effectively is very thin on the ground. It’s a battery hog, so you don’t want to run it any more than necessary, but there’s nothing said about what it actually does when it’s turned on, and my experiments seem to suggest that it doesn’t do anything but draw power unless you open the Maps app and select “My Position”.

I want to emphasize how wonderful it is to have any access at all to a Java-programmable pocket-sized GPS, though. The things you can do are wonderful enough that I don’t mind pulling up the map and waiting for the GPS to calm down and find its inner self before I start my code.

Relational Pain · Android ships with a built-in SQLite3 engine. The API for it, unlike the rest of Android, is fragile and persnickety and brittle. To do anything at all you have to deal with two or three different Hash tables, and since the database isn’t on spinning rust, I really wonder about the time trade-offs of all that hashing when I just want to update a column or fetch a couple of rows.

Also, it’s subject to silent failures of various sorts. I don’t know, maybe it just hates me. Maybe RDBMSes in general hate me, goodness knows I’ve abused them enough over the years.

Now, let’s be fair. It’s totally wonderful that my cellphone comes with a database, and I’ve made good use of it in my code. I should also note that it’s surprisingly robust in some respects. I was neglecting to close the database down after a query, and never found out until I was watching the error log and saw this big stack trace with a message along the lines of “Query on database left open and stale, blowing up, oh well, will clean up and do the query anyhow.” I like that.

Summing Up · It’s still the best phone I’ve ever used, and it’s the only way I know of for an old POJO hound to build an Atom-Enabled Map-driven Location-aware Web-centric Mobile Application in a few weeks, working part time. These are just Release 1.0 gripes, published so that the next puzzled geek who goes searching will not feel so alone.

And just so I add a little value along with the gripes, if you care about this location-aware stuff you might want to invest some time in reading I Am Here: One Man’s Experiment With the Location-Aware Lifestyle from Wired. Thought-provoking.

---

---

Contributions