As with my last post, I'll warn folks that I'm still learning about MobileFirst and to please forgive any mistakes I make. I also want to give a shout out to my coworker Carlos Santana who has been incredibly helpful in getting me up to speed. As this is my first post on MobileFirst, let me begin with a bit of background.

MobileFirst-Logo

MobileFirst is a collection of products that offer features and support for mobile developers. This support covers the full range of mobile development, from native to hybrid (my main area of concern). These features/support include:

  • Logging: You can using MobileFirst to enable/disable logging profiles for devices in the wild in real time. So for example, if users on Android begin complaining about a problem, you can quickly enable logging for that platform to try to determine what's going wrong.
  • Application version management: Control what versions of an application are allowed to be used and even send out notices to users to let them know about updates, service interruptions, etc.
  • API management: You can proxy requests to remote APIs via MobileFirst giving you more control over API usage in your apps.
  • Push notifications for all supported platforms.
  • Deep analytics about app usage (device, version, etc).
  • A QA and Security scanning service.
  • Full web-based portal for all of the above to make it easy to use.

And more, of course. If you know me, you know I try to get to the nitty gritty of products as opposed to talking about them at a high level. In order to get up to speed I've been working with MobileFirst specifically in terms of hybrid application.

MobileFirst uses Cordova itself under the hood for hybrid apps. But you can't (for now) simply take an existing Cordova application and drop it into your MobileFirst project. Nor can you use Cordova tooling. While this may improve in the future, it isn't that difficult to take an existing application and bring it into MobileFirst. In this post I'm going to talk a bit about how to create hybrid apps, how to test them, and take a look at how you would take an existing Cordova application and bring it into MobileFirst.

Create the MobileFirst Server/Application

A full look at installation, usage, etc. for MobileFirst is outside the scope of this document. You can see the Getting Started documentation for a start and peruse the hybrid-specific portions. The docs mainly focus on MobileFirst Platform Studio, an Eclipse plugin for managing MobileFirst projects via the IDE, but I much prefer using the CLI. You can find that download and installation instructions here.

Given you've got stuff downloaded and installed, you can fire up a new server and hybrid application quickly:

mfp1

In the above screen shot, I create a new MobileFirst server, added a hybrid application, and then enabled support for iPhone and Android. Now let's take a look at the directory structure.

mf2

The folder we care about is the common folder. This is where your HTML, CSS, and JavaScript exists and represents what you'll spend most of your time editing. Right now we've got a basic application, essentially the MobileFirst version of the Cordova skeleton.

Editing and Testing

So given that you now have a folder of web assets, how do we actually test this thing so we can see it in action. Also, what is the process like to edit and update the application?

One of the first things you want to do is start the server you created and then open up the console. That's done with mfp start and mfp console.

mf3

The console gives you a variety of options, but the one we care most about is the preview. Clicking the eye icon next to a platform opens up a preview tab.

mf4

What you've got here is essentially a web browser view of the mobile app with tools to simulate various different events and plugins. Yep, this is much like the Ripple tool. I'm going to talk about this a bit deeper in another post, but for now, let's focus on the editing process. Whenever I edit my common resources, I need to tell MobileFirst about it. This is typically done with two commands: mfp build and mfp deploy, but you can combine these into one nice call: mfp bd. As you can imagine, you could further automate this with a Grunt file watcher to make it automatic.

What about working with the native device, or simulator? Within the app folder, and next to the common folder, is one folder for each native platform you added via mfp add environment. For now, let's consider the iPhone folder:

mf5

Within it is an XCode project. If you double click to open it, you can then send the project to the simulator (or a device).

mf6

So in my testing, my process so far has been: Edit in Brackets, do mfp bd, then simply click the Build/Run button in XCode. You don't have to reopen or refresh the project at all, the command line takes care of that.

Now - what about using an existing Cordova project? Perhaps an Ionic one? Let's start with a simple one - my Cordova skeleton folder from my Cordova Examples GitHub repo. This project is pretty minimal. It contains one HTML, one JavaScript, and one CSS file. Here is the HTML:

<!DOCTYPE html>
<html>
	<head>
		<meta charset="utf-8">
		<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
		<title></title>
		<meta name="description" content="">
		<meta name="viewport" content="width=device-width">
        <link rel="stylesheet" type="text/css" href="css/app.css" />
	</head>
	<body>

	<script src="cordova.js"></script>	
	<script src="js/app.js"></script>
	</body>
</html>

And here is the JavaScript (I'll skip the CSS as it is empty):

document.addEventListener("deviceready", init, false);
function init() {
	
}

As I said - it is pretty simple - which is kind of the point. So how would I integrate this into a MobileFirst project?

  1. The first step is to copy out the contents from the common folder. I moved them into a temp folder.
  2. I then copied my existing project into the common folder.
  3. Next, remove the script tag that includes cordova.js: <script src="cordova.js"></script>. This may seem unnatural to you as it is part of the basic requirements for a Cordova project, but MobileFirst handles this for you.
  4. Next, copy back the file initOptions.js. As you can probably guess, this file handles setting up default options for MobileFirst. It will also automatically call a function named wlCommonInit. This will replace your deviceready call from your existing application. Right now you can't tell the platform to run another function so you must use a function with that name. My code listened for deviceready to fire init, so I removed my event listener and renamed init to wlCommonInit. (I'll share the modified code at the end.) You can also simply copy in the code from initOptions.js into your JavaScript file. Right now I kind of think it makes sense to keep them separate. I reserve the right to change my mind on that before I finish writing this blog entry.
  5. At this point, you have your code set up to listen for MobileFirst's platform to be ready along with the default Cordova deviceready. You can use both device features and MobileFirst APIs. I've zipped up my common folder as an attachment to this blog entry.

Here's the updated index.html file:

<!DOCTYPE html>
<html>
	<head>
		<meta charset="utf-8">
		<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
		<title></title>
		<meta name="description" content="">
		<meta name="viewport" content="width=device-width">
        <link rel="stylesheet" type="text/css" href="css/app.css" />
	</head>
	<body>

    <script src="js/initOptions.js"></script>
    <script src="js/app.js"></script>
	</body>
</html>

My initOptions.js is the same as the default, but here is my new app.js:

function wlCommonInit() {
	//I'm ready to do MFP stuff and Cordova stuff.
	console.log("BRING THE EPIC");	
}

So what about plugins? By default, MobileFirst includes all the core plugins. You don't have to implicitly add camera, device, etc. The full MobileFirst API is documented here and I'll show some examples of this in my later posts. Custom plugins require manual installation. I'll demonstrate this later as well.

I hope this wets your appetite a bit and let me know if anything isn't clear. As I said, I've got multiple other blog entries to write on this to help flesh out the process.