Blogs

There was a fair amount of news about Android 3.0 coming out. There was tons of hype regarding the new Honeycomb release, and how it would be designed for tablets, how there is 3D Acceleration, and how the User Interface would be changed. Well, even though it’s rumoured that at Google IO, we’re all going to get tablets, we decided to go and get the Motorola Xoom so that we can have solid answers to our clients about Honeycomb tablets.

Unfortunately, we have answers, and they’re not very good with respect to Google.

First of all, the Honeycomb Emulator is so horrifically slow, we had to buy a device. The device we bought was the Motorola Xoom Wi-Fi Only model. After booting up the model, we put PhoneGap on it and ran tests. Most of the tests worked fine, however we did notice that the Native Storage (SQLite) does not work anymore and throws a security error. This is a serious problem for many PhoneGap applications that use this, and I plan on investigating the storage situation, and seeing what storage is used on the device.

Secondly, when we ran our mobile-spec test suite and ran it with no try/catch, this actually causes the browser to close. The browser shouldn’t close when a Javascript Error is thrown. The fact that you can force someone out of the browser by throwing an exception should be an indicator that this should not have been released,

Finally, this device is rumored to have 3D Acceleration, including in the browser with 3D Transforms. First, we tested the browser with the standard WebKit test here. When you test it in the actual Android Browser activity, you get the following:

Then, when you take the poster-circle.html file (which is nice and self-contained) and stick it in PhoneGap (which at this point is just an Android Webview), you get the following here:

Now, since we don’t have the source code, we have no idea why Android Webview has broken 3D CSS Transforms, but Android’s browser does. It’s clear that Android WebKit didn’t go through any sort of rigorous QA process, and was once again cobbled together. The thing that I don’t like about this situation is that I can’t see what they did to fix it on their browser. Many people would love to see 3D CSS Transforms on Android, Tablet OR Phone, but we don’t have either right now.

The thing that I don’t understand is this. If Google as a company isn’t proud enough to release this source code, then why were the proud enough to release a half-baked product? As many people know, I have been developing Android applications both with WebKit and with straight-up Java ever since I heard that the T-Mobile G1 was going to be released. I put up with flaky APIs, with WebKit bridges that would crash, and with the mess that the Android 2.0 release was. The fact that Google hasn’t learned from their mistakes with Android 2.0 was disappointing. It wasn’t too bad in 2009 when they did this, because not too many people were using Android yet, but now that we’re in 2011, and Android is on a ton of devices, and Android is in the tablet space, I’d expect there to be a little bit of consistency between the Android Browser and the WebView with respect to what is supported in WebKit.

That being said, I’d forgive flakiness in a x.0 version of Android if it came with the source code. Mainly because the community could fix the bugs and help create something kick-ass like the awesomness that Android 2.1+ was (Android 2.1 was the first solid Android version, everything else before it people liked because we were rooting for the underdog). However, today, as it stands, there’s two different versions of WebKit on the SAME DEVICE that operate differently. I think that this is a serious regression, and it’s unfortunate.

Update: I’m an idiot! The reason you don’t get 3D CSS Transforms is the fact that you have to enable 3D Acceleration for the app in the Android Manifest. A quick Google Search turned this up, and now I have it working. I still think the bug with the storage, and the fact that when you hit the back button you end up back at the First Use screen are still big reasons that Honeycomb is not ready for primetime, but WebKit has many problems, but 3D CSS Transforms aren’t one of them.

Recently, the way we were creating a camera and using it broke. I’m not sure why it broke, but I decided to say screw it and to use the Camera Intent in Android, because that’s what you’re supposed to do on Android anyway. This is what most Twitter Applications use, and since Twitter Apps are probably the most used application on Android, I figure if it’s good enough for them, it’s good enough for me…

Oh how wrong I was!!!

I added the new intent code, and I tested it on four phones. I tested it on the HTC EVO 4G that I received from Google IO, the Nexus One, the Motorola Milestone with the official Telus Firmware (with camera), the HTC Dream with stock Android 1.6 and the Rogers HTC Magic with Android 1.5 and the 9/11 update. Basically, everything worked but the Rogers HTC Magic. The thing is that once you use intents, you are relying on the OEMs to write a good enough Android Camera Application for you to get a picture from. This may be good for a Google blessed image, or a stable HTC phone like the EVO, but it’s clear that on certain phones from certain providers, that there may be some issues.

