Category Archives: Windows Phone

UX & Mobile Apps Leveraging the IBM MobileFirst Platform

When you are developing a mobile app (or website, or mobile web, or TV app, etc..) you should always ask yourself “What kind of an impact does this have on the end user?” It doesn’t matter whether you are creating enterprise apps or games, or anything in between. Every development decision that you make should be weighed upon it’s impact to the overall impact it has on the end user. Simply put: if your app sucks, nobody is going to want to use it.

When building mobile apps using IBM MobileFirst you have two options for a user interface layer; you can write a native app, or you can write a hybrid app using HTML, CSS, & JavaScript.

Native VS HTML Hybrid

So, what kind of an impact does the addition of IBM MobileFirst have on the app?

NONE, granted the app’s UX can vary depending upon whether you are developing a native app or a hybrid app.

IBM MobileFirst Platform Foundation is a platform that consists of a server tier and client-side SDK. If you are developing a native app, the SDK/API provides access to MobileFirst platform features, like user authentication, app version management, data access through adapters, encrypted storage, unified push notification, remote log collection, and more. If you are developing a hybrid app, the app’s UX must be developed complete inside of the web view container. The MobileFirst Foundation SDK provides additional functionality just like mentioned above for the native SDK, plus a few classes that enable native dialogs and a few native UI elements, but for the most part, there is very, very minimal impact on the user’s experience.

When building any kind of mobile app, regardless of whether it is native or hybrid, you need to pay attention to what the user experiences. Are you following human interaction or design guidelines for the platform? Are you forcing your user to go through unnecessary or redundant steps? Are you making forms more complex than they need to be? Are you forcing multiple taps for a simple interaction? Can things be simplified?

The IBM MobileFirst Platform does not add any additional overhead for UX processes.

The IBM MobileFirst platform can be used to develop native apps on iOS, Android, Windows Phone, or Java ME platforms. Follow native coding conventions and UX guidelines for each individual platform. Make sure you follow these guidelines, otherwise your app may feel alien within the ecosystem, or may be rejected from app store approval altogether.

What should you think about when building a hybrid app leveraging IBM MobileFirst?

First, it depends on your hybrid approach. If you are using the for Xamarin hybrid approach for MobileFirst apps, then your considerations will be much like writing a native app.

If you are using the HTML/CSS/JavaScript approach (leveraging the Apache Cordova container), then you really want to focus on the user’s experience inside of the HTML container. You want to make sure the UI feels like “an app”, not like “a web page”. There are many client-side frameworks that help address this need. Feel free to use any of them, or roll your own – just keep the UX/human interaction guidelines in mind.

(this is by no means an exhaustive list, there are more out there)

Make sure you’re building for touch interactivity, addressing animations correctly to minimize browser reflow operations, and more… Read this post on Dzone that I wrote last year for a lot more detail on performance considerations for hybrid or mobile web apps.

If you are using any of these (or none of these), also don’t forget an architectural pattern/framework for helping keep your code organized and consistent. Read this post on hybrid/web app architectural patterns and considerations for even more detail.

For both native and hybrid approaches, you also want to consider impacts of perceived performance vs actual raw processing  power. These techniques deliver the appearance that the app is fast and responsive, instead of sluggish or locked while waiting to perform an action. Perceived performance improvements can be achieved simply by providing instant feedback, performing animations during an asynchronous request, or preemptive tasking. Don’t miss this post, where I go into perceived performance in mobile apps in great detail.

 

Strategies for Managing App Versions & Updates With IBM MobileFirst Foundation (aka Worklight)

IBM MobileFirst Foundation provides two mechanisms to manage app versions and updates.  Neither requiring you to write any additional code!

