Developing Hybrid Mobile Apps with IBM MobileFirst 7.1

in yesterday’s blog post ( getting started with mobile development and ibm mobilefirst 7.1 ), i discussed what mobilefirst was and why it could be beneficial for mobile developers. in today’s post, i’m going to discuss how hybrid mobile development works with mobilefirst. this is something i’ve discussed before (for mobilefirst 7.0), and while the process wasn’t difficult, it was definitely a few steps away from the “typical” cordova development workflow. mobilefirst 7.1 really improves this process and makes it somewhat simpler for hybrid developers. in this post i’ll talk about the process both for new projects as well as how an existing project can be migrated to mobilefirst. i will not be discussing specifics for ionic until tomorrow, but most of what i say today will apply there as well. ok, let’s get started!

prereqs

before i begin, i’m assuming you’ve already downloaded and installed the cli as i described in yesterday’s post . you’ll also want to have a server up and running, either locally or on bluemix . i also assume you have the “normal” cordova prereqs like the ios or android sdks.

creating a project

to create a new hybrid project, you begin by running mfp cordova create . you’ll be prompted for the name and given a default package id and version:

next you’ll be prompted to select platforms. like any other cordova project, you can change this later.

next, the cli lets you know that some plugins are installed by default. these plugins are required for cordova apps running with mobilefirst:

now the cli prompts you about other plugins you may want to install. note that you can easily add, remove, and list plugins later on so don’t stress too much over this.

finally, the cli prompts you to select a template to use for your app. you can pass in other templates via the -t argument and you’ll see this in action tomorrow when i blog about ionic:

at this point, the cli will start generating your project as well as push a copy to your mobilefirst server. if everything went well, the last thing you’ll see is: “mfp cordova project created successfully.” let’s look at the folder created by the cli.

for the most part, this should look very similar to a regular cordova project. notable differences include:

• application-descriptor.xml: this allows you to tweak some settings for the application under mobilefirst. in general, you won’t need to tweak this and when you do, do not edit it by hand, use mfp config .
• mobilefirst: the files in this folder are what get pushed up to the mobilefirst server. you won’t need to mess with this.

and that’s it – the rest of this is vanilla cordova stuff.

working with the mobilefirst/cordova project

so now that you’ve got a project, how do you use it? the mobilefirst cli wraps calls to the cordova cli, much like ionic does. so for example, to add a platform, you would do: mfp cordova platform add android . in general, the commands are very similar, but sometimes there are small differences. so for example, to emulate, you need to pass a -p flag: mfp cordova emulate -p ios . in this case, -p stands for platform. you can easily see the syntax by typing mfp help cordova :

so the process to code/test is pretty similar. you can open up the www folder, edit, and then see your changes by doing: mfp cordova emulate -p ios :

at the time i write this blog post, we have a small bug with the cli that impacts this process. when working with a mobilefirst server, you need to deploy the bits to the server so it is aware of it. (there’s more reasons than that, but let’s keep it simple for now). that command is: mfp push . the emulate command is supposed to do a push automatically, but right now it does not. again, this is a bug, and a known one that is already being worked on. (i’ll try to remember to edit this post once the fix is released). for now, i recommend doing both commands at once. in osx, this would be: mfp push && mfp cordova emulate -p ios . you could automate all of this with grunt/gulp of course.

outside of that – you’re done. build your app. make use of the cool features of mobilefirst, iterate, deploy, and be successful.

migrating an existing application

so what do you do if you’ve got an existing application? first, begin by creating a new mfp cordova project as i outline above. you’ll want to match the id and application name. you can also tell the cli to install the plugins your app needs, but if you forget, you can always add the plugins later. you can then simply copy the www folder from your existing project into the new mfp www folder.

ok, so at this point, you need to make one very small tweak to your application code. as you know, cordova applications need to wait for the deviceready event before they do anything related to the device itself. most folks treat deviceready as their main application “bootstrap” – i.e., they don’t really do squat till after it has fired.

in a mfp cordova application, you have another event as well – the initialization of the mobilefirst client-side framework. by default, your code can (probably should) have a function called wlcommoninit . when this function is run, you can then do “mobilefirst stuff”, much like how deviceready implies device readiness. you can simply include this function in your application so you can begin doing things like remote logging, or other utilities. here is an example:

function wlcommoninit(){
}

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

}

if you use the default mfp cordova project, you’ll see some additional bits:

var messages = {
    // add here your messages for the default language.
    // generate a similar file with a language suffix containing the translated messages.
    // key1 : message1,
};

var wlinitoptions = {
    // options to initialize with the wl.client object.
    // for initialization options please refer to ibm mobilefirst platform foundation knowledge center.
};

these are optional and can be left out if you don’t need them.

and that’s it. heck, technically you don’t even need wlcommoninit, it won’t throw an error without it, but the assumption here is that you actually want to use mobilefirst. any questions?