I’m certain that there’s phones in the wild that have broken cameras, and it’d be good to find out which phones have broken cameras. If people could test on these phones (with Canadian carriers next to them), that would be greatly appreciated:

• HTC Hero (Telus)
• LG EVE (Rogers)
• Motorola DEXT (Bell)
• Motorola Quench (Rogers)
• Motorola Backflip (Telus)
• Samsung Galaxy (Bell/Rogers)
• Acer Liquid E (Rogers)
• Xperia X10 (Rogers)

Those are the phones that I know are in the wild in Canada. I’m sure there’s more than this in other countries, namely in the United States, but this is a good cross-section of devices from a handful of manufacturers who may have their own customized camera applications. I’ve exempted test devices from this post, because I don’t think it’s fair to take a broken firmware and say “Hey, the Camera Doesn’t work!”. However, the HTC Magic should work, and it’s disappointing that it doesn’t, since this breaks not only PhoneGap’s camera capability, but anything that uses that intent. Hopefully in the future, Android cameras will be more reliable.

This is my biggest pet-peeve to date. We get a lot of people trying to use PhoneGap across all devices. However, despite the work that people have done on droidgap, most people still use Eclipse as the primary way they develop with Android, because that’s what people read in the Wiki.

The problem is that when you start developing for Eclipse, you notice that PhoneGap is set to the latest version of Android. However, for some reason people want to change their target because they’re running an earlier version of Android. Since they use Eclipse to deploy their app, they are misled to believe that if you write an APK, you must target only one version.

If we’re deploying multiple APKs, PhoneGap has FAILED to do the job it was meant to do. If you have to change the target, there is something wrong!

Now, why do I say that, because I discovered this when using Eclipse:

• Automatic Selection of your running target is EVIL!
• Manual Selection allows you to choose your APK

The reason Automatic Selection is evil is because it will launch an Emulator and go for the highest level device it can go. Not what you’re running, but whatever the highest device is. This is the correct behaviour, but this does NOT help people who are looking to test it on their device. This causes people to instinctively mess with PhoneGap and do bad things like change the target. Here’s why you should NEVER have to change the target:

This is the line from the AndroidManifest.xml. This sets the Minimum SDK Version to 2, which is Android 1.5. A while ago, we fixed the Android 1.5 issues by changing the conditional compatibility code to look for the SDK string. We could probably do this better, and we’ll look into it in the coming weeks. However, as it stands right now, this is how we do it, and it works.

The other thing that annoys me about eclipse that I’m sure causes people to change it is this:

This is the stupidest UX ever. It should be a warning, not big red X, and this causes a LOT of headache and unnecessary gnashing of teeth. If you click OK, it will actually run on the device. As you see here, this is pointing to my Nexus One, which is still running Android 2.1-update1. I’m currently building PhoneGap for Froyo, BUT it still runs, and it works fine. This is actually how you can have one APK that runs on all devices.

I can see how someone wouldn’t want to support all Android devices, BUT given the fact that according to Google, Android 1.5 and 1.6 phones far outnumber the Android 2.x devices, it makes sense to make one APK to rule them all. The idea is to write once and deploy anywhere, and not write once and deploy to every single version of the platform. If this doesn’t work for you, you’ve found a bug, and we would appreciate it if it was filed. It’s important for PhoneGap to both run on Android 1.5 AND be able to take advantage of all the latest browser features, and the current approach we are using with the EDGE version allows us to do exactly that.

Fragmentation? The only fragmentation on Android that we care about is the fragmentation between WebKit versions, but that’s another issue entirely.

Over the past month, I was working from home, and when I wasn’t busy wiping spit-up from my kid’s face, I was working on various stuff, including a new Android PhoneGap demo to replace the one that I took off the Android market. The problem with these demos is that they do not stand the test of time. However, this one should. After playing with C5Bench a couple months ago, I decided to do a quick hack of the Canvas. After many bug fixes to PhoneGap Android later, I finally managed to put together this simple example:

Now, of course, this is an early version, and the code has been thrown together very quickly, and there are bugs, which is why I haven’t posted it in the market, but you can download and try out the application here, or scan in the QR code below.

This code is based on a few examples that I found on the web of good Canvas Tutorials, namely the Breakout Clone tutorial by Bill Mill. It’s a pretty solid tutorial and shows how to effects like bounce fairly effectively. Of course, I didn’t add bounce, because I wanted more of a sliding bubble effect. I also decided to NOT use the jQuery framework to keep the javascript code as small as possible. (In fact, I didn’t even use XUI, since I didn’t see the need).