The first is app versioning; MobileFirst Foundation tracks each version of an app that you deploy, and gives you the ability govern or restrict access to specific platforms and versions. App versioning applies to all apps, native or hybrid, on any platform that MobileFirst Foundation supports. The second is Direct Update, which allows you to push new HTML/CSS/JavaScript (web) resources to a MobileFirst hybrid app. Direct Update only applies to hybrid apps, but it works for any platform that MobileFirst supports.

App Version Management

When you deploy an app to the MobileFirst Foundation server, the server will automatically track versions based on the version number specified in you application-descriptor.xml file.

Set Application Version
Set Application Version

When you load the MobileFirst Foundation Server Console, you’ll be able to view all of the deployed app platforms and versions.

The screenshot below shows a hybrid app deployed for both Android and iOS platforms. You would also be able to see the exact same version and platform information for native apps that leverage IBM MobileFirst Foundation.

Managing Versions in the MobileFirst Console (click to enlarge)
Managing Versions in the MobileFirst Console (click to enlarge)

You’ll notice in the MobileFirst console that next to each platform/version you can set the status for that version. This makes it possible to set notification messages for users on specific platforms and versions, or even restrict access to specific platforms and versions.

For example, look at the screenshot above… Version 1.0 on Android is active. Version 1.2 on iOS is active. Version 1.1 on iOS is notifying, and Version 1.0 on iOS is disabled.

There are 3 statuses that can be set for each platform and version combination.: Active, Active Notifying, and Access Disabled.

Set Platform/Version Status
Set Platform/Version Status

When you set the status of a platform/version, this status is only for that specific platform/version pair. This enables you to selectively notify users of specific versions, or even block access to specific versions if they are outdated and no longer supported.

“Active” means that the application is active. Services to this version will operate normally, and no messages will be presented to the user.

“Active Notifying” means that the application is active, services will continue to work, but a message will be presented to the user when the app becomes active, or when a service request is made to the MF server.

Setting Active Notification Message
Setting Active Notification Message

This can be used to send any text-based message to the app users. This could be a deprecation notice, service maintenance notice, or any other general notice.

Within the app, the user will see a message when the app becomes active, or when a request is made to the server. This message can be dismissed, and the app functionality is not impacted in any way.

In-App Active Notification Experience
In-App Active Notification Experience

“Access Disabled” means that access to the application is disabled. In this state, a notification message will be presented to the user, and access from the app version will be disabled. The user will also be presented with an “Upgrade” button, which will redirect the user to any URL, which presumably will be for an updated version of the app.

Setting Disabled Status
Setting Disabled Status

In this state, the app will not be granted access to the MobileFirst/Worklight server. So, if your app requests data from a data adapter, all requests to the adapter from this platform/version will be blocked. If your app initialization code is inside of the Worklight client’s connect:onSuccess handler, then this can prevent your app from loading at all.

In-App Disabled Experience
In-App Disabled Experience

Again, When you set the status of a platform/version, this status is only for that specific platform/version pair.

You can learn more about managing applications through the MobileFirst/Worklight Console using the Administering Worklight applications with Worklight Console online documentation.

Direct Update

MobileFirst hybrid applications leverage Apache Cordova plus MF-specific APIs as a foundation to deliver hybrid apps. Apache Cordova enables developers to build natively-installed cross platform apps using web technologies.

Direct Update is a feature for MobileFirst hybrid apps, which enables you to push updated app content (HTML, CSS, & JavaScript) without the user having to deploy a new version of the app through the app store.

Direct Update is considered an additional security feature b/c it enforces users to use the latest version of the application code. However, when an app uses Direct Update, it *only* updates the web resources.  No native changes or version # changes will be applied. However, it should not be abused. In particular this will bypass the Apple’s app store approval process. You should not overhaul the entire UI and break Apple’s Human Interaction Guidelines, otherwise you could be kicked out of the app store.

Direct Update User Experience
Direct Update User Experience

