more android thoughts

I remember right when Android came out, I downloaded the SDK and tried playing with it, and there was some kind of silly show-stopping problem with it on the Mac. Thoughts from then, just a little under a year ago. IIRC, the bug got fixed fairly quickly, but not quick enough for me to get a chance to get back to looking at it in any depth. A long time goes by, and right before this Thanksgiving, I got the urge to look at it again, so I did. Here are some unorganized thoughts.

Note that I still didn't really spend a lot of time with it; the time I spent probably raised more questions than it answered, in a good way. I did the obligatory HelloWorld demo, the Notepad tutorial, and lots of browsing and reading in between.

Please comment if I misspeak about something; lots of guessing and incomplete research on my part here (this thing is big!).

Wow. Lots of stuff here.

Hats off to the team. This thing is huge, and seems fairly well put together, especially considering the size. The source takes up 1.4GB on disk; Linux and WebKit and on and on and on. It's fun just to troll around the source directories to see what's there. But I recommend downloading the wad and browsing with your usual editors/tools.

Rev 1

So sure, maybe it's not as sexy and polished as the iPhone, and sure the devices got shipped with a silly little bug, but I'm willing to forgive early releases. Given the scope of the effort, again, I think they've done a great job. It's early days.

But I'm also not willing to shell out my own pocket money for a rev 1 device or o/s. Just like I (no longer) buy rev 1 Apple products or immediately install new versions of OS X. Tired of playing pioneer.

I guess I'm most worried about the potential immaturity of the application and UI frameworks. Usually good frameworks require evolution, and I've used lots of "intelligently designed" frameworks over the years, so I'm a bit of a doubter when I see a new one pop up overnight. Might be interesting to get some background on them, kinda like Google has done with BigTable and some of their other technologies.

Here's an example worry: the Touch Mode blog post has me a bit confused. Touching the screen causes selection and focus to be lost? eh? I've been using my finger on PDA touch screens since the Palm. I'm used to touching the screen causing selection and focus events to occur, not to be lost. I'm either not understanding what's going on here, or this seems wrong. And here's a funny little note: "This is why some developers are confused when they create a custom view and start receiving key events only after moving the trackball once: their application is in touch mode, and they need to use the trackball to exit touch mode and resurrect the focus." Um, developers are confused? I think users will be confused by this also, won't they? I'll give them the benefit of the doubt here, I'd like to see how well this works on an actual device before passing judgement. Lastly, I'm glad to see that the wiggly mouse is back - it's been years! The referenced mail doesn't go into details, but I've been dealing with self-inflicted wiggly mouse problems since the Smalltalk days. Those were due to bugs though, not design.

Devices other than the T-Mobile G1?

I kinda hate to even provide the link the aurally offensive T-Mobile G1 site, but I'll let you feel my pain.

So what other devices are going to be available? More phones, I guess, but I wonder if anyone will do a non-phone version, like Apple's iPod Touch? I'm currently not willing to pay the data charges for presumably light bandwidth usage (over cell); I'm too much of a cheapskate and live fine with my cheapo phone. But I'm more than willing to carry a device I can connect to wifi.

I didn't see much (any?) information on any newer devices coming out, which is a bit worrisome. Before spending a significant amount of time playing with this, I'd like to know this thing has a future. It seems like a no-brainer to me that device manufacturers would take advantage of Android (many caveats apply), but I'm not willing to bet on common sense.

How would you do a port something like the Nokia N800?

In lieu of new devices, what about porting to existing devices, like (my) Nokia N800? Or say, a netbook?

Turns out folks have ported Android to the N800; see here and here.

It appears what these folks have done is ported the entire stack to the device, starting with Linux. Youch. More what I was thinking was porting the minimum number of things to be able to run Android apps on it somehow. Basically, get something like the emulator running as a native app on the device, as an application container. I don't really feel the need to either blow away my existing device, or run another Linux on top of (beside?) it. And I'd be willing to live with having to run Android apps in a container, instead of as native apps themselves.

We did this sort of thing back when we were working on embedded Java; we had a MIDP environment that could run on the native operating system, with the UI layer (for instance) implemented in SWT. In fact, I assumed this was probably how the emulator that ships with the Android SDK was implemented, but it slowly dawned on me that it's actually running the entire stack, from Linux up, in a virtualization environment of some kind. Wowsa. That's why it takes 23 seconds for the emulator to start up.

