First of all, I should announce my editorship (starting
today)
of another blog, the
Android Developers Blog.
But at Google there are stories behind the stories.

Android Dev Blog
It’s been around since November 2007, way before I’d ever heard of Android.
In recent times it’s been used
somewhat like a press-release channel; each of the pieces heavily group-edited
into just-the-facts mode. Perfectly OK (if a bit tedious) when that’s
the kind of channel you want.

It seemed obvious to me that there was scope for a real bloggy kind of
blog, since there are a ton of interesting stories inside Android crying to be
told. So I said that a few times and I suspect irritated a few people, and
the upshot was I got the whole thing dropped into my lap.

Let me drive a stake in the ground: If you want to
know the actual technical substance of what’s being built here, or to read
inside-Android stories,
that blog is the place
to come, or rather
subscribe
to if you really care.

Blogging at Google
It’s hard, way harder than I’d realized. There’s this thing in the company
culture where everyone is very free with information, internally, and
expected to be very close-mouthed, externally. Within a few days of arriving,
my brain was bulging with more Really Big Secrets than I’d picked up in years
at Sun.

In fact, I now know how much storage we’re dedicating to support... hold
on, even mentioning what it’s being used for would probably get my ass
appropriately fired. And so on. There are a million stories around here and
a person like me who can’t not write is dying to tell them; but it’s really
hard to keep track of which ones are fair game.

To make matters worse, Google is interesting. Since I’ve come to
work here, my blog readership and Twitter follower-count have both ballooned,
and I’ve noticed that more or less anything we say, whether or not I think it
matters, is news.

Twitter follower count; I started at Google on March
15th. Statistics courtesy of
twittercounter.com.

On top of which there are many out there who are kind of scared
and nervous about Google, for a variety of reasons some of which are
perfectly reasonable. And there are those, including some who write for
large audiences, looking to pounce with glee on any whiff of evil or
hypocrisy. Fair enough, I suppose, since Google presents what we in the trade
call a Large Attack Surface.

Which means that Google in general and the Android project in particular
are careful, verging on paranoid, about what gets said in public.

Since I’ve been here, I’ve argued repeatedly that there are a lot of people
who would like to like us, and that there are lot of stories here
that would be good to tell; that the rewards of open-ness greatly exceed the
risks. There are people here, including some very important ones, who
are unconvinced. But they’re still giving this a chance. Let’s hope I’m
right.

Last week I wrote
Content
Provider Iterator, which simplifies the task of dealing with Android’s
Content Providers. Reto Meier, the author of what is currently the
best
Android developer book, got
all
nervous about my approach. He’s got a point, but so do I.

If you haven’t read Reto’s piece, please hop on over there and do so; I’ll
wait till you get back.

To recap; my
providerhelper package
lets you write the following code:

Reader<Call> calls =
new Reader<Call>(Call.class, activity, CallLog.Calls.CONTENT_URI);
for (Call call : calls)
String number = call.getnumber();
I claim that this is about as idiomatic as you can possibly get, if your
idiom is Java’s flavor of object-orientation.

But On the Other Hand
Reto, and others, point out that this creates a lot of objects (one per
Call, plus one for any field you choose to store in an Object field) and does
a lot of reflection (one method.invoke() for each field you want
to extract from the Cursor, for each Call). This, they argue, will have an
unacceptable cost and flies in the face of the official recommendations on
designing
for performance in Android.

Jerome Lacoste actually wrote
some
code to measure
the performance, and it suggested that the slowdown was as much as a
factor of ten. So this is not just a theoretical problem. I guess
those people who wrote the Design-for-performance guidelines knew what they
were talking about.

Well, for some applications, anyhow. The problem is,
for others it’s not going to make a damn bit of difference.
For example, in my own app code, the delay for reading a few hundred records
out of the phone-call log, and doing a bit more work with them than Jerome
did, isn’t even measurable. (I’m working to reconcile my result with his;
something funny is going on).

At a more general level, I’d like to appeal to Knuth’s
Premature
optimization is the root of all evil. What Knuth didn’t say, as far as I
know, was the reason why his statement is true: nobody is smart enough to
predict where the performance bottlenecks will occur in any reasonably complex
application. And let’s grant that some “premature” optimization is
common practice: as in, the selection of sensible algorithms and data structures.

So, my take-away is: Yes, you have to learn the lessons Reto’s teaching and
be nervous about the things he says you should be nervous about.

Having said
that, I still believe that the right way to build an application is to do
the Simplest Thing That Could Possibly Work, and maybe it’ll be fast
enough, and if it’s not, then don’t bloody guess where the problem is, measure
it until you know.

Other Gripes
Reto and my commenters also point out that:

Getters and setters are often bad practice, and

the code isn’t thread-safe, and

developers shouldn’t have to inherit from
Builder.

Those are all fair points, particularly the one about concurrency. I will
update the package docs to include warnings about the potential performance
problems and all these other gotchas.