By default, the update’s user experience is a modal overlay that shows download and installation progress. The updater’s UX can be configured to use silent updates that do not block the user’s experience, can be a completely custom user experience, or can be disabled altogether.  Updates can also be paused or resumed using the JavaScript API so that it does not block the user from performing a critical task, however this would require a custom UI – the default UI does not enable pause/resume.

Updates in the current version of Worklight (6.2) are complete updates containing the entire application (www) code, however MobileFirst Foundation 6.3 (coming this month) will have a Differential Direct Update feature that includes only the changed files. More detail will be posted once this is available.

Direct Update can also be disabled if you don’t want your hybrid apps to update automatically.

For more information on Direct Update, be sure to check out these additional resources:

Additional note:  If you’re wondering by I interchange MobileFirst and Worklight in this post, it’s because Worklight is now MobileFirst Platform Foundation

So, What is IBM MobileFirst?

I’m still “the new guy” on the MobileFirst team here at IBM, and right away I’ve been asked by peers outside of IBM: “So, what exactly is MobileFirst/Worklight?  Is it just for hybrid apps?”

In this post I’ll try to shed some light on IBM MobileFirst, and for starters, it is a lot more than just hybrid apps.

MobileFirst-Logo

IBM MobileFirst Platform is a suite of products that enable you to efficiently build and deliver mobile applications for your enterprise, and is composed of three parts:

IBM MobileFirst Platform Foundation

IBM MobileFirst Platform Foundation (formerly known as Worklight Foundation) is a platform for building mobile applications for the enterprise.  It is a suite of tools and services available either on-premise or in the cloud, which enable you to rapidly build, administer, and monitor secure applications.

The MobileFirst Platform Foundation consists of:

  1. MobileFirst Server – the middleware tier that provides a gateway between back-end systems and services and the mobile client applications.  The server enables application authentication, data endpoints/services, data optimization and transformation, push notification management (streamlined API for all platforms), consolidated logging, and app/services analytics. For development purposes, the MobileFirst server is available as either part of the MobileFirst Studio (discussed below), or as command line tools.

  2. MobileFirst API - both client and server-side APIs for developing and managing your enterprise mobile applications.
    • The server-side API enables you to expose data adapters to your mobile applications – these adapters could be consuming data from SQL databases, REST or SOAP Services, or JMS data sources. The Server side API also provides a built-in security framework, unified push notifications (across multiple platforms), and data translation/transformation services. You can leverage the server-side API in JavaScript, or dig deeper and use the Java implementation.
    • The client-side API is available for native iOS (Objective-C), native Android (Java), J2ME, C# native Windows Phone (C#), and JavaScript for cross-platform hybrid OR mobile-web applications. For the native implementations, this includes user authentication, encrypted storage, push notifications, logging, geo-notifications, data access, and more.  For hybrid applications, it includes everything from the native API, plus cross-platform native UI components and platform specific application skinning.  With the hybrid development approach, you can even push updates to your applications that are live, out on devices, without having to push an update through an app store.  Does the hybrid approach leverage Apache Cordova?  YES.

  3. MobileFirst Studio - an optional all-inclusive development environment for developing enterprise apps on the MobileFirst platform.  This is based on the Eclipse platform, and includes an integrated server, development environment, facilities to create and test all data adapters/services, a browser-based hybrid app simulator, and the ability to generate platform-specific applications for deployment.  However, using the studio is not required! Try to convince a native iOS (Xcode) developer that they have to use Eclipse, and tell me how that goes for you… :)  If you don’t want to use the all-inclusive studio, no problem.  You can use the command line tools (CLI).  The CLI provides a command line interface for managing the MobileFirst server, creating data adapters, creating the encrypted JSON store, and more.

  4. MobileFirst Console – the console provides a dashboard and management portal for everything happening within your MobileFirst applications.  You can view which APIs and adapters have been deployed, set app notifications, manage or disable your apps, report on connected devices and platforms, monitor push notifications, view analytics information for all services and adapters exposed through the MobileFirst server, and manage remote collection of client app logs.  All together, an extremely powerful set of features for monitoring and managing your applications.

  5. MobileFirst Application Center - a tool to make sharing mobile apps easier within an organization.  Basically, it’s an app store for your enterprise.