To implement an emulator for Android, you need to decide how low-level access you want to support. And the answer is obviously: the "Java" code that you use to write applications. All I'd want to do is run existing apps, which can only (?) access "Java" APIs, so all you have to do is have a matching set of Java APIs that do the right thing on the platform (note the 'all' is italicized).

In terms of implementation, since this is, really, Java source, you could (?) just run the apps in plain old Java. Alternatively, if you didn't have a Java available, you could port the Dalvik VM, and run it that way.

For the N800, there is a Java available (I've not tried it); it's a J2ME flavor, so may not be enough anyway. Might be better off porting the Dalvik VM, then porting the UI bits to Hildon/GTK/whatever; the N800 is already running Linux, so presumably other natively accessed things would have a bit of hope of running out of the box (but not camera, GPS, etc). Webkit's got me nervous.

Lots and lots of caveats here, and it's entirely possible that for some reason or another, you really, really need that Linux kernel to even run the plain ole "Java" applications.

Java

So I'll admit Java isn't my first choice for a language on a device like this. I like the option of Python on Maemo.

But I can live with Java on a constrained device like this; I wasn't unhappy doing embedded Java years ago. One of my pain points with Java is the sheer bulk of crap needed to get anything done, pulling in, eventually, loads of Apache and Eclipse projects to do some heavy lifting for you. The nice thing here, everything is included, or seems to be. But even we if end up needing more stuff (why do I even bother saying "if"), we're talking about a constrained device here, where you'll get laughed at if you want to install a 1MB library to pull in some function. People will have to learn how to write small code. Forced sanity.

Scripting?

Mark Murphy's blog post on using Java-based scripting languages on Android sums up the major points, especially as to language implementations that generate Java byte code directly; those will be a problem, and I think that affects a number of the interesting scripting languages. Presumably, someday you'll be able to generate and load Dalvik bytecode in Android. Maybe there will be a way to load Java bytecode and have it internally generate creamy Dalvik output automagically. Many possibilities.

But I wonder how appropriate scripting languages would be anyway? I've written about this before. If my option is to write Java code, or to write Java code in a Python dialect, I'll just stick to Java.

JavaScripting

Of course there's always JavaScript available, either in the native browser via web applications, or in some other way through the use of the WebView UI View class. And check out this interesting looking method, in that class: WebView.addJavascriptInterface(). hmmm ...

Dalvik docs

Some Dalvik docs like bytecode descriptions, file shapes, etc are available here. Of course, almost no one needs this info, but in case you just had to know ...

I was a little surprised the Java-ness of Dalvik went so far as to support JNI, but I guess that really makes a lot of sense.

Proprietary stuff

The licensing situation with maps is a little disconcerting, and at 11 pages, a bit long. But this feels a lot more like an application-level service than, say, core infrastructure, and I'm fine with people setting limits on application services like this. Of course, the core infrastructure / application service line is a bit fuzzy. I use Google Maps a lot; it's starting to feel like core infrastructure. Google's got us right where they want us!

How about a native desktop version?

Imagine something similar to Apple's Dashboard, only running Android applications. You know I just want to start using that WebView.addJavascriptInterface() API on the desktop ...

I had the same thoughts on MIDP, back in the day, of using it as a container for little useful desktop apps. But that was pretty silly, given the lameness of MIDP.

Again, I think the nice way to do this would be to run the apps "native" instead of in a virtualized Linux box. I think if you looked at some of the common componentry used in Android and Chrome, you might end up thinking that being able to run Android apps in Chrome would be an interesting idea.

Now, you might say "the UI capabilities of Android are too lame to be useful on a desktop!" Thing is, I hear that complicated GUIs are on the outs. Even on the internets! I generally agree with those thoughts, and I have to admit, one of the most interesting UI's I've seen recently was Muxtape (R.I.P.); simple.

Speaking of simple UIs, after watching this video discussing ListView, I couldn't help but to think of our old, dear friend Gopher (R.I.P.?). Once upon a time, I imagined having Gopher server interfaces on everything, so I could have a simple universal client that could talk to anything. Good times.