Tag Archives: mobile

Adventures with PhoneGap

Palm Pre, Motorola DROID, iPod TouchI’ve been working with PhoneGap this week to create a simple geolocation app. It’s a framework for creating mobile applications in HTML, JavaScript, and CSS that will run on all the major platforms. You write your application and reference the APIs that PhoneGap provides. Then you simply drop your HTML and JavaScript into the various platform-specific template projects they provide and compile it with the platform’s native compiler. Simple as that.

But the devil is in the details. Every platform and device has subtle differences that make cross-platform development painful. There are even differences between how an emulator and a device run the application.

I’ve been testing on three platforms: webOS (Palm Pre Plus), Android (Motorola DROID with Android 2.1), and iPhone OS 3 (iPod Touch).

Here are a few of my frustrating findings:

Notification: alert, beep, vibrate

First off, webOS doesn’t support the alert() command at all. Android and iPhone do, in the typical fashion.

Beeping is fine on the devices themselves (the Motorola DROID even says “Droid” when you call that function). But the Android SDK emulator kills my app when I call it.

Vibration works on Android. I assume it also works on the iPhone, but I only have an iPod Touch at the moment, and it doesn’t have a vibrator in the first place. The Palm Pre won’t vibrate unless the package name begins with com.palm. Obviously for testing purposes it would be fine to label your app as coming from Palm, Inc. itself, but that won’t fly if you want to distribute the app. So no vibration on webOS. And can you guess what the iPhone simulator does with the vibrate() command? It makes the app hang. Go figure.

Moral of the story: Alert, beep, and vibrate won’t work reliably if you need to support every platform and don’t want your code to break in an emulator.

Location services

The webOS and iPhone simulators both show their location as the headquarters of their respective companies (Sunnyvale or Cupertino). The Android simulator doesn’t even provide location data, so it’s utterly useless for testing in that regard.

My Palm Pre Plus (running on Verizon) can get its location relatively accurately when I’m running it on 3G (even inside my office). Not so if I’m on the WiFi. If I get a fix at all, it’ll take a long time and may be quite inaccurate. (Note that this is the behavior I get everywhere in webOS, not just with PhoneGap.)

The iPod inexplicably thinks it’s in Lilburn, Georgia. For comparison, I’m in Provo, Utah. Only 1,927 miles off. Google Maps on the iPod gets the correct location, but not PhoneGap.

The worst of my problems, though, is the Motorola DROID. More than half the time, my app can’t find its location. It doesn’t matter whether I’m on 3G or WiFi, inside the office or out on ground level. When I compile and run the app immediately after I’ve changed something, it usually seems to get a location fix. But when I subsequently run the app (whether connected to the debugger or not), it fails to get the location. I’ve tried it on two different DROIDs and they both exhibit the same behavior. Google Maps and turn-by-turn navigation work perfectly–they find the location and track it reliably. But something between the phone’s GPS and the PhoneGap library is getting screwed up.

Device UUID

webOS and iPhone OS both return a useful UUID on the device.uuid property. However, Android (both on the emulator and on the DROID) returns simply the unhelpful “undefined.” My app needs to be able to identify users by the UUID of their device, which simply doesn’t work on the Android.

UPDATE: Android 2.2 (Froyo) returns a UUID as you would expect. Only problem is that hardly anyone has it as of now (July 2010), and a lot of older mainstream handsets won’t be getting it at all.

HTML Select boxes

This one really ought not to be a problem. But webOS won’t let you tap on an HTML select box inside a PhoneGap application. It’ll display just fine, but you can’t make a selection. Select boxes work fine on normal web pages. iPhone and Android both support the select box perfectly, including the native OS skins. No dice with PhoneGap on the Palm Pre.

EDIT: Ryan from Nitobi is working on a solution for this on webOS. You can read about it on his blog.

UPDATE: Ryan has fixed this now. See his comment below for the updated files for your project.

Conclusion

So. After wrestling with all of these issues, what have I determined?

PhoneGap is a really slick framework, and it makes it very easy to create a mobile app that is “write once, run anywhere.” But the actual implementation details get hairy, and even fundamental operations like geolocation services and vibration are not implemented uniformly across all these devices.

Caveat emptor.


