PhoneGap Build @ PG Day

Observations/whining, mostly

Transcript

1. Adobe® PhoneGap™ Build Andrew Lunny Hardeep Shoker Friday, 20 July, 12 Hello all. I’m Andrew Lunny, that’s Hardeep Shoker, and this talk is about PhoneGap Build.
2. @alunny webmaster Friday, 20 July, 12 me: I’ve worked for 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
3. @hardeepshoker lackey Friday, 20 July, 12 my lovely assistant is 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
4. is what Friday, 20 July, 12 who knows what PhoneGap Build is? who has used it? please don’t hit me
5. https://build.phonegap.com Friday, 20 July, 12 here’s the URL. We handle sensitive stuff, so everything goes over SSL. It’s still in public beta right now, so you use the service freely.
6. Friday, 20 July, 12 Here’s a sneak peek of the new design, done by bearded gentleman Ryan Betts. It’s got some textures and different colors and stuff
7. ‣ upload code ‣ get apps ‣ ????? build apps 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
8. six platforms API collaborations debug git + GitHub Adobe® ID 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.
9. observations/ whining Friday, 20 July, 12 but anyway, I’m not 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
10. the internet (is hard) Friday, 20 July, 12 so the internet - external resources that you have to load - are a source of confusion
11. ‣ iframes (ads) ‣ static resources ‣ XHRs kinds of 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
12. target=_blank (mostly harmless) Friday, 20 July, 12 target=_blank has been 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
13. $(‘#foo’).on(‘click’, function () { // caution: not real Cordova.openURL(this.href) }) 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
14. cross-platform multi-platform Friday, 20 July, 12 okay. so another observation 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
15. is a problem PhoneGap Build aims to abstract the SDK 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
16. app != index.html Friday, 20 July, 12 what this boils 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
17. Friday, 20 July, 12 thankfully, there’s a standards body 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
18. config.xml != config.xml [joke about NaN] Friday, 20 July, 12 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
19. plugins mostly don’t exist Friday, 20 July, 12 and finally, 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
20. ‣ cross-platform ‣ the same JS ‣ consistent native API ‣ 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
21. what we have Friday, 20 July, 12 instead, phonegap-plugins are 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
22. Friday, 20 July, 12 here’s a cartoon I made to illustrate the situation
23. consistent native APIs, or let’s pick on Android Friday, 20 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
24. 1.x: up to1.4.1 github.com/alunny/ChildBrowser 2.x: 1.5.0 - 1.8.1 3.x: (just!)1.9.0 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
25. Is not sustainable. Let’s fix this. Friday, 20 July, 12 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
26. new stuff Friday, 20 July, 12 alright, enough complaining. we have a pretty cool new feature we’d like to demo
27. Hydration Friday, 20 July, 12 the feature’s called hydration, and 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
28. [bad analogy] h/t @maxogden Friday, 20 July, 12 on the 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.
29. demo now & thanks Friday, 20 July, 12 anyway, enough of my blathering. hardeep’s gonna show off the feature now