By contributing code that converts PhoneGap APIs to the Symbian WRT API, we’ve made it easier for Symbian developers to write applications using PhoneGap. You no longer need to include any extra code which, of course, makes deployment faster.

PhoneGap developers benefit by getting even better support for the Symbian WRT platform.

PhoneGap supports WRT 1.1 and implements these APIs: geolocation, accelerometer, camera, vibration, contacts, SMS, sounds, orientation change and storage. The network availability API is under development.

If you’re new to PhoneGap, it’s worth checking out. PhoneGap is an open source development framework for building cross-platform mobile apps that run on Symbian as well as iPhone/iTouch/iPad, Google Android, Palm and Blackberry. The PhoneGap open source code has been downloaded more than 250K times and there are thousands of PhoneGap apps in app stores and directories.

› Visit the original post

Get the source and view the README

Below are screenshots from the test app included, called ‘iAdHost’

› Visit the original post

Then don’t miss Advanced PhoneGap training online on July 8, 2010 from 10 am to 1 pm PT. During this online session, you’ll learn everything you need to know to build complex, cross platform mobile apps with advanced GUIs and functionality using the PhoneGap open source framework.

You’ll learn how to:

• Extend PhoneGap and work with plug-ins
• Dive deep into mobile JavaScript to build complex apps
• Work with XUI
• Take your PhoneGap apps offline
• Work with GitHub and contribute back to the PhoneGap project.

Advanced PhoneGap Training – Online
Thursday July 8, 10 am – 1 pm PT
Cost: $99
Register now

We hope you’ll join us for this informative session! Find out more about what you’ll learn at Advanced PhoneGap training.

› Visit the original post

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.

› Visit the original post

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

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

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

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

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

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.

› Visit the original post