Tag Archives: blackberry

PhoneGap Explained Visually

I’ve been “out and about” lately, attending tech conferences, meetup groups, and meeting with developers in their offices, and I am getting great feedback on mobile development and PhoneGap. There are some common questions that I am often asked, and I hope this post helps everyone understand PhoneGap better.


Before I go too far, let me attempt to clearly state what PhoneGap is… PhoneGap is an application container technology that allows you to create natively-installed applications for mobile devices using HTML, CSS, and JavaScript.   The core engine for PhoneGap is also 100% open source, under the Apache Cordova project.  You can read more about PhoneGap under my “What is PhoneGap?” & Other Common Questions post.

PhoneGap User Interface

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

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

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

PhoneGap API

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

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

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

PhoneGap Application Packaging and Distribution

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

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

PhoneGap High-Level Application Architecture

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

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

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

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

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

Changes with PhoneGap 1.5

Earlier this month, PhoneGap 1.5 was released.   There were a lot of enhancements in this release.  However, if you’ve tried to update an existing codebase from PhoneGap 1.4 to 1.5, you may have realized that things look a bit different.   Basically, the entire PhoneGap codebase has migrated from PhoneGap naming to Apache Cordova naming conventions.

Every reference to “PhoneGap” is now “Cordova”.  This includes, but is not necessarily limited to:

  • phonegap.js is now cordova.js
  • The “PhoneGap” object in JavaScript is now “Cordova” – this means every reference to “PhoneGap” should now reference “Cordova”
  • In native code, every PhoneGap class that was prefixed with “PG” is now prefixed with “CDV”; for example, “PGPlugin” is now “CDVPlugin”
  • Documentation that refers to the PhoneGap class may be out of date… just switch the name reference.
  • The “PhoneGap” project template in Xcode is now “Cordova”

This is just a naming convention change as the PhoneGap project is moving to its new identity as Apache Cordova.  However, it is just a name.  Be sure to read this article from the PhoneGap team to understand why the name changed and to understand the relationship between “PhoneGap” and “Cordova”.

As a PhoneGap developer, how you build applications has not changed, and the power of PhoneGap/Cordova has not changed.   You can still create awesome apps with it, and it is still 100% open source.

If you are looking at code that doesn’t work in PhoneGap 1.5, then chances are you need to update to use the new naming conventions.

If you are just getting started, be sure to check out my “Getting Started with PhoneGap” guides on Adobe Developer Connection for both Android and iOS – both of these articles use the new naming conventions.

Mobile Web & PhoneGap HTML Dev Tips

Recently I’ve been spending a fair amount of time working on HTML-based applications – both mobile web and mobile applications using PhoneGap.   Regardless of whether you are targeting a mobile web browser or a mobile app using the PhoneGap container, you are still targeting a mobile web browser instance.  If you haven’t noticed, mobile web browsers can often have peculiarities with how content is rendered, or how you interact with that content.   This happens regardless of platform – iOS, Android, BlackBerry, etc…  All have quirks.  Here are a few tips that I have found useful for improving overall interaction and mobile HTML experiences.

Disclaimer: I’ve been targeting iOS and Android primarily, with BlackBerry support on some applications.  I don’t have a Windows Phone device to test with, so I can’t comment on support for the Windows platform.

AutoCorrect and AutoCapitalize

First things first: autocorrect and autocapitalize on Apple’s iOS can sometimes drive you to the brink of insanity.  This is especially the case if you have a text input where you are typing in a username, and it keeps “correcting” it for you (next thing you know, you are locked out of the app).   You can disable these features in web experiences by setting the “autocorrect” and “autocapitalize” attributes of an <input> instance.

Disabled AutoCorrect:
[html]<input type="text" autocorrect="off" autocapitalize="on" />[/html]

Disabled AutoCapitalize:
[html]<input type="text" autocorrect="on" autocapitalize="off" />[/html]

Managing the Keyboard

