Last week I heard about Palm’s new hot app promotion. It is pretty much an incentive to developers to make palm apps, have them get ranked and get some easy money (find details here). I realized that a lot of PhoneGap developers seem to just develop for the iPhone and android and I wanted show how easy it is to convert that iPhone PhoneGap app to a palm PhoneGap app.

The app which I am converting is called Snow Reports. You can download the source from my github at http://github.com/stevengill/SnowReports. You will see that I already have a working version of the app for iPhone, android, and palm. I have made three screen casts walking through converting the iPhone version to the Palm version.

Screen Cast!

Set Up

Once you have followed the getting started guide for palm on the phonegap wiki, you should have your system setup and ready to make the palm version of this app. Make sure you download the latest version of phonegap-palm from github here. We want to copy over the contents from the www folder in the iphone repository into the phonegap-palm/framework/www folder.

Changes I Made

There were very few changes I had to make to get this working perfectly on the palm emulator. The ultimate goal of PhoneGap is to have the user never need to make changes to the source but the PhoneGap team hasn’t started focusing on rendering issues yet so until then we will have to make a few css tweaks.

For index.html, first thing that all Palm applications need is the mojo library.
<script src="/usr/palm/frameworks/mojo/mojo.js" type="text/javascript" x-mojo-version="1" ></script>

You will also notice that in the meta viewport tag that height is set to 460px. This is set for the iPhone and takes into account header in the webview. With palm we can have varying heights of devices so I usually set this to device-height.
<meta name = "viewport" content = "width = device-width, height = device-height">

For snowreport.css, some of the styles that looked good on the iPhone will not render over so good on the Palm emulator. Here are a the two styles I changed to make it look pretty:

.header div, .footer div {
height: 34px;
padding-top: 8px;
background-repeat: repeat-x;
float: left;
}


.footer .mid-blue, .footer .mid-black {
padding: 8px 9px 0px;
}


Some Cleaning Up

There are a few things left over to do before I can call this app complete:

• I want to copy Icon.png from the iphone/SnowReports to phonegap-palm/framework/www directory.
• Then I want to change the id of my app. Open up appinfo.json file located in phonegap-palm/framework/www and edit the id. In my screencast I chose com.palm.snowreports. In reality you probably want to name this something different. If you leave it as com.palm.* it might not get accepted by the palm store due to them thinking you are trying trick the store into saying that palm made the app. The reason why it is set to that by default is because there is a bug in webOS that requires you to have com.palm if you want vibration in your apps. Palm is currently looking into this and will hopefully release a fix soon. Your best bet as a developer is not to include vibration for the moment and change this id to something unique.

After you have changed the Id and have the emulator running, in the terminal you will need to do a make, palm-install com.palm.snowreports, and palm-launch com.palm.snowreports.

There you have it. That’s how simple it is to convert your iPhone PhoneGap app to a Palm PhoneGap app and ready to submit to the Palm webOS app store. Get to it developers!

› Visit the original post

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.

› Visit the original post

A recent blog post by Steve at http://globalconstant.scnay.com/ revealed that HTML Select elements were not working in PhoneGap Palm … and after a quick test it appears that they’re not supported by WebOS at all. I scoured the internets trying to find this documented or discussed, and all I found was someone else mentioning it in the Palm Developer Center. This is quite surprising and a bit frustrating to know that such a basic HTML element is unsupported, and really messes with the cross-platform support of PhoneGap. It also gets me wondering what other HTML tags are unsupported.

The select element is rendered (though it is ugly, supporting the theory that this element is unsupported by webOS), but cannot be interacted with. I’m guessing that the custom Tap events used by Mojo are unimplemented on it.

Ideal world solution: Palm fixes this and gets it out in an upcoming release.

Real world solution: I start experimenting with ways to fix this. Would love to hear from the community on suggestions … but really the solution that comes to mind is that PhoneGap, during initialization, finds all the html select elements and replaces them with Mojo List Selector elements. Even at first thought, I see some hurdles:

- we will have to copy over all of the style and class attributes … but these may have an unexpected effect on the look of the widget, since the Mojo List Selector consists of html elements with internal Mojo css classes.

- we will have to implement the standard javascript events, if they are not already available, such as onchange, onfocus, etc.

So I hope to get some time to experiment with this soon, and see if I can sort it out. And hopefully not find out that there is a list of html tags unsupported by webOS.

PS — Suggestions appreciated!

› Visit the original post

I’ve been a bit inactive on PhoneGap recently, as we’ve had some client projects on the go. Need those $$ to keep the open-source projects rollin. But since its been a while, I wanted to give at least a status update on the PhoneGap platforms that I maintain.

There have been some updates to the PhoneGap Mobile Spec, so I’ve re-run them on WebOS and Symbian (see below).

96 / 100 on Palm:

Contacts fails, as a full device contacts api is not available to us in WebOS (discussed in an earlier post); some of the device info tests fail, as we can only provide device properties that are provided to us by the device (not much we can do here); Network.isReachable fails, I believe because this spec has been updated to return a network status ‘code’, rather than the previous return value of just ‘true’ or ‘false’. I’m going to fix up the Network api, hopefully today … but we’re looking pretty good on Palm. And Palm devices are really nice, and very quick and easy to deploy to. I highly recommend trying it out, even in their emulator (also really nice).

81 / 98 on Symbian Web Runtime:

HTML 5 Storage fails: not available in WRT, and can’t really implement SQLite in javascript ; Network reachability fails, as WRT provides no API for this (however I’m going to revisit this as I figure their should be a way to do this); File I/O fails, as WRT does not provide access to the file system. Basically after running these tests (and having them crash regularly, I think due to running out of memory), I’m thinking more and more that PhoneGap Symbian using Qt for Symbian is the way to go. WRT is a great tool, for lightweight apps, but its performance is not good. Javascript animation simply can’t be handled, and extensive sensor interaction will crash the application. Initial tests on PhoneGap using Qt for Symbian were much better. Not to say we should drop the WRT implementation overall, as it does meet certain needs.

› Visit the original post

Lots of new features have been added to Android Froyo 2.2. Among the most exciting ones are: Better speed with the inclusion of the V8 Javascript engine, JIT compiler as well as a new set of backup/storage and cloud messaging APIs.

I wanted to see how PhoneGap would work on Froyo so I ran mobile-spec on it and below are the results.

As you can see it runs the same as on Android 2.1 and previous ! Some tests fail but there not relevant to the Android Platform (orientation etc…)

› Visit the original post