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.

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.

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.

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.

Desanka Polajnar was probably the first CS professor that actually made people worry about failing a Computer Science course when I was up at UNBC ten years ago. People for some reason couldn’t quite understand how boolean logic worked, and why K-Maps were a good idea. In fact, many people didn’t even realize why it was relevant to learn Assembly Programming at all, and many people consider knowing the internals of a processor a waste of time. I remember hating the first CPSC 230 class, because it was hard, and because it seemed to have absolutely no bearing, or connection to what I’d be doing now. I also remember thinking that MIPS and ARM assembly was useless because you know, everything runs on an x86.

Also, it was in her class that I got introduced to Hardware, which has turned into a pretty awesome hobby. It’s strange, since to this day, I haven’t met too many people that even know what a PDP-8 even is, let alone actually implement it with microcontrollers and TTL logic. Thanks to Desa, I can say that I actually have done that, and I think that’s pretty awesome. I definitely appreciate the time I spent in her classes, even if I didn’t seem like it back in the 90s, when I was actually in them.

Thanks

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.

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

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.

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.

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.