Mobile software is taking the world by storm and building mobile applications using web technology has never been easier thanks to PhoneGap, using just HTML, CSS, and JavaScript for creating an app. Since those apps are based on web standards, they can be used on a variety of mobile platforms including iOS, Android, Windows Phone, and more. Brian LeRoux has worked on PhoneGap since its very beginning at humble startup Nitobi to the project stewardship today at Adobe. He acts of the VP at Apache for the open source foundation of PhoneGap known as Apache Cordova.
Adobe released version 3.0 of PhoneGap and we had the chance to talk to Brian LeRoux on what's new in PhoneGap 3.
InfoQ: There will be lots of new features on PhoneGap 3 - was there some kind of special focus for this release? What do you think is the feature of PhoneGap 3, that developers will care about most?
Brian LeRoux: PhoneGap 3.0 had an overarching theme of 'developer ergonomics'. This spanned the work-flow experience and API surface to overall project architecture.We spent a great deal of timing observing and talking to our developer community and context switching between platforms was still causing pain so we unified all the common work-flows between platforms (such as compiling, logging, and emulating) into a set of common scripts. Now if you are in a PhoneGap/iOS project the commands for compiling are the same as PhoneGap/Android. We took these work-flows a step further and unified all the platforms under a new global CLI tool which you can install from npm using `npm install phonegap -g`. The PhoneGap CLI is just an extension of the Cordova CLI. The only real difference between Apache Cordova and PhoneGap is the latter is backed by our hosted Creative Cloud service called Adobe PhoneGap/Build. You can use Cordova interchangeably with PhoneGap and many do. It is super great to be able to kick up a build via any web browser regardless of operating system. Its also super great to know that when you need to get your hands dirty with the native bits you can. We're not here to tell you how to build apps. We just want to help you do it with web technology. We've also added new platforms, with Firefox OS and Ubuntu on the horizon, and a couple of new APIs for dealing with Globalization and spawning in-app browsers. Finally, we have added huge improvements to the PhoneGap plug-in architecture and associated tooling. You can now easily install, remove, and discovery plug-ins all through the same command line tooling mentioned before.
- All new command line tooling
- More platforms
- New APIs
- Plug-in architecture and tooling
InfoQ: Sometimes, when major release numbers change, this leads to painful migration efforts to developers. Will it be hard for developers to adapt PhoneGap 3 in their existing projects? How much time will there be for developers to switch to the new version?
Brian: The biggest change in PhoneGap 3 is that we now treat the www as the top level concern and the native platforms something closer to build artifacts. We are not quite at the point where we can treat the native projects we generate as complete throw away code, it is still necessary to keep that source around as sometimes you need to tweak it for specific use cases, but we are very close to making this a reality. PhoneGap 3 gets us closer to that goal. It shouldn't be hard to port your project from a PhoneGap 2 native project to the PhoneGap 3 structure if you just used vanilla web code. Just copy the www over and you are good to go. If you augmented a 2.x project with native plug-ins there will be a window of time while we port those community plug-ins over. We're going to keep 2.9 around a very long time and focus on working with the community to get plug-ins over to the new architecture and tooling. We'll be cherry picking bug fixes into 2.9 for at least 6 months after releasing 3 to ensure the community has a long support path.
InfoQ: iOS 7 was released to the developer community in June and will be available on phones in fall. About when will iOS 7 be supported? Are there special challenges related to the changes in design, that Apple made?
Brian: While I can't comment on when iOS 7 ships I can comment that PhoneGap will be ready for iOS 7 the day it does ship. We are participating in the beta and forward compatibility, as well as backward compatibility, is very important to us. This is a great example of where web technology wins. When iOS 7 drops your web code is portable and will now be able to advantage of the latest Mobile Safari features and performance improvements. With each release the iOS browser improves and therefore so does PhoneGap.
InfoQ: What is your recommendation for a PhoneGap tool-chain? How is it possible for a developer to efficiently develop apps for various platforms?
Brian: We don't get too involved in the business of web development but rather we do like to enable it for native operating systems. That being said, I have been working on a new project at Adobe called Topcoat which is just simple CSS for building fast and clean apps. This again demonstrates the power of the web platform. You can use any text editor you want. I happen to use VIM but find myself hacking in and on Brackets a tonne lately. PhoneGap doesn't care: there is no IDE requirement for using it so as a web developer you aren't being forced into unfamiliar tools. Any text editor will do just fine. Developers and even designers are more savvy than ever these days. A great example of modern design/develop process can be seen Stephen Hayes excellent Responsive Design Workflow book. The new generation of developers learned HTML, CSS, and JavaScript in high school. They aren't afraid of the command line, and happily compose a project of open source tools. They iterate. They use Github. We love this diversity and embrace it with our own tooling in PhoneGap. Everything is completely modular and can be composed into bigger and better projects. For example, the PhoneGap command line utilities are simply extensions of the lower level Cordova project command line utilities. We're seeing the community embrace this on their own with projects like Yeoman, Eclipse plug-ins, and many others. To get back to the original question about efficiently development I think the best path is to start very small, test on real devices, and only include code from third parties when you absolutely need it not as a precaution to a possible future requirement. Mobile devices are notoriously difficult to squeeze out good performance web or native so make sure every line of code counts.
InfoQ: Are there types of applications that are better suited for PhoneGap than others? Why so?
Brian: This is getting harder to answer every year. I used to say that games are not really appropriate for web technology but this is clearly no longer the case. Certainly, first person shooters and graphics intensive three dimensional business is not ready for prime time but nearly every other category of game is now very possible. PhoneGap apps shine when the content comes first, and it feels particularly good when you are reusing assets from other web projects. It only takes a few seconds to generate a PhoneGap project so I'd recommend web developers reading this to just try it out for themselves. If it works for you then that is great and if it does not thats o.k., too. Most importantly you'll have had that direct experience yourself which is truly the best way to understand the appropriateness of any technology.
InfoQ: What was the last time that you saw an app realized with PhoneGap and thought "Wow, I wouldn't have thought that this would be possible"?
Brian: That is tricky. I think the first time I saw CSS Shaders demoed at Adobe I felt that way. The feature is nascent and not really something developers can use just yet today but they are coming to browsers and they will represent a significant step forward in our ability to create really immersive animations and transitions in our designs.
Brian LeRoux is the principal product manager of PhoneGap and topcoat at Adobe as well as VP of Apache Cordova. A passive member of the Node Firm, mobile web hacker, beer enthuist with a JavaScript problem which he and many others document at wtfjs for fun. You can catch up with Brian on his website.