Mobile App emulation using Google Chrome Canary

February 12, 2014 Leave a comment

The mobile web has evolved to enable increasingly sophisticated applications, which we often wish to debug during development on the desktop. The DevTools include support for a number of features that can help with this which we will walk through in this section.

Note: Some of our documentation may be ahead of the stable version of Chrome. If you are unable to locate a feature listed, we recommend tryingChrome Canary which contains the latest version of the DevTools.

Enabling the Emulation Panel

Chrome Canary has received a number of improved mobile emulation tools which can be accessed by enabling the Emulation panel through the Settings panel. To enable:

  1. Open the Settings panel within the DevTools.
  2. Enable “Show ‘Emulation’ view in console drawer.”
Enabling emulation

Bring up the DevTools console drawer by hitting the Esc key and then select the Emulation panel.

Emulation panel

Note: Emulation tools within DevTools were previously contained within an Overrides pane inside the Settings panel. The Emulation panel is the new Overrides pane.

Emulating Devices

It’s often easier to start prototyping on the desktop and then tackle the mobile-specific parts on the devices you intend to support. Device emulation can make this process more straightforward.

DevTools contains built in presets for a number of devices, this allows you to emulate and debug mobile viewport issues like CSS media query breakpoints. Selecting a device preset automatically enables a number of settings:

  • User agent – a string available at navigator.userAgent and also sent as a request header for page resources. See Useragent Spoofing.
  • Screen resolution – matches the actual dimensions (width and height) of the selected device. For example, selecting the Nexus S will emulate a resolution of 480×800.
  • Device Pixel Ratio – matches the DPR of the selected device. Allows emulation of a retina device from a non-retina machine. This also means media queries such as @media only screen and (min-device-pixel-ratio: 2) can be tested.
  • Emulate viewport – zooms the page out to the physical default viewport of that device. In the case of the Nexus 4 this is 768×1280.
  • Text autosizing – emulate font boosting which occurs on mobile devices.
    • Android font metrics – Android artificially increases the font metrics used by text autosizing based on the system settings and screen size. Enabled by default only when emulating an Android device.
  • Touch screen (part of the Sensors pane) – uses touch events, see Emulating Touch Events.
Viewport emulation

Emulate a device via a preset using the following steps:

  1. Open the Emulation panel within the DevTools
  2. With the Device pane selected, select “Google Nexus S”.
  3. Click Emulate.
Viewport Overrides

You are now in device emulation mode. The Screen, User Agent, and Sensors panes reflect the device settings which are now enabled.

Viewport Overrides


  • The Swap dimensions button in between the Resolution values () will swap the width and height.
  • Shrink to fit ensures the emulated device screen is completely visible within your browser window. This setting does not emulate the device differently.
  • Device media queries (e.g @media only screen and (min-device-width:768px)) will be enabled according to the values defined in the Resolution settings.
  • You may want to undock DevTools or dock it to the right while working with emulated viewport settings.
  • Device settings can be configured independently of a device preset.
  • If you would like to contribute patches to support new device presets, please see our contribution docs.

Read More from Google help

Categories: Android, iPhone, PhoneGap

Multi-platform mobile application development with PhoneGap

February 12, 2014 Leave a comment

Adobe’s PhoneGap platform enables a developer to create an app that runs on a variety of mobile devices. The developer accomplishes this largely by writing the user interface portion of their application with Web technologies such as HTML, CSS and JavaScript. PhoneGap’s development tools then bundle the HTML, CSS and JavaScript files into platform-specific deployment packages. PhoneGap supports a wide variety of platforms:

  • iOS
  • Android
  • Windows 8
  • Windows Phone 7 and 8
  • BlackBerry 5.x+
  • WebOS
  • Symbian
  • Tizen

For this article, we’ll focus on getting our sample FasTip application running on iOS and Android:

As with the previous articles in this series, all of the code for our application may be obtained from a GitHub repository.

Applications built with PhoneGap use the mobile platform’s Web view to render content. As such, the content will appear nearly identical on each platform, much as any Web page would. While you can style the controls differently on each platform, take care in doing this. This issue is covered in detail in the section below on multi-platform considerations.

Plugins: Closing The Gap On Native Features

PhoneGap essentially wraps a Web view of your HTML, CSS and JavaScript in a native application. This is required because the Web view in an application does not inherently support many device features, such as access to the file system or the camera. PhoneGap has a bridging mechanism that allows JavaScript running in the Web view to invoke native code contained in the application. PhoneGap comes complete with plugins to support device capabilities such as the following:

  • accelerometer,
  • camera,
  • contacts,
  • file system,
  • media playback and recording,
  • network availability.