That being said, I’m definitely going to have to work on my own JS library at some point that maintains complex objects, since redrawing functions can quickly become large and cumbersome, even when using a JS library, which is better suited to the DOM and not pixel-manipulation.

So, basically you move around two objects which are directly related to each other on a screen with the accelerometer, and the method that we use is below:


var watchAccel = function()
{
var canvas = document.getElementById("canvas");
canvas.width = document.body.clientWidth;
canvas.height = document.body.clientHeight - 100;
ctx = canvas.getContext("2d");
var succ = function(a){
updateValues(a);
updateDraw(a);
};
var fail = function(){};
var opt = {};
opt.frequency = 100;
timer = navigator.accelerometer.watchAcceleration(succ, fail, opt);
}


Now, what’s interesting is how the frequency is handled. Currently, we use the setInterval to do this, exactly like the iPhone. However, this actually kinda sucks, and we may in the future move more of this into the Java land, similar to how we manage the Geolocation code that we use. However, this is good enough to create the sliding bubble effect of the application. I hope to have the final version of the app up and working before Google IO, however I’ll probably post it up to GitHub this week, feel free to try and and let me know if there’s serious issues.

Now, for people who are Java developers, I can understand the attachment to Eclipse, but for the rest of us, Eclipse is a giant piece of bloatwear that gets in the way of the code and what we want to do with that code. However, it’s a fact of life for Android developers, or is it?

Building and running Android Applications:

Now, the first command that we deal with is the android command, which can generate a project. In typical java fashion, it takes a crap ton of flags, but you can create a project by typing this:


android create project -t 7 -k package name - a name -n name


This will create an android project. Now, on Android, the DroidGap script actually uses the Android script to create a project. So, once you have your project, what do you do with it? Well, the first thing to do is to build it, which you can do with ant. When you type ant on an Android project, you’ll get a list of commands like this:

help:
     [echo] Android Ant Build. Available targets:
     [echo]    help:      Displays this help.
     [echo]    clean:     Removes output files created by other targets.
     [echo]    compile:   Compiles project's .java files into .class files.
     [echo]    debug:     Builds the application and signs it with a debug key.
     [echo]    release:   Builds the application. The generated apk file must be
     [echo]               signed before it is published.
     [echo]    install:   Installs/reinstalls the debug package onto a running
     [echo]               emulator or device.
     [echo]               If the application was previously installed, the
     [echo]               signatures must match.
     [echo]    uninstall: Uninstalls the application from a running emulator or
     [echo]               device.

I think this is pretty self-explanatory, BUT there needs to be something said for the difference between debug versions and release versions of the same piece of software. Most of the time, you’ll want to sign the apks with a debug key, so that these are specific to your workstation. However, when releasing a project, you will want to sign it with a key in the keystore. (It’s important to take care of your keystore and not to do what I did and forget about it. This is why I haven’t gotten a free Nexus One from Google for the PhoneGap Demo Application.)

Of course, this only works either for one phone, or one emulator. What if you have multiple emulators? No problem, use adb. The Android Debug Bridge is one of the most handy tools in the Android Developers toolkit, and is extremely handy for debugging. To see what devices you have, run adb devices like this:


bowserj@shapley:~/Orbot$ adb devices
List of devices attached
0123456789012 device


To install an APK onto a device, type the following:

apk -s 0123456789012 install phonegap.apk


Debugging Javascript and Java on the Android WITHOUT ECLIPSE

Now, here’s where things get interesting. When you need to debug javascript in the latest version of PhoneGap, you can use logcat to do so, all you need to do is run adb logcat, like this:


adb logcat


Of course, to actually use a Java Debugger, such as jdb, you need to attach it to a process on the device. ADB has you covered as well, all you need to do is this:

adb jdwp


Then once you have the PID that you want, do this:

adb forward tcp:8000 jdwp: jdb -attach localhost:8000


Then you’re in! Make sure that you don’t have another process (i.e. Eclipse) running that connects to this, and you should be able to debug your Java code just like how you would debug Java code normally. I admit that I’m not a jdb/gdb ninja and things like DDD have made me dumb. Therefore, I’d appreciate any book recommendations on how to use JDB/GDB for debugging.

