Blogs

PhoneGap Plugins Demo from Joe Bowser on Vimeo.

Recently, we have been working on each platform to get the platform-specific features to be encapsulated as plugins. Now, for the iPhone, that may take the shape of native controls, but for Android, we’re working on a project for the plugins called PonyGap. Why did I call it PonyGap? Because chances are that you would use this app in a demo, and that you would most likely stick to the basic feature set of HTML5. Of course, you MIGHT use one of these, but generally not all of them.

Currently the first plugin feature that we added was the ttsHook. This will hook into the Android Text to Speech functionality and allow PhoneGap applications to be useful to people who may not necessarily have the best vision or coordination. We’ll work on a better MobileSafari example and release it with the plugin.

This functionality was inspired by the Eyes Free work that Google did.

Update: This post is now obsolete, and there’s a new and different method of creating plugins for Android. Please visit the PhoneGap-Plugins repo for more info.

One of the big complaints that we keep hearing when you port PhoneGap apps over is that they don’t follow the Android UI specifications AT ALL. The alerts don’t have buttons, the back key doesn’t do what it’s supposed to do, etc, etc.

Well, we fixed the back button, and introduced a new event, menuKeyDown. When the menu key on any Android device is pressed, this will fire an event that will let the user know if they need to present the user with a menu of some sort. The menu could come from the bottom like the typical Android menu, or be a lightbox that takes over the window. The event exists so that the user can decide on it.

Also, the alerts have buttons now! I’m going to push these up to the EDGE version of PhoneGap momentarily.

I just finished the basic version of Android 1.6 Database Storage for PhoneGap. Unlike Android 2.0, which has a proper implementation of this, Android 1.6 does not. There are definitely numerous bugs that can happen with this implementation of Database Storage, such as mis-formatted numbers being passed into Javascript due to what SQLite sends back to the browser, however I’ve tried to mimic the HTML 5 spec the best I could with Java and JavaScript.

Now, the code being passed is VERY primitive, and it’s not well documented. Android is notorious for having this weird API in the providers that gets in the way of you and your SQLite Database. Providing a mapping from Javascript to the rawQuery seems to have made the most sense. We have yet to add a fail condition to this yet, so when it fails, it will fail silently. That’s somewhat annoying when it comes to errors in SQL syntax, and we’ll try to hammer out that bug later this week.

OK, so as many of you know, I’m in Canada. In Canada, we have some pretty nasty providers. Honestly, choosing between Bell, Telus or Rogers is like choosing which limb you want to saw off. So, because I can’t wait anymore, I’ve decided to start work on SQLite Storage on Android 1.5. This will hopefully emulate the HTML5 storage, but I haven’t really tried it out too much yet. However, I found some weirdness with the databases.

Databases in Android have to be stored in the /data/data/ /databases/ directory if they are accessed by an Android app. This is ever-so-slightly different from the /data/data/ /app_databases/ directory that Android 2.0 needs to support HTML 5 proper databases. I’m hoping that by exposing this and adding it in the conditional logic, that I can hack in the appearance of HTML 5 storage on Android 1.5 and Android 1.6. However, here’s a code fragment that comes in very handy:


Package pack = this.getClass().getPackage();
String appPackage = pack.getName();
path = "/data/data/" + appPackage + "/databases/";


This is particularly handy when dealing with Databases in General, since you may want to take your code and throw the thing in a JAR so that you can deploy numerous apps easily. Of course, making a JAR for Android Development is a simple, but completely undocumented process. I’ll post about that later.

But the fact that this feature will be necessary because of the maintenance of the 1.x Android tree is depressing. I really wish that tricks like Java Reflection, and multiple APIs for multiple versions weren’t required, but at least we managed to hack around the annoying fragmentation for the time being.