frogpad

Frog call
© Nerelle Ring

In "iPhone and text entry" K1v1n complains about the iPhone / iTouch 'keyboard', and wonders if instead of spending time correcting the endemic finger checks, "Can we libe with good eoifg?"

No, we can't.

Here is a step in the future direction we'll be going with mobile keyboards: Frogpad. Obviously not good enough; it's too big. I'm thinking I'd want something like the stick of a joystick, that I could grip and do entry with my fingers, with buttons where the fingers rest. TrackPoint on the end controllable via your thumb, for moving the 'cursor'. Hell, I'll live with one finger button and learn morse code.

Anything is better than a soft keyboard. Multi-tap is better than a soft keyboard.

The funniest thing to me is that the assumption that a soft keyboard is deemed acceptable at all. We've been stuck with this same damn keyboard layout for over 100 years. I think we can move on. Apple, you're supposed to be innovative, right? Let's see some real innovation, please.

Once we have that nasty 'keyboard' problem solved, and since we already have the audio problem solved, the last problem is video. That solved, I can just keep my iBoxen, which only needs an on/off switch and maybe a power plug, in my pocket or man-purse, where it belongs.

We're not talking about flying cars here folks.

BTW, the FrogPad looks like it would be fun to try as a MIDI controller, except for the fact that it costs $150.

initial android thoughts

Some initial, random thoughts / wild speculation on Android, given the limited amount of information currently available.

• I don't think the mobile app 'problem' has ever been about the programming experience. Frankly, all the wonky tools, languages, frameworks are nothing but an enticement for interested hackers. More puzzles. Certainly, that's why I got involved with these guys about ten years ago. I'll go ahead and make the obligatory Smalltalk reference now, and then just shut up about it, mkay?

• No, the problem with the mobile app 'problem' has always been about lock-in by the various entities. Service providers that charge exhorbitant prices for network data access; that don't allow the download and install of Joe Rando application, instead, monetizing the application story; not even having a toolkit available to build apps in the first place. Maybe times have changed since I stopped paying attention to the market, but I doubt it. Perhaps Google and indirectly Apple can help break down some of these barriers. That's the real problem to be solved. Or perhaps Google could more directly fix the problem. I should be able to write an app for my mom that she can easily install on her plain old phone. That's got to be the long term story, anyway.

• Android is Java, and not Java. You write your application in Java, but it's translated to Dalvik format for running on the Dalvik VM. The Dalvik VM is not a Java VM, presumably.

• Dalvik is a registered-based VM, instead of a stack-based VM. What does that mean? A friendly link in the android mailing list points to an document describing the inferno VM. Note one of the authors, Rob Pike. How conveeeeenient. :-) BTW, he's got a great email address!

• I've heard folks claim "it's not J2ME", or whatever it's called today. Not quite right. Esmertec says it will support J2ME per customer request. Presumably, customers being service providers. But you could imagine Sprint charging you a few bucks for a MIDlet capability. Of course, your MIDlets will have to be modified to Dalvik VM format, presumably, before run.

• There are actually three J2ME-ish packages included in the android.jar file that shows up in Eclipse when you create an "Android project". javax.microedition.[khronos.opengles|lcdui|lcdui.game], though the packages appear to be radically stripped down. Why are they even there? The khronos.opengles package appears to be 'public', not sure why the others are there.

• Apache Harmony classes are included. Any Java lover that ever dissed Apache Harmony as pointless, needs to eat crow right now. Because, had it not been for Apache Harmony, you might be programming Android in Python instead of Java. Or C++.

• Includes an XML pull parser. Thank &diety;! Well, it's in the android.jar used in Eclipse, but I don't see how you get to it via published API.

• Includes SQLite. I'd rather have seen LittleTable. heh

• The .class files in the jars seem to have (or at least some have) debug information. Decompile away! Though you're probably not allowed to per whatever click-through license you clicked through.

• Ian Skerrett has a blog post titled "What Does Android Mean for Sun's OpenJDK" which is pretty self-descriptive. Read up, if you're interested in licensing hoo-haa, especially the Java variety.

• Miguel de Icaza has some thoughts on "Android's VM" and Mono. We'll see a lot more of this, including folks wanting to target existing languages to the Dalvik VM, presumably. I wonder if any of the PyPy developers work at TheGoog?

• Could 'typical' JavaDoc have been so hard to build?

• I got to install Gutsy in a VMware session on my MacBook, and then Java, and then Eclipse, and then the Android SDK, then the Android plugin. Because there's a little problem running the Android plugin in Eclipse for some Mac users. Perhaps that's why there's soft keyboard in the emulator?

• Personally, I think Google is shooting a bit low here; the platform sounds like it would be good enough to run little 'mini-apps' on your desktop. Like say, AIR does. Or like Google Gadgets.

• It's not a real platform until it has IDL. Woo Hoo!!