A full list of capabilities for each platform is available on PhoneGap’s website. If these capabilities aren’t enough, PhoneGap may be extended with plugins that enable the developer to access more device features, including these:

  • barcode scanning,
  • Bluetooth,
  • push notifications,
  • text to speech,
  • calendars,
  • Facebook Connect.

In previous versions of PhoneGap, a GitHub repository contained a set ofprebuilt plugins. With the arrival of PhoneGap 3, a new plugin architecture has resulted in the old repository being deprecated. A registry has been created for all plugins compatible with PhoneGap 3.

Some command-line tools are also provided to make it easy to add the plugins to the repository for your project. We’ll see these later on in this article. PhoneGap also publishes documentation and examples on how to write your own plugins. Of course, development of plugins assumes familiarity with the native platform on which the plugin is to be supported.

An HTML, CSS And JavaScript Foundation For Mobile Development

The majority of PhoneGap’s capabilities lie in non-visual components — things that access the file system, network availability, geolocation, etc. PhoneGap does not provide much assistance with building the user interface itself. For this, you must rely on the HTML and CSS foundation that you’ve built yourself or on a framework. Applications written for mobile browsers must respect the limitations of the given mobile platform (processing speed, screen size, network speed, touch events, etc.).

Unless you have been working with HTML and CSS for a long time and are well aware of these issues, developing an effective mobile application without some sort of framework can be daunting.

Fortunately, some mobile frameworks have arisen to help with this. Here are just some of the offerings in this area:

These frameworks vary from CSS-oriented libraries (like Topcoat) to complete MVC-based libraries with sets of mobile UI controls (like Sencha Touch). Discussing the differences between these frameworks in detail is beyond the scope of this article and would require an entire series of articles. Visit the websites above and try some of the demonstrations on several mobile devices.

One distinction to be made is that some frameworks support a wider variety of devices and device versions than others. Some mobile frameworks are built on a particular MVC platform. For example, Ionic is built on the AngularJSframework. This might make a particular library more attractive to developers who are already familiar with the respective MVC framework.

Frameworks such as Sencha Touch abstract the DOM from the developer through the use of APIs, freeing the developer from having to worry about details of browser vendor implementations. Sencha also provides graphic development tools, such as Sencha Architect, to aid the development process. Sencha provides commercial support and training, too, which are worth investigating.

I’m often asked to recommend a framework for mobile development. But the right tool depends largely on your application’s functionality, the mobile platforms you need to support, your demand for commercial support and your experience with Web and mobile development in general. I’m encouraged by some emerging frameworks, particularly Ionic, but as of the time of writing, Ionic is still in the alpha stage. If you are looking for something with a longer track record, then Sencha Touch or, for some cases, jQuery Mobile might be appropriate.

To be expedient and because of the wealth of tutorials and documentation available, I’ve written our FasTip application in jQuery Mobile, which provides a wide range of support for mobile devices. It’s a good choice for applications that do not require significant customization to the user interface. The simplicity of our application makes it well suited to jQuery Mobile.

PhoneGap Or Cordova: What’s In A Name?

In the process of learning about PhoneGap, you’ll encounter the name Cordova. In fact, the command-line tool that we’ll use in just a moment to create our PhoneGap project is named Cordova. Simply put, Cordova is the open-source project that is the basis of PhoneGap. Think of it as the engine that drives PhoneGap.

In most cases, the names may be used interchangeably. With “PhoneGap” already being trademarked, a new name was needed when the project was open-sourced — hence, Cordova. “PhoneGap” continues to be used by Adobe for commercial products. Most people still refer to
the project as a whole as PhoneGap.


Installing PhoneGap

With the introduction of version 3, installing PhoneGap’s tools and setting up projects have been greatly simplified, thanks to the new command-line interface (or CLI). The command-line tools are based on Node.js; thus, you must install it before installing PhoneGap. Once Node.js is in place, simply run one command for the node package manager to install PhoneGap’s tools:

npm install -g cordova


The command-line tools provide only the PhoneGap portion of the tools that are necessary for development. You will still need the mobile SDKs for the platforms that you wish to support. For this article, we’re mostly concerned with iOS and Android. For iOS, you’ll need to install the same developer toolset that we used when building native Objective-C applications.

Refer to the earlier article on native iOS development for instructions on installing those tools. This will give PhoneGap the tools necessary to compile and build your app into something that can be deployed to an iOS device. Likewise, to build applications for Android, you’ll need the Android SDK.

