A while back I wrote about adding parallax effects to your HTML/JS experiences to make them feel a bit richer and closer to a native experience. I’ve just added this subtle (key word *subtle*) effect to a new project and made a few changes I wanted to share here.

If you are wondering what I am talking about with “parallax effects” – Parallax movement is where objects in the background move at a different rate than objects in the foreground, thus causing the perception of depth. Read more about it if you’re interested.

First, here’s a quick video of this latest app in action. It’s a hybrid MobileFirst app, but this technique could be used in any Cordova/PhoneGap/MobileFirst/mobile web app experience. The key is to keep it subtle and not too much “in your face”, and yes, it is very subtle in this video. You have to watch closely.

The techniques that I wrote about in the previous post still apply – I’ve just added a bit more to cover more use cases.

This sets the background image and default position. The distinct change here is that I set the background size to “auto” width and 120% height. In this case, you can have a huge image that shrinks down to just slightly larger than the window size, or a small image that scales up to a larger window size. This way you don’t end up with seams in a repeated background or a background that is too big to highlight the parallax effect effectively.

In the requestAnimationFrame loop, it only applies changes *if* there are changes to apply. This prevents needless calls to apply CSS even if the CSS styles hadn’t changed. In this, I also truncate the numeric CSS string so that it isn’t reapplying CSS if the position should shift by 0.01 pixels. Side note: If you aren’t using requestAnimationFrame for HTML animations, you should learn about it.

If you used my old code and were holding the device upside down, it wouldn’t work. Not even a little bit. This has that fixed (see comments inline above).

This moves the background in CSS, which doesn’t cause browser reflow operations, and moves the foreground content (inside of a div) using translate3d, which also doesn’t cause browser reflow operations. This helps keep animations smooth and the UX performing optimally.

I also added a global variable to turn parallax on and off very quickly, if you need it.

The result is a faster experience that is more efficient and less of a strain on CPU and battery. Feel free to test this technique out on your own.

If you use the code above, you can modify the xMovement and yMovement variables to exaggerate the parallax effect.

This post specifically covers native iOS, though there are also Android and hybrid options available. This should have everything you need to get started. It covers all aspects from creating the app, to updating the back end, to leveraging Cloudant storage, push notifications, and monitoring & logging.

So, without further ado, let’s get started…

Part 1: Getting Started with Bluemix Mobile Services

In this first video I show how to create a new mobile app on Bluemix, connect to the cloud app instance, and implement remote logging from the client application. This process is covered in more detail in the Getting Started docs, but below are the basics from my experience.

You’ll first need to sign into your Bluemix account. If you don’t already have one, you can create a trial account for free. Once you’re signed in, you just need to create a new mobile app instance.

The process is very simple, and there is a “wizard” to guide you. The first thing that you need to do is create a new app by clicking the big “Create an App” button on your bluemix dashboard.

Create a new app from IBM Bluemix Dashboard

Next, select which kind of app you’re going to create. For MBaaS, you’ll want to select the “Mobile” option.

Select the type of app

Next you’ll need to select your platform target. You can choose either “iOS, Android, Hybrid”, or the “iOS 8 beta” target. In this case I chose the iOS 8 beta, but the process is similar for both targets. Hybrid apps are built leveraging the Apache Cordova container.

Select your platform target

Next, just specify an app name and click “Finish”.

Give your app a name

Once your app is created, you will be presented with instructions how to connect the app in Xcode. I’ll get to that in a moment…

Now that your app has been created, you’ll be able to see it on your Bluemix dashboard. This app will consist of several components: a Node.js back-end instance, a Cloudant NoSQL database instance, an Advanced Mobile Access instance, and a Push instance. The Advanced Mobile Access component provides you with app analytics, user auth management, remote logging, and more. The Push component gives you the ability to manage and send push notifications (either manually, or with a rest-based API).

You app has been created – here are the components and the activity

Once your app has been created, you will need to setup the mobile app to connect to Bluemix to consume the services. Again, this is a very straightforward process.

The next step is to register your client application. Once your app is created, you will be presented with a screen to do this. If you don’t complete it right away, you can always come back later and register an application. You’ll need to specify the Bundle ID and version of your app, then you can setup any authentication (if you choose).

Register your app’s bundle ID and version

Once your app has been registered, you need to configure Xcode. You’ll first need to create a new project in Xcode. There are two options for configuring your Xcode project: 1) automated installation using CocoaPods, or 2) manual installation. I used the CocoaPods installation simply because it is easier and manages dependencies for you.

If you aren’t familiar with CocoaPods, it is much like NPM… CocoaPods is a dependency manager for Cocoa projects. It helps you configure the Bluemix libraries and manages dependencies for you.

If you’ve got Xcode up and running, then close it and install CocoaPods, if you don’t already have it. Next open up a terminal/command prompt, go to the directory that contains your Xcode project and initialize CocoaPods using the “setup” command:

pod setup

This will create a new file called “podfile”. Open this file in any text editor and paste the following (note: you can remove any lines that you don’t want to actually use):

source 'https://github.com/CocoaPods/Specs.git'
# Copy the following list as is and
# remove the dependencies you do not need
pod 'IMFCore'
pod 'IMFGoogleAuthentication'
pod 'IMFFacebookAuthentication'
pod 'IMFURLProtocol'
pod 'IMFPush'
pod 'CloudantToolkit'

Save the changes to the “podfile” file, and close the text editor. Then go back to your command promprt/terminal and run the installation process:

pod install

Your project will be configured, and all dependencies will be downloaded automatically. Once this is complete, open up the newly created .xcworkspace file (Xcode Workspace).

You have to initialize the Bluemix inside of your application to connect to the cloud service to be able to take advantage of any Bluemix features (logging, data access, auth, etc…). The best place to put this is inside of your AppDelegate.m class application didFinishLaunchingWithOptions method because it is the first code that will be run within your application:

One of the first features I wanted to take advantage of was remote collection of client-side logs. You can do this using the IMFLogger class, in much the same fashion as you do with OCLogger in MobileFirst Foundation server. Once great feature that requires almost no additional configuration is the captureUncaughtExceptions method, which automatically configures the Advanced Mobile Access component to collect information for all app crashes.

Next, launch your app in the iOS simulator, or on a device, and you’ll see everything come together. Log into your Bluemix dashboard, and you’ll be able to monitor app analytics and remote logs.

Note: If you experience any issues connecting to the Bluemix mobile app from within the iOS simulator, just clear the iOS Simulator by going to the menu command “iOS Simulator -> Reset Content and Settings…”, and everything should connect properly the next time you launch the app.

Part 2: Configuring the Node.js Backend

In the next video, I demonstrate how to grab the code for the backend Node.js application, create a git repository on IBM JazzHub, then pull the code for local development.

When the app is created, you’ll see an “add git” link under the app name. Using this link, you can create a git repository for the backend code.

Add a git repository

Once your git repo has been created, you can check out the code using any Git client (I used the CLI). You’ll need to use the “npm install” command to pull down all the app dependencies. The biggest thing you need to know is that it uses express.js for the web application framework. You can make any changes that you want, and they will be automatically deployed to your Bluemix server instance upon commit. Yes, this workflow is also configurable b/c this process may not work for everyone.

One other thing that you will need to watch out for if you are doing local development: You will want to wrap the following code on line 6 in a try/catch block, otherwise you will hit errors in the local environment which will prevent your app from launching locally:

Part 3: Consuming Data from Cloudant

Another part of Bluemix mobile applications is the Cloudant NoSQL database. The Cloudant NoSQL database is a powerful solution that gives you remote storage, querrying, and client-side data storage mechanisms with automatic online/offline synchronization, all with monitoring/analytics capabilities.

By default, objects within the Cloudant data store are treated as generic objects (over-simplification: think of it is an extremely powerful JSON store in the cloud). However you can also serialize your objects to strong data types within the client code configuration.

In your AppDelegate class application didFinishLaunchingWithOptions method, you’ll also want to initialize the IMFDataManager class, which is the class used for interacting with all Cloudant data operations.

IMFDataManager *manager =
[IMFDataManager sharedInstance];

In my sample, I setup the database manually with open permissions, but you’ll probably want something more secure. Once your database is created, you can create indexes, search for data, create data, etc…

In the following code, I create a search index and query for data from the remote Cloudant database. You really only need to create the index if it doesn’t already exist. You can do this either through the mobile app code, or manually through the Cloudant database’s web interface. I did this inline in the following code, just for the sake of simplicity:

Part 4: Push Notifications

The IBM Bluemix mobile services app also contains a component for managing push notifications within your mobile applications. With this service, you can send push notifications to a specific device, a group of devices using tags, or all devices, and you can send push notifications either manually via the web interface, or as part of an automated workflow using the REST API.

Part 5: Monitoring and Logging

Did I mention that every action that you perform through Bluemix Mobile Services can be monitored? Analytics are available for the Advanced Mobile Access component, the Cloudant NoSQL data store, and the Push Notifications service. In addition, you also have remote collection of client logs and crash reports. This provides unparalleled insight into the health of your applications.

MBaaS, or Mobile Backend as a Service, seems to be a particularly hot topic these days. MBaaS generally refers to backend services for mobile applications that provides data storage, user management, push notifications, and other pertinent mobile APIs.

This is more than just “Cloud Services” which more generally refer to a scalable virtual cluster of computing or storage resources. Bluemix is IBM’s suite of cloud service offerings, and covers lots of use cases:

Bluemix is an open-standards, cloud-based platform for building, managing, and running apps of all types, such as web, mobile, big data, and smart devices. Capabilities include Java, mobile back-end development, and application monitoring, as well as features from ecosystem partners and open source—all provided as-a-service in the cloud.