MobileFirst Platform Application Scanning

MobileFirst Platform Application Scanning is set of tools that can scan your JavaScript, HTML, Objective-C, or Java code for security vulnerabilities and coding best practices.  Think of it as a security layer in your software development lifecycle.


MobileFirst Quality Assurance

MobileFirst Quality Assurance is a set of tools and features to help provide quality assurance to your mobile applications.  It includes automated crash analytics, user feedback and sentiment analysis, in-app bug reporting, over-the-air build distribution to testers, test/bug prioritization, and more.


So, is MobileFirst/Worklight just for hybrid (HTML/JS) apps? You tell me… if you need clarification more information, please re-read this post and follow all the links.  ;)

 

Video: Native vs. Hybrid vs. Web

Here’s a video from the “What Developers Love and Hate about iOS, Android, Windows and HTML5″ panel discussion that I took part in during MoDev East back in December.  The panelists represented native app developers, HTML/web developers, and myself-representing the HTML/hybrid app paradigm.


I thought it was a great discussion, and nearly everyone acknowledged the benefits of choosing a hybrid solution such as PhoneGap. (That’s me in the brown jacket.)

Enjoy!

My Workflow for Developing PhoneGap Applications

I am asked all the time “How do I get started developing PhoneGap applications?”. My normal answer is to advise people to check out the PhoneGap Getting Started Guides, which provide a great starting point for every platform. However after further thought, I’m not sure this is always what people are asking. Rather than “how do I get started?”, I think people are often looking for insight into the workflow for developing PhoneGap applications. Everything from tools to developer flow, to getting the app on devices. The Getting Started Guides are essential for setting up the initial project structure, but once you get that setup, you might be wondering “what do I do next?”. In this post, I’ll try to shed some light on the workflow and tools that I use when developing PhoneGap applications.

Know What You’re Going To Build Before You Build It

First and foremost – it is essential to have at least some kind of idea what you are going to build before you build it. If you just start hacking things together without a plan, the final result is seldomly great. Complete (pixel perfect) UI/UX mockups are fantastic, but you don’t have to have a fully polished design and screen flow. Just having wireframes/sketches are a great start. Heck, even a sketch on a napkin is better than starting with nothing.

The UX design/wireframes help you understand what you application should be doing from the user’s perspective, which in turn helps you make decisions on how you tackle a project. This can be purely from a HTML level, helping you figure out how you should position DOM elements and/or content. Or, it can help you gauge your project’s technical complexity – How many “moving parts” do you have, how much of the app is dynamic or asynchronus, or how do different visual elements need to work together? You can leverage this design/mockup to analyze the needs of your application and determine if a particular framework/development methodology is a best fit (Bootstrap, Backbone.js, Knockout.js, Sencha, jQuery Mobile, Angular.js, etc…).

When working with a designer, I use Adobe’s Creative Suite Tools for pretty much everything – wireframes, UI/UX designs, chopping up assets, etc… I’m currently working on a project that was designed by the talented Joni from Adobe XD. Joni designed everything in Creative Suite, and I’m using Photoshop to view screen flows and extract UI assets for the actual implementation.

UI Mockups in PhotoShop
UI Mockups in Photoshop
PS-ScreenFlow
Screen Flow in Photoshop

Note: This app will also be free and open source as a sample/learning resource for PhoneGap, including all of the design assets – I’ll follow up with another post on this later, once the app is available in the app stores.

