Blogs

So, apparently I forgot to mention the build.rb script I wrote last year. It’s checked into the phonegap-android repository, and you can pull it. To use it, you just have to do the following:

1. First, build a PhoneGap.jar (this should be built before being distributed in future releases)

ant jar


2. Run build.rb with the various attributes:

ruby build.rb TestApp com.testapp www /foo/bar


3. Profit.

You should have a test application created. The application name should have no spaces, and it’s expected that you know enough about Android development to change the res/values/strings.xml file to what you want it to be (you don’t need to know much). The www directory should have an icon.png in it for the icon that you want to use with your application. It’s an early script, and it’s an intermediary step that’s designed to make life easier for those who don’t want to bother with Eclipse.

Also, many people go here to post bugs. While I appreciate all the comments I get on Android, it works better if the bugs are also filed in the PhoneGap bug tracker. That way I can keep track of what’s broken. It’s also the place to put feature requests, since like the Android developers themselves, I will often not reply to the forums because I’ll be too busy with other tasks. I hope to have a plugins project added here soon.

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.

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.5 Database Storage for PhoneGap. Unlike Android 2.0, which has a proper implementation of this, Android 1.5 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.

After spending a day with Java reflection, I believe that we are now at the point where PhoneGap Android can now be supported on 1.5, 1.6 and 2.0 versions of Android. This wasn’t incredibly hard, except for the fact that I was unfamiliar with reflection, and the example on the Android site is less than helpful, since it deals with the Debug static methods, and not a real world object that can have things like instances. Also, reading Sun’s documentation made me realize how useless examples that use the word Class is as a classname.

The result of this is that we may have a JAR that can be used on Android 1.5, 1.6 and 2.0, which solves the divergence issue. However, this doesn’t mean that we have SQLite database storage that doesn’t exist on Android 1.5 or 1.6. It means that if you are using Android 2.0, you have access to the SQLite Database if you are running the Edge version.

After pairing down PhoneGap to a jar, it appears to be weighing in at under 200k. I’m thinking about distributing it as an installable library on Android so that if you have it installed, you can download PhoneGap compatible APKs. This would be similar to the Text-To-Speech API functionality. This may encourage Google to close the browser gap, or it may just get ignored if people just use their own stand-alone PhoneGap + app apps.

More info on this will come shortly.

Hey

Recently, we’ve been making changes similar to the iPhone code so that we can make it even easier for people to write Android Applications. We’ve encapsulated the PhoneGap source code into a JAR file, so that your Android Application can literally be as short as this:


import android.os.Bundle;
import com.phonegap.*;
public class TestApp extends DroidGap {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
super.loadUrl("file://android_asset/www/index.html");
}
}


Of course, you’d have to have the AndroidManifest setup correctly to accomodate the activities, but this is minor in comparison to how messy everything’s been before this change. We’ll have to do more restructuring of the repository to demonstrate how to use the new library in Android Applications, and this should allow for the Java code to be abstracted away and made even easier. Of course, we’d have to do more work to figure out how this will work on Android 2.0, but it’s some exciting stuff.

*EDIT*: Apparently Rogers didn’t push an upgrade to Android 1.6, and it’s very possible that they may never push up this update. Since I still use the phone I received from Google IO, I was not aware of this.

Recently, there’s been talk about Android splintering. This isn’t a rumour, it’s a fact. Here’s a short list of the Android Devices that are either in Canada right now or are slated to arrive and what they support:

• HTC Magic (Rogers): Android 1.5 (Upgradeable to 1.6)
• HTC Dream (Rogers): Android 1.5 (Upgradeable to 1.6)
• HTC Hero (Telus): Android 1.5
• LG Eve (Rogers): Android 1.5
• Motorola Milestone (Telus): Android 2.0 (Coming: Early 2010)

OK, this sucks! Android 1.6 introduced one MUST HAVE feature for Android, and now we’re excluding ALL the Canadian carriers? Now, it’s clear that Telus didn’t really have Android to begin with because of the fact that they were stuck with CDMA so long. However, that being said, this is not theoretical splintering, this is something that’s happened. Now, while I don’t care about the LG Eve, since it looks like a piece of crap (I can actually walk into stores and look at these devices!), I do care about the HTC Hero not being able to run PhoneGap.

Now, I could downgrade, but I lose support for the Sony Ericsson Xperia X10 and the Motorola Droid, but I can tell you right now that we’re not going to downgrade. This trend of shipping devices with a sub-standard version of Android needs to stop. I don’t expect people to ship with 2.0, because while it has nice, new features, it’s clearly got some issues that need to be resolved. However, shipping without the latest minor version (1.6), or at least pushing an OTA update is stupid. Hardware manufactuers and carriers need to keep in line with latest, which should be pushed to the Android Open Source Project repository. If that doesn’t happen early, and often, it’s going to keep frustrating developers.

So, after hearing the news that Nokia will be dropping Symbian from their High-End N-Series phones by 2012, and adopting Maemo, I decided that I would do a bit more research into the platform. I heard good things about it being open and it having an actual mature Linux stack (as opposed to what is running on Android and Palm), and I wanted to see how much effort it would take to get a PhoneGap prototype to run on it. At around 4 PM, I have this to show for it:

I used QtWebView to implement this, and it took more time to get the SDK started and working than it took to actually write the app and run it. I think getting the SDK for Maemo was the biggest hurdle for developing for the device so far. Of course, this is ONLY for Nokia phones, and not for many other phones, but the fact that the N900 was a device that I was considering until I found out it couldn’t support Canadian HSPA frequencies, I figure it was worth messing with. Also, QtWebKit is a part of Qt, and in theory can run on Windows Mobile with mostly the same codebase. With the uncertainty of whether Maemo would get Symbian WRT running on the device in some way, this may be an option.

At the end of the day, I’ll probably stick with my Android Phone, but this was rather interesting.

Recently, I’ve been looking at the old Audio Handler code that was contributed a while back and why it can only play on the SD Card. I assumed that there was some weird permission issue that didn’t allow for data to be written in other parts of the device, but I didn’t look into it too closely until recently.

In PhoneGap, the files that are being loaded are stored in the assets directory. The decision to do this was because they could be accessed through file://android_assets, and this seemed to be rather convenient for the time, since I wanted to prove that you could in theory take the HTML and Javascript from an iPhone PhoneGap app, and put it into an Android App and have it still work. However, the issue is that this is not really a file location.

All files in the Android solution are zipped up and compiled into an apk, which is signed and installed on a phone. Dalvik comes across this package, and runs this package much like a traditional Java VM runs a JAR. The big difference is that if you’re trying to do things like access a file natively, store data into a database, or run an executable, this doesn’t work. Now, in the past, we just used the SD card for when we needed file storage, BUT last week when figuring out the WebKit SQLite Support for Android 2.0, I discovered where the data actually was being stored on the device, in the /data/data/package_name/ directories.

I then decided to look at how other people are using this storage, and I checked out the Orbot project. A while back, I had a passing interest in porting Cryptographic tools such as OTR and Tor onto Android so that I could have this on my phone. However, other people who are more dedicated to making awesome things, actually made this happen with Orbot, and shared the source. I saw that they were grabbing an executable written in C, and storing it in the data directory. This allows for ARM code to be run on the device, and allows people to get around the Android SDK, and the problems that it has.

So, I’m faced with a dilemma. Do I keep with storing the data in the assets directory, or do I copy the www directory to the /data/data/app_name/www directory and allow the files to sit in the Application FS storage? Will there be an issue on initial install? Will Android PhoneGap require a loading screen where we do this sort of heracy? Putting layout and executable code in the /data/data directory herasy? What do you think?