Windows 8 Security and Dynamic Code

Recently while working on bringing Apache Cordova to Windows 8 I came across an issue with dynamic content.  The Apache Cordova mobile-spec project, which defines all of our tests,  has some tricks for loading a configurable cordova-js file without having to modify every html page.  It seems the security model does not like to script tags written at runtime with document.write ( a poor practice anyway ) Here is the original source with the issue :

var cordovaPath = scripts[scripts.length - 1].src.replace('cordova.js', 'cordova.windows8.js');
document.write('<script type="text/javascript" charset="utf-8" src="' + cordovaPath + '"></script>');

Here is the error message, with a helpful link to the docs :

Unable to add dynamic content. A script attempted to inject dynamic content, or elements previously modified dynamically, that might be unsafe. For example, using the innerHTML property to add script or malformed HTML will generate this exception. Use the toStaticHTML method to filter dynamic content, or explicitly create elements and attributes with a method such as createElement. For more information, see

In order to dynamically load a script, I had to change to use the DOM APIs, here is the updated working source :

for (var n = 0; n < scripts.length; n++) {
    if (scripts[n].src.indexOf('cordova.js') > -1) {
        var cordovaPath = scripts[n].src.replace('cordova.js', 'cordova.windows8.js');
        var scriptElem = document.createElement("script");
        scriptElem.src = cordovaPath;


Apache Cordova :: The framework formerly known as PhoneGap :: repost

Note: This post is a reprint of an article I submitted to the Software Developers Journal a few months ago. -jm

This article uses the names PhoneGap and Cordova synonymously to refer to the open source project currently in incubation within the Apache Software Foundation.

What is PhoneGap?

PhoneGap is a collection of tools, and libraries that allow you to build native mobile applications for multiple devices. PhoneGap supports the development of portable application code that can run on Apple iOS iPhones, iPads, iPods, all Android devices, Windows Phone 7 devices, BlackBerry phones and PlayBooks, HP WebOS phones and TouchPad, as well as Symbian and Samsung Bada devices.

PhoneGap embraces web technology, so web developers can leverage their existing skills and write their applications in HTML, CSS, and JavaScript.

How does it work?

Running an Application on a device.

At runtime, PhoneGap works by instantiating a browser component on the device. This is a chrome-less browser, meaning that it does not have an address-bar or forward/back buttons. The end developer’s application consists of HTML, JavaScript and CSS that are loaded into the browser component. PhoneGap provides a JavaScript API that allows developer code to access device functionality, that is currently not accessible to web sites loaded in the default browser.

Building for a device.

PhoneGap includes tools and libraries for packaging developer code into an application that can run on the device. The exact process of packaging will depend on the device as each has its own methods of packaging. The developer code is typically maintained in a www folder indicating the root of the application. All content within this root folder is considered to be portable and will have little if any modification between device targets.

Distributing your application

PhoneGap applications are distributed through app stores, just like any other native application. The same rules apply for what your app is allowed to do, and what kind of content is appropriate. Your PhoneGap application will typically need to be reviewed, and upon passing review, it will be distributed via app store downloads.

What need does it fill?

The best explanation of how PhoneGap can help your company is really the story of how it came to be in the first place. When the iPhone SDK came out, the entire team at Nitobi was excited and wanted to build apps for this new cool platform. Nitobi at the time was primarily a web development shop selling JavaScript components, and providing consulting and dev services to companies in need of performant ajaxy websites. Nitobi was not in a position to send the entire team off to learn Objective-C, but some of the team while playing with the SDK discovered that they could present pretty compelling markup in the browser component. With a little more work, they were allowing the hosted JavaScript code to call native code and access device functionality.

Next came Android, similarly appealing, so instead of sending everyone to learn Java and the Android SDK, a single developer was tasked with providing the same features via a hosted WebBrowser control and almost instantly Nitobi had created a cross platform framework allowing for applications running in a hosted WebBrowser on multiple mobile devices.

… and so on, …

Nitobi, as a company, has always embraced open source, so naturally, PhoneGap has always been open source. This is without question why the project is so successful today. Early in the project, most of the contributions were coming from Nitobi developers, but a community was also uniting around the openness of the project. Early in 2011 the community caught up to Nitobi in number of commits, most certainly due in part to IBM putting 4 full-time developers on the project.

 Source: —

Nitobi additionally had to earn revenue, so developer work time was focused on client development projects and consulting. We identified client needs that were filled by PhoneGap, and strove to use it wherever possible. We also identified opportunities to commit code back to the PhoneGap project and made deals with clients at a discount if they were willing.

As new Adobe employees we are now even more committed to contributing to the project as we no longer have to split our time with client projects, and can focus on the framework itself.


Implementing consistent functionality across different devices exposed the need to follow standards. While investigating interfaces for addition into PhoneGap, the team has kept a close eye on standards bodies like the W3C. Several PhoneGap contributors have even joined standards groups to help define the next wave of device APIs.

The Geolocation API was implemented in PhoneGap before it made its way to iOS ( then iPhone OS ). Following standards meant that in many cases the browser maker actually implements the same API as PhoneGap and PhoneGap can simply defer to the browser implementation when running on these devices.

How PhoneGap can help ease you into the world of mobile development

Software development is not easy, and good mobile software development is downright hard. Factors like limited processor power, screen size, and battery consumption all play a role in challenging the developer to deliver a compelling experience. A common consideration when choosing a device to target is the skill-set that is required to develop for the device. Each device manufacturer/provider typically provides it’s own Software Developer Kit (SDK) to enable developers to target the device. An SDK will have restrictions on what languages an application can be written in, as well as what tools you can use to develop for it. The SDK will provide the device level functionality, and define what functionality is available through its APIs.

While many articles focus on the development language being the only blocker to jumping to a new platform, the issue is much deeper.

Developers wishing to target a new device will have to potentially:

  • Learn or know the language required for the device
  • Learn or know how to use the tools to build for the device
  • Learn the User Interface APIs, and how to construct their application
  • Learn the device APIs available, and how to use them

In the case of PhoneGap applications, this picture is simplified somewhat. The only piece that changes from one device to another is the tooling. The language used to develop is always JavaScript, so users already familiar with JavaScript are ready to go. The User Interface API is again, JavaScript, with HTML + CSS to define layout, and positioning, look and feel. Also, the device APIs are exactly the same, so a developer moving from one PhoneGap device to another can expect it to work in exactly the same way, just like their portable PhoneGap code does.

More than websites on the phone

A common mis-conception that newcomers to PhoneGap have is that it is just a website. There is an important distinction that must be made when approaching developing a JavaScript based application.

You should not expect to update your application whenever you like, as you would with your website. App store policies generally do not allow you to make changes without going through the review process again. While it is possible to serve web content over http to your app, it is best to avoid having this be the primary function of your app.

PhoneGap is not a web server, so you should not expect to run php, or .net code, or have paths like ‘/’ magically resolve to ‘/index.html’. Some consideration should also be made for data access methods. PhoneGap applications can not connect to a remote database servers directly, so you will need a web server to manage translation of your data from your database, and serve it over http.

A typical PhoneGap application consists of one or more standalone web pages hosted on the device connecting to a RESTy API on the server, typically serving JSON for transport efficiency.

Your application should provide some sort of offline functionality, or it should at least be aware when it is running offline, and inform the user of what to expect. App stores generally will not accept an application that shows an infinite spinner while attempting to connect to an unreachable server. PhoneGap provides the Network Connection API so your application can not only detect when it is connected, but tell if the connection is via wifi, or cellular data.

In the world of mobile devices, although remarkable, processor capabilities are limited. The amount of code that needs to load before a user interface is presented is an important consideration.

There are potentially 3 areas where code size can impact performance and applications should be optimized :

  1. Time for code to be loaded from the file system.
  2. Time for code to be interpreted by the script host.
  3. How much memory the code occupies at runtime.

Modern best practices for JavaScript suggest that you concatenate files, and use a minification tool to compress the amount of data delivered. While file size will improve the load time for your app, there is no benefit in zipping your content as is currently done by many web servers. This is primarily because the file itself will not be subject to network latency, so minification should be enough for text based files.

Another area to consider is the actual screen sizes of the devices. Using css3 media queries it is possible to target different resolutions with different runtime assets.

The following example demonstrates targeting small screens, versus tablet size devices.

@media screen and (max-width: 599px) { .class { background:url(MySmallImage.png); } } @media screen and (min-width: 600px) { .class { background:url(MyTabletImage.png); } } 

I’ll tell you when I’m ready

The entire PhoneGap API is asynchronous, meaning calls to get device values do not return an immediate result, but return the result at some later time via a callback method. This approach is similar to an AJAX website, where the page is refreshed without having to reload, and the user interface can remain responsive to the user even while data is pending.

Application logic, sometimes referred to as Business logic, is typically running in the webpage itself in JavaScript. This may be in contrast to web developers coming from an environment where the web server is doing all the work, and maintaining state for multiple clients. Application logic, including state, and view management is typically performed in JavaScript in PhoneGap applications.

HTML has many features that make it suitable for defining user interface presentation, as opposed to typical document layout.

Gap Stores

The usual process for distributing PhoneGap apps is through an App store. For most devices, this is the only way to distribute an app. This means all the usual processes apply, from app review, to code signing. PhoneGap itself does not provide any extra help in this area, and developers are still at the mercy of whichever store they are pursuing.

The liberal license that PhoneGap distributed under does not require any attribution, so there is effectively no way to know how many PhoneGap applications there are in the wild. Developers will typically announce their app on the mailing list, or submit a form on that allows developers to list their applications. There are literally tens of thousands of PhoneGap applications published throughout the various App stores.

Reuse of assets

Many companies come at PhoneGap looking to establish a presence in an app store. Typically they already have a website, and sometimes even a mobile friendly website. In these cases much of the css and image resources will not change, however the approach is typically different as these items are packaged into the app, and not served by a web server. If the current web site consists of server side logic, they may need to restructure either some or all of code to work in a disconnected state.


The most common complaint with PhoneGap ( really about HTML5 user interfaces in general ) is related to the scrolling interaction. Everyone has come to expect iPhone’s beautiful smooth scrolling, although this can be difficult to recreate in HTML5. There are several libraries that do a very good job at mimicking the native interaction, but developers must still be mindful of what they are doing to avoid choppiness or flickering during scrolling. Libraries include iScroll4, which is a standalone solution, and Sencha Touch which requires developers to embrace the Sencha way more deeply.

The browser components running on mobile devices are very similar. In fact, most of them are running a variation of WebKit, the exception of course being Windows Phone 7, which is running Internet Explorer 9. All of the browsers support W3 defined DOM Level 2 events which allows calls to addEventListener to be implemented consistently.

PhoneGap’s device APIs

PhoneGap allows your application to access everything that a normal native app would.

PhoneGap core device APIs include:

  • Accelerometer
    • Monitor the motion sensor on the device.
  • Camera
    • Take pictures with the device camera
    • allow the user to select images from their photo library on the device.
  • Capture
    • Capture video and still images from the camera, and audio from the microphone.
  • Compass
    • Give users of your app some direction.
  • Contacts
    • Search and Create contacts in the user’s address book.
  • File
    • Low level read and write access to the file system.
    • Upload and download files from a web server.
  • GeoLocation
    • Make your app location aware.
  • Media
    • Play and record audio files.
  • Network
    • Monitor the device connections
  • Notification
    • Access to vibration, beep and alerts.
  • Storage
    • Persistent data store in WebStorage.

All APIs are implemented consistently across all supported devices, so the same code will run everywhere.

What doesn’t PhoneGap do?

Quite purposefully, PhoneGap does not provide any user interface controls. PhoneGap is solely focused on being the best container, and device api host for your web tech built application. But PhoneGap does not limit your choice either, and it allows you to develop with whatever UI framework you are familiar with. There are many options including jQuery Mobile, and Sencha Touch. Similarly, there is a multitude of choices for providing application structure, via best practice patterns. Frameworks like Backbone, or Knockout fit comfortably into PhoneGap.


In architecting PhoneGap, it became obvious that there would always be some differences in what each device could do. The APIs defined as the core PhoneGap device APIs represent a very broad set of functionality that can be consistently delivered, but there is also a need to extend functionality for a particular device if a feature is compelling enough. PhoneGap provides an easy mechanism to ‘plugin’ new functionality as it is developed. At it’s heart PhoneGap is providing a bridge from the JavaScript world to the native code world, and back again. This bridge can also be used by developers wishing to augment this functionality with their own native additions.

There is currently a huge list of plugins in a separate repository to support everything from PayPal, Facebook, and Twitter integrations, to Scanning BarCodes with the Camera. The beauty of plugins is that they can be developed organically, in that if a developer has a specific expertise on a platform they can develop a plugin for it without being concerned with how to implement it elsewhere. Another developer can pick it up and fill in the functionality for another device.

The plugin repo can be found here:

How much does it cost?

PhoneGap is and always has been free. It was licensed under the liberal MIT license before being contributed to the Apache Software Foundation. Apache Cordova is licensed under the Apache license.

About the author

Jesse MacFadyen is a senior computer scientist at Adobe Systems. Jesse was part of the team at Nitobi that created PhoneGap and joined Adobe when Nitobi was acquired in October of 2011. PhoneGap has been submitted to the Apache Software Foundation and is now called Apache Cordova. Jesse continues to contribute to Apache Cordova and recently worked closely with Microsoft to bring the full functionality of PhoneGap to Windows Phone 7.