The previous article on native Android development provides some assistance in locating these tools and installing them. In addition, you may wish to consult PhoneGap’s documentation for details on installing for Android and iOS.

FasTip In PhoneGap

Given that FasTip is such a simple application, we don’t have to leverage much of PhoneGap’s functionality to access device features. Most of our time will be focused on the Web components needed to build the user interface. Unlike with native platforms, there is no vendor-supplied integrated development environment (IDE) for PhoneGap that is similar to Xcode or Eclipse.

Developers may use whichever IDE they please. I use JetBrains’ excellentWebStorm IDE for Web development because it suits PhoneGap development nicely. We’ve developed much of the FasTip application in WebStorm and tested it on the desktop version of Google’s Chrome browser, before packaging it for mobile devices in PhoneGap.

The figure above shows the FasTip application loaded in WebStorm. Note that relatively few files make up this project:

The user interface is shaped by index.html. This one file contains all of the HTML used by this application. The HTML starts out with this head section:

  <meta name="viewport"
    content="initial-scale=1, minimum-scale=1, maximum-scale=1">
  <meta charset="utf-8">
  <title>FasTip - Tip Calculator</title>
  <link rel="stylesheet" href="css/themes/default/">
  <link rel="stylesheet" href="css/app.css">
  <script src="js/jquery.js"></script>
  <script src="js/"></script>

The viewport meta tag scales the width of the page to match the width of the device’s browser. If this is not present, then the mobile browser wouldn’t know that the page is optimized for mobile use and would zoom out to display the page as though it were on a desktop browser.

Next, we load two style sheets. The vast majority of the CSS is contained in file, with a few minor application-specific CSS overrides in the app.css file. The head section then loads the scripts needed to support jQuery and jQuery Mobile.

Navigating Screens, jQuery Mobile-Style

Unlike our native apps, in which we had separate view controllers or activities for each screen, here we’ll place the HTML markup for both screens in one file. jQuery Mobile supports the concept of a page being divided into sections that make it appear to the user as though they are navigating between screens. In fact, the user would never leave this single Web page.

<div data-role="header">
  <a href="#settingsPage" id='settingsButton' class="ui-btn-right&quot
    data-role="button" data-icon="gear">Settings</a>
<div data-role="content">
  <div data-role="fieldcontain">
  <label for="billAmount">Bill Amount:</label>

Above is the code in the HTML file for the header of the main input form for the tip calculator. Note that many of the HTML elements have data- attributes. Pay particular attention to the data-role attribute, which indicates to jQuery Mobile the purpose of the various elements on the page. The data-role="header"attribute defines the upper part of the page, which looks something like theUINavigationController in iOS apps. The data-role="content" attribute is the main content of our page and displays the main form of the tip calculator.


For our native iOS and Android apps, we had to write some code to enable the user to navigate between pages. In PhoneGap, a simple HTML anchor tag takes the user to the settings page:

<a href="#settingsPage" id='settingsButton' class="ui-btn-right"
  data-role="button" data-icon="gear">Settings</a>

Further on in the HTML, we see this:

<div data-role="page" id="settingsPage" data-add-back-btn="true" >
  <div data-role="header">
   <a href="#mainPage" class="ui-btn ui-icon-delete ui-btn-icon-left"
   <h1>FasTip - Settings</h1>
  <div data-role="content">

This div element defines the boundary of the settings page in our application. The page has a div in it for the header and the content, just like the main page. Note how the first anchor tag in the header div defines the “back” and “cancel” button that enables the user to return to the first screen. The data-rel="back"attribute signifies that the link should close the current page and navigate to the main page, just like hitting the “back” button in a Web browser. In fact, pressing the dedicated “back” button on an Android device would perform the same function.

jQuery Mobile takes care of performing the transitions between these virtual “pages” in our application. Because much of the user interface and interaction between the controls is defined declaratively in our HTML, we have considerably less code to write to get the application running. All of our code is confined to a single app.js file that is just 41 lines long. The meat of our application starts with this snippet:

