To say that the project has grown up is a huge understatement. Mixed with jQuery Mobile or any number of other UI systems and with the community improvements to interfaces for native functionality, you can reach a huge percentage of device types with an easy to use toolkit.
While a lot of new features are available in the release (and are detailed in PhoneGap’s own blog at http://phonegap.com/blog/2013/07/19/adobe-phonegap-3.0-released/), I am most excited about the new plugin and build architecture.
Plugins were always the weak spot for PhoneGap. They were hosted on GitHub under different developer accounts and it was always a little difficult to tell which version to grab and from whom. There was also the problem of the platform, grabbing the Android version and stowing it away in a separate project dedicated to that build system (typically Eclipse) versus the iOS version in a separate tree for the XCode build. In this new version, the plugins are included from fixed endpoints and adjust to the platform during the build cycle (more on that in a minute). This means that you can go to the official docs (web site), snag the official URL for the plugin and add it on a per-project basis, and forget about it.
There is a little room for improvement here, in my opinion, but I don’t think it would take long to get there. I wouldn’t be surprised to see the plugin retrieval process get even easier. I can foresee a command line utility baked into the existing “phonegap” command set that retrieves a list of the possible plugins and by responding to the list with “phonegap plugin get 1,4,12” it would retrieve them by listed # and forgo the URL-chasing part.
In a recent discussion on PhoneGap Build, the commercial cloud-based system that allows you to upload your source and have it taken through an automated build cycle and then return binaries to you, I noted that while this is a great offering, the ability to take the system to a continuous-build environment that was local (i.e. on-site in your office) would lead to even greater adoption of the PhoneGap line even if it meant diminishing the value of the Build (capital “B”) service offering.
Fast forward to the enhanced build (lowercase “b”) system introduced in PhoneGap 3.0 that essentially does just that. Now you can set platform-specific options in a centralized configuration file and then build from a common www source to all of the platforms you have enabled on your system. For example, I have Android SDKs and XCode loaded onto my MacBook Pro running OS X (insert “cat” name here). I can type “phonegap build ios” or “phonegap build android” and the build system will take the source project and copy the www source out into a platform-specific folder and run through an actual binary build cycle with the appropriate settings, plugins, images, etc that I have specified for the project. I can even instantiate the newly-built app on a simulator from the command line as well.
I don’t think it is a real stretch to take this and move it to a server, probably one running Xserve so you get the ability to link Apple’s iOS goody bag, and set up a continuous-build environment around it. If it isn’t quite there yet (no, I haven’t tested this) then I feel it has to be close.
PhoneGap 3.0 is an incredibly-strong offering from Adobe and you can’t beat the price (free). with the new feature set, you save time and confusion in your source tree by simplifying the build process and selection of plugins.
If you are interested in diving in or finding out more, head over to the official site. You won’t be disappointed.