Have you ever experienced an an app or web site on a mobile device where you have to enter numeric data, and the default keyboard pops up. Before entering any text, you have you switch to the numeric input. Repeat that for 100 form inputs, and try to tell me that you aren’t frustrated… Luckily, you can manage the keyboard in mobile HTML experiences very easily using HTML5 Form elements.

Default Keyboard: Supported Everywhere [html]<input style="width: 400px;" type="text" value="default" />[/html]

Numeric Keyboard: Supported on iOS, Android & BlackBerry (QNX) [html]<input style="width: 400px;" type="number" value="numeric" />[/html]

Numeric Keyboard: Supported on iOS [html]<input style="width: 400px;" type="text" pattern="[0-9]*" value="numeric" />[/html]

Phone Keyboard: Supported on iOS [html]<input style="width: 400px;" type="tel" value="telephone" />[/html]

URL Keyboard: Supported on iOS & BlackBerry (QNX) [html]<input style="width: 400px;" type="url" value="url" />[/html]

Email Keyboard: Supported on iOS & BlackBerry (QNX) [html]<input style="width: 400px;" type="email" value="email" />[/html]

Disable User Selection

One way to easily determine that an application is really HTML is that everything on the UI is selectable and can be copied/pasted – Every single piece of text, every image, every link, etc… Not only is this annoying in some scenarios (and very useful in others), but there may be instances where you explicitly don’t want the user to be able to easily copy/paste content. You can disable user selection by applying the following CSS styles. Note: This works on iOS, and partially works on BlackBerry/QNX for the PlayBook. It did not work on Android in my testing.

