Why you should use AngularJS for your Phonegap Applications

There are tons of heavy hitting javascript frameworks / libraries out there that seek to make javascript more managable, dependable, and let developers approach the language as more than just a quick fix language. There are libraries like jQuery, Zepto, and backbone, which simplify tasks like DOM manipulation, JAX, and many other standard tasks. These libraries aren’t really desirable for a large scale all javascript application because they don’t enforce any type of pattern. This is where frameworks like EmberJS, AngularJS, ExtJS step in. These frameworks enforce the MVC pattern and make your application much cleaner to develop. Why should you pick Angular over another framework like Ember or Ext?

It’s free

and it is made by Google, so it will probably always remain free. I only point this out because ExtJS’s latest build isn’t free.

Declarative HTML

I love that HTML can be used to express events, bindings, etc. Some critics of Angular have said that this is not good because it mucks up production HTML code and user’s can see it. That isn’t an issue for a Phonegap app because your code is not exposed to the user! Going with this fact, I think that the declarative HTML will help separate concerns between event / data binding and the actual events / data. This is in contrast to a framework like jQuery where the event binding and events are comingled.


Angular does pretty well in the speed department, as you can see here. This is important on phones which do not have the performance of your browser on your computer.

Ember is a really solid framework as well, doing things like data binding, views, etc which libraries like jQuery don’t. Each will help improve your application’s code organization and lead to a more solid and inviting application, there are just a few points with Angular which make it more desirable, to me, on a Phonegap application. I’ll be exploring a basic Angular application which will use liquid lab’s google tasks on Phonegap tutorial, but applying it to Angular instead of jQuery mobile.

Now PhoneGap Apps Can Feel Native | Monaca

What is Monaca?

Monaca is a development environment for smartphone applications provided by Asial Corporation. You can write program codes on Monaca IDE which operates on the Web. Monaca does not only provide you a development environment at your fingertips, but also allows anyone to be able to develop smartphone applications.

Monaca smartphone and tablet apps are using a technology called Hybrid apps. Hybrid apps are written using HTML, CSS, and JavaScript. Therefore, they have both web and native characteristics


  • Complete Cloud Toolkit for Delivering Rich Hybrid App Experiences
  • Monaca is a Cloud based integrated development environment for Hybrid Applications
  • Monaca enables developers   to use in web technologies to develop,test and publish application that run natively across multiple platforms



HTML5 ,CSS , JavaScript

  • Apps for multiple platforms can be created using HTML5 and Java Script ,Significantly improving development speed and efficiency

Full PhoneGap Support

  • Using web APIs provided by PhoneGap and Monaca , You can get access to mobile device features and native UI

Everything on the cloud 

  • Monaca is a Comprehensive platform that provides all tools necessary for app development ,debug and operating .All you need is a browser

More Details Visit


Create cross-platform apps with PhoneGap and jQuery Mobile

One of the biggest challenges of developing mobile applications is trying to port the application to multiple platforms. This can lead to extensive development costs, and the need for multiple skillsets internally in order to maintain the application. This has led to the development of a number of technologies that provide a cross-platform solution.

Arguably, the most popular of these technologies is PhoneGap. The solution allows developers to create applications with a familiar tool set: HTML, CSS, and JavaScript.


 When PhoneGap is combined with a mobile web development framework, it’s possible to develop cross-platform mobile applications quickly. One of the most popular frameworks is jQuery Mobile due to its simplicity and native look and feel.

I’ll demonstrate how to develop a simple application that uses PhoneGap APIs with jQuery Mobile to search for a list of contacts by name and display them (Figure A). Then, I’ll show how to deploy the application to your Android device with PhoneGap.  Follow along with the step-by-step tutorial, or download and import the project.

Figure A


1. Install PhoneGap. It’s platform dependent, so I refer you to the PhoneGap documentation.

2. Execute the following lines in a terminal window to create the application in the current directory:

$ phonegap create ContactsList
$ cd ContactsList
$ phonegap run android

3. PhoneGap provides a variety of plugins for accessing the native APIs of a device.  This example will make use of the PhoneGap Contacts Plugin. To add the Contacts Plugin, execute the following at the command line:

$ phonegap local plugin add https://git-wip-us.apache.org/repos/asf/cordova-plugin-contacts.git

4. Enable the plugin within your PhoneGap application by adding this line to the app/res/xml/config.xml file:

<plugin name="Contacts" value="org.apache.cordova.ContactManager" />

5. You must provide permissions to contacts within the AndroidManifest.xml, so within the application, add these lines to the app/AndroidManifest.xml file:

<uses-permission android:name="android.permission.GET_ACCOUNTS" />
<uses-permission android:name="android.permission.READ_CONTACTS" />
<uses-permission android:name="android.permission.WRITE_CONTACTS" />

6. Now you’re ready to start developing the application. The first step is to create a page that will hold the list of contacts you’re attempting to show. With jQuery Mobile, this is achieved using the <div data-role=”page”> element. Copy this code snippet into the www/index.html file of your application:

<!DOCTYPE html> 
	<title>Page Title</title> 

	<meta name="viewport" content="width=device-width, initial-scale=1"> 

  <link rel="stylesheet" 
    href="http://code.jquery.com/mobile/1.1.0/jquery.mobile-1.1.0.min.css" />
  <script type="text/javascript" src="phonegap.js"></script>
  <script src="http://code.jquery.com/jquery-1.7.1.min.js"></script>
  <script type="text/javascript" src="js/index.js"></script>
  <div data-role="page">
    <div data-role="header">
      <h1>Show My Contacts</h1>
    </div><!-- /header -->

    <div data-role="content">	
      <div id="contactsList">
    </div><!-- /content -->
  </div><!-- /page -->


We included the jQuery Mobile script and stylesheet in the <head>; this is all that is needed to use the jQuery Mobile framework. Within the <div data-role=”page”> element, we define the <div data-role=”header”> and <div data-role=”content”> elements. These elements define what content will be rendered in the page header and the content section, respectively.

7. In the previous snippet, there was an empty <div id=”contactsList”>; this <div> element will contain your contacts list. You can use JavaScript to retrieve the contacts and display them. PhoneGap provides an event to hook into the moment the application is loaded, and the device is ready. Replace the code in the www/js/index.js file with the following:


document.addEventListener("deviceready", onDeviceReady, false);

function onDeviceReady() {
    // find all contacts with 'Jacob' in any name field
    var options = new ContactFindOptions();
    options.filter = "Jacob";
    options.multiple = true; 
    var fields = ["displayName", "name", "phoneNumbers"];
    navigator.contacts.find(fields, onSuccess, onError, options);

This code snippet adds a listener that will retrieve all contacts with “Jacob” anywhere in the name once the device is ready. The data returned from the retrieval will contain the contact names and phone numbers, and will be passed to an onSuccess method.

8. After retrieving the contacts, you need to display them to the user. You can use the jQuery Mobile Collapsible List to display the contact names and allow them to be expanded to show the phone numbers. Add the following snippet to the www/js/index.js file:


function onSuccess(contacts) {
  for(var i = 0; i < contacts.length; i++) {
    var html = '<div data-role="collapsible" data-inset="false">';

    html += '<h2>' + contacts[i].displayName + '</h2>';
    html += '<ul data-role="listview">'

    var contact = contacts[i];

    for(var j = 0; j < contact.phoneNumbers.length; j++) {
      html += '<li>' + contact.phoneNumbers[j].type + 
        ": " + contact.phoneNumbers[j].value + '</li>';

    html += '</ul></div>';



function onError(contactError) {

Notice that we make use of the PhoneGap Contact object here. Be sure to specify the fields you want to use when finding the contacts list.9. If you have your Android device or an emulator set up appropriately, execute this command to deploy the application:


$ phonegap install android

Keep exploring

Try deploying the application to other platforms and using additional PhoneGap APIs. It may just convince you to use the platform for your next app.

Debugging iOS PhoneGap Apps with Safari’s Web Inspector

At some point, something will go wrong in your PhoneGap application, and you’ll want to know why. Ideally, you’ll be able to reproduce the problem in a desktop web browser, fix it, and move on. Inevitably, however, you’ll run into a problem that is only reproducible on a device. If this happens to you on iOS, and you are targetting iOS 6 or higher, you’re in luck… well, aside from that nasty defect you just found, but hey, it happens!

With Safari 6 and higher (OS X only, sorry Windows) you can use Safari’s developer tools to remotely debug web pages in mobile Safari on an iOS device.

But wait, there’s more!

Not only can you remotely debug web pages in mobile Safari, you can remotely debug any web page in any plain old UIWebView, which just happens to include that UIWebView hosting your PhoneGap application. Note that you can only inspect UIWebView content in apps that were transferred to a device from XCode. Sorry, no inspecting apps downloaded from the App Store!

Here’s how to set up for debugging PhoneGap apps with Safari’s web inspector.

Disable Private Browsing

Open your device’s Safari settings and ensure that Private Browsing is turned off. Remote debugging will not work if Private Browsing is enabled. I learned this the hard way after wasting a couple hours trying to set up remote debugging.

Disable private browsing

Enable Web Inspector

Tap the Advanced tab on your device’s Safari settings and ensure that Web Inspector is turned on.

Enable web inspector

Enable Safari’s Develop Menu

On your desktop or laptop, open Safari’s Preferences and click on the Advanced tab. Check the box to Show Develop menu in menu bar.

Enable Safaris develop menu

Start Web Inspector

Launch your app either in the iOS simulator or on a physical device. If you are using a physical device you’ll need to connect it to your desktop or laptop with the standard USB cable. Once the app has launched, switch to Safari, select the Develop menu item, then find the entry corresponding to the web page you want to debug.

Attach remote web inspector

Now you can use web inspector just like you would to debug a web page.

Use remote web inspector


One disadvantage to using web inspector like this is that you cannot attach early enough to debug issues that occur at start up. You can fake it a little by adding a delay to your start up code withsetTimeout, but even that won’t help catch every issue. You’ll have to rely on the old standbysalert() and console.log() to figure out these issues, and of course, just opening your app’s main HTML page in a browser can be quite helpful for diagnosing start up problems.

Conditional Dependency Injection with AngularJS

The excitement level around AngularJS got high enough that I thought I should give it a shot, so I took it for a spin in a PhoneGap application I am working on.

My application defines an OAuth service that handles authentication and authorization. I want to inject different implementations of the OAuth service depending on the environment the application is running in. In a web browser the OAuth service simply wraps the Google API JavaScript client. In the PhoneGap web view the OAuth service uses a custom implementation that relies on InAppBrowser.

I think conditional dependency injection will be a common need for most PhoneGap developers, especially developers that hope to reuse some, or all, of their code in a web application.

Unfortunately, it is not immediately obvious how to do this…

Here was my first attempt:

var app = angular.module('app', []);
if (window.cordova) {
  app.service('oauth', function(phonegapDependencies) {
    this.authorize = function() {};
} else {
  app.service('oauth', function(webDependencies) {
    this.authorize = function() {};
app.controller('LoginController', function($window, oauth) {

This is simple, but the problem with this approach becomes apparent when you need to make a decision about which service to use after bootstrapping. It also hurts testability. You can’t test both implementations in the same test run.

My next attempt was to define two services, declare a dependency on both, and choose which to use at runtime:

var app = angular.module('app', []);
app.service('webOauthImpl', function() {
  this.authorize = function() {};
app.service('phonegapOauthImpl', function() {
  this.authorize = function() {};
app.controller('LoginController', function($window, webOauthImpl, phonegapOauthImpl) {
  if ($window.cordova) {
  } else {

This is somewhat better from a testability standpoint, but I still don’t like the thought of having these checks littered throughout my code. I want my controller to only be aware of one OAuth service. This will make it easier to use some other useful features of AngularJS, like decorators for example.

After digging around in the AngularJS documentation some more, I discovered providers, which allow more control over the dependency injection process. Here was my attempt at using providers:

var app = angular.module('app', []);
app.provider('oauth', function($window, phonegapDependencies, webDependencies) {

  function webOauthImpl(webDependencies) {
    this.authorize = function() {};

  function phonegapOauthImpl(phonegapDependencies) {
    this.authorize = function() {};

  this.$get = function() {
    if ($window.cordova) {
      return new phonegapOauthImpl(phonegapDependencies);
    } else {
      return new webOauthImpl(webDependencies);

app.controller('LoginController', function(oauth) {

Okay, now we’re getting somewhere. This is easy to test, I managed to keep the conditional in one place, and the controller only depends on a single OAuth service. The only thing I still don’t like is having to specify the dependencies for both implementations in the provider, and then pass the dependencies to the appropriate controller. I want AngularJS to do this for me…

Well, it can! I realized I could use the $injector service with a factory to accomplish exactly what I wanted:

var app = angular.module('app', []);
app.service('webOauthImpl', function(webDependencies) {
  this.authorize = function() {};
app.service('phonegapOauthImpl', function(phonegapDependencies) {
  this.authorize = function() {};
app.factory('oauth', function($window, $injector) {
  if ($window.cordova) {
    return $injector.get('phonegapOauthImpl');
  } else {
    return $injector.get('webOauthImpl');
app.controller('LoginController', function(oauth) {

That’s it! First I register two different OAuth services, each with the same interface. Then I register a factory method that depends on the $window and $injector services. In the factory method I check whether or not the cordova global variable is defined and resolve the appropriate OAuth implementation using the $injector.get method. Now I can test each implementation in isolationand test that the OAuth factory gives the right implementation under the right conditions.

Performance Testing iOS PhoneGap Apps

PhoneGap apps tend to have a bad reputation when it comes to user experience, and for the most part this is due to poor performance. Nowadays, I often hear about teams starting work on a mobile app, and there is inevitably a debate about whether to go native or hybrid. The argument on the native side is usually something like this:

We cannot compromise on user experience.

Demanding the best user experience is a good stance to take. However, there are plenty of successful PhoneGap apps out there in the wild right now. You just don’t know that they are PhoneGap apps because once an app reaches a certain level of performance, customers are happy and it doesn’t matter how the app was developed.

When you set out to build a PhoneGap app, your goal should be to make it feel like a native application instead of just a web page running in a UIWebView. You can do this by learning and implementing the techniques on this site, and emphasizing performance testing early and often.

In this post I will cover my testing process for iOS PhoneGap apps, with a focus on performance. The process will be similar for other platforms such as Android and the latest Blackberry phones which both use WebKit-based browser engines, but each of these platforms deserves a separate post where testing is concerned.

Test on a Physical Device Early

In my opinion, testing is one of the biggest wins for PhoneGap apps, and this is especially true on iOS. Before you can test a native app on a physical device you have to pay Apple. With a PhoneGap app, you can easily test on a real device before forking over any cash to Apple. Just host your source files on a web server somewhere, and point mobile Safari at the server. On iOS devices you can simulate full-screen by pinning the page to your home screen.

Naturally, when you test in this manner you will not have access to some of the device functionality exposed through the PhoneGap API. However, by using a variant of feature detection and stubbing you can have fairly high confidence that the parts of your application that rely on device functionality will work correctly when you finally deploy your app to a physical device.

PhoneGap App Testing Progression

Here is the testing process I follow for iOS PhoneGap apps:

Desktop Chrome or Safari

I test as much functionality as possible in a desktop browser like Chrome or Safari. This includes running automated test suites. I generally prefer the developer tools in Chrome, but testing in Safari has the advantage of being closer to the environment your app will run in when it is on the device. Safari also recently shipped with remote development tools that can help immensely when you need to debug issues that only happen on device (and this will happen to you eventually).

iOS Simulator Safari

Test in the iOS simulator’s web browser when you need an environment closer to what you will get when you ship your app. This is most useful for flushing out iOS Safari-specific display issues and seeing how your app handles simple touch input. Note that you cannot draw any conclusions about your app’s performance from this step, the simulator will be considerably faster than a physical device in most cases.

iOS Device Safari

This is where you should start focusing very heavily on performance. Pay special attention to animations and interactive elements. Mobile Safari does have Nitro enabled, so you’ll need to keep in mind JavaScript execution will be faster than what you will see when you deploy your app to a device. This is also a good time to test more complicated multi-touch gestures.

PhoneGap app on iOS Simulator

This is the last step you can perform without enrolling in the Apple developer program. You’ll have access to most device functionality like contacts and filesystem, but there is some device functionality (like push notifications) that you can only test on a physical device. Again, you cannot rely on the iOS simulator for performance testing.

PhoneGap app on iOS device

Now that you’ve shelled out the $100 to enroll in the developer program, you need to get ready to deploy your app to the App Store! Focus on testing all device functionality you cannot test in the simulator, and pay very close attention to performance. Ideally, you’ll see performance very similar to what you saw in step 3, just slightly slower due to the lack of Nitro in UIWebView.

The progression from browser to simulated mobile browser to physical mobile browser should happen rapidly with each feature you complete. Testing the fully packaged PhoneGap app on either the simulator or physical device can happen less frequently depending on your situation. The more your app relies on device functionality, the more time you’ll want to spend testing a fully packaged app.

Test PhoneGap Apps on Old Hardware

Modern mobile devices have considerably less horsepower than modern laptops and desktops, and while Moore’s Law dictates that this will improve over time, for the moment you need to build your app with these constraints in mind. Not only do you need to test on physical hardware, you need to test on old hardware. This is where you will experience the most extreme performance challenges. However, if you can make your PhoneGap app fast on old hardware (and you can if you keep reading this blog!) you will be in great shape on the more recent hardware.

A good rule of thumb is to test on the oldest possible device for the lowest iOS major version you intend to support. So if your app requires iOS 6 or higher, that means you need to test on an iPhone 3GS or an iPad 2. If your app supports iOS 4 or higher, you need to test on an iPhone 3G or a first generation iPad, provided you haven’t upgraded the iPad to iOS 5 already! Unfortunately, I don’t have my first generation iPad anymore, but I tested with it religiously at my last job and I found it extremely helpful in keeping me ahead of looming performance problems.

To demonstrate the hardware differences, I put together a simple benchmark that renders an animation as fast as the device will allow, either with or without hardware acceleration. The table below shows how many frames per second different devices achieved on the benchmark.

Device Version Acceleration On Acceleration Off
Chrome 26.0.1410.65 195 192
iPhone Simulator 6.1 228 228
iPad 2 6.1.3 220 55
iPhone 4 6.1.3 150 55
iPod Touch 2 4.2.1 45 31

Clearly, on physical iOS devices hardware acceleration makes a huge difference, and the difference is particularly noticeable on more recent devices. However, on desktop browsers and simulated iOS devices, hardware acceleration makes little or no difference. I’ll cover some techniques for squeezing as much performance as possible out of hardware acceleration in a whole series of future articles. But for now, hopefully this helps to illustrate why testing on old, physical hardware early on will help you out in the long run!

Tips and Tricks for Developing PhoneGap Apps for Windows Phone 8

One of the biggest perceived advantages of developing a mobile app with PhoneGap is writing once and generating binaries that run natively on nearly every mobile platform. For those of us who have tried to simply migrate an iOS PhoneGap app to Android (or vice versa), we know that sometimes it’s easier said than done. And as the landscape continues to evolve, we are being confronted with what is becoming a relatively strong third option in the mobile realm – Microsoft’s Windows Phone 8. So how do we, as PhoneGap developers, write our apps from day one to make them easier to port to new platforms? What mistakes can we avoid before we write a single line of code? In this article I hope to outline some of the top tips and tricks to use whether you are porting an existing iOS or Android PhoneGap app to Windows Phone 8 or starting a new app from scratch.

windows phone 8 logo

Windows Phone? Really?

“Why should I care about Windows Phone 8?” I can hear the groans and complaints already! Yes, I realize it’s yet another platform to deal with. Yes, I realize it doesn’t use a WebKit-based rendering engine. Yes, I realize it’s Microsoft with their questionable track record on mobile. The numbers don’t lie though. As of the end of 2013, usage of Windows Phone 8 (WP8) is increasing everywhere with almost 4% of global market share and 10% of the European market. It’s also important to note that Microsoft is listening to developers and has made WP8 a legitimate mobile platform – including making Internet Explorer 10, with its standards compliant and performant engine, the default browser.

As of today, the battle for third place is essentially over, and Microsoft has a firm grip on the bronze medal. And for those of you who want to capture that last 4-10% of the smartphone market, it’s time to start listening!

Let’s first talk about how we initiate a WP8 PhoneGap project – whether it is by starting from scratch (using the PhoneGap CLI or Visual Studio) or by expanding an existing PhoneGap project.

Please note that you will need to download and install the Windows Phone 8 SDK before you can build a WP8 app locally.

If you are not on a Windows PC, Icenium will be adding full support for Windows Phone 8 in an upcoming release. You can also create a WP8 app using PhoneGap Build.

Getting Started with a New PhoneGap Project (Using the PhoneGap CLI)

The release of version 3.0 of PhoneGap brought with it a strong push to utilize the command line interface (CLI). The promise of the PhoneGap CLI brings with it the start of consistency of syntax and implementation across all PhoneGap platforms. It takes a little bit of initial configuration to get your CLI environment set up with Windows. Unfortunately the PhoneGap docs lag behind a little as far as Windows Phone 8 goes, but if you use the following instructions all will be well:

  1. If you don’t have it already, download and install node.js.
  2. Node will add some PATH variables, therefore if you have a command prompt open, you will need to restart it. Sorry.
  3. Run the command npm install -g phonegap. There will be a lot of downloading and installing that happens next, Matrix-style.
  4. Once the PhoneGap installation is complete, you’ll want to take a look at where everything was just installed. For me it is in: C:\Users\rdlauer\AppData\Roaming\npm
  5. Run cd [path from previous step] to navigate inside of that directory. Finally, run the phonegap command by itself to verify that everything is working as it should.

Now I’m guessing you don’t want to have to remember that directory whenever you want to execute a phonegapcommand, so you should probably add the path to execute the command as a new PATH variable (if it’s not already in there):

  1. Hold the Win key and press Pause (or right-click on My Computer and choose Properties).
  2. Click on Advanced System Settings.
  3. Click on Environment Variables....
  4. Append (don’t replace!) ;C:\Users\rdlauer\AppData\Roaming\npm (using the appropriate path from Step 4 above) to the PATH variable.
  5. Restart your command prompt.

That was the difficult part – and luckily you only have to do it once!

To actually create a new WP8 PhoneGap project, all you have to do is navigate to a new directory where you want to store your project and execute the following command:

phonegap create hello com.example.hello HelloWorld

This creates a new PhoneGap project with hello being the name of the directory, com.example.hello the optional app identifier, and HelloWorld the optional display name of your app.

Now, run the cd hello command to navigate inside of your newly created project to execute the next set of commands.

Gotcha: There is a minor issue that will surely be fixed in a future version of PhoneGap (I am on 3.3). Before you try to build your WP8 app, you’ll probably need to change the name of your .csproj file to match the display name of your app (if you’ve specified one). Navigate to the platforms\wp8 directory inside of your PhoneGap project.

In that directory, in my case, I had to change CordovaWP8AppProj.csproj to HelloWorld.csproj.

Now that we have that little workaround out of the way, we can build our WP8 app using the following command:

phonegap -V local build wp8

If all has gone correctly, at the bottom of your command prompt you should see the following message:

successfully compiled Windows Phone 8 app

Next up you’ll probably want to fire up the handy Windows Phone 8 emulator that came with your SDK installation:

phonegap run wp8

Again, if all has gone correctly, you should see the following in your emulator:

wp8 emulator hello world

Great success!

Getting Started with a New PhoneGap Project (Using Visual Studio)

Now what if you are a hardcore Visual Studio user and don’t necessarily take to these fancy-pants command line tools? There is nothing wrong with that at all and luckily for you it’s pretty darn easy to get started using only Visual Studio. The Cordova distribution actually comes with Visual Studio project templates, so if that is your cup of tea, you can start a new project within Visual Studio and choose a Windows Phone 8 Cordova template.

And yes, I did say “Cordova”. For the purposes of this article, you can consider “PhoneGap” and “Cordova” one and the same. If you would like to know more about the difference, I suggest you read this post on “Demystifying Apache Cordova and PhoneGap”.

Disclaimer: I have only tested the following method with Visual Studio 2012 and 2013. If you are using an older version of Visual Studio your mileage may vary!

The first thing we are going to do is download the full Cordova distribution. Got the zip archive? Great. Go ahead and unzip that beast.

Within this archive, there are a series of individual archives for each supported platform. You are going to want thecordova-wp8.zip archive, as that is what contains our Visual Studio templates for Windows Phone. Extract that archive and discard the rest.

Now within this archive, you will find a batch file with the name of createTemplates.bat. Go ahead and double-click to execute this batch process. This will, no surprise, create your Visual Studio templates. If you ran it, you should now see two new archives: CordovaWP7_3_3_0.zip and CordovaWP8_3_3_0.zip (depending on the version of Cordova that you downloaded of course).

These are our Visual Studio templates! Depending on whether you expect to do either Windows Phone 7 or 8 development, you’ll want to put one or both of those templates into your Visual Studio template folder. Mine was located here:

C:\Users\rdlauer\Documents\Visual Studio 2013\Templates\ProjectTemplates

That’s it! Start (or restart) Visual Studio, go to File -> New Project, and under the Visual C# tab, you should be presented with the following template option:

new visual studio project

Enter a name for your project and you are ready to begin!

Once inside Visual Studio, you can use the Run menu option to test your app inside of the Windows Phone emulator. You should see the exact same result as if you had run it from the CLI (see emulator image above).

Getting Started with an Existing PhoneGap Project

If you’ve been a hybrid mobile developer for long and have already set up a PhoneGap 3.0+ project, you’ll surely appreciate the simplicity of running the following command inside of your existing project to add a new platform:

phonegap platform add wp8

Note that you still need to download and install the Windows Phone 8 SDK for this method as well.

Likewise to build and run your newly-added platform in the emulator, you’ll want to run:

phonegap build wp8

…and then use the run command to view your output in the Windows Phone 8 emulator:

phonegap run wp8

The beauty of this method is that you can share your web assets across multiple platforms. One PhoneGap project can hold all of the HTML, JavaScript, and CSS assets for all of your platforms, making it much easier to make updates to each supported platform.

But, Now What?

We have created a new PhoneGap project, either by using the CLI or Visual Studio. But now what do we do with it? This is where the beauty of the PhoneGap platform excels. Create your mobile application using HTML, JavaScript, and CSS. Use any JavaScript framework you like, or roll your own. The amazing thing is that you can create a performant mobile app using the skills and technologies you’ve already spent years honing as a web developer!

If you want a boost, might I suggest a few places to get started?

  • Kendo UI Mobile is a great JavaScript framework that provides out of the box support for a variety of mobile operating systems (including Windows Phone 8). The latest version includes a flat UI as well if you want to provide a consistent look across platforms. Kendo UI Mobile is also very much focused on performance (and is based on jQuery which makes it easy to get started).
  • jQuery Mobile is another wildly popular mobile JavaScript framework. While it doesn’t provide a native look or feel, it is free and has a strong community backing.
  • ChocolateChip-UI is a mobile framework that has been gaining momentum lately. Slightly risky in that it is a relatively untested option, it is a framework that may be worth looking into if you want a free and performant alternative.

The Part Where You Say, “There Had to Be a Catch”

If you are a seasoned PhoneGap developer, you probably know that moving from the WebKit-based web view of iOS and Android to the IE10-based web view of Windows Phone 8 could not be as simple as copying your web assets over. While IE10 is an amazing improvement, it still lags behind in some areas of HTML5 support, and the mobile offering doessacrifice a certain amount of functionality for performance.

What I’m including here are some of the biggest “gotchas” that iOS/Android PhoneGap developers will probably encounter when migrating an app to Windows Phone 8 (also useful if you’re starting a WP8 project from scratch).

Custom Fonts

Due to a limitation (whether it was purposeful or not) you are unable to include a font file with your app and reference it for use via CSS. This of course applies to font-based icon providers, such as the popular Font Awesome. 🙁

The workaround is to fallback on your standard web fonts (such as Verdana, Arial, Helvetica, etc) and to use image sprites for your icons. There are also hacky solutions available but your mileage may vary!

Remove the -webkit Prefix

This should be an obvious one, but if you are migrating an existing app and use the -webkit prefix in your CSS, those rules will not be applied to your WP8 app. The good news is that since IE10 is a much more standards-compliant browser, you can most likely ditch that prefix altogether.

Device Pixel Ratio

WebKit introduced the “device pixel ratio” to help developers detect the resolution of the device in use. Developers have been using window.devicePixelRatio to help set the size of the viewport and to determine what resolution of images to display in the app. WebKit also utilizes the device pixel ratio to set the correct page size when the viewport width is set to device-width (which helps to set the width on both high density and normal devices in order for the page to look the same on both devices).

The sad truth is that device pixel ratio isn’t supported at all in IE10 on Windows Phone 8. Fortunately we can get a close approximation by using the screen.width and a simple calculation:

screen.width / 320 = 1.5 (our approximate device pixel ratio!)

For example, the Lumia 920 with a 768 x 1280 4.5” screen provides us with:

screen.width / 320 = 2.4

Once we calculate this ratio, what can we do with it? We simply use relative font sizes. Since IE10 supports the em and rem units, these are what we will use to specify our font sizes. Go ahead and set the font-size of the document element to the ratio in em, then base all of the sizes in your application to em or rem units and they will re-size accordingly. For example:

html { font-size: 1.5em; } /* example for simulated device pixel ratio of 1.5 */

Special thanks to Burke Holland and Kamen Bundev for their help with investigating these mobile IE10 issues.

The Word from Microsoft

One of the most useful posts from the Windows Phone blog (at least for a PhoneGap developer like myself) is an article on Adapting your WebKit-optimized site for Internet Explorer 10. There are all kinds of tips and tricks included in this post like:

  • CSS prefix changes (similar to what we already covered)
  • Touch and Pointer events
  • Handling non-standard behaviors like IE link highlighting and disabling some native styling

Read through that post as well and you’ll be well on your way to developing an app that rolls from one platform to the next with fewer inconsistencies.


Hopefully this post has brought to light how easy it can be to add that third platform to your PhoneGap app. By exploring the Windows Phone 8 platform you are not only broadening the reach of your app, but you are also helping to legitimize PhoneGap itself by showing off one of the primary reasons it exists – true cross-platform mobile app development.

PhoneGap for Flex/AIR Mobile Developers

If you’re a Flex/AIR developer or any developer focused on mobile for that matter, I believe it’s worth your while to spend some time reading this first post in a series of posts I will be writing on usingPhoneGap (aka Cordova) for building mobile apps. It’s another great technology choice for rapid cross-platform mobile development and becoming more and more popular. I’ve heard some developers express how they feel like they’re going back in time with HTML/JS development, or simply don’t want to ‘go there’ but it’s worth checking out how it can be used to quickly build a mobile application with HTML/JS and PhoneGap and you should consider this option for building mobile apps.

What is it?

The crux of PhoneGap is essentially a big ‘ol .js file (per platform, separate one for iOS vs Android etc) along with some simple native code to enable it to work. In the main JavaScript file (phonegap.js or cordova.js) are a bunch of functions that give you access to native features including the camera, compass, accelerometer, file system, storage access, media capture, audio playback, notifications, contacts and network connection status etc, similar to what Adobe AIR APIs offer, with the addition of a couple more. You write your applications in HTML/JavaScript and use CSS to style them. PhoneGap apps are wrapped in a native web container component, which is why your HTML/JS/CSS work. This also means there is a dependency for your phone’s browser to be based on the WebKit engine. This really isn’t an issue though since WebKit is the default for iOS, Android, BlackBerry Tablet OS and webOS currently. A great overview ofcommonly asked questions about PhoneGap can be found on my teammate Andy Trice’s blog, as well as a bunch of other great PhoneGap posts, so definitely check out his blog for heaps of good content.

How Does it Work?

The API functions in the phonegap.js (or most recently cordova.js) files call native plugin/extension code to provide the access to the native features through JavaScript exec calls. If you’re an AIR developer, it’s similar to the AIR Native Extensions model, except in PhoneGap they’re called plugins, and the set of APIs listed above (notifications, compass etc) are included and set up for you by default in the PhoneGap download. There are a bunch of other open source plugins available too which can easily be added to your project, or if you don’t find one you need, they’re easy to write. Here you can find instructions on how to write one for Android, and here for iOS. You can see that the JavaScript exec calls for iOS use .h/.m files for the actual native implementation, and .java for Android.

When you’re ready to use one of the APIs in your application, it’s very straightforward and easy to use. Here’s an example of adding a notification to your application:

Code Example

    function showAlert() {
            'You are the winner!'// message
            alertDismissed,         // callback
            'Game Over',            // title
            'Done'                  // buttonName

Here’s the result:

You will find that all of the APIs are accessed through a navigator variable (declared in the phonegap.js file). To see examples of how to use all of them, check out the nicely done API reference docs.

If you’re curious of how this works underneath, here’s the notification code snippet straight out of the cordova.js file (NOTE: remember phonegap and cordova are currently the same library, so if you download it now you may find that your main API files are named cordova.js file instead of phonegap.js):

phonegap.js Source for Notifications

 * Open a native alert dialog, with a customizable title and button text.
 * @param {String} message              Message to print in the body of the alert
 * @param {Function} completeCallback   The callback that is called when user clicks on a button.
 * @param {String} title                Title of the alert dialog (default: Alert)
 * @param {String} buttonLabel          Label of the close button (default: OK)
Notification.prototype.alert = function(message, completeCallback, title, buttonLabel) {
    var _title = title;
    if (title == null || typeof title === 'undefined') {
        _title = "Alert";
    var _buttonLabel = (buttonLabel || "OK");
    <strong>Cordova.exec(completeCallback, null, "org.apache.cordova.notification", "alert", [message,{ "title": _title, "buttonLabel": _buttonLabel}]);</strong>

The above code shows the notification alert function definition to use for performing a native alert notification on iOS. The important line there is the Cordova.exec(…) call, which will use the native plugin code for iOS or Java to perform the notification. If you’re extra curious and want to see what the native code looks like for this, you can open the Notification.java or CDVNotification.m files such as shown (note: you need to download the actual cordova/phonegap project source from github here to view the source files for the core plugins. This is only necessary if you wish to view them or want to make your own custom changes to them, typically you would just install from here). I pasted a couple snippets from the native code files below to give an idea:

Java Source for Notifications

public PluginResult execute(String action, JSONArray args, String callbackId) {
    PluginResult.Status status = PluginResult.Status.OK;
    String result = "";  
    try {
      else if (action.equals("alert")) {
        this.alert(args.getString(0),args.getString(1),args.getString(2), callbackId);
        PluginResult r = new PluginResult(PluginResult.Status.NO_RESULT);
        return r;

Objective-C Source for Notifications

- (void) alert:(NSMutableArray*)arguments withDict:(NSMutableDictionary*)options
    int argc = [arguments count];
    NSString* callbackId = argc > 0? [arguments objectAtIndex:0] : nil;
    NSString* message = argc > 1? [arguments objectAtIndex:1] : nil;
    NSString* title   = argc > 2? [arguments objectAtIndex:2] : nil;
    NSString* buttons = argc > 3? [arguments objectAtIndex:3] : nil;
    if (!title) {
        title = NSLocalizedString(@"Alert", @"Alert");
    if (!buttons) {
        buttons = NSLocalizedString(@"OK", @"OK");
    CDVAlertView *alertView = [[CDVAlertView alloc]
    alertView.callbackId = callbackId;
    NSArray* labels = [buttons componentsSeparatedByString:@","];
    int count = [labels count];
    for(int n = 0; n < count; n++)
        [alertView addButtonWithTitle:[labels objectAtIndex:n]];
    [alertView show];
    [alertView release];

Common Questions

    • What kind of UI Components does PhoneGap offer? PhoneGap does not offer UI Components, they leave that implementation up to you with your choice of HTML/JS/CSS or some other UI frameworks available like Twitter Bootstrap, jQuery Mobile, Kendo UI etc…
    • How can I consume data in a PhoneGap app? The same way you consume data from a web application – REST, JSON, SOAP etc.
    • What’s the difference between PhoneGap and Cordova? Cordova is the Apache Open Source project behind PhoneGap. If this is confusing to you, please read this post!
    • What kind of development environment do I need? You can develop in your editor of choice on any platform. There are some workflow tips I can provide and will do so in the next post with my choices for editing, debugging etc. Once you have created your app in your platform of choice, you can just upload the source directly from your source control system or via zip file to PhoneGap Build as the screenshot below shows and it will create a ready to install package for all of the different platforms.


Pros and Cons of the Top 5 Cross-Platform Tools

As the market temperature for cross-platform tools (CPTs) continues its steep climb into hotter territory, it’s understandable why many feel we are witnessing a mobile fragmentation that is perhaps much larger and more significant than the recent wars waged over the desktop. If this fragmentation tells us anything, it’s that cross-platform tools for mobile development are often not a “one-size-fits-all” solution – and that there are numerous veteran users of these tools that do not believe the problem has been solved as well as it could be….yet. In our Developer Economics Q1 2013 report, the breakdown of the top CPTs looks like this:


As you’d expect, each approach comes with trade-offs. Let’s examine the top five cross-platform tools (PhoneGap, Appcelerator, Adobe AIR, Sencha, Qt), as identified in our research, and list out the more salient pros and cons of each. This is not an exhaustive list, of course, as each platform can’t be explored in depth in one post alone. Want to contribute to the Developer Economics research? The new survey will be live until November 22 [UPDATE: Survey closed – results out in January 2014]

Apache Cordova/PhoneGap

Apache Cordova (known by many as “PhoneGap“) holds the top slot in developer mindshare. Cordova/PhoneGap developers write their mobile applications using HTML, JavaScript and CSS. These assets run in a “WebView” inside a native application container on the target platform. It is, conceptually, a web application packaged within a native application container where your JavaScript has access to device-level APIs that normal web applications would not (more on that below).

The name “PhoneGap” is quite possibly one of the more recognizable names in this space. Originally created by Nitobi, the name was changed to “Apache Cordova” when it was donated to the Apache Software Foundation. Adobe purchased Nitobi – including rights to the PhoneGap name – and now distributes Cordova under that name.


  • Regardless of server side platform & language experience, a significant number of developers have experience with HTML, JavaScript and CSS. Apache Cordova allows developers to immediately leverage these existing skills. The value of this can’t be overstated – as it reduces training and can enable a quick-to-market stance in companies ready to adopt it.
  • Cordova apps install just like a native application, and are able to leverage app store discoverability.
  • Cordova follows a plugin architecture, which means that access to native device APIs can be extended in a modular way. There are a lot Cordova/PhoneGap plugins to choose from – enabling developers to focus on the web-based skills they already have. (This is a weakness as well, as we’ll see in a moment.)
  • Cordova is open source and free, so there are no licensing costs (also a potential weakness, mentioned below).
  • Cordova/PhoneGap solutions existed in this space early on, and have matured to the point where value-add offerings on top of the basic CPT are the norm. For example, both Adobe’s PhoneGap Build and Telerik’s Icenium enable developers to build for supported target platforms in the cloud, without local SDKs (meaning non-Mac users can build iOS applications). In addition to Icenium’s cloud build services, Telerik also provides Kendo UI Mobile (an MVVM framework targeted for performance on mobile), app analytics via EQATEC and a Backend-as-a-Service (BaaS) offering named Everlive. Adobe has integrated PhoneGap Build capabilities into Brackets (a web based IDE) and Dreamweaver.


  • Of course, being free is no guarantee of success. In fact, the emergence of PhoneGap Build and Icenium are clear demonstrations that a “bare bones” Apache Cordova is woefully incomplete. The strength of being open source – and leveraging the talents of a wide array of contributors – is both a blessing and curse. If you need to extend your app with a custom Cordova/PhoneGap plugin, odds are you will find one. Yet it may be out of date and not support the target platforms you need.
  • The plugin architecture works well if you can find the plugins you need or if your web developers are capable of changing gears to write their own custom plugin(s) as needed. However, odds are that you chose Cordova, in part, to avoid the need for specialized native platform skills.
  • The performance of Cordova/PhoneGap apps has often been criticized. Native UI will always outperform a hybrid solution, but improvements in device hardware and WebView implementations have narrowed the gap. Your web developers will need to pay close attention to performance, which means their knowledge of profiling tools as well as which web UI frameworks are mobile-friendly is essential.


Appcelerator’s Titanium provides a unified (across devices) JavaScript API, coupled with native-platform-specific features. Developers write JavaScript and utilize a UI abstraction (the Alloy MVC framework) that results in the use of native UI components, greatly aiding UI performance compared to other hybrid options.


  • The use of native UI components is a performance win, and the Alloy framework attempts to normalize UI across platforms.
  • The use of JavaScript to normalize code across platforms enables you to leverage existing skills on multiple target platforms.
  • Appcelerator provides value-adds such as a Backend-as-a-Service (BaaS), app analytics and a marketplace for 3rd party components.


  • Developers are required to manage target platform SDKs locally. It’s highly recommended for your team to establish a controlled build environment/CI process if you choose to manage SDKs locally, especially if you target multiple platforms. SDK version & build-related issues can be a horrific time sink, when you really need your team delivering features.
  • Normalizing the UI across platforms, while arguably a “pro”, is also a “con” in that your team will need to train on a proprietary technology to gain skills that are not directly transferrable outside Titanium.

Adobe AIR

Adobe AIR is “a cross-operating-system runtime that lets developers combine HTML, JavaScript, Adobe Flash® and Flex technologies, and ActionScript® to deploy rich Internet applications (RIAs) on a broad range of devices including desktop computers, netbooks, tablets, smartphones, and TVs.” The problem with that description is that you cannot use HTML & JavaScript to write Adobe AIR applications for mobile applications (Flash/ActionScript skills need only apply).


  • Adobe AIR has impressive reach – running on a wide array of desktop and mobile devices. In addition, if you plan to have a more involved/animated UI (and don’t plan to use a native approach), using AIR over a HTML/JavaScript/CSS approach may help.
  • Most Flash/ActionScript developers consider the IDE tooling for these technologies as mature.


  • The “elephant in the room” for many mobile developers is the fact that Adobe purchased Nitobi (and the rights to the PhoneGap name), clearly signaling to many that AIR may not be a long term strategy for mobile development. This combined with the rapid decline of Flash erodes the confidence many developers might otherwise have in choosing AIR.


Sencha Touch is an HTML5 mobile application framework for building web applications that look and feel like native applications. Apps built with Sencha Touch can be used with Apache Cordova/PhoneGap or Sencha’s native packager – either which will package the application in a native container and enable access to select device-level APIs unavailable to traditional web apps.


  • Sencha have produced a larger quite of interoperable products, from “Sencha Architect” (a visual HTML5 app builder) and “Sencha Touch Charts” (for data visualization) to IDE integration with the Sencha Eclipse Plugin and an secure Enterprise app deployment story with Sencha Space.
  • Sencha Touch offers an MVC style architecture, a library of UI components, an extensible API and UI themes among other features.
  • Native packaging is possible via Apache Cordova/PhoneGap or Sencha’s SDK.


  • Mobile apps written with Sencha Touch can suffer from the same performance pains as Cordova/PhoneGap apps if developers aren’t disciplined in writing efficient JavaScript and DOM structure(s).
  • Many developers already have established opinions and experience with preferred frameworks for building HTML5/JavaScript/CSS based apps. Sencha’s emphasis on its own stack will be perceived as vendor lock-in.
  • Extending a Sencha Touch app with access to additional native APIs will likely involve writing custom Apache Cordova/PhoneGap plugins. This will require specialized platform skills (or training to acquire them).


Qt (“Cute”) is a cross-platform development tool that targets a number of embedded, desktop and mobile platforms. Developers write using “QML“, touted as a “CSS & JavaScript like language”, and apps are backed with an extensive set of C++ libraries, and utilize graphics/UI components written in C++. [UPDATE: As clarified by @qtproject, “Qt exists as a free and open source version from @qtproject and a commercial offering on top, from @QtbyDigia“]


  • Qt provides a substantial set of libraries containing intuitive APIs for things like threading, networking, animations and more.
  • Qt’s IDE tooling (Qt Creator IDE & Qt Designer) appear to be solid development tools, and code profiling is available in QML Profiler.
  • Qt Linguist enables translation and internationalization in applications – giving you the support of multiple languages within your app (in a single binary).

Cons [updated thanks to new information from Digia]

  • Qt’s tools are advertised as a “complete tool chain”, and QML is a proprietary language specific to Qt’s stack. Committing to this approach could be seen by many companies as ‘platform lock-in’, given that most businesses are seeking to re-use existing skill sets when adopting a CPT, not fragment skills further. (The leap from JavaScript to QML may not be as far as a leap from web-based skills to Objective-C, for example – each team just needs to evaluate what it can handle).
  • [Updated] Originally we listed pricing as a “con”, since full commercial support could exceed €4,000 (this includes plug-in development, platform development, device modification as well as unlimited support and updates). The cost of this kind of support is significantly higher than support costs for the other CPTs we’ve looked at. However, Digia reached out with a link to the recently announced Qt Mobile Edition. According to Digia the monthly fee will be $149 (approximately €110) and will launch in the coming weeks after the release of Qt 5.2.  This pricing level puts Qt’s mobile development costs more in line with the alternatives we’ve discussed. (It’s also important to note that Qt supports an open source LGPL v2.1 license.)

Reality: You’ll Probably Use More Than One

In our Developer Economics 2013 report, we noted the following:

Developers most often use several cross-platform tools; on average CPT developers will use 1.91 CPTs, confirming the lack of maturity and niche nature of cross platform tools much like we observed in our dedicated CPT survey just over a year ago. Moreover, we found that one in four developers will use more than three cross platform tools.

What CPT(s) do you plan to investigate or adopt?

Appcelerator Titanium Review: No-Hassle Cross-Platform Mobile Development

Recently, we posted a guide helping software developers and tech executives choose the most cost- and time-effective mobile development approach, addressing whether they should go with a native, hybrid or web-based solution. However, there is also an alternative that allows you to make the right choice individually for each particular project, since it handles creating apps across various mobile OSs, as well with hybrid and HTML5 variants. It’s called Appcelerator Titanium.

Here I present an overview of the Appcelerator Titanium mobile development environment, outlining what you should and shouldn’t expect from it, along with general recommendations and comparisons with the following IDEs: PhoneGap, Sencha Touch, jQuery Mobile, and Xamarin.

Appcelerator Titanium overview

Appcelerator Titanium Review

Supported platforms

Titanium, developed by Appcelerator, makes it relatively inexpensive and easy to simultaneously build native apps for various mobile OS platforms. Currently it provides support for Apple iOS, Android, BlackBerry, and mobile web applications; later this year the company plans to add Windows Phone/RT as well.

As of this writing, here are the IDE statistics for the following mobile devices:

  • Android — 123 apps
  • Apple iPad — 99 apps
  • Apple iPhone — 410 apps

Development process

Titanium’s applications are written in JavaScript with the use of a special Titanium SDK that allows access to the required frameworks. It doesn’t offer a screen design tool, and developers create and modify apps through the code only. CSS isn’t used either.

To build an app with Titanium, you first install the official SDK for each mobile platform (Xcode and iOS SDK, Android SDK, etc.) . After a build is completed, the project will be extensively modified by the original SDK so the result becomes 100% native in terms of UI and functionality.

Hiring a team

The major requirement for a Titanium developer is knowledge of JavaScript, although any experience in mobile application development for any platform would certainly be an advantage. Since there are far more JavaScript specialists than mobile developers, choosing Titanium gives you a wider list of candidates to select from for your development team.

Should you choose Titanium?

We have previously covered several aspects to take into consideration when choosing an app type: marketing strategy, development costs, features and design, etc. Choosing an IDE is an important decision as well. We suggest first answering a few simple questions that can help considerably with making the best choice:

  • What functions do you plan to implement?
  • What platforms do you plan to cover?
  • How do you plan to distribute your app: through the platform’s official app store (AppStore, Google Play, etc.), your corporate web site, etc.?
  • What skills do the developers on your team have?

Generally speaking, Titanium is an ideal choice if:

  • your team is proficient with JavaScript; and
  • your business model targets a multitude of mobile platforms.

HTML5 applications with Titanium: Pros and Cons

If your goal is to develop a universal web app rather than a set of native apps for various platforms, Titanium may be the best solution as well. In this case, your app will include a combination of JavaScript, CSS, and HTML5.

A web app built with Titanium has specific advantages that allow you to:

  • use standard UI elements (tables, buttons, etc.) along with animation effects;
  • access network resources via HTML (noting that there are security limitations you should take into consideration and plan on possible ways around);
  • store data locally (with the amount of data limited by the browser);
  • provide support for asynchronous module definition (AMD) and CommonJS;
  • pre-cache resources for faster loading.

However, web apps have several limitations as well, such as:

  • restricted access to certain components of a mobile OS (e.g., Android activities, iOS local notifications, or the Apple iAd service);
  • limited access to device resources (such as the camera;
  • dependence on a browser to run the web app;
  • limited functionality without an Internet connection;
  • restricted use of native UI elements;
  • limited access to calendar and contacts (varies depending on the platform);
  • no support for Titanium Extensions distributed through the Appcelerator Open Mobile Marketplace (the extensions are provided as executable code for each platform and therefore can’t be launched in the browser).

General guidelines for making a choice

  • Keep in mind that the more platforms you plan to cover, the fewer features you may be able to offer.
  • While you save time developing apps with Titanium, you still have to test apps on native platforms. Thus, don’t forget to add in the extra costs to the project budget for the QA team and device testing, and extra time in project scheduling.
  • Even if you don’t plan on building apps for multiple platforms, Titanium still may be a good solution for your team as it makes the development process much easier. There’s no need to solve high-level tasks specific to a particular platform, such as memory management. Therefore, instead of developers needing to focus on OS documentation they can concentrate on adding more features and on design implementation.

Titanium vs. Other IDEs

Here at this point in the overview, I’ll compare Appcelerator Titanium with several other alternative development tools. It’s also worth mentioning that Appcelerator has been recognized by Gartner Research as one of the companies in their Mobile Application Development Visioneers category, along with Sencha and Xamarin.

PhoneGap by Adobe

PhoneGap by Adobe

Adobe’s PhoneGap API exceeds the capabilities of standard web applications by providing access to resources such as the GPS, file system, accelerometer, etc. However, the controls are not native, and the UI is created via HTML5, CSS, and JavaScript. This may considerably increase development costs if you decide to create UI versions for multiple platforms and device types, on account of factors such as provision for numerous display sizes and resolutions, etc.

PhoneGap offers a convenient cloud-based service called Build which allows you to compile applications for several mobile OSs without installing any native SDKs to the developer’s desktop. To compile a project, all you need to do is upload it to the Build site, and when you’re done you’ll get ready-to-run apps for each target platform.

Although Build creates native apps, the original code stays the same and the app is launched via a browser, which does result in lower performance for certain types of apps.

Sencha Touch by Sencha

Sencha Touch by Sencha

Sencha Touch is a framework for web app development (HTML 5, CSS, and JavaScript). It allows access to a rich diversity of resources like control libraries and the UI.

Until recently, Sencha Touch could not build native apps and was often used in conjunction with PhoneGap Build. But now Sencha has a cloud service of its own – which is really convenient.

jQuery Mobile

jQuery Mobile

This jQuery-based framework allows you to create web applications and sites optimized for touchscreen UIs. Just like jQuery itself, jQuery Mobile grants access to a huge library of ready-made components you can use in a project.

Xamarin (previously MonoTouch)

Xamarin (previously MonoTouch)

This IDE allows you to create native apps for iOS, Mac OS X, Android, and Windows Phone. The programming language is C# within a .NET framework.

Here are the examples of applications developed with this IDE; the component catalog is presented here, although the number of components is not very large (somewhere around 100).

The major advantage of this solution is that you can use the original SDK for each platform, thus resulting in 100% native apps. The primary disadvantage is found in the disappointing fact that only some of the code is universal, with a considerable amount needing to be written specifically for each platform – thereby increasing development costs.

While Xamarin does offer an IDE of its own, it also provides support for integration with Microsoft Visual Studio.

Summing Up

In wrapping up this post, I want to remind you that a wide variety of options for mobile development are available nowadays, so it’s totally possible to find the perfect solution for your particular project. Like with any other IDE, Appcelerator Titanium has its strengths and weaknesses. But its ease of use, speed – and ability for the simultaneous creation of native and web apps – make it a great choice for a wide range of projects.