Category Archives: JavaScript

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.  ;)

 

IBM Worklight Powered Native Objective-C iOS Apps

IBM MobileFirst Foundation (also known as IBM Worklight) is a middleware solution for developing mobile applications. Out of the box, Worklight enables security and authentication, device management, encrypted storage, operational analytics, simple cross platform push notifications, remote logging, data access, and more…

Historically, most people think that Worklight is just for creating hybrid mobile (HTML-powered) applications. While this is one of the powerful workflows that Worklight enables, it’s also the proverbial “tip of the iceberg”. Worklight does a lot more than just provide the foundation for secure hybrid applications. Worklight also provides a secure foundation for native applications, and can be easily incorporated to any existing (or new) native app.

In this post, I’ve put together a video series to take a look at just how easy it is to setup Worklight in an existing iOS native application to provide remote log collection, application management, and more. Read on for complete detail, or check out the complete multi-video playlist here.

The existing app that I’ll be integrating is based on an open source Hacker News client, which I downloaded from GitHub. Check out the video below for a quick introduction to what we’ll be building.

If you want, you can leverage the Worklight IDE – a set of developer tools built on top of the Eclipse development environment. If you don’t want to use Eclipse, that’s OK too – Worklight can be installed and configured using the Worklight command line interface (CLI) and you can leverage any developer tools that you’d like to build your applications. Want to tie into Xcode ? No problem. I’ll be using the Worklight CLI to setup the development environment in this series.

Setting up the Worklight Server

The Worklight server is the backbone for providing Worklight features. App managment, remote logging, operational & network analtics, and all of the Worklight features require the server, so the first thing that you need to do is setup the server for our environment. Check out the next video, which will guide you through setting up a Worklight server/project using the CLI.

First things first, you have to start the Worklight server. If you haven’t already configured a Worklight server, run the create-server command to perform the initial setup – this only has to be run once ever.

wl create-server

Now that the server is setup, we need to create a Worklight project. For this walkthrough, I’ll just call it “MyWorklightServer”:

wl create MyWorklightServer

Next, go into the newly created project directory and go ahead and start it.

cd MyWorklightServer
wl start

Once the server is started, add the iOS platform:

wl add api

You will be prompted for an API name. This can be anything, but you should probably give it a meaningful name that identifies what the API will be used for. In this walkthrough I specify the name “MyiOSNativeAPI”.

01-Worklight-CLI

Next you will be prompted to select a platform, select “iOS”
Next, build the project, and then deploy it to the server:

wl build
wl deploy

Next, launch the Worklight console to view that the project has been deployed and the native API has been created. The console will launch in the system web browser.

wl console
02-Worklight-Console
Worklight Console

 

Be sure to check out the Worklight CLI documentation for complete detail on the CLI commands.

Xcode Integration

Next we need to setup the Xcode project to connect to the newly created Worklight server. If you’re adding Worklight to a new Xcode project, or an existing Xcode project, the preparation steps are the same:

  1. Add Worklight files to your Xcode project
  2. Add framework dependencies
  3. Add the -ObjC linker flag

This next video walks through configuration of your Xcode project and connecting to the Worklight server (which we will cover next):

In the Xcode project navigator, create a folder/group for the Worklight files, then right click or CTRL-click and select “Add Files to {your project}”…

03-add-files

Next, navigate to the newly created MyiOSNativeAPI folder and select the worklight.plist file and WorklightAPI folder, and click the “Add” button.

04-add-files-2

Once we’ve added the files to our Xcode project, we need to link the required framework/library dependencies:

  • CoreData.framework
  • CoreLocation.framework
  • MobileCoreServices.framework
  • Security.framework
  • SystemConfiguration.framework
  • libstdc++.6.dylib
  • libz.dylib

Next, In the Xcode project’s Build Settings search for “Other Linker Flags” and add the following linker flag: “-ObjC”.

05-linker-flag

If you’d like additional detail, don’t miss this tutorial/starter app by Carlos Santanahttps://github.com/csantanapr/wl-starter-ios-app

 Connecting to the Worklight server

Connecting to the Worklight server is just a few simple lines of code. You only have to implement the WLDelegate protocol, and call wlConnectWithDelegate, and the Worklight API handles the rest of the connection process. Check out the video below to walk through this process:

Implement the WLDelegate protocol:

//in the header implement the WLDelegate protocol
@interface MAMAppDelegate : UIResponder <UIApplicationDelegate,
   WLDelegate> {

//in the implementation, add the protocol methods
-(void)onSuccess:(WLResponse *)response {
}
-(void)onFailure:(WLFailResponse *)response {
}

Connect to the Worklight Server:

[[WLClient sharedInstance] wlConnectWithDelegate: self];

Next, go ahead and launch the app in the iOS Simulator.

You’re now connected to the Worklight server! At this point, you could leverage app management and analytics through the Worklight Console, or start introducing the OCLogger class to capture client side logging on the server.

App Administration via Worklight Console
App Administration via Worklight Console

 

Worklight Analytics Dashboard
Worklight Analytics Dashboard

 

Remote Collection of Client Logs

Once you’re connected to Worklight, you can start taking advantage of any features of the client or server side APIs. In this next video, we’ll walk through the process of adding remote collection of client app logs, which could be used for app instrumentation, or for debugging issues on remote devices.

On the server, you’ll need to add log profiles to enable the capture of information from the client machines.

Adding Log Profiles
Adding Log Profiles

On the client-side, we just need to use the OCLogger class to make logging statements. These statements will be output in the Xcode console for local debugging purposes. If a log profile has been configured on the server, these statements will also be sent to the Worklight server.

OCLogger *logger = [OCLogger getInstanceWithPackage:@"MyAppPackageName"];
[OCLogger setCapture:YES];
[OCLogger setAutoSendLogs:YES];

//now log something
[logger log:@"worklight connection success"];
[logger error:@"worklight connection failed %@", response.description];

For complete reference on client side logging, be sure to review the Client-side log capture API documentation.

App Management & Administration

Out of the box, Worklight also provides for hassle-free (and code-free) app management. This enables you to set notifications for Worklight client apps and disable apps (cutting off access to services and providing update URLs, etc..). This next video walks you through the basics of app management.

Be sure to check out the complete documentation for app management for complete details.

All done, right?

At this point, we’ve now successfully implemented Worklight server integration into a native iOS app. We have remote collection of client-side logs, we can leverage app management, and we can collect operational analytics (including platforms, active devices, and much more).

If you don’t want to leverage any more Worklight features, then by all means, ship it! However, Worklight still has a LOT more to offer.

Exposing Data Through Adapters

Worklight also has the ability to create adapters to expose your data to mobile clients. Adapters are written in JavaScript and run on the server. They help you speed up development, enhance security, transform data serialization formats, and more.

In the next two videos we will walk through the process of collecting information inside the native iOS application and pushing that into a Cloudant NoSQL data base (host via IBM Bluemix services).

Cloudant databases have a REST API of their own, so why use a Worklight Adapter? For starters, Worklight becomes your mobile gateway.  By funneling requests through Worklight, you are able to capture analytic data for every server invocation, and Worklight gives us the ability to control access to the enterprise.  Worklight gives you the capability to cut off mobile access to the backend at any time, just by changing the API status.

Now let’s take a look at the process for exposing the Cloudant database through a Worklight Adapter:

Once the data adapter has been configured, it is simple to invoke the adapter procedures to get data into or out of the your applications.

This next video covers the process of pushing data into the Cloudant database adapter from the native mobile client application:

Once again, you will have to implement the WLDelegate protocol to handle success/error conditions, and the procedure invocation is implemented using the WLClient invokeProcedure method:

NSMutableDictionary *userProfile = [[NSMutableDictionary alloc] init];
[userProfile setValue:self.email.text forKey:@"email"];
[userProfile setValue:self.firstName.text forKey:@"firstName"];
[userProfile setValue:self.lastName.text forKey:@"lastName"];    

WLProcedureInvocationData * invocationData = [[WLProcedureInvocationData alloc] initWithAdapterName:@"CloudantAdapter" procedureName:@"putData"];
invocationData.parameters = @[userProfile];

[[OCLogger getInstanceWithPackage:@"UserProfile"] log:@"sending data to server"];
[[WLClient sharedInstance] invokeProcedure:invocationData withDelegate:self];

It is as simple as that.

IBM MobileFirst Foundation (aka Worklight) is for more than just hybrid app development. It is a secure platform to streamline your enterprise application development processes, including everything from encryption, security and authentication, to operational analytics and logging, to push notifications, and much more, regardless of whether you’re targeting hybrid app development paradigms, or native iOS, native Android, or native Windows Phone projects.

DevNexus 2014 PhoneGap Presentations

I’ve just wrapped up my presentations for this year’s DevNexus event in Atlanta – it has been a great event, filled with tons of information on web, mobile, and back-end development. I had 3 sessions on PhoneGap – One intro, one advanced, and one a mobile frameworks panel.

Below are my presentations.  I didn’t record them this time, since they were being recorded by the conference organizers, so expect to see a video once they’re released.

Just press the space bar, or use the arrow keys to view the presentation in your browser.

Getting Started with PhoneGap and Cross Platform Mobile Development

View Presentation …

intro_2_pg

(Lesson learned, never make changes to you presentation/environment after midnight when you have the first session of the day – it will always bite you)

Designing & Architecting for PhoneGap & the Mobile Web

View presentation …

architecture_pg

Enjoy, and feel free to reach out with any questions!

PhoneGap Presentations from HTML5DevConf

I was  searching the web earlier this week for an older presentation from a few months back, and just happened to stumble across my recent presentations from HTML5DevConf from this past October. Looks like the videos were posted in November, but I’m just seeing them now. I had two sessions: Designing and Architecting PhoneGap and Mobile Web Apps and Getting Started with PhoneGap and Cross-Platform Mobile Development, and if you weren’t able to attend them, you’re still in luck! Here are the videos from those sessions:

Designing and Architecting PhoneGap and Mobile Web Apps

Tired of Hello World? In this session, we explore best practices to build real-world PhoneGap applications. We investigate the Single Page Architecture, HTML templates, effective Touch events, performance techniques, modularization and more. We also compare and contrast the leading JavaScript and Mobile Frameworks. This session is a must If you plan to build a PhoneGap application that has more than a couple of screens.

Getting Started with PhoneGap and Cross-Platform Mobile Development

Unfortunately, I ran into network issues which prevented some of my samples from working in this one, but you’ll still be able to get the point.

HTML has emerged as a powerful alternative to “native” to enable cross-platform mobile application development. In this session, you learn how to leverage your existing HTML and JavaScript skills to build cross-platform mobile applications, how to access the device features (camera, accelerometer, contacts, file system, etc) using JavaScript APIs, and how to package your HTML application as a native app for distribution through the different app stores.

You can also check out highlights from HTML5DevConf and find my presentation assets and materials online here.

More Device Motion Experiments with HTML & Adobe DPS

I wanted to follow up my last post on 3D Parallax effects in HTML or Adobe DPS, I’ve decided to release some of the other experiments that I’ve been exploring with device motion in DPS publications. Check out the video below to see two new samples, and a corrected version of the strawberries example from my last post (the plants were going the wrong way in the last post).

All three of these samples leverage the same basic technique for responding to device motion inside of a DPS publication. The motion-interactive components are implemented using HTML and JavaScript, and are included in publications as web content overlays. In JavaScript, it takes advantage of the ondevicemotion event handler to respond to the physical orientation of the device.

In all three of samples, the web content overlay is set to autoplay, with user interaction disabled. This way the HTML & JavaScript automatically loads and the scripting is active, but it doesn’t block interaction or gestures for DPS navigation. I also enabled “Scale Content To Fit” so that HTML content scales appropriately between retina and non-retina devices.

Adobe InDesign - Web Content Overlay Options
Web Content Overlay Options

Strawberries

The strawberries sample is identical to the one from my previous post. This is just a capture of the updated motion. You can access the full source project to this sample at:
https://github.com/triceam/DPS-HTML-Samples/tree/master/strawberries

strawberries

Adobe San Francisco

The Adobe/inline content example is implemented in the same manner as the strawberries example. The large city image It is a two-layer composition created with Adobe Edge Animate. The foreground building and flag move independently from the background image. I used Photoshop to separate the content into layers and made them animate based on device orientation in the exact same fashion as the strawberries sample. All of the text and image content surrounding the cityscape panorama is laid out with InDesign.

adobe

You can check out the Adobe Edge Animate project at:
https://github.com/triceam/DPS-HTML-Samples/tree/master/adobe%20roof

AT&T Park/San Francisco Giants

The AT&T Park/San Francisco Giants example is implemented with basic HTML and JavaScript, no additional tools were used to create this interactive scenario.   The content on the left hand side was all laid out with InDesign. The content on the right side is the interactive HTML.

att_park

The image used in this example is a vertical panorama captured from a remote control helicopter. This image contains various perspectives that have been composited in Photoshop. The motion of the device is aligned to match the perspectives in the image/viewport; When the device is facing down, the image is looking down and when the device is vertical, the image faces forward. You can check out the vertical panorama image below. If you’re interested in creating a vertical panorama, be sure to check out this tutorial from Russell Brown.

Vertical Panorama over AT&T Park

The HTML and JavaScript used in this example is fairly minimal. The image is applied as the background of the root HTML <body> element, and the position of the background is shifted based upon the device motion event. This approach keeps the HTML DOM as flat and simple as possible.

Here’s the HTML that makes up this example:

<html>
    <head>
        <meta charset="utf-8">
        <meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no">
        <title>Parallax Vertical Background</title>
        <link rel="stylesheet" href="assets/styles.css">
        <script src="assets/zepto.js"></script>
    </head>
    <body></body>
</html>

… and the CSS styles used to apply the background image.

body {
    background-image:url('att_park_vert_panorama.jpg');
    background-position: center;
}

… and the JavaScript used to shift the position based on the device orientation event. Note: this also uses the Zepto JavaScript library.

window.ondeviceorientation = function(event) {
        var gamma = event.gamma/90;
	var beta = event.beta/180;
	var temp = 0;

	// shift values/motion based upon device orientation
	switch (window.orientation) {
		case 90:
			temp = gamma;
			gamma = beta;
			beta = temp;
			break;
		case -90:
			temp = -gamma;
			gamma = beta;
			beta = temp;
			break;

	}

	// update positions to be used for CSS
	var yPosition = 1200 - (beta * 2200);
	var xPosition = -200 + (gamma * 300);
	xPosition = Math.max( -300, Math.min( 0,xPosition));
	yPosition = -Math.max( 100, Math.min( 1400,yPosition));
	//console.log(xPosition, yPosition);

	// apply css styles
	var css = xPosition + "px " + yPosition + "px";
	$("body").css( "background-position", css);
}

Textual content used in this example from: http://en.wikipedia.org/wiki/At%26t_park

Source code for the device motion in this example is available at: https://github.com/triceam/DPS-HTML-Samples/tree/master/ATT%20Park

All of the HTML, CSS and JavaScript code used for these examples is available in the GitHub repository at: https://github.com/triceam/DPS-HTML-Samples