If you aren’t a “graphics person”, or don’t have creative suite, there are a bunch of other tools that you can use for wireframing and/or sketching (but c’mon, Creative Cloud is only $50 a month). Here are several I’ve used with great success, but this is not a comprehensive list at all:

  • OmniGraffle – A drag & drop wireframing tool for OS X. This is fantastic for wireframing or documenting screen flows. In fact, the screen flow image shown in Photoshop above was originally composed in Omnigraffle, using the mockups created in Photoshop.
  • Visio – A powerful drag & drop wireframing/design tool for Windows – much like OmniGraffle, but for windows.
  • PowerPoint or Keynote – These aren’t just for presentations. They can be really useful for putting together screen flow diagrams, or annotating images/content.

Often people like to sketch out ideas & wireframes on their tablets, here are a few tools that I use for that:

  • Adobe Touch Apps – Adobe Ideas can be great for digitally sketching ideas.
  • iBrainstorm – A great app for collaboratively taking notes and sketching. I’m partial to this one b/c used to be on the dev team, and I wrote a good chunk of the graphics sketching logic.

There are a bunch of other tablet sketching apps out there, but I haven’t used most of them.

Coding Environment

Coding environments are a tricky subject. There is no single solution that meets the exact wants and needs for everyone. Some people chose lightweight text editors, some people chose large-scale IDEs, some people use designer-centric tools, and many of these choices are dependant upon which operating system you use or your background as a designer or developer. Since PhoneGap applications are really just editing HTML, CSS & JavaScript, you can use whatever editor you want. In fact, I know a several people that use vim as their primary editor.

Large-Scale IDEs

I’m a bigger fan of of using a complete IDE (integrated development environment) than I am of a lightweight editor, simply b/c IDEs tend to have hooks into more features/languages, etc… I know people complain about startup time, but there is no startup time if you leave it open all the time. :)

There are a few catches when talking about IDEs with PhoneGap. The first is that if you want to deploy anything locally to devices (without using PhoneGap Build), you have to delpoy using the IDE for the particular platform that you are targeting. That means Xcode for iOS, Eclipse for Android, or Visual Studio for Windows Phone, etc… However if you wish, you can use your editor of choice, and just use the IDE to deploy to devices locally. You can even share source code across several IDE installations using symlinks (which I describe here). I very often use this type of a configuration to share code between Xcode, Eclipse, and WebStorm.

My preference for coding PhoneGap applications is to use WebStorm by JetBrains. WebStorm has great code-hinting (even for your own custom JS and 3rd party libraries), great refactoring, hooks into Git, CVS, or SVN repositories, and is a very mature IDE.

WebStorm IDE
WebStorm IDE

I tend to use this as my primary coding tool, then switch to Eclipse or Xcode when I want to locally deploy to a device for testing. When using PhoneGap Build to simplify cross-platform compilation, I just push the code to git, then recompile via PhoneGap Build.

I’m not a fan of Xcode’s HTML/JS editing, and haven’t found an HTML/JS plugin for Eclipse that I really like. To target Windows devices, I use Visual Studio.

Lightweight Editors

I’m a bigger fan of larger IDEs than lightweight editors, but Adobe Edge Code (also known as Brackets) is a great lightweight editor for quick edits. Edge Code/Brackets is an open source HTML/JS editor that supports live editing in the browser and inline editors for CSS styles, without leaving your HTML files. If you tried Edge Code Preview 1, but weren’t sold on it, you should try Edge Code Preview 2. The team has come a long way very quickly. It’s fast, easy to use, and there is a plugin to tie it into PhoneGap Build. I sometimes use this for quick edits.

Adobe Edge Code
Adobe Edge Code

Edge Code/Brackets also has a thriving open source project, and encourages you to get involved and help contribute.

There are tons of other lightweight editors out there, and everyone has their favorite. As long as you’re happy with the tool, and it can edit text (HTML, CSS, JS) files, you can use it to build PhoneGap applications.

Designer-Friendly Editors

