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.
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.
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.
IBM MobileFirst Foundation provides two mechanisms to manage app versions and updates. Neither requiring you to write any additional code!
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.
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.
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.
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.
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.
“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.
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.
Again, When you set the status of a platform/version, this status is only for that specific platform/version pair.
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 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.
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:
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:
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.
MobileFirst API - both client and server-side APIs for developing and managing your enterprise mobile applications.
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.
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.
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.
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.)
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.
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:
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.
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.
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.
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.
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.
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.
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.
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:
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).
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.
Monitor function execution time, memory consumption, event listeners, and frame rendering time via the timeline panel.
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.
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…
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.
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.
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.
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: