Learn PhoneGap From Lynda.com

While things have been kind of insane as I start my new job I was lucky enough to be able to travel down to Carpenteria, CA and do a Lynda.com recording on Up and Running with PhoneGap. The title is part of their “Up and Running” Series which means it’s about a 2 hour course and is meant to provide a basic overview of some of the features behind PhoneGap. So it’s not an intense deep dive but hopefully for some of you looking into PhoneGap it will give you a good sense of how the APIs work and some of the general workflows.

Up and Running with PhoneGap

The video goes through setting up the SDKs, setting up a PhoneGap project, adding device-specific APIs, incorporating jQuery Mobile, and using PhoneGap Build to compile and test binaires. So if you’re a Lynda.com subscriber, check it out!

One quick note, there’s currently an issue with using jQuery Mobile 1.3 and the Handlebars templates I use in the course. I’m working on figuring out if that’s going to be fixed or if people will have to use jQuery Mobile 1.2.

Using Ratchet with PhoneGap

When I saw the Ratchet project I was stoked. While the initial site talked about being able to prototype iPhone applications with HTML/JS/CSS it was pretty apparent that this could be something even bigger than that. And sure enough, on their README page it talks about long term goals:

We eventually want to extend Ratchet beyond the prototying for iPhone and create HTML/CSS/JS components for iPad and Android devices. Our dream is that Ratchet becomes the best way to create mobile experiences with web standard languages.

To me, that means this could be a great project for PhoneGap applications. So I threw it into a project and looked at getting it running. Unfortunately nothing happened. I could get some components to work but once I tried to move between pages it wouldn’t respond. I tracked it down to the push.js-esque functionality that they’re using. Specifically, it’s a single line of code that causes issues.

if (xhr.readyState == 4) xhr.status == 200 ? success(xhr, options) : failure(options.url);

The issue is that PhoneGap only seems to return a status of 0 when using XMLHttpRequest. I’m fairly sure this has something to do with the fact that it’s loading from the file system and not a server, but I’m not 100% sure. By making sure that Ratchet accounts for status of 0, page transitions work perfectly.

if (xhr.readyState == 4) xhr.status == 200 || (xhr.status == 0 && options.url.indexOf('file:///') != -1) ? success(xhr, options) : failure(options.url);

I’ve got the full project up on GitHub and you can bring it into PhoneGap Build and test it yourself. I’ve only tested it on iOS but it works pretty damn well. I’m definitely intrigued. I’ve also posted this to the Google Group to see if they can support this out of the box.

Update: Simon mentioned in the comments below that by tweaking the code to check for status 0 AND file system, it would be safer. So I modified the ratchet.js file in my project to take that into account. Thanks Simon.

Speaking at Seattle Google Developer Group’s Devfest

There has been a lot going on and I’ll cover it over the next few weeks. But this weekend, on Saturday at 11:00, I’m going to be speaking on PhoneGap for the Seattle Google Developer Group’s Devfest. The whole conference looks awesome so if you’re in the area, sign up and learn a ton about creating apps across device form factors.

Join Us on the Create the Web Tour

Today we announced the Create the Web tour, a series of events that we will be doing around the world to talk about all the things Adobe has been doing with the web including new tools, new features in CSS, and services for web developers.

The tour is going to be in two parts, the first part is a full day event in four cities (San Francisco, London, Tokyo, and Sydney) that covers the full gamut of Adobe web tools and technologies. The second part is a much wider tour where the Adobe evangelist team will be spreading out across the globe to talk in more detail about specific tools and technologies at user groups, hack-a-thons, and other events.

We’ll have more information about that bigger tour soon, but in the meantime, if you’re in one of the 4 cities for the full day event, we’d love to see you.

Speaking on PhoneGap 2.0 in Phoenix on Sept 18th

If you’re in Phoenix and looking to get up to speed on PhoneGap 2.0, I’m going to be giving a presentation on exactly that on September 18th at AZCFUG. I’ll be talking about what’s new in PhoneGap 2.0 (and a few previous releases) including the command line tools and common JS. If you’ve never used PhoneGap before there will be info that will get you started and if you’re currently using PhoneGap but wondering what’s new (and what the future holds) I’ll be talking about that as well.

Hope to see you there!

PhoneGap 2.0 Released

PhoneGap 2.0

PhoneGap Day Swag

PhoneGap (and Cordova) got their 2.0 release today at PhoneGap Day here in Portland. The project has been moving at an insane pace so 2.0 is a good chance to take a look at everything that’s been added over the past few releases. A quick list:

  • A common cordova.js file so the API is consistent across devices.
  • A command line interface for generating (and debugging/testing) projects.
  • Bada/Windows Phone 7 support.
  • CordovaWebView which lets you use PhoneGap within an app that uses the native UI framework.
  • Weinre for testing remotely on devices.

Lots of awesome stuff and with the way the project cranks out releases, there will be more to keep up with very soon.

PhoneGap 2.0.0rc1 – With Command Line Goodness

The PhoneGap team announced that PhoneGap (and Cordova) have reached release candidate one for 2.0.0. They’ll be doing the official 2.0.0 release in Portland at PhoneGap Day (go get the last few tickets if you haven’t already!) but you can grab RC1 and start checking it out.

One of the cool new shineys is that the team has added command line tooling making it easy to create and test Cordova applications. You can see some of how the command line works here in the Docs repo. You basically create the project with the ./create command and that will build a sample project for you and also generate scripts in your project for building and emulating the app.

So if you get a chance, pull down RC1 and give it a spin. Then come see all the hotness in action in Portland.

A Response to Benjamin Sandofsky’s Shell Apps

Dion Almaer retweeted an article by Benjamin Sandofsky that covers “shell apps”, or HTML/Hybrid apps in contrast to native apps. His thesis seems to be, from his post:

If you plan to write an app for iOS or Android, you will save time and create a better product if you stick to Objective-C and Java, respectively.

Which I agree with in principle, but I also found some of his arguments deeply flawed. He spends a lot of time talking about the cross-platform problem of trying to build a web-experience that looks native on iOS and native on Android. Specifically he calls out differences on iOS and Android:

The harder problems are inconsistencies in platform conventions. The iPhone uses Helvetica as its system font, while Android uses Roboto. iOS transitions between views by sliding new views in from the right, while Android uses a zoom effect.
You could recreate each platform in HTML5, but that requires a lot of work. You could design everything around an iOS look, and settle for things looking weird on Android. You could create a platform agnostic design language, making things equally weird for everyone. In a web view, it’s an uphill battle for consistency, whereas going native provides consistency for free.

Put aside the fact that if you’re doing native development you’re writing two different versions anyway (I’m not sure why that would be a knock against an HTML-centric solution), why do you have to design around an iOS or Android specific look?

The Native Component Question

I know it’s harder, and potentially more expensive, and requires more design sense, but why should developers of HTML-centric apps for mobile devices be locked into the specific UI look and feel of that platform? I’m not talking about UI paradigms (eg, soft back buttons on iOS, menu buttons on Android), but the specific look of apps. Instead of skinning your application to look like an iOS app and then try to make it look like an Android app, do a design that looks unique and polished that would translate well across both platforms. Then as you start to get into the specific differences (he brings up a good point about transitions) you can implement those device/platform-specific patterns. To me one of the beautiful things about the HTML/JS/CSS stack is the freedom with which we can develop. Bringing that to mobile applications, and letting some great CSS/HTML designers loose on that platform is a great thing. And it’s one of the reasons I love PhoneGap.

There are definitely some performance implications by going with a shell app/HTML-centric app approach. And as your application gets more complex, those will pop up more and more. So it’s something to be very aware of. Benjamin quotes some of the reasons he sees for people choosing HTML-centric apps: “we need to release faster”, “write once, run anywhere”, “HTML is easier”. I’m not sure any of those are great reasons to choose HTML-centric apps. Instead I see the primary benefits of the HTML approach as not being locked into a specific platform or deployment model. With HTML you can repurpose code for mobile web and you can target new platforms as they come (no device is not going to support HTML). But maybe most importantly, with HTML you can easily create custom app experiences. There are some great designers out there who can do amazing things with HTML and choosing something like PhoneGap lets you use those skills to create a unique web-like experience with all of the device features users expect from native apps.

Is it a silver bullet? Definitely not. But I think dismissing HTML-centric apps as being done because they’re cheaper/faster/easier doesn’t do them justice. For some kinds of apps, the HTML-centric approach is just better. There’s an amazing community of people that know HTML/JS/CSS, the web is the ultimate platform for reach and flexibility, and shell-apps bring those two elements to the native app world. That’s something to celebrate.

Presenting PhoneGap at the AT&T Hackathon – Seattle, April 14th

I’m going to be presenting/talking about PhoneGap at the AT&T Hackathon here in Seattle on Saturday, April 14th. The hackathon actually starts on Friday night, and the last one I was at was a really fun event. If you’re in the area I encourage you to come check it out, build an app, and win some prizes. I’ll be there in and out (not totally sure when I’m speaking) but I’m hoping to see some cool PhoneGap projects and chat with developers. Here are the details:

F5 Networks HQ
401 Elliott Avenue West
Seattle, WA 98119

Friday, April 13, 2012 at 6:00 PM – Saturday, April 14, 2012 at 9:00 PM (PT)

The PhoneGap Starter Project

As I’ve been digging more and more into PhoneGap Build I’ve also been discovering that there are some gaps in the workflow and that it’s not always easy to go from a feature I want to use to a cross-platform implementation for it. Most of the time I’ll use the PhoneGap documentation as a starter point and then try to wrangle it into a local project and then make that local project work with PhoneGap Build. One of my favorite features of PhoneGap Build is that it can pull directly from a git/svn repository and build binaries from that repo. So last night I did a little bit of work to pull a couple of features/code from the documentation into GitHub projects that can be quickly loaded into PhoneGap Build and turned into binaries. Fueled by some NW Peaks beer last night I built some initial ideas for the PhoneGap Starter Project. As you can see it’s pretty sparse but there are a few goals I have in mind.

  • Showing how to structure projects for use in PhoneGap build. I struggled with this a bit–with things like making the config.xml file work, setting the files up correctly (in a www folder, and referencing cordova.js in the script tag but not including it), etc. Each one of these projects works with PhoneGap Build out of the box.
  • Linking documentation to a real project. The documentation for PhoneGap is pretty good and I wanted an easy, out-of-the-box way for people to see the features in action. So I took the code from the documentation and turned them into projects. Load them into PhoneGap Build and you can see them in action on your device in a matter of seconds.
  • Helping fix documentation! I’m looking for ways to contribute to the Cordova project and some of the documentation code is a bit out of date. What better way than to go through that code, make sure it works, fix bugs, and then submit them back?
  • Showing how kick ass PhoneGap Build is. I really, really like PhoneGap Build and once you get a good workflow down I think it’s a great help in creating binaries quickly. This shows it in action.

To use the project in PhoneGap Build, just create a new app from SVN and put in the URL of the repo.

Adding an App to PhoneGap Build

Creating a new app based on Git/SVN project

I’m going to be filling out some of other documented features over the week as well as doing an example for the ChildBrowser plugin. I’m curious to hear if this seems useful for people or solves any kind of pain point. Since it helps me find the gaps/issues in the documentation, it serves a higher purpose for me, but if it seems useful then I’ll work on keeping it up to date.