I’m not necessarily the primary target for Dreamweaver, but it has some nice features. Dreamweaver gives you a great programming environment plus a WYSIWYG editor for HTML experiences. It also features PhoneGap Build integration directly inside the coding environment. If you’re used to Dreamweaver for creating web experiences, you can continue to use it and target mobile apps as well.

Adobe Dreamweaver
Adobe Dreamweaver

Debugging Environments

Yes, that is plural… Debugging Environments. Due to the cross-platform nature and PhoneGap’s leveraging of native web views for each platform, debugging PhoneGap applications can sometimes be tricky. Here are some tips that will make this significantly easier.

The PhoneGap Emulator

The PhoneGap Emulator is my primary development/debugging tool for all PhoneGap apps. It is a browser-based emulator leveraging the Google Chrome browser and the Ripple Emulation Environment. The PhoneGap Emulator runs inside of Google Chrome, and provides emulation of PhoneGap’s core APIs. Since it is built on top of Chrome, it enables you to leverage Chrome’s Developer Tools, which in my opinion are second to none for web/application development. This is a highly-productive developer environment.

PhoneGap Emulator in Google Chrome
PhoneGap Emulator in Google Chrome

Here’s why I like the PhoneGap/Ripple/Google Chrome development environment:

First, this combination enables you to emulate most core PhoneGap APIs without leaving the desktop environment. It enables you to test various APIs including geolocation (with simulated locations), device events (deviceready, back, etc…), sensor events (accelerometer, compass), and even let’s you test with different device aspect ratios – all without having to push anything to an actual device. This saves a lot of time in development iterations. You can read about the supported Ripple emulator features here.

Second, Chrome’s Developer Tools are awesome. Here are just a few things that you can do while developing/debugging your app, live within the emulation environment:

  1. Alter DOM and CSS at runtime via the elements panel.
  2. Analyze all resources consumed by your app, via the resources panel. This includes all scripts, images, html files, cookies, etc… it even includes insight into any local data stored via PhoneGap’s local storage database (WebSQL implementation).
  3. View/query all local databases within your app. You can write your own queries to view/alter data in the WebSQL database. Thanks to Ray for sharing this, it’s not immediately intuitive.

    Debugging Local Storage Databases in Chrome with SQL
    Debugging Local Storage Databases in Chrome with SQL
  4. Analyze network requests/utilization via the network panel.
  5. Debug JavaScript with the Scripts/Sources Panel. You can set breakpoints in JS execution, inspect & alter values in JS objects in-memory, and view details and line numbers for any exceptions that occur.
  6. Monitor function execution time, memory consumption, event listeners, and frame rendering time via the timeline panel.

    Chrome Timeline Panel
    Chrome Timeline Panel
  7. Profile CPU/Memory usage via the profiles panel.
  8. Use the console to monitor console.log() statements, inspect properties of objects in memory, or execute arbitrary JavaScript whenever you want.

The PhoneGap Emulator enables developers to be extremely productive with development, however I cannot emphasize enough that on-device testing is critical for having a successful app. On-device testing can expose performance problems or browser rendering variances that you may not notice in the emulator environment.

On-Device Remote Debugging

As I mentioned above, on-device testing is critical for successful applications. iOS and BlackBerry have an advantage over other platforms b/c the latest developer tools allow you to remotely debug content live on a device.

Since the release of iOS 6, you can debug content in the iOS simulator using Safari’s Developer Tools. Safari’s developer tools give you many of the same debugging capabilities that I mentioned above for Chrome.

To debug an app running in the iOS simulator, just go to Safari’s “Develop” menu, select “iPhone Simulator”, then select your app’s index.html file.

Connect Remote Debugging
Connect Remote Debugging

You’ll end up with a full remote debugging experience, just like if you were debugging inside the Safari browser, complete with JS breakpoints, DOM inspection, etc…

Remote Debug iOS Simulator with Safari
Remote Debug iOS Simulator with Safari

The process to remotely connect to a live app running on an external iOS device is very similar. Just follow the instructions here, under the “Remote Debugging” section, and you will be up and running very quickly.

