Our goals are wrought from our beliefs, and development philosophy. Understanding a free software project, like PhoneGap, requires more than knowledge of the implementation details. It requires understanding the individuals behind the code. Knowing the people and what motivates them inform you more about whether the technology is right for you, your goals, and the people you work with. The world is diverse and very often this comes across in our code, and the tools we use to write it.

Background

PhoneGap was born at Nitobi Software in the summer of 2008. Nitobi was very much a web consultancy with deep roots in the JavaScript scene, and web dev at large. Being a consultancy we had a few beliefs that have grown into the PhoneGap project team members. These views are mine own and shared by many PhoneGap developers and Apache Cordova committers.

Beliefs

We have two core tenants of belief:

• The web solved cross platform.
• All technology deprecates with time.

We believe the web has been the most convincing solution to reaching many devices of differing capabilities. Truly, C is the only technology that deserves the title but even then, all readers here know, there be dragons there. HTML, CSS, and JavaScript, for all the respective warts and quirks, have reached critical mass. This is in no small part due to the incredibly low barrier for authoring web technologies. Anyone, at any time, can publish anything from anywhere. That is the stuff of revolutions, and our evolution as a species.

Our second belief makes a brave statement: all technology deprecates. This is more of an observation, and history is on our side. With this in mind, as consultants, we knew hitching our wagon to any one horse could have disastrous consequences. Of course this is not absolute. Some technologies span many decades to the profit of the specialist. As technologists it is our responsibility to remain present and aware of change. Whether we act is the choice. The consequences of not acting could be witness to a technology replacing our own.

Goals

Understanding our beliefs makes it easier to understand why we have composed a development team that is proficient in 8 languages, as many operating systems, and works daily with enough phones to fill a refrigerator. We would put ‘em in the fridge but that’s where we keep the beer so we built a giant wall. The device wall isn’t something to keep phones in: it’s for keeping proprietary platforms out. Beliefs in hand, let us look at the goals with PhoneGap.

We have two high level goals with PhoneGap:

• The web as a first class development platform.
• The ultimate purpose of PhoneGap is to cease to exist.

The web is decidedly not a first class development platform: opaque introspection, blunt tools, poor API surface area, and a rather limited set of GUI elements. The web has host of other problems, or perhaps features, such as the sandbox and many missing APIs which need addressing which provides a fantastic opportunity. In short, we feel the web as a platform is at a disadvantage, and we’re working to polyfill those gaps with PhoneGap.

Our second goal is not nihilistic but is rather a commitment to standardization of the web as a platform. We believe in a web open to everyone to participate however they will. No locked doors. No walls. The things we do with PhoneGap are directly influenced by the work we see at the W3C, WHATWG, and other research such as Mozilla’s WebAPI, BONDI, WAC, Webinos, webOS, Tizen and the like.

Philosophy

Many of us are UNIX geeks. We believe in simple, wickedly sharp, purpose built tools. PhoneGap is a solution much the same. We are not trying to be everything to everyone. We do believe the web has solved a great many use cases in software, and as it improves, it will continue to do so.

It isn’t without a sense of irony that our first belief (the web solved cross platform) is at stake with the second (all tech deprecates). This is why we act. We know the web is not the platform it can be and we are actively working to improve it. We recognize that the limitations of the web platform are harming the viability for a great many use cases and giving an edge to proprietary solutions with better tools. That is not the future aligned with our beliefs, nor our goals.

Attachment is the root cause of all suffering. We are not attached to the web, JS or any of it. Indeed, in order to implement PhoneGap many of us are now veterans of many platforms, languages, tools and operating systems. Keep ‘em coming: we’ll put a browser there too.

We ship fast, often twice a month, and have done so for a long time now. I’ve heard it said that PhoneGap can lag behind native implementations and, while technically correct, we rarely lag more than two weeks. Additionally, there is a very low barrier for a developer to author a plugin for functionality we haven’t yet writ ourselves. I highly encourage you to read about our release philosophy. I feel we are among the best at it in the industry today.

Closing Thought

We agree that there are no silver bullets, and the web isn’t the best tool for every job. However, the web is not getting worse, and the browser abstraction layer is ultimately the same across operating systems (C, C++). If the web doesn’t do something today it’s not because it can’t, or won’t, but rather it is because we haven’t gotten around to implementing that capability yet.

If you want to help the web get there you can learn more about contributing here. If you want to have an intelligent debate on the real drawbacks of PhoneGap: you can start by trying it out here.

You can view the rest of the changes below in the change log.

iOS

• Fixed CB-183, CB-54 – ios camera targetWidth/Height don’t match the documentation Fixes CB-183 and CB-54
• Fixed CB-511 Changed deviceproperties version to “cordova” property
• Fixed CB-483 – FileTransfer – unknown property attribute ‘atomic’ when building from source (Xcode 3 only)
• Fixed CB-507 – Remove excessive debug logging in execute delegate method in CDVViewController
• Implemented CB-536 – Add new selector to CDVViewController to create a new CDVCordovaView, so subclasses can override it
• Workaround for CB-509 – geolocation.clearWatch doesn’t shut the GPS down under iOS Fixed CB-537 – media.seekTo fails with NSRangeException
• Fixed CB-544 – iOS Geolocation fails if Cordova.plist EnableLocation = YES
• Fixed CB-543 – FileTransfer.upload WebKit discarded an uncaught exception
• Fixed CB-391 – camera.getPicture crash
• Implemented CB-535 – Add a way to log JavaScript exceptions, parse errors, and get JS stack frame events (with line numbers, etc)
• Fixed CB-494 – Move Cordova.plist section from “How to use Cordova as a Component Guide” to its own doc
• Fixed CB-571 – stubbed out create method to remove error when creating Media objects, also added another check if file does not exist.
• Fixed CB-386 – added retina iPad splash screens. made sure retina ipad icon files shows up during load.
• Re-fix CB-347 – localStorage / SQLDatabase Error after App update (timing issue for applying fix)
• Adjust splash screen position based on orientation and status bar size

Android

• [CB-164] Changed network plugin to sync from async and removed setKeepCallback(true) on plugin result in there. Fixes location.reload() not firing deviceready due to network plugin being unresponsive
• Proper fix for CB-164. Online/offline events now propagated to webview properly
• [CB-473] run ant clean before ant debug install
• CB-480 work, back button and history issues are preventing this from being tested properly
• Fixed back button behaviour. WIN
• Reverting the back button change that I made, for some reason certain methods aren’t inherited when you extend DroidGap
• Fix for CB-549
• Updating the JS and re-tagging 1.7.0
• CB-539: FileTransfer.download fails when target starts with ‘file://’
• Removing un-needed logs
• Refactor Android SplashScreen
• Adding SplashScreen plugin to plugins.xml

Windows

• added issue with regards to debugging media functionality in the framework to the README
• Updating various script files to latest
• added hint to debug output when device ready cannot fire because the dev did not include the tag in their page.
• release was private, and therefore uncallable from js
• changed test project to use updated tests + jasmine
• remove method added, dispatches not supported error
• debug output for exception in ProcessCommand
• remove unused
• added mouse support
• fancy animation on load, ala metro style
• splash image is animated away on load
• update JS from cordova-js, update version file
• rebuild of lib + template gen
• Added notification alert/confirm button text. CB-110
• remove version number from readme instructions so we don’t have to change it every time.
• remove old build cruft
• rejigger, packaged zip is rc1 but assets are 1.7.0
• updates 1.7.0.js file with latest changes, remove rc version
• fetch meta viewport on page load
• CB-596
• wip for handling both meta + preventDefault
• metaviewport tag content attribute user-scalable yes|no is observed.
• added tagged 1.7.0 js src, alert patch in template with comment
• 1.7.0 release packaging
• remove old template
• update example to 1.7.0
• filetransfer download returns FileEntry on success
• repackage for 1.7.0
• updated test project for jasmine tests
• update template for 1.7.0
• Fixed filetransfer boundary without parameter.
• [CB-559] Cache instantiated plugins in CommandFactory
• [CB-338] fixing firing online and offline events
• [CB-336] getFormatData did not return due to threading issues in Capture.cs
• [CB-334] Nickname was not being returned properly in contacts.search

Bada

• added Bada 2.0 support

If you wish to follow or join in the development of this project, send an email to callback-dev-subscribe@incubator.apache.org to subscribe to the developer mailing list. All bugs can be found on our issue tracker.

PhoneGap

Before I go too far, let me attempt to clearly state what PhoneGap is… PhoneGap is an application container technology that allows you to create natively-installed applications for mobile devices using HTML, CSS, and JavaScript.   The core engine for PhoneGap is also 100% open source, under the Apache Cordova project.

PhoneGap User Interface

The user interface for PhoneGap applications is created using HTML, CSS, and JavaScript. The UI layer of a PhoneGap application is a web browser view that takes up 100% of the device width and 100% of the device height.

Think of this as a “chrome-less” web browser.  It renders HTML content, without the “chrome” or window decoration of a regular web browser.  You build your application to take advantage of this space, and you build navigational/interactive/content elements and application chrome into your HTML and CSS based user interface.

The web view used by PhoneGap is the same web view used by the native operating system.   On iOS, this is the Objective-C UIWebView class; on Android, this is android.webkit.WebView.  Since there are differences in the web view rendering engines between operating systems, make sure that you account for this in your UI implementation.

PhoneGap API

PhoneGap provides an application programming interface (API) that enables you to access native operating system functionality using JavaScript. You build your application logic using JavaScript, and the PhoneGap API handles communication with the native operating system.

You can read about the PhoneGap API and all of the native functionality it exposes at docs.phonegap.com.

In addition to the “out of the box” functionality, you can also leverage PhoneGap’s JavaScript-to-native communication mechanism to write “native plugins”. PhoneGap native plugins enable you to write your own custom native classes and corresponding JavaScript interfaces for use within your PhoneGap applications.  You can read more about PhoneGap native plugins at: http://www.tricedesigns.com/2012/03/01/phonegap-native-plugins/and http://wiki.phonegap.com/w/page/36752779/PhoneGap%20Plugins

PhoneGap Application Packaging and Distribution

PhoneGap applications are developed using HTML, CSS, and JavaScript, however the final product of a PhoneGap application is a binary application archive that can be distributed through standard application ecosystems.

For iOS applications the output is an IPA file (iOS Application Archive), for Android applications the output is an APK file (Android Package), for Window Phone the output is a XAP file (Application Package), etc…  These are the same application packaging formats used by “native” applications, and can be distributed through the appropriate ecosystems (iTunes Store, Android Market, Amazon Market, BlackBerry App World, Windows Phone Marketplace, etc…)

PhoneGap High-Level Application Architecture

Specific application architectures are going to differ on a case-by-case basis, however most data-driven applications employ the following basic architecture.   The PhoneGap application acts as a client for the user to interact with.   The PhoneGap client communicates with an application server to receive data.   The application server handles business logic and communicates with a back-end data repository.

The application server is normally a web server (Apache, IIS, etc…) and has a server side scripting language such as ColdFusion, Java, .NET, PHP, etc… PhoneGap is agnostic of back-end technologies and can work with any application server using standard web protocols.   The application server performs business logic and calculations, and generally retrieves or persists data from a separate data repository – this is normally a relational database, but could be any structure or mechanism for data persistence.

PhoneGap applications generally do not talk directly to a database; communication is routed through an application server.    The client to application server communication can be based upon standard HTTP requests for HTML content, REST-ful XML services, JSON services, or SOAP (or websockets if your OS supports it).  These are the exact same techniques that you would use in a desktop-browser based AJAX application.

The client-side architecture generally uses the single-page application model, where the application logic is inside a single HTML page.  This page is never unloaded from memory.  All data will be displayed by updating the HTML DOM, data is retrieved from the application server using AJAX techniques, and variables are kept in-memory within JavaScript.

Multi-page client-side application architectures are supported, but are not recommended because you lose in-memory variables when loading a separate page.

Andrew Trice is a Technical Evangelist with Adobe Systems. Andrew brings to the table over a decade of experience designing, implementing, and delivering rich applications for the web, desktop, and mobile devices. Andrew is an experienced architect, team leader, accomplished speaker, and published author, specializing in immersive experiences, mobile development, realtime data systems, and data visualization. Andrew regularly writes at tricedesigns.com, or you can follow him on twitter @andytrice.

From March 12-29, I visited 5 different countries — Israel, Singapore, Hong Kong, South Korea and Japan — and talked about PhoneGap with established and emerging developer communities. Each event had a similar format which included 6 hours of presentations followed by 5 hours of hacking. The presentations were mostly done by Facebook developers and covered the basics of the Facebook platform and an in-depth talk on their mobile platforms.