* {
-webkit-touch-callout: none;
-webkit-user-select: none;

The -webkit-touch-callout css rule disables the callout, and the -webkit-user-select rule disables the ability to select content within an element. More details on webkit css rules from the Mobile Safari CSS Reference. More detail about disabling copy/paste on iOS is available at StackOverflow.com.

Disable Zoom

If you want your content to feel like an app instead of a web page, then I strongly suggest that you disable gestures for pinch/zoom and panning for all use cases where pinch/zoom is not required. The easiest way to do this is to set the viewport size to device-width and and disable user scaling through the HTML metadata tag.

[html]<meta name="viewport" content="width=device-width, user-scalable=no" />[/html]

You can read further detail on the viewport metadata tag from the Apple Safari HTML Reference, or the Mozilla reference.

On a Phone? Integrate With It

Your application can dial phone numbers very easily. Just use a standard web location, but use the “tel:<phonenumber>” URI format.

Test it with Apple Customer Support: 800-275-2273[html]<a href="tel:800-275-2273">800-275-2273</a>[/html]

This technique works on both Android and iOS devices, and I assume other platforms. However, I don’t have the devices to test all of them.

Touch Based Scrolling

Touch-based scrolling is critical to having an application that feels native. I dont mean that the whole page should be able to scroll… Your browser will be able to take care of that alone. Instead I mean that you should be able to scroll individual elements so that they mimic clipped views, lists, or large blocks of content. You should be able to scroll content where it is, and not have to scroll an entire page to reveal something in only one area of the screen. You should minimize scrolling when it may cause poor UX scenarios. This is especially the case in tablet-based applications which have a larger UI than phone-based applications.

Luckily, this is also really easy. I personally prefer the open source iScroll JavaScript library from cubiq.org. iScroll works really well on iOS, Android and BlackBerry – I haven’t tested other platforms, but you can test them out yourself: http://code.google.com/p/iscroll-js/source/browse/#hg%2Fexamples%2Fcarousel

Remove “click” Delays

“Click” events on HTML elements on mobile devices generally have a delay that is caused by the operating system logic used to capture gestural input based on touch events. Depending on the device, this could be 300-500 MS. While this doesn’t sound like much, it is very noticeable. The workaround is to use touch events instead of mouse events: touchStart, touchMove, touchEnd. You can learn more about touch events from html5rocks.com. There’s also a great script from cubiq that adds touch events for you to optimize the experience for onClick event handlers on iOS devices.

Add To Home Screen

If you want your web app to fee like a real app and take up the full screen without using PhoneGap as an application container, then you can always add it to the device’s home screen. Although this can only be done manually through the mobile browser, there are a few open source scripts to guide the user through this processs: cubiq.org or mobile-bookmark-bubble should get you started.

Use Hardware Acceleration

Animations will generally be smoother and faster if your content is hardware accelerated (and the device supports hardware acceleration). You can make html elements hardware accelerated just by adding the translate3d(x,y,z) css style to the element (be sure to set all three x, y, and z attributes otherwise hardware acceleration may not be applied. If you don’t want any translation changes, you can use the translate3d CSS rule with all zero values: translate3d(0,0,0).
[css]transform: translate3d(0,0,0);
-webkit-transform: translate3d(0,0,0);[/css]

In your development/testing, you can even visualize which content is hardware accelerated in both desktop and mobile Safari using the technique shown at http://mir.aculo.us/.

Make You Apps Fast

Last, but certainly not least, make your apps fast. Follow best practices, and be efficient in code execution and the loading of assets (both local and remote). Here are a few links to get you going in the right direction:

I hope these get you moving in the right direction! If you have read this, and aren’t sure what it all means, check out the Adobe Developer Connection to ramp up on HTML5, or theexpressiveweb.com to see what HTML5 & CSS3 can do.

Interesting App Store Statistics

Here are some interesting and quite surprising statistics for the US Census Browser HTML/PhoneGap showcase application that I released in December, which I wanted to share. The app is a browser for US Census data, full detail available here: http://www.tricedesigns.com/2010-census/. The Census Browser application was intended as a showcase app for enterprise-class data visualization in HTML-based applications, and all source code is freely available to the public.

What is really surprising is the “health” of my app within the given ecosystems. I offered the app as a free download in each market. The app is focused on Census data, so there is obviously not a ton of consumer demand, however the data is still interesting to play around with. I would not expect the same results for all types of apps in all markets.

Here are a few observations from the data:

  • Barnes & Noble Nook downloads far exceeded all other markets combined (69% of all downloads)
  • BlackBerry Playbook downloads were in 3rd, just behind iOS (BB is 11% of all downloads)
  • Android traffic was minimal (2% of all downloads)

The general public perception/assumption that I encounter is that the iOS market is strongest, followed by Android, and that BB is dead. These numbers show a conflicting reality. Barnes & Noble was the strongest, with iOS in second place, and BlackBerry just behind iOS.

Here is the full data for downloads in December:

Market Release Date # Downloads Link Notes
iOS 12/4/11 1151 link (iPad only)
Android (Google) 12/6/11 58 link (large-xlarge screens only)
Android (Amazon) 12/6/11 63 link (includes Kindle Fire)
BlackBerry 12/14/11 752 link (PlayBook only)
Barnes & Noble 12/20/11 4508 link (Nook)

Other Observations

Here are a few other observations from analyzing the download statistics for the various app markets…

Lots of people got Nook devices for Christmas this year:

BlackBerry Playbook downloads spiked from the BerryReview.com app review:

iOS traffic peaked just after the inital release with an increase after the winter holidays, but has been more-or-less consistent with no “spike”:

Amazon Market only had 8 downloads on Christmas day – this is likely the result of the fact that the Kindle Fire is branded as a consumer media device, not an analytics/computing device:

Know what else is interesting?   The charting/analytics for Amazon, Google, and Nook markets are all built with Adobe Flash, with both Amazon and Nook built using Adobe Flex.

Why Cross Platform Mobile Development?

Perhaps you have heard of the topic “cross platform development”, but aren’t really sure what it is, or you aren’t sure why you would want to use cross-platform technologies. If this is the case, then this post is especially for you. I’ll try to shed some light onto what it is, and why you would want to use cross-platform development strategies.

What is cross-platform development?

Cross platform development is a concept in computer software development where you write application code once, and it runs on multiple platforms. This is very much inline with the “write once, run everywhere” concept pioneered in the 90s, and brought to a mainstream reality with Flash in the browser, and AIR on the desktop. The standard evolution of technology has been to make everything faster, smaller, and more portable, and it is only natural that that this concept has now come into the mobile development world. In mobile scenarios, it is applied by writing an application using a codebase & technology that allows the application to be deployed and distributed across multiple disparate platforms/operating systems/devices.

Using Adobe AIR, this includes Apple’s iOS devices (iPhone and iPad), Android (a plethora of devices), BlackBerry Playbook & upcoming BBX platform, and soon Windows Metro (the tablet offering of Windows 8).   Using PhoneGap, this includes Apple iOS, Android, BlackBerry 4.6 and higher, HP WebOS, Symbian, Samsung Bada, and Windows Phone 7 – Mango platforms.

In case you’re wondering why I offered 2 cross platform technologies, that is because Adobe will soon have 2 cross-platform product offerings.  Adobe has entered an agreement to purchase Nitobi, the creators of PhoneGap.

Adobe AIR

Adobe AIR is a cross-platform technology with roots in the Flash Player and the AIR desktop runtime.  AIR allows you to build cross-platform mobile applications using ActionScript and the open source Flex framework.   AIR apps can be built from the Flash Professional timeline-based design/animation tool, Flash Builder (an Eclipse-based development environment), or other open source solutions using the freely available AIR SDK.   Applications developed with Adobe AIR can target desktop platforms (Mac, & Windows), smart phone and tablet platforms (iOS, Android, BlackBerry, soon Windows), and even smart televisions.

PhoneGap (Apache Callback)

PhoneGap is an open source cross platform technology with roots in the HTML world. Essentially, a PhoneGap application consists of a web view that consumes 100% of the available width & 100% of the available height, taking advantage of web browsers on each platform.   PhoneGap offers a JavaScript to native bridge that enables you to build natively-installed applications using HTML and JavaScript, using the native bridge to interact with the device hardware/APIs.   Note: PhoneGap is also being submitted to the Apache Foundation as the Apache Callback project.

More Devices, Less Code

The driving factor behind cross-platform technologies is that you will be able to use those technologies to target more devices & platforms, with writing a minimal amount of source code.   There are many advantages with this approach.  Here are a few of the major reasons…

Lower Barrier of Entry

Generally speaking, development with HTML & JavaScript or Flex & ActionScript is easier than developing with Objective-C or Java.   Due to the ease of use of the development tooling and familiarity of the languages, cross platform technologies lower the technical barriers which may have prevented adoption of native development.  This allows your development team to build applications that they may not previously have been able to, and also enables your team to focus on what matters – the application; not the skills required to develop on multiple disparate platforms.

Reduce the Number of Required Skills for the Development Team

Native development on multiple platforms requires your development team to learn Objective C for iOS applications, Java for Android applications, Silverlight for Windows Phone applications, etc…   Finding all of these skills in a single developer is nearly impossible.   Using cross-platform development technologies, your team only needs to be proficient with one language/skillset.  Knowledge of the native development paradigms and languages are always a plus, but are no longer a requirement.   Many developers transitioning from web development already know either Flex/ActionScript and/or HTML/JavaScript, and making the transition from web to mobile development will not be a major undertaking.

Reduced Development & Long Term Maintenance Costs

Cross-platform mobile applications can originate from a single codebase, which requires a single development skillset.  You don’t need to have staff for each individual platform.  Instead, resources working on the shared codebase can cover all target platforms.   Having a single codebase also reduces long term maintenance costs.  You no longer need to have bug tracking for X number of codebases, and do not need to maintain a larger staff to support each platform.  Did I also mention that you have one codebase to maintain?

Having a single codebase doesn’t reduce the need for QA/testing on each target platform – nothing can get rid of this.  It is absolutely imperative that you test your codebase on physical devices for all platforms that you intend to support.   Emulators and Simulators can go a long way during development, but they will undoubtedly not cover all scenarios possible on a physical device, and they will not have the same runtime performance as a physical device.

Play the Strengths of a Technology

Some technologies make tasks easier than others.   For example, programmatic drawing and data visualization are very easy using Flex & ActionScript.   Developing equivalent experiences in native code can be significantly more complex and time consuming.   Use the the features of the language to their fullest potential, to your advantage- that’s why they exist.