Honeycomb (Or, Why I Haven't Blogged Much Recently)
Today’s the one-month anniversary since my last blog post.
Part of that hiatus was due to an extended bit of travel, as I continue to deliver Android training to various groups.
Part of that hiatus was due to an annoying cold that I picked up late in that travel that dogged me for a couple of weeks.
And part of that hiatus is that Honeycomb left me depressed.
I understand why Fragments were added. I can even sorta justify why it’s a whole new framework, rather than simply being general development guidance (e.g., organize your code into custom Views for cross-activity reuse).
But it just really hammered home how frakkin’ complex Android development has evolved into.
I mentioned training at the top of this post. I have personally trained several hundred people on how to develop Android applications. Some took to it like ducks to water. Some took to it like oil to water.
Never once did I hear, “this is so easy, even a caveman could do it”. Admittedly, GEICO took that meme and rode it into the ground, but, still…
There’s a group of people who have problems grasping the concept of activities: why they’re there, what’s with all this lifecycle nonsense, and so on. Fragments will cause this group’s heads to explode into…ummm…fragments.
Each passing Android release layers complexity on top of complexity. To make even a bare-bones app, you need to understand — not just read, but actually grok — a couple hundred pages’ worth of material, from umpteen XML formats, to how to properly manage threads across configuration changes, and everything in between. And I’m not even talking about creating sizzling apps that will wow the VCs, but just garden-variety stuff.
The problem is that I don’t get the sense that Google really
cares much about this problem. Yes, the tools team has obviously
gotten a boost, and I am grateful as anyone for the work they
are doing. However, using tools to deal with complexity is
like re-positioning furniture to hide a carpet stain —
yes, the stain may be less noticeable, but it is there, and
when noticed it will be quite embarrassing. And, yes, there
are individuals that are trying to provide stuff to help
with some of the nastier problems (kudos to Brad Fitzpatrick
StrictMode). But these are just nibbling around the edges
of the complexity. We need more stuff that truly simplifies
development, such as templates that can be used for constructing
apps, or portions of apps, that implement desired best practices.
Ordinarily, this is where I’d pipe up and say that the community needs to lead. However, in this case, the complexity issue is fundamental to Android. While the community could cook up a library of app and interaction templates, Google won’t help spread it, since Google has steadfastly refused to acknowledge that developers even exist, let alone contribute. If you don’t believe me, count the links on developer.android.com leading to community-supplied resources. If you get past one (StackOverflow), I’ll be surprised. If Google won’t help promote community-led solutions, Google needs to solve the complexity problem itself, or suffer the inevitable consequences (Symbian, anyone?).
(And, no, I am not angling for Google to link to anything of mine)
Fortunately, I think that I have gotten past my mental blocks and am ready to charge ahead into our honey-flavored future, whatever it may hold.
With respect to books, there will be no updates until after Honeycomb ships and I get buy a XOOM for testing purposes. The rumor mills suggest that this all will be reasonably soon, and let’s hope that they are more accurate than some of the Gingerbread timing rumors.
Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!