My PhoneGap talk was the last presentation of the day and focused on the Facebook Plugin for PhoneGap. The plugin allows developers to build apps using the Facebook Javascript SDK and use PhoneGap to gain access to native single sign-on and native dialogs. It works by adding hooks into the Facebook Javascript SDK that would in turn call the plugin. The plugin then maps those calls to the Facebook Native SDK for that platform.

Check out the screencast for installing the plugin on iOS .

All the events had great attendance. The attendees were very interested in the presentations and the ratio of people who stayed and decided to hack was high. Each event had some groups using the PhoneGap Facebook Plugin or indicated they planned on implementing it after they created their web app.

The most challenging part of the tour was having non-English speaking developers in South Korea and Japan. We solved this by having amazing translators at both events. As a presenter, I had to remove some jokes and simplify what I said during the presentations. During the hackathon, I helped people with a lot of hand motions to break through communication barriers. And of course, when Mark Zuckerberg did a surprise appearance in Tokyo, there was no need for a translator with how excited the crowd got.

One thing was clear to me at every event I attended and presented at: a large number of people have heard about PhoneGap. Over 80% of people raised their hands at each event when I asked them if they have heard about PhoneGap. This showed me that the PhoneGap love is spreading all over the world.

The PhoneGap team plans on continuing to help these up and coming developer communities to use PhoneGap for their projects and assist them with more advanced topics. We will continue to attend as many conferences and meetups as we can to ensure this. To see a list of where we are speaking next, check out our event calender or find us on http://phonegap.meetup.com.

If you are interested in checking out the PhoneGap Facebook plugin, check out the source code over at https://github.com/davejohnson/phonegap-plugin-facebook-connect.

This version of PhoneGap is composed mainly of bug fixes from the previous version.

We decided to start issuing release candidates as proper releases in order to have our users report bugs on the latest code base we are working on. If you find any bugs with this version, help out the community and project by reporting them on our issue tracker. Rest assured, we only tag a release candidate if we are happy with where the code is.

When you click the main download button, you will be downloading 1.7.0rc1. You can download older versions of PhoneGap from Github.

Haven’t heard of PhoneGap Build? PhoneGap Build is a service that allows developers to compile PhoneGap projects in the cloud. Instead of configuring environments and installing platform specific tools, PhoneGap Build allows developers to focus on writing apps. Simply upload your project assets to Build and boom! you have distribution-ready apps for iOS, Android, Blackberry, WebOs, and Symbian. From there it’s as simple as uploading your new packages to the various app stores.

After working with Microsoft to bring PhoneGap to WP7 last year, we’re excited to see it finally join PhoneGap Build!

Go check out our PhoneGap Build Service and sign up for our open public beta! You can also read more about WP7 on PhoneGap build on the PhoneGap Build blog.

Author HTML5, CSS3, and JavaScript-based applications with ease. Log into PhoneGap Build via the PhoneGap Build Service Panel (Site > PhoneGap Build) and build your web applications directly in Dreamweaver CS6. Compile and sign your applications in the cloud and download the resulting native mobile applications to your local desktop or mobile device. The PhoneGap Build service handles the compilation of native mobile apps for iOS, Android, BlackBerry, WebOS, and Symbian.

The benefits to using PhoneGap Build in Dreamweaver CS6 are:

• targeting more platforms than previous versions of Dreamweaver
• compiling against up-to-date SDKs without installing updates in a local environment
• a smoother development experience with quickly deployed patches by the PhoneGap Build team

Besides PhoneGap Build, Dreamweaver CS6 has a bunch of other cool features like jQuery Mobile 1.0 and jQuery Mobile swatches. Learn more about what’s new in Dreamweaver CS6.

Learn more about PhoneGap Build and our open beta.

The main issue driving this quick release was the incorrect xml folder that was included with the Android code that caused the network API to fail. This was a bug that needed to be addressed and could not wait for the 1.7 release. Thanks to the community for its quick work on turning around these fixes!

You can view the rest of the changes below in the change log.

iOS

• Fixed CB-496 – Camera.getPicture – will always return FILE_URI even though DATA_URL specified
• Fixed CB-497 – online and offline events are not being fired in 1.6.0
• Fixed CB-501 – orientationchange event is not being fired in 1.6.0
• Fixed CB-302 – orientation change event fired off twice on iOS 5.x
• Fixed CB-507 – Remove excessive debug logging in execute delegate method in CDVViewController