After being shown many more ways of writing applications on Android, I decided to investigate the possibility of using the V8 Javascript Engine in Android Scripting Environment. I saw what was done with the other platforms, so it should just be a simple matter of porting node. Unfortunately, I’m not there yet, so I started with what I know should exist, which is V8.

Blogs have it on good authority that Android Webkit now uses V8 as its Javascript Engine instead of JSC as it used to in previous versions of Android. Now, in the Android Open Source Project, the build system that is used there (which has even less documentation than the WebKit docs on the Android SDK), has the ability to compile every single module in Android independently. However, if you type the following:


make modules


You will notice that libv8 and v8shell are lacking. However, if you run this:


make modules JS_ENGINE="v8"


You will then notice that you will have access to these things. Given that most phone companies do their own builds of the OS, it’s not clear which phone has v8 and which phone does NOT have V8. I’m certain HTC knows this, but what about Motorola, Sony, LG, Dell, Acer or any of the other manufacturers of phone who all do their own builds and all have their own buildbots. It’d be great if you could find out which engine you were running on your phone, since WebKit can run many JavaScript engines, and soon we’ll be able to run Javascript on the phone wherever we want. Of course this is more pie in the sky than the reality, which looks like this:

adb shell
$ cd /tmp/
$ ./v8shell
V8 version 1.3.10 (candidate)
> print('Hello world');
Hello world
>

We’re working on it, and we’ll see what happens when this does exist. In the meantime, the DroidScript stuff is really interesting, and the more ways to develop on Android, the better. While some people are married to the idea of Java, I like the idea of writing whatever works for the developer. If anyone can recommend some solid books on Makefiles, that would be greatly appreciated. If I ever manage to get this to work, I’ll have an APK for download.

Recently, a blog post came forward from Mikael Kindbord about running Rhino on Android. I was then asked to take a look at it,and it was pretty interesting. He recently released a project called DroidScript, which is actually really interesting. It’s an interesting front-end to Rhino, and it has the Javascript using Dalvik Android classes with Javascript so that you can have intents and invoke any method in Javascript that you can in Java. It does produce some pretty verbose code, and while I’m not going to re-structure Android PhoneGap so that it uses this just yet, it’s an interesting thought experiment in how many different ways you can write code for Android.

If you’re interested in Android and Javascript, I high recommend checking it out.

Recently, I started looking at Canvas on Android, and I came across the C5 Canvas Benchmarking test. I tested it on both the Motorola Milestone that I recently bought, and the Sony Ericsson Xperia X10, and it was pretty surprising. Now, it should be noted that the Motorola Milestone has a TI OMAP3430 processor, and is capable of speeds up to 600 MHz. However, the Xperia X10 has a Qualcomm Snapdragon processor, and has a clockspeed of 1.02 GHz. Now, people have been speculating whether this clock speed will make a difference, and I think that when you look at the results, it clearly does.

Now, I don’t think that performance is quite there yet, but you may see more advanced uses of Canvas on mobile web applications in the future.

I recently bought a new phone, the Motorola Milestone from Telus. The Milestone currently features Android 2.0.1, and is the first Canadian phone that actually features Android 2. So, while confirming fixes on the device, I noticed in LogCat that my WebCore wasn’t logging error messages. For those of you who don’t know, on Android 1.x, you could debug your javascript by using adb logcat and grepping for the WebCore errors. This frustrated me, since this wasn’t listed in the API changes. I then decided to sift through the WebView source code, and I found addMessageToConsole.

The method addMessageToConsole is a method that currently exists on the WebChromeClient that can be overriden with your own custom error message. Now, according to the Google Documentation, this is not a public method to be used until Android 2.1. However, I just tested it on my Motorola Milestone, and the method actually works. I’ve included this fix to PhoneGap and you should now be able to go back to debugging your Javascript directly on the device, as opposed to the other methods of using a different browser.

BTW: The code to add it is as follows:


public final class EclairClient extends WebChromeClient
{
private String TAG = "WebErrorLog";
// This is a test of console.log, because we don't have this in Android 2.01
public void addMessageToConsole(String message, int lineNumber, String sourceID)
{
Log.d(TAG, sourceID + ": Line " + Integer.toString(lineNumber) + " : " + message);
}
}


For backwards compatibility with Android 1.6, it’s a good idea to have this class extend a pre-existing WebChromeClient, and to dynamically chose the client you instantiate so you can actually get your application working.

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.