What Next?
I’m not sure yet. On the one hand, Reto’s arguments and Jerome’s results
are certainly sobering.
On the other, I think the problem I was addressing is real: Having read quite
a lot of Android apps source, I do think I see quite a bit of tedious ugly code
concerned with pulling fields out of cursors; the kind of thing that has
me thinking
Don’t repeat
yourself.

Having said that, I have to observe that the Google-provided apps work
pretty well and run pretty fast, and the
source code is a lot easier to read
than that of a bunch of other open-source projects I could name. So maybe I’m
straining at gnats here.

Maybe I’ll end up plastering a big Never do things like
this all over that providerhelper code. Maybe I’ll find
a way to do away with some boilerplate at a more acceptable cost.
I’m quite positive that I’ll come away a deeper and better understanding of the
Android SDK; this is by way of sharing the lessons.

The fact that this isn’t posted on
developer.android.com is a bug,
I’d say. If you’re going to
be doing any Android programming, you really need to get Reto Meier’s
Professional Android 2 Application Development.
Yeah, he works for Google (same group as me) so I’m prejudiced. Whatever. For
the moment, Reto’s book is the Bible.

I want to be able to write apps for my phone in in something other than the
Java language; for example Ruby or Python.
This isn’t one of the things my group at Google has asked me to look at, but I
think it’s worth doing and worth some of my time.
I’m writing this today because I’m amused by the contrast with the current
hubbub over Apple having
tightened
the developer thumbscrews.

Why?
I like
the libraries, but I have to confess
that these days, I’ve slipped into the camp of those who find the Java
language verbose and rigid and overly ceremonious. It bothers me less on
Android than on general-purpose computers, because Android apps tend to have a
pretty thin layer of application code between calls out to the network and GPS
and accelerometer and so on.

But having said that, I’m pretty sure that in, for example, Ruby, I could
write less than half the number of lines of code to get any particular job
done. Also, I entirely loathe
Java generics.

What Google Thinks
As usual, I’m not speaking officially for Google here, but my impression is
that if there were an official reaction, it’d be along the lines of “Uh,
whatever, we’re focused on shipping this next release.” Which is likely
appropriate; The Androiders are so zoned-in on building a great SDK and runtime
and Market that my wild-eyed screw-the-semicolon ideas are not exactly likely
to become front-of-mind. Well, unless I can show that they work.

It may come as a surprise to regular readers here, but there are vast
expanses of our profession, including some of the best and brightest, who
haven’t got the dynlang bug yet.

And the Official Policy?
That’s a non-issue. An Android app has to be an
APK file, and if
you generate/sign one of those and are in the developer program, and it’s not
illegal or porn or something, you can drop it into the Android Market.
(If falls afoul of Market rules, you can post it on your own website or some
other market, and people can still install it, no jailbreaking required.)
How you build the APK is up to you.

In practical terms, if you want it to look-and-feel like an Android app,
you have to use the
Android
SDK; but what language you generate those bytecodes and method calls with,
and how you compile it, well, why should anyone care? I’m using Eclipse,
and while it Just Works with the library and emulators and other tools, it’s
failed to win my heart.
I’m seriously thinking of going to
Emacs and seeing if I could replace Ant with Rake. And, of course,
every piece of the toolchain is open-source and thus in
principle can be forked and improved and replaced.

If what you produce sucks, the word will get around quick; having used the
official Android toolchain won’t save you. And if it doesn’t suck, not having
used it won’t get in the way.

I’m actually a little puzzled by the Apple policy; the technical side I
mean, not the business issues, which Gruber
explains
with ruthless clarity. I can see Apple wanting to enforce the use of their
APIs, but the compulsory linkage to the Objective C programming
language makes me feel like I’m missing something; where is it carved in
stone that it provides the optimal, impossible-to-improve, way to use the
iPhone APIs? And if nobody’s allowed to try anything else, how will we find out?

Anyhow, the market will decide; the big small-m market, not the iPhone nor
Android Markets. But in the meantime, I’d say we’ve got more scope for fun
over here on the Android side.

Candidates
Right at the moment the Rubyists seem to be in the lead in this race, what
with
Ruboto and
Duby.
I can’t think of any architectural reasons why Jython shouldn’t be a
candidate, except for Sun let
Frank Wierzbicki go and I’m not
sure anyone’s working on it much, these days.

Also, in theory you ought to be able to use the
Android NDK to
get the native C versions of Ruby and/or Python going. It’d be a slog, but
the idea doesn’t seem insane.

There are lots of other languages, and maybe one of them is a better bet;
My focus on Python and Ruby reflects my own prejudices, but my
mind is open. And of course JavaScript is already a first-class
citizen pretty well everywhere.

In Conclusion
Got any good ideas for how to let me write serious, shippable Android code
without ever having to do this again?
HashMap<String, List<Person>> buf = new HashMap<String, List<Person>>();

If you do, get in touch. I might be able to help you help me.