Android

• Copying new XML into the templates for 1.6.1. Turns out tags are broken
• CB-489 – Adding .js to the example, thought it was removed for a reason
• Adding fix for CB-482
• Remove duplicate files from repository
• Automatically update index.html in templates directory on version change

Windows

• cleanup console logging, toLower on OverrideBackButton
• updated template, permissions, and js

Bada

• updating bada project parameters
• adding artwork and removing old phonegap references
• CB-4 adding Apache Source Headers
• fixing network problem

If you wish to follow or join in the development of this project, send an email to callback-dev-subscribe@incubator.apache.org to subscribe to the developer mailing list. All bugs can be found on our issue tracker.

1. localStorage and WebSQL databases have been moved to ~/Library/Caches from ~/Library/WebKit
2. “SECURITY_ERR: DOM Exception 18″ error when calling window.openDatabase after updating to iOS 5.1

Persistence of localStorage / WebSQL databases

The first issue is a policy issue — this change means that localStorage and WebSQL databases are not backed-up and may be deleted by iOS at any time to save space. In the “Data Storage Guidelines for iCloud” article it describes data in ~/Library/Caches as “Data that can be downloaded again or regenerated”.

You thought localStorage was supposed to be persistent? So did I, but it appears that expiring localStorage is well within the definitions of the spec: Section 6.1 “Expiring stored data”

The solution for embedded UIWebView developers is to backup and restore the databases from ~/Library/Caches to persistent storage (e.g the Documents folder), or move the storage location to persistent storage.

This issue has been worked around and the backup/restore mechanism is implemented in Cordova 1.6.0, and the issue has been further discussed also in this bug: https://issues.apache.org/jira/browse/CB-330.

SECURITY_ERR

The second issue appears to be a genuine Apple bug when you are on iOS 5.1, and upgrading an app to a newer version. This issue has been reported to Apple and they know about this issue:
rdar://11081309 rdar://11081647 rdar://10296507 rdar://11105407 rdar://11063678

A sample of what was filed is here: http://openradar.appspot.com/radar?id=1608403

Through the community’s efforts (see this issue here: https://issues.apache.org/jira/browse/CB-347) and our experimentation, we hypothesize that during an app upgrade the app bundle’s GUID is changed, but the WebKit database locations in the app’s .plist have not been changed. These database locations have hard-coded paths in them (which of course include the app bundle’s GUID).

The way we arrived at this conclusion is by:

• Printing the app bundle path before and after an app upgrade when on iOS 5.1
• Iterating through the app’s .plist keys and values and observing the “WebDatabaseDirectory” and “WebKitLocalStorageDatabasePathPreferenceKey” values

The data supports our conclusions. The app bundle path does change when upgrading the app (the GUID changes). The plist values which point to database paths within our app bundle point to a path that is not in our app bundle, and the GUID is from the previous app bundle GUID.

This issue has been ‘fixed’ by Cordova in 1.6.0, by changing the paths in the app’s .plist to the correct paths.

Hopefully in a newer version of iOS this issue will have been resolved by Apple by either:

• Changing the database locations in the app’s .plist when the app bundle’s path changes OR
• Use relative paths for the database locations, not absolute ones

Changing the database location

For the second issue, it is also clear that a developer can change the database location permanently to persistent storage, and not do the backup/restore method. iOS Cordova is steering clear of this solution because of the potential of side-effects if and when this issue is resolved by Apple.

This partnership agreement will allow SAP to help developers build more open mobile apps based on their choice of client architecture, ranging from native to hybrid web containers to the mobile web.

“As a leader in the enterprise mobility market, SAP is constantly looking for innovative ways to serve our customers and partners, and advance our vision for this market,” said Sanjay Poonen, president, Global Solutions, SAP.

“By joining forces with leading mobile app development vendors like Adobe, Appcelerator and Sencha, we are making it easier for large communities of developers, in the millions, to innovate on our platform. We believe SAP is the only mobile platform provider delivering on the promise of an open platform architecture that supports innovative third-party development environments and tools, providing flexibility for customers to implement the right mobile app every time. SAP, customers, partners and the entire ecosystem now have a tremendous opportunity to rapidly produce millions of high quality apps using the tool of their choice.”

Read the full SAP release for more information.