The latest BlackBerry devices also have the same remote debugging capability (since it is all actually based on the webkit engine). You can view detailed instructions how to remotely debug PhoneGap apps on BlackBerry devices here.

Remote Debugging with Weinre

Not every platform supports live remote debugging, especially older versions. Weinre (pronounced winery) is a remote web inspector that allows you to inspect/edit DOM and CSS elements on remote devices. Basically, you include some JavaScript in your app, and it communicates back to a server that will tell you whats happening inside of the app running on the mobile device. It won’t give you full debugging capabilities like JS breakpoints and memory inspection, but it’s better than nothing. You can use Weinre by setting up your own instance, or by leveraging debug.phonegap.com.

Weinre for On-Device Debuggin
Weinre for On-Device Debugging

When All Else Fails

If you’re still debugging your apps, and the solutions mentioned above don’t work, you can always resort to plain-old “alert()” statements to pop up debug messages, or use “console.log()” statements to write to system logs.

On Android, all console.log('...'); messages will appear as printouts in the command-line tool logcat, which is bundled with the Android SDK and integrated into the Android Eclipse plugin.

On BlackBerry, all console.log('...'); are printed to the BlackBerry’s Event Log. The Event Log can be accessed by pressing ALT + LGLG.

On iOS, all console.log('...'); are output to the Xcode Debug Area console.

Read more about debugging PhoneGap apps here.

Building PhoneGap Apps

The PhoneGap getting started guides will point you to the right direction for getting started with a particular platform. If you are just targeting iOS, you can use Xcode for building. If you are just targeting Android, you can use Eclipse, etc… It is all very easy to get up and running.

However, this process gets much more complicated when targeting multiple platforms at once. When I have to do this, PhoneGap Build becomes really, really handy.

Build-Bot-Preview

PhoneGap Build allows you to either upload your code, or point to a Git repository. PhoneGap Build will then pull your code and build for 7 different platforms, without you having to do anything special or setup multiple environments. All that you’ll have to do is install the cloud-compiled binaries on your device. You can do this by copying/pasting a URL to the binaries, or by capturing a QR code that will directly link to the compiled application binary.

One other advantage of PhoneGap build is that it lets designers/developers build mobile applications without having to install any developer tools. If you want to compile a PhoneGap app for iOS, but are on Windows – just use PhoneGap build and you won’t need Xcode or a Mac.

Check out the PhoneGap Build FAQ for more detail about how exactly it works.

PhoneGap UI/Development Frameworks

Probably the most common PhoneGap question that I get asked is “what MVC/development framework should I use?”. If you’ve been waiting for me to answer this, don’t hold your breath. It is impossible to be prescriptive and say that one solution fits all use cases for every developer.

When people ask me this, I like to paraphrase Brian Leroux from the PhoneGap team: “Use HTML, it works really well.”

I think people often overlook the fact that PhoneGap’s UI renderer is a system web view. Anything that is valid HTML/CSS content can be rendered as your application’s user interface. This could be something incredibly simple, like text on the screen, or it could be incredibly creative or complex. The important factor is that you need to focus on a quality user experience. If you’re worried about your UX, and are worried that Apple may reject your app, then read this article where I explain Apple rejections in detail.

HTML/JS developers come from many different backgrounds, with varying degrees of programming expertise. Some frameworks appeal to some people, other frameworks appeal to other people. There also seem to be new UI & architectural frameworks popping up every week. It would be a disservice to all people who use PhoneGap for us to proclaim that we should only use one singe framework.

If you are interested in UI frameworks, take a look at these:

If you are interested in architectural patterns, take a look at these.

There are lots, and lots, and lots more options out in the HTML/JS development world… I’m not even taking into account JavaScript generating tools and languages like CoffeeScript, TypeScript, or others…

Hopefully this helps get you on the right track.

Enjoy!