$( document ).on( "ready", function(){
  $('#calcTip').on('click', calcTip);
  $('#saveSettings').on('click', saveSettings);

  var tipPercentSetting = localStorage.getItem('tipPercentage');

  if (tipPercentSetting) {
   tipPercent = parseFloat(tipPercentSetting);


When the document is ready, event handlers are attached to the buttons in order to calculate tips and save settings. In this example, we’re using HTML5’slocalStorage object to persist the setting for a tip percentage. PhoneGapsupports localStorage and will save the content in the proper directory of the native platform to ensure that the data is backed up with the device’s normal backup mechanism. When the user choses to save their settings, the following code is run:

var saveSettings = function() {
  try {
   var tipPct = parseFloat( $('#tipPercentage').val() );
   localStorage.setItem('tipPercentage', tipPct);
   tipPercent = tipPct;

  } catch (ex) {
   alert('Tip percentage must be a decimal value');

Note the use of localStorage.setItem to write the tip percentage under the key of tipPercentage. Once the user has saved their tip percentage, they return to the previous screen. Because jQuery Mobile integrates with the browser’s History API when transitioning between pages, we can leverage the History API here and simply jump back to the previous page via window.history.back();. On Android where the device supports a “back” button, this will have the same effect as hitting the browser’s “back” button and moving back one screen.

For more complex apps, jQuery Mobile also enables you to dynamically load new pages, rather than place all of the markup in one file. This is the preferred approach if your application has several screens, because maintaining all of the markup in one file would become difficult and the mobile browser would have to parse that large document before rendering anything. Forcing the browser to process a large document would slow down the startup time of your application.

Calculating the value of the tip is done with the following code:

var calcTip = function() {

  var billAmt = Number( $('#billAmount').val() );
  var tipAmt = billAmt * tipPercent/100 ;
  var totalAmt = billAmt + tipAmt;
  $('#tipAmount').text('$' + tipAmt.toFixed(2));
  $('#totalAmount').text('$' + totalAmt.toFixed(2));


This is standard jQuery code for reading the bill amount, calculating the tip percentage and returning the results to the display fields on the page. When the user taps on the calcTip button, the calcTip function is invoked via an event handler that is attached when the DOM is loaded and ready:

$( document ).on( "ready", function(){
  $('#calcTip').on('click', calcTip);

The interaction between the DOM and the HTML and CSS should be familiar to anyone who writes Web pages. Of course, other frameworks, such as Backbone.js and AngularJS, may be employed to bind data, render content from templates and so on. This is an important aspect of PhoneGap: It does not dictate that particular libraries or CSS be used. Use whatever tools you want to get the job done.

Getting Our Project Into PhoneGap

PhoneGap provides a command-line tool, named Cordova, to set up a new project, build an application, run the application and install plugins. Follows the steps below to set up a project in PhoneGap.


To create our application, navigate to an empty directory and use the createcommand:

$ cordova create fastip org.traeg.fastip FastTip

This command will create a subdirectory, named fastip, to hold our application files and to establish a new application named FasTip, with an org.traeg.fastipnamespace.


Switch to the fastip directory that PhoneGap has just created from the command above.


We’ll need to tell PhoneGap which platforms we want this app to run on. We’re supporting iOS and Android, so run the following two commands to support them:

$ cordova platform add ios
$ cordova platform add android


We can test our project to see whether PhoneGap has been properly initialized:

$ cordova build ios
$ cordova emulate ios

This will compile the application for iOS and then run it in the iOS simulator.

To run the application on Android, you would use the following commands:

$ cordova build android
$ cordova emulate android

Note the directory structure that PhoneGap has established:


Note also that the sample code is copied by PhoneGap into the respective iOS and Android subdirectories. When you run the build operation, PhoneGap updates the respective build directories and places the updated files in a project suitable for each platform. If you examine the iOS directory, you’ll see that an .xcodeproj file has been created.

In fact, this project may be opened in Xcode, like any other iOS project. Similarly, the Android project may be readily imported into Eclipse. Do not change the contents of your application’s files in the platform directories, or else they will be overwritten the next time the build process is run.


We can place the various files that comprise our application in the www folder directly in the project’s root. The next time the cordova build command is executed, the application’s content will be copied to the respective platform directories, and the application will be run with that new content.

Note that our Web application’s entire structure resides in this www directory. When you create a new PhoneGap project, it is preconfigured to run whatever is in the index.html file in the www directory. In addition to the Web files that we’ve added to the project, one more file is important to a PhoneGap application, config.xml. This file controls various options used in the build process, including the display of a startup splash screen, viewport scaling, supported device orientations, etc. The settings for this file will vary according to the platform, so review the settings for each.

Also, note that PhoneGap has a merges directory. In this directory you can place platform-specific files, which will be copied to the respective build directories. In this way, you can customize HTML, CSS and JavaScript files to each platform.

Considerations For Supporting Multiple Platforms

We’ve seen that, by using PhoneGap and a framework like jQuery Mobile, building a cross-device application is easy. One caveat with jQuery Mobile is that both iOS and Android users would see the same UX; that is, the UX would not be tailored to the respective platform, much like a Web page looks the same whether viewed on OS X or Windows.

Attempting to mimic the native platform controls in HTML and CSS is generally a bad idea. While you could approximate the look of the native platform, mimicking the feel of the platform is exceedingly difficult. The controls might not respond to taps and other gestures in exactly the same way. The result is usually a UX that just feels wrong. Successful PhoneGap projects generally eschew this approach in favor of a platform-independent UX.

If your project requires an experience that closely matches that of the native platform, PhoneGap might not be the right choice.

HTML5 capabilities vary widely across devices. While iOS and Android browsers are built on WebKit, some features are implemented only in the latest versions of the platforms. One useful website for checking browser version capabilities is Mobile HTML5. The browsers on some old platforms, particularly Android 2.x, have various rendering bugs, which could also hamper your development.

Frameworks such as jQuery Mobile and Sencha Touch take these compatibility issues into account. If you choose to roll your own solution, perhaps to gain greater control over the UX, then you will need to plan additional time for testing, particularly for old device versions, on which HTML5 support is less consistent.

jQuery Mobile makes it easy to get started and provides a good feature set for simple applications. Much of the functionality on the screens of our sample application is provided by jQuery Mobile itself, leaving us with less code to write. However, the speed of development with jQuery Mobile comes at the expense of customization. While jQuery Mobile does offer a “theme roller” tool to customize appearance, much of that is “chrome” related to colors and visual attributes like rounded corners.

Assess whether your application fits jQuery Mobile’s paradigm. The platform does offer some alternate layouts for things like forms, but the options are still somewhat limited. If your application requires a truly custom look or layout, then you might find jQuery Mobile too confining. Consider one of the frameworks suggested earlier. Or adopt a “best of breed” approach, mixing a CSS-oriented framework (such as Twitter BootstrapZurb Foundation orRatchet) with an MVC framework (such as AngularJS or Backbone.js).

Some of the large mobile solutions, such as Sencha Touch and Ionic, marry a powerful MVC platform to a set of prebuilt controls focused on mobile development. These tools are attractive and worthy of consideration. But bear in mind the different range of devices that each of these tools supports. At the moment, Sencha Touch supports more devices than Ionic, but jQuery Mobile supports even more. This should also factor in your selection process.

Using A Native Plugin

If you try our sample application on iOS 7, you’ll run into an issue with the device’s status bar that has affected many PhoneGap applications. That is, the status bar now overlaps the top of the application:


You could give the body tag a 20-pixel top margin to make the page clear the status bar, but that would cause problems on iOS 6 and Android. A cleaner solution is to use a native plugin that fixes this specific issue. To add the plugin to our sample project, we’ll use this command:

cordova plugin add org.apache.cordova.statusbar

This pulls the necessary code from the plugin repository into our application. Now we’re ready to invoke the plugin in our code:

$( document ).on( "deviceready", function(){
  StatusBar.overlaysWebView( false );
  StatusBar.backgroundColorByName( "gray" );

This snippet of code waits for the deviceready event from PhoneGap, which tells our application that the PhoneGap environment has been initialized and is ready to receive commands from the JavaScript. The StatusBar object has been added to the window namespace via the PhoneGap plugin system so that we can access it via JavaScript.

The following screenshot shows the status bar overlay being turned off, as well as the background color of the status bar being changed to better fit our application:


Building In The Cloud

Generally speaking, to build an application for a particular platform, you must install the SDK for that platform on your machine. This could be a problem if, for instance, you’re on a Mac and want to target Windows tablets, whose SDK requires you to be on a Windows machine. Adobe offers a service namedPhoneGap Build to help in this situation.

PhoneGap Build enables you to upload a ZIP file containing the HTML, CSS and JavaScript of your application. Additionally, PhoneGap 3 enables you to submit an application to PhoneGap Build right from the command line; from there, PhoneGap Build takes over and produces a deployment bundle for the desired platform.


Once the build process is complete, you may either download the deployment bundle and manually install it to your device or take a picture of a QR code on PhoneGap Build’s website and download the deployment package directly to your mobile device. What’s more, PhoneGap Build supports a feature namedHydration, which enables the application to download updates to the HTML, CSS and JavaScript files whenever it launches.

This means that testers will always be running the latest version of your application, without having to go through the traditional updating process. Note that, at least for now, Hydration is meant for development and testing — not for final production code that will be submitted to the app store.


You can do more than simply compile and package your application in the cloud. Cloud-based Icenium provides a browser-based IDE that lets you edit code in a browser and immediately turn those edits into a deployment package. Using an application in the iOS App Store named Icenium Ion, you can dynamically load updates to your application as you change the code in the Web-based IDE.

In addition, Icenium bundles a license to Telerik’s KendoUI library. I’ve used this to make changes to an iOS PhoneGap application while on a Windows-based laptop. Icenium also offers a Windows desktop IDE named Graphite, which expands on the capabilities of the browser-based tool.

Another alternative to PhoneGap Build is AppGyver. It is not an IDE like Icenium, but it does offer a UX library, named Steroids, that facilities navigation between Web views using some native controls. Note that for page content itself, you must still use HTML and CSS.

The main downside to cloud-based development services is that they have limited support for PhoneGap plugins. However, new plugins are being supported all the time. Determine your application’s needs to see whether a particular cloud-based tool supports the plugins you require.

Debugging Your Application

In most cases, when attempting to debug an application, you’ll be mostly concerned with debugging the JavaScript, examining the console log and perhaps doing some interactive inspection and manipulation of the DOM. Unfortunately, there is no integrated way to debug across all platforms. However, there are several useful techniques, covered below.


I generally find it easiest to work with Chrome DevTools by treating my pages as standard Web pages loaded in a desktop browser (although this doesn’t help with the portions of code that rely on PhoneGap plugins). Chrome DevTools provides an emulation panel that simulates the aspect ratios, touch events and more of various mobile device screens.


Apache’s Ripple is a NodeJS project that serves PhoneGap content in a desktop browser. Ripple enables you to experiment with different screen sizes and orientations. It also allows you to simulate geolocation coordinates and network connectivity events, as well as allows JavaScript code to invoke many of PhoneGap’s core plugins while running in a desktop browser.

Ray Camden has more information on using Ripple on his blog. Do not confuse this newer NodeJS-based version of Ripple with the outdated Chrome browser extension. The Chrome extension is no longer supported and is not compatible with PhoneGap 3.


Starting with Safari 6, Apple has included support for using the Web inspector in desktop Safari to debug Web views running in the simulator. With your app running in the simulator, simply go to the “Develop” menu in Safari and look for the “iPhone Simulator” option. This will connect the Web inspector to the running instance of your PhoneGap application and will allow to you manipulate the DOM, set breakpoints in JavaScript, etc.


Starting with version 4.4, Android’s Web view is now based on Google Chrome. With this change comes the ability to connect to the Web view from DevToolsand to debug interactively, just like you can with iOS. If you don’t have a 4.4 device, fear not: It works with the 4.4 emulator as well. Note that you’ll need to add a special plugin to your PhoneGap project to enable Web view debugging on Android.


Web Inspector Remote (WEINRE) provides a partial set of debugging features, including DOM manipulation and access to the console. However, it does not support JavaScript debugging. Add WEINRE to your application by including a script tag in your application’s HTML and running a NodeJS server that this script connects to. The main advantage of WEINRE is that it works with earlier versions of WebKit on mobile devices and is one way of debugging cross-platform.

The PhoneGap wiki also has a page on debugging, with links to other tools.



Peter Traeg

Peter Traeg is a Solutions Architect at Universal Mindwhere he brings his broad base of technical and business consulting skills to work for our clients. With 25+ years of experience in the application development field, Peter has worked on a wide range of applications from data warehousing to online photo sharing sites. At the Eastman Kodak Company he made extensive use of Flex, AIR, HTML5, iOS, and Android technologies to help Kodak customers share their memories across a wide range of devices.

Peter is active in several development user groups where he regularly speaks on web and mobile application development technologies. When he is not experimenting with his seemingly ever growing list of mobile devices, you can find him engaging in activities such as photography, cycling, and spending time with his family in Rochester, NY.

Click Here to read more

Categories: Android, iPhone, PhoneGap

Access camera in phoneGap, it works in both android and iphone

November 26, 2012 Leave a comment

Adding Camera Functionality
Below is a function to takes a photo and upload it to a server :

function uploadPhoto(data){
// this is where you would send the image file to server
//output image to screen
cameraPic.src = “data:image/jpeg;base64,” + data;

function capturePhoto(){, null, {sourceType:1, quality:100});
html will be :

Capture Photo

How to setup MySQL database replication

August 3, 2012 Leave a comment

You can back up your MySQL database using the built-in dump tool, but the second you do that backup is out of date. Since so many companies and web-based tools rely heavily on databases, it’s crucial that those databases are as up-to-date as possible. One very simple solution is database replication, which keeps a real-time copy of the database on a remote server. With this in place, if something happens to the primary database, it will be much easier to get your database back up and running with current information.

This is what you’ll need to set up MySQL database replication:

  • Two correctly configured MySQL servers
  • Root access and access to the database administrator on both servers
  • Ability to work from the command line

The setup will use two machines: the Master and the Slave. We’ll start with the setup of the Master.

Configure the Master

The first step is to enable MySQL for networking. To do this, open the file my.ini, look for the following lines, and uncomment them if they exist:

#bind-address =

If the lines do not exist, you should add them (minus the “#”). Within the same file, we have to make MySQL aware of the database that will be replicated. You can do this with these lines:

log-bin = /var/log/mysql/mysql-bin.log

DATABASE_TO_BE_REPLICATED is the actual name of the database you want to replicate.

The above lines tell MySQL the following:

Line 1: Configures the log file to be used

Line 2: Configures the database to be replicated

Line 3: Configures the machine as the Master

After you add these lines, save the my.conf file and restart MySQL with the command /etc/inid.t/mysqld restart.

You might need to use sudo to issue the above command. Another option for the restarting of the MySQL daemon is using the service command like service mysqld start.

With this configuration complete, it’s time to set up a user for replication privileges. Log on to the Master and issue the command mysql -u root -p. Enter the password for the MySQL admin password. Upon successful authentication, you will be at the MySQL prompt, where you will enter the command GRANT REPLICATION SLAVE ON *.* TO ‘USER’@’%’ IDENTIFIED BY ‘PASSWORD’;. USER is the user who will have replication privileges, and the PASSWORD is that user’s MySQL password.

With that command issued, you must flush the database privileges with the command FLUSH PRIVILEGES;.

Let’s make sure MySQL can see the Master with the command SHOW MASTER STATUS;. This command should list information (including the all-important position number, which will be required for the Slave setup) for the database to be replicated. You need to write down that information, which will look something like this:

File: mysql-bin.00002
Position: 230
Binlog_Do_DB: database_to_be_replicated
1 row in set (0.00 sec)

The next step is to retrieve the tables and data from the database to be replicated; in order to do this, the database must be temporarily locked. When the database is locked, it cannot be used, so do this at a time when the database won’t be needed. To lock the database, issue the command FLUSH TABLES WITH READ LOCK;.

You must dump the database that will be copied to the Slave. There used to be a command LOAD DATA FROM MASTER, but that command has been deprecated. So, to get the data, you must do a dump with the command mysqldump -u root -p DATABASE_TO_BE_REPLICATED > DATABASE_TO_BE_REPLICATED.sql where DATABASE_TO_BE_REPLICATED is the name of the actual database being replicated. You’ll be prompted for the MySQL admin password; enter that password, and the dump will process.

Now unlock the tables with the command UNLOCK TABLES; and then quit the MySQL prompt with the command quit.

Copy that database dump file to the Slave (using a USB drive or the scp command) and then restore the database (on the SLAVE) with the command mysql -u root -p DATABASE_TO_BE_REPLICATED < DATABASE_TO_BE_REPLICATED.sql where DATABASE_TO_BE_REPLICATED is the name of the database being replicated.

Configuring the Slave

In order to configure the Slave, open the my.ini file, add the following, and save and close that file:



  • IP_ADDRESS_OF_MASTER is the actual IP address of the Master server.
  • USER is the database administrator with replication privileges.
  • USER_PASSWORD is the password associated with the USER.
  • DATABASE is the name to be replicated.

This next step requires information returned from the SHOW MASTER STATUS; command that was run. Stop the Slave by issuing these commands:

mysql -u root -p (enter the MySQL admin password)


You must run the following command:


Where the following applies:

  • IP_ADDRESS_OF_MASTER is the actual IP address of the Master
  • USER is the MySQL admin user
  • USER_PASSWORD is the password for the USER
  • NUMBER is the Position Number reported from the SHOW MASTER STATUS command.

Restart the Slave by issuing the command SLAVE START; and then exit the MySQL prompt with the command quit. Now you can follow these steps to make sure everything is working:

1. Issue the command mysql -u root -p (enter the database admin password).

2. Issue the command SHOW SLAVE STATUS;.

You should see something like this:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

If all is set to Yes, you now have a working, replicated MySQL database.

Categories: MySQL Tags: ,

Phonegap Media API

July 17, 2012 1 comment

I have done several research on the internet for phone gap media API and finally found.

Here is the Sample Code

<Capability Name=”ID_CAP_MEDIALIB” />
<Capability Name=”ID_CAP_MICROPHONE” />
<Capability Name=”ID_HW_FRONTCAMERA” />
<Capability Name=”ID_CAP_ISV_CAMERA” />
<Capability Name=”ID_CAP_CAMERA” />


<title>Media Example</title>
<script type=”text/javascript” charset=”utf-8″
<script type=”text/javascript” charset=”utf-8″>
function playAudio(url) {
// Play the audio file at url
var my_media = new Media(url,
// success callback
function() {
console.log(“playAudio():Audio Success”);
// error callback
function(err) {
console.log(“playAudio():Audio Error: “+err);

// Play audio;
<a href=”#”
onclick=”playAudio(‘’);“>Play Audio
<a href=”#”
Audio #02</a>

If i click “Play Audio #01”, the wave file plays, next if I try playing “Play Audio #02” it goes in the error section with no details about the error. This happens only for Windows Phone, works for Android.

Categories: Android, PhoneGap Tags: , , , ,

How does HTML5 affect me?

July 10, 2012 Leave a comment

HTML or Hypertext Markup Language is a formatting language that programmers and developers use to create documents on the Web. HTML5 is being developed as the next major revision of HTML.

For most of us, HTML is behind the scenes and not really something we ever think about. However, you may have heard of HTML during the last couple of years as it made national news when Apple refused to support Flash animation in favor of HTML5 on the iPhone and iPad.

How does this affect me?
The booming mobile market is probably the biggest proponent in HTML5’s popularity. While Apple created a stir when they refused to support Flash on their mobile devices, the truth is that most mobile devices either don’t support Flash, or don’t support it well.

HTML5 is largely making its mark on the Internet by overcoming the limitations of Flash and older versions of HTML. Simply put, it is responsible for the enhanced features in videos, audio and graphics that are not as reliant on third-party plug-ins.

To the consumer, this means finding, downloading, or viewing content such as videos will become easier, lighter and quicker. Searching locally will become more reliable as HTML5’s geolocation feature becomes the standard.

For marketers, it means reaching more clients and ensuring a common user experience. Additionally, as more and more browsers become HTML5 compatible, it will mean less programming, fewer updates and less cost to maintain your Web presence.

Will HTML5 replace Flash?
Yes and no. While HTML5 is the future for the vast majority of our interactivity on the Web, Flash still has a niche for complex animations and video games.

For audio and video, HTML5 will largely replace Flash on the Internet as this method does not require the end user to have a third-party plugin. In large part, this has already happened.

Simple animations, image transformations, charting, drag-and-drop, geolocation, 3-D vector graphics, and simple interactivity that once required Flash to achieve are now achievable via HTML5.

Complex animations, video games, and other applications that are too intricate will still require the use of Flash.

How soon should I consider using HTML5?
Immediately. Even though it is still in development and not yet supported in all browsers, it is the future of Web development. Implementation now will require some additional code for browsers without support, but this is a common technique used for outdated browser support.

Firefox, Google Chrome, Opera and Safari are currently supporting most elements of HTML5. For Internet Explorer, limited support for HTML5 began with IE8 and was extended with IE9 – IE10 promises to bring Internet Explorer in line with the other major browsers.

Creating Splash screen / Start up screen for Android app using phonegap / jqtouch

October 18, 2011 8 comments

I’ve recently started working on developing andorid a app using phonegap. I have got my application on andoid phone and I notice that there was black blank screen shows up before showing the main application page. So i have decided to put a splash screen on the app and played in jqtouh but that did not help me.

After lots of searching on the internet I have learned that the changes need to be done the main activity class that inherits from DroidGap and also splash screen support on Android was added in version 0.9.3.
Now here is the simple solution:

1) Create a slash screen with splash.png filename
2) Add splash.png file to drawable-hdpi folder which is under the res folder.
3) the thread super.setIntegerProperty( “splashscreen”, R.drawable.splash ); needed to be added to file in the onCreate method. you should place this thread before “loadURL”. For example:

Here is the method in in the relevant file (src>com.testapp>
/** Called when the activity is first created. */
public void onCreate(Bundle savedInstanceState) {
super.setIntegerProperty("splashscreen", R.drawable.splash);

3) Now run the application.

Hope it works for you also….

Categories: Android, JQTouch, PhoneGap