Why is it a hot topic? MBaaS enables growth of mobile applications with seamless (and virtually endless) scalability, all without having to manage individual systems for the application server, database, identify management, push notifications, or platform-specific services.

I’ve been writing a lot about IBM MobileFirst lately for a seamless API to deliver mobile apps to multiple platforms; though it has been in the context of an on-premise installation. However, did you know that many of the exact same MobileFirst features are available as MBaaS services on IBM Bluemix?

Mobile Data – The mobile data service includes a NOSQL database (powered by IBM Cloudant), file storage capabilities, and appropriate management and analytics features to measure the number of calls, storage usage, time/activity, and OS distribution.

Push Notifications – The push notification service allows you to easily push data to the right people at the right time on either Apple APNS or Google GCM platforms – all with a single API. Notifications can be sent by either an app or backend system, and can be sent to a single device, or a group of devices based on their tags/subscriptions. Of course, with appropriate analytics for monitoring activity, distribution, and engagement.

Many of these are the exact same features that you can host in your own on-premise IBM MobileFirst Platform Foundation server – the difference is that you don’t have to maintain the infrastructure. You can scale as needed through the Bluemix cloud offering.

Push notifications, love them or hate them, are everywhere and there’s no getting around it. Push notifications are short messages that can be sent to mobile devices regardless of whether the apps are actually running. They can be used to send reminders, drive engagement with the mobile app, notify completion of long running processes, and more. Push notifications send information to you in real time, rather than you having to request that information.

If you are building a back-end infrastructure to manage your application’s data, and you want to leverage push notifications, then guess what? You also have to build the hooks to manage subscription and distribution of push notifications for each platform.

The unified push notification API allows you to develop your app against a single API, yet deliver push notifications to multiple platforms, and it works with both hybrid (HTML/CSS/JS) apps, as well as native apps.

You will still have to build the logic to subscribe devices for messaging, and dispatch push notification messages, but you’ll only have to do it once against the unified API – not once for each platform.

The apps that I showed in the video above are sample apps taken straight from the IBM MobileFirst platform developer guide for iOS and Android, and can be accessed in their entirety (with both client and server code) using the links below:

On the client app, you’ll need to subscribe for messages from the event source. See the hybrid or native code linked to above for syntax and examples.

Once your clients are subscribed, you can use a single server-side implementation to distribute messages to client apps. Below is an excerpt from the sample application which demonstrates sending a push notification to all devices for a particular user (on any platform):

From the MobileFirst console, you will be able to monitor and manage event sources, platforms, and the devices that are consuming push notifications.

Push Notifications on the MobileFirst Console

If you were wondering, yes, these can be cloud-hosted on IBM BlueMix and yes, it can also be installed on-premise on your own server in your data center. You have the option to configure your physical or cloud servers however you want.

One of the many popular feature of IBM MobileFirst SDK is the ability to capture client-side logs from mobile devices out in the wild in a central location (on the server). That means you can capture information from devices *after* you have deployed your app into production. If you are trying to track down or recreate bugs, this can be incredibly helpful. Let’s say that users on iOS 7.0, specifically on iPhone 4 models are having an issue. You can capture device logs at this level of granularity (or at a much broader scope, if you choose).

The logging classes in the MobileFirst Platform Foundation are similar in concept to Log4J. You have logging classes that you can use to write out trace, debug, info, log, warn, fatal, or error messages. You can also optionally specify a package name, which is used to identify which code module the debug statements are coming from. With the package name, you’ll be able to see if the log message is coming from a user authentication manager, a data receiver, a user interface view, or any other class based upon how you setup your loggers. Once the log file reaches the specified buffer size, it will automatically be sent to the server.

On the server you can setup log profiles that determine the level of granularity of messages that are captured on the server. Let’s say you have 100,000 devices consuming your app. You can configure the profiles to collect error or fatal messages for every app instance. However, you probably don’t want to capture complete device logs for every app instance; You can setup the log profiles to only capture complete logs for a specific set of devices.

As an example, take a look at the screenshot below to see how you can setup log collection profiles:

Configuring Log Profiles on the MobileFirst Server

When writing your code, you just need to create a logger instance, then write to the log.

If you’re curious when you might want a trace statement, vs. a log statement, vs. a debug statement, etc… Here is the usage level guidance from the docs:

Use TRACE for method entry and exit points.

Use DEBUG for method result output.

Use LOG for class instantiation.

Use INFO for initialization reporting.

Use WARN to log deprecated usage warnings.

Use ERROR for unexpected exceptions or unexpected network protocol errors.

Then on the server, you can go into the analytics dashboard and access complete logs for a device, or search through all client-side logs with the ability to filter on application name, app versions, log levels, package name, environment, device models, and OS versions within an optional date range, and with the ability to search for keywords in the log message.