Nitobi/Adobe for about five years now, the last two of which have mostly been on PhoneGap Build. I wrote a book about PhoneGap but it’s all out of date, so I’m not gonna mention it again. I also came up with the name “Apache Callback”. I’m on Twitter if you enjoy people complaining about Arsenal Football Club
Hardeep Shoker, who’s worked with me on PhoneGap Build for about a year. If you’ve ever used PhoneGap Build, Hardeep has probably helped you with the horribly broken bits that I wrote. He seems pretty smart, but he really likes PHP, so I dunno
in the cloud Friday, 20 July, 12 in a nutshell: PGB lets you skip the SDK part of PhoneGap development (with some caveats). you upload your web code to us
Friday, 20 July, 12 on that basic product, we have a bunch of other crap. so we support six platforms - Android, iOS, BB WebWorks, Windows Phone 7, webOS and good old Symbian. we have an API that, glaring security flaws aside, works pretty well for people. we have some neat collaboration support, so you can let others test or contribute to your app. (deep breath) we have a weinre server running at debug.phonegap.com that’s integrated with PG Build apps easily, but that anyone can use. we have support for integration with your git repos, and we’re working on tighter integration with private GitHub repos. Also Adobe ID support which may do something with Creative Cloud, I guess.
the type to give a marketing talk, especially not when we have a room full of PhoneGap contributors I can complain at. so here are some things I’ve learned after a couple of years of doing this
things Friday, 20 July, 12 most people, after a little stumbling, kinda grok the “your app is a set of static files running on the file protocol”. and the whitelist kinda sorta helps if you know in advance which domains you need access to, which you may not know for some ad networks. but then weird things happen when you wanna go outside the box a little - for example, opening a web page in the system web browser
proposed as a solution but has issues on iOS, where it’s implemented, and is not implemented anywhere else. there’s a couple long threads about this on JIRA and the mailing list if you want to read lots of people ranting about this
open a thing in a browser Friday, 20 July, 12 what we need is an API to open URLs in the browser, and a more precise way to declare when a URL should open in the browser and when it should not. it’s a messy problem, but it’s a major sticking point for people
is that cordova apps aren’t cross-platform, in the way that Flash or Java are cross-platform - there isn’t a single runtime that the code executes on, that’s available on different hosts. you have separate projects that share a www directory, but are compiled for different runtimes
away PhoneGap apps are dependent on the SDK Friday, 20 July, 12 this may seem like a subtle point but it’s important. one of the assumptions of most of the tutorials and documentation around PG/Cordova is that you do have the native project in front of you - that you can go and fiddle with the AndroidManifest or Whatever.plist or whatnot
down to is that your app is more than what happens in your web code - there’s simple stuff like selecting icons for different devices and different DPIs, and more involved preferences like “my app should quit when the OS goes back to the home screen”, or whatever - and all of this has to be set up long before a JavaScript runtime is instantiated. this is all stuff that PhoneGap, or a PhoneGap plugin, has no access to
help with that! on PhoneGap Build we have a config.xml file based on the W3C’s Widget Packaging spec that desugars into the configuration files specific for each platform. It’s an old spec - it goes back to 2006, at least - and we patch it a bunch to make things work, but at least it’s something
PG 2.0, for Android at least, has a file called config.xml that, as far as I can tell, has no resemblance to the W3C Widgets config.xml (other than the file name). Which will make the documentation more confusing
plugins. Plugins are far and away the most requested feature on PhoneGap Build, but we haven’t been able to implement them, for a bunch of reasons. The single biggest blocker, to my mind, has been the lack of high-quality, reliable plugins
‣ declarative installation ‣ documentation what we want Friday, 20 July, 12 here’s what a high-quality plugin should look like: it should be cross-platform, if it makes sense. it should have the same JS API for every platform it supports. It should follow a consistent native API, that doesn’t change on every release (oh hi Android). It should declare its dependencies in a manner that allows for automated installation. and it should be well documented
a big github repo that anyone can fork and contribute to. it’s very difficult to find a plugin, or to test a plugin, or to do much of anything unless you’re interacting with this repo on a regular basis. and any changes have to be approved by a moderator before they can be integrated
July, 12 I actually think the consistent native APIs are the lowest-hanging fruit here - the other factors require concerted effort for every plugin, whereas this one just needs a single commitment. I’ll pick on Android because that’s the worst
4.x: 2.0.0 Friday, 20 July, 12 For PGB I maintain a cross-platform fork of the ChildBrowser plugin, which was originally developed by Simon MacDonald for Android. We support a lot of PhoneGap releases on PGB, so we need the plugin to support those. The 1.x series of the plugin uses the PhoneGap namespace; 2.x was cut for org.apache.cordova compatibility. Then we get more fun - 1.9.0 had the CordovaWebView merge, which changed the plugin interface in a non-backwards compatible way, so we had a different release just for 1.9.0. And 2.0.0, as mentioned earlier, changes the Android config files to different locations, so we’ll probably need a 4.x release when we have 2.0 support. And who knows what’s next
we can just about manage this for one plugin, but what about two? what happens when we want to have twenty or fifty plugins on the site? should every plugin author change every one of their plugins on every release? anyhow, this is a problem that can be solved, so let’s go and do this
it’s really cool. instead of waiting for a new build to finish each time you wanna test your app, you can reload the app on your device and get your new code
PGB dev team, we’ve been trying to think of a suitably bad analogy to describe Hydration. The best thing I can think of is a hot dog. Instead of having to make a new hot dog every time you get hungry, you just switch the weiner and keep the bun, which is much quicker since the weiner’s are usually pre-cooked when you buy them. If you’re making a big change, like switching from white bread to wholegrain or something, you’ll need a whole new hot dog. I dunno, the cat seems convinced.
alunny
ufried
cyberagentdevelopers
freee
kymmt90
kazushi_ohata
datachain
smt7174
linkers_tech
horsewin
minorun365
yng87
garrettdimon
addyosmani
lara
lynnandtonic
phodgson
reverentgeek
bluesmoon
sugarenia
tammyeverts
holman
davidbonilla
brianwarren
![config.xml != config.xml [joke about NaN] Friday, 20 July, 12](https://files.speakerdeck.com/presentations/5009e466d46e8b0002017467/slide_17.jpg){kind=link}
![[bad analogy] h/t @maxogden Friday, 20 July, 12 on the](https://files.speakerdeck.com/presentations/5009e466d46e8b0002017467/slide_27.jpg){kind=link}