For those interested, I’ve posted a few questions about these issues on Stack Overflow:

Check-in attendance

Today this article came through on my Twitter stream (via lnxwalt):

Ariz. college to position sensors to check class attendance
Devices would be installed in underclassmen lecture halls; some say infringes on privacy

Students at Northern Arizona University will have a hard time skipping large classes next fall because of a new attendance monitoring system.

The new system will use sensors to detect students’ university identification cards when they enter classrooms, according to NAU spokesperson Tom Bauer. The data will be recorded and available for professors to examine.

Some quoted in the article decried the development as “Orwellian,” others found nothing wrong with the practice.

The main concern was that the system could potentially grow to include not only recording attendance in certain large classes but also tracking students’ presence across the entire campus, potentially enabling university personnel to know the precise location or behavior of any given student. While I don’t envision such a system running that wild, it does raise interesting privacy issues.

Many colleges uses i>clicker devices in large underclassmen courses for providing quick feedback on in-class quizzes, etc. They can also be used as a means for recording student attendance, a fact referenced in the article. Interestingly,

UW professor Dana Geary, who uses the clickers for one of her classes, said the clickers do not seem to affect the number of students who attend class.

Using an i>clicker is voluntary (even though it may have obvious bearing on a student’s grades). This eliminates the “privacy concerns” raised by the opponents of such attendance-tracking systems.

Why not implement a check-in attendance system, perhaps with the RFID cards used at NAU, perhaps with smartphones, perhaps with single-purpose devices like i>clickers?

I have pondered this possibility before. College-age students regularly use smartphone applications like foursquare and Gowalla to track their attendance at social functions. “Checking in” to a restaurant, a bar, a movie theater, or a concert has become second nature to them. I even use foursquare to “check in” to various academic buildings at my university.

Rather than trying to track students against their will, why not turn it into a self-driven system of checking in to class? The system wouldn’t necessarily have to use smartphones. Indeed, RFID checkpoints at classroom doors (similar to those used in public transit systems) would likely be a simpler and more reliable solution. It then remains (as it should be) the student’s responsibility to ensure that she is in class on time.

Google Docs and Dropbox

I’ve been using a couple of “online” products the last few days for managing my documents. The first is Google Docs. It’s a lightweight, online editor for documents, spreadsheets, and slideshows. Everything is stored on the servers of the ubiquitous Google. It’s (usually) readily accessible, but only as long as you have an internet connection. (No there is Google Gears for offline file management, but it doesn’t “officially” run on 64-bit linux, which is what I have. There is a package someone has put together, but I haven’t got it all to work yet…)

The other product I’ve been using in Dropbox. Basically, it allows you to sync files across multiple computers. It stores your files on their servers and even keeps revision and deletion history. You can set up the client on Windows, Mac, or Linux. Dropbox then synchronizes them all. If one of them dies, it’s simple to put everything back. And all of your files are accessible on your local machine if you don’t have an internet connection. And, obviously, you’re not just limited to documents, spreadsheets, and slideshows–you can put up any file you like.

What is my evaluation? Google Docs is a lot easier to use. No daemon to install, no separate account (assuming you already have Gmail). But if you need to work on a document offline and haven’t explicitly exported it or installed Google Gears, you’re out of luck.

Dropbox leaves everything in your hands. You have your own copy of the files, with which you may do as you please. No internet? No problem. And you have no vendor lock-in. You edit files using whatever programs you like. You keep them in their native format (which means no data or formatting loss during file-type conversions). Plus, you can even upload and download files using the web interface, making your docs accessible even on a computer where you don’t have Dropbox installed.

Final answer: Google Docs for the little things where I need a quick and easily accessible document. But Dropbox for reliable handling of everything else.

Want a Dropbox  invite? Shoot me an email or leave a comment.

Usability, the iPhone, and Fitt’s law

I just read a great iPhone usability review on the Humanized Weblog. Interface design interests me, and Humanized has a ton of really cool ideas for creating humane, usable, intuitive interfaces.

Also on the post was a discussion on Fitt’s law and the way Apple designed multi-level lists on the system. I found a link on the Wikipedia article to a Microsoft blog discussing the implications of Fitt’s law in interface design for Windows and Microsoft Office.

Very interesting reads.