This blog post contributed by Markus Van Kempen, a Canadian SAP Mobile leader.

How does sensor integration with the Message Queue Telemetry Transport (MQTT) protocol and the Internet of Things cloud work, and what makes it so special?

My colleagues keep telling me how cool MQTT is—it’s the protocol of the Internet of Things (IoT). So I went on a quest to understand what’s so great about MQTT and investigate how it works with devices, sensors and the Internet of Things cloud. To do this, I built a scenario to see if I could get some of my devices to communicate with the IBM Internet of Things Foundation. I also visualized the sensor data in a graph using a local application on my notebook.

First, let’s talk about a couple of basics.

What is MQTT?

MQTT is a lightweight messaging protocol that supports publish/subscribe messaging. With MQTT, an application publishes messages to a topic. These messages may then be received by another application that is subscribed to that topic. This allows for a detached messaging network in which the subscribers and publishers do not need to be aware of each other. It’s like the electronic newspaper publishing model: there are publishers of newspapers or topics and many possible subscribers or clients.

Getting started with my MQTT project

I needed the following components for my project:

An MQTT broker or an IoT cloud (like IBM IoT Foundation)

MQTT clients or applications

Devices

There are several brokers (for example, mosquitto.org and other IoT clouds available on the Internet that you could also use. The task for the broker is the registration of publishers or devices and the distribution of messages to applications that subscribe to the specific message topic. I used our IBM IoT cloud, also known as the IBM Internet of Things Foundation, for my prototype as the MQTT broker.

As an MQTT test client, I used Paho, which is a commonly used Eclipse-based MQTT client.

The general information flow

A device that is registered with IBM IoT Foundation may publish event data or consume command data using the MQTT protocol. The Eclipse Paho MQTT client is used to publish and subscribe to the IoT cloud.

Now I needed a device or sensor that I could pull or publish data from. I looked around my desk and found my Pebble smartwatch, the Moto 360, Google Glass, Tile, Electric Imp, Leap Motion and my smartphone, but all these would require more coding to get some results. (By the way, there is also an Android sensor app from IBM you could use to get data like an accelerometer.) I decided to use one of our Nest thermostats as a sensor, hoping for the easiest route, with less coding.

After browsing GitHub, I found a simple Node.js project that allowed me to pull data from Nest (note that there is an official application programming interface, API, from Nest that offers a lot more functionality). I also found an MQTT Node.js implementation that allowed me to publish or subscribe using the MQTT protocol to a broker. After I mashed the two JavaScript files together (the MQTT client and the Nest project), I was able to pull the data from my Nest devices and publish to the IoT cloud. In order to use the IBM IoT cloud I had to sign up and register my notebook (MAC address) as a device. After that, I was able to see the message from my Nest thermostat in the IoT cloud.

Now I had a virtual device using my notebook that would publish Nest temperatures every five seconds or so to the IoT cloud, with the following JSON messages format:

The hardest part so far was registering the device (my notebook) on the IoT cloud and dealing with the authentication tokens, which took a couple of tries. My example code in GitHub should be very self-explanatory.

Since I now had the data in the IoT cloud, I wanted another client to subscribe to the message/topic and visualize the Nest temperature data. I found a visualization tool that was part of the IBM IoT Starter that allows you to run locally and pulls the IoT cloud device’s data to visualize the message from a specific registered device.

If I change the temperature using the Nest app, my MQTT client would be notified of the change and display the change in the target temperature.

There was one more thing I wanted to accomplish: sending a command from one of my MQTT clients to the device, which would essentially be doing the same as the Nest app could do.

I added some JavaScript code to my MQTT proxy run on my notebook, which subscribed to a command topic like the following code snippet:

client.subscribe('iot-2/cmd/settemp/fmt/json');

When I received a message event like client.on('message', …)I would check to see if the JSON message had a target temperature and device ID that I could use to set the new temperature in Nest with the following function:

nest.setTemperature(deviceId, myNewTargetTemp);

Now I had basically the mechanics in place to do what the Nest app already does using MQTT and IBM IoT Foundation.

My conclusions about MQTT

It was fun to tinker with the MQTT protocol and to try to find a new way of pulling information and making devices talk to each other. One of the coolest features was the subscription that would automatically notify me of events. In the past I would have to constantly ask the server for an update. MQTT also shines in its concept simplicity and in various implementations. I think MQTT will be the protocol of the Internet, but it may also be the future of messaging in mobile and web apps and has the potential of being the next Ajax!

Part of developing HTML5-based mobile apps is choosing a JavaScript framework that will speed up the development of the mobile app. MobileFirst Platform Foundation is a very open environment and can be used with a wide range of JavaScript frameworks such as JQuery and Dojo. This openness is important because new frameworks continue to be created and rapidly developed.

One such framework is Ionic, based on AngularJS. While still fairly new, it has gained popularity because of its simplicity and modern-looking user interface.

To use such a framework in the MobileFirst Platform Foundation, you need to make a couple of adjustments to ensure that the framework and the platform are both able to start, or bootstrap, correctly. This blog post will walk you through the steps to set up Ionic correctly with MobileFirst Platform Foundation. These principles should apply more widely. In this post, I will assume some basic knowledge of MobileFirst Platform Foundation for creating and previewing hybrid apps. Further information on this can be found in the MobileFirst Platform getting started guide.

To provide a useful demonstration of the integration, we are going to use the Todo app provided by Ionic. Download this from their Git repository, and extract it on your file system.

In the MobileFirst Platform Studio, create a new hybrid application project, Todo, containing a new app called TodoApp. (If you don’t wish to use the Studio environment, this can all be done using the command-line interface too.)

If you’re not familiar with the structure of a MobileFirst Platform app, it will be worth familiarizing yourself with the structure used. The content for the hybrid application will be found in Todo > apps > TodoApp > common, where all cross-platform development is done.

index.html will handle the dependencies for the app, and in the sample it contains the user interface too (as a best practice you would likely remove this into separate files).

js/main.js will handle the bootstrap processes for the MobileFirst Platform Foundation in the important method wlCommonInit().

Now let’s copy the contents of the Todo app into the MobileFirst Platform Foundation. The Git download actually provides a lot of artifacts that we don’t need. We will just take the artifacts needed to run the Todo app.

Before copying in the new code, rename the existing index.html to index.orig. We will need to copy some dependencies from the original afterwards.

Copy the following files from the Ionic Todo app on your file system into the MobileFirst Platform Foundation project. (You can just use drag and drop, or import from the file system.)

index.html – application user interface

js/app.js – application code

css/app.css – simple design overrides

lib folder – Ionic and AngularJS frameworks

It may be interesting to note that this application will now already run if you right-click on the common folder and select Run As > Preview. However, the MobileFirst Platform Foundation needs to bootstrap first, to ensure that all the MobileFirst Platform libraries are available to the application. The following steps walk through all that is needed there.

Make the following small changes to the application code:

Copy the MobileFirst Platform Foundation dependencies into the new index.html. Copy the three <script> tags from the bottom of index.orig and add them just inside the closing <body> tag. It is primarily the main.js and initOptions.js files that are of importance here because they help configure the MobileFirst Platform Foundation bootstrap.< /br>

From index.html provided by the Todo sample, remove ng-app=”todo” from the <body> tag. This would otherwise automatically bootstrap Angular before we’re ready for it.< /br>

While we’re in the index.html, remove the <script> tag containing “cordova.js”. MobileFirst Platform Foundation will provide access to all Cordova and related libraries.

Open the js/main.js file and add the following code to the wlCommonInit method. This will manually bootstrap AngularJS after MobileFirst Platform Foundation has been bootstrapped.

Preview the application by right-clicking on the common folder and selecting Run as > Preview. This should run the Todo app correctly in the browser. These small changes are all you need to run the Ionic (and actually any AngularJS) application in MobileFirst Platform Foundation.

I’d be interested to hear what other JavaScript frameworks have been used with IBM MobileFirst Platform Foundation. Are other considerations needed when using other tools? Please do leave comments or chat with me on Twitter at @jmarshall1.

This blog post contributed by Markus Van Kempen, a Canadian SAP Mobile leader.

Integrating SAP with different systems, websites or mobile applications has become necessary, and the good news is that it has also become more simple. Formerly, connectors and programming languages were more proprietary, but in the last couple of years SAP has opened its enterprise resource planning (ERP) system and adopted more standard technologies to enable easier integration. In this post, I’d like to show one example of how you can extract the number of workflow items from SAP for a user by enabling SAP services.

There are several ways to enable SAP services to consume SOAP or RESTful services (JSON, or JavaScript Object Notation). SAP has an add-on called “SAP Gateway” that allows service integration and service management in different configurations.

For development and prototyping, I like to use the JSON adapter for ABAP, since it can sometimes take time for the SAP Gateway to be installed or added to the landscape. ABAP is the SAP proprietary programming language. It stands for “Advanced Business Application Programming,” originally “Allgemeiner Berichts-Aufbereitungs-Prozessor,” which is German for "general report creation processor."

The JSON adapter for ABAP and information on how it can be installed and loaded into a SAP system are shown on this website. Once you have the JSON adapter enabled, all remote function calls (RFC) can be called using a URL, returning the input and output results in JSON format. (Note: other notations are also supported by the adapter.)

JSON is a lightweight data-interchange format and, together with jQuery, is a great way to build an application. There are different ways to parse the JSON results, but I prefer jQuery. In addition, SAP has its own query library called SAP UI5 that can be used to parse the JSON result.

Your SAP landscape then looks like what you see in the following graphic:

Of course what is shown above is a simplified landscape—you would need a SAP Web Dispatcher or a remote proxy to proxy the request and for the DMZ. Again, for development and rapid prototyping, this landscape is simple and perfect for fast development results.

Once you have the JSON adapter for ABAP set up, you can address RFC through a URL like this one:

The JSON adapter for ABAP supports GET and POST. To keep it simple, I just used GET to pass the input parameters. To add value in the transparent tables with the TASK_FILTER_TABLE element, you would need to use the POST method. For just reading data from SAP, the GET method will be sufficient in most cases.

Once you have the right RFC and figure out the parameter that you have to pass, you can use the URL and add it to your jQuery HTML code and display the information.

With the above-mentioned tools (jQuery and UI5) and a JSON-enabled SAP system, building simpler and more intuitive user interfaces for more productivity is not a secret anymore. SAP services, HTML5 and the modern responsive web design methods enable us to build native and mobile web apps faster than ever before.

This blog post is contributed by Kyle Craig, a software developer for the IBM Mobile Innovation Lab who enjoys playing around with new things.

With iOS 8, Apple has given developers the ability to expand the functionality of their apps to perform specific tasks even when the parent app isn't running. This expansion of functionality comes in the form of app extensions. The seven types of app extensions are:

Today

Photo editing

Storage provider

Document picker

Custom keyboard

Custom actions

And, the focus of this post, share

More information about the various types of app extensions can be found here.

The remainder of this article will detail how to set up a share extension to upload a single image to an IBM Bluemix database. I will cover the following topics:

Adding a share extension to your app

Adding a custom configuration option to your share extension

Verifying user input

Uploading the photo, message and configuration options all to a Bluemix mobile data back end

Requirements

Because extensions are an iOS 8 feature, you need to be able to develop for iOS devices. This means that at a basic level you need to have some understanding of Objective-C or Swift (example code will be in Objective-C) and have access to a Mac running Xcode 6 or newer to follow these steps. You'll also need access to the Bluemix Mobile Data SDK.

Adding the share extension to your app

After creating your project, adding an extension to it is a simple, straightforward process. In Xcode, simply select File > New > Target. This will bring up the following window:

As shown in the image above, select Application Extension from the left menu, and then select Share Extension in the center and click Next. In the next screen, give your extension a name and then click Finish. You should now be able to see a folder with your extension's name in your project directory as shown in the following image:

As you can see, the share extension comes equipped with an automatically generated view controller and a storyboard. For the rest of this tutorial, the storyboard will be ignored since it is only used by a share extension if you wish to create a completely new UI rather than using Apple's default share extension view (which you probably shouldn't do).

At this point, you can see your share extension, so go ahead and build your project. After your parent app has launched, press the Home button (Command+Shift+H on the simulator) to return to your home screen. Then select the Photos app. Once in the Photos app, select a picture to bring up a single view of it. It should look something like this:

Next, you want to tap the share icon in the bottom left corner. This will bring up the action center.

If you scroll the top panel all the way to the right you'll see a More button; tap that. This will bring up a configuration window where you can add and remove different share extensions from your action center's launch panel.

Here I have the Example Share extension turned off, and your app's new share extension should also be off. So turn it on! Once the extension is turned on, it will appear in that top panel menu for you to select, whereupon you should see something like the following image:

This default share extension view can be modified to give the user additional configuration options such as adding a location name or uploading to a specific album.

Adding configuration options

As you may have noticed by now, Xcode has generated three functions for you in the ShareViewController. These three functions are isContentValid, didSelectPost and configurationItems. In this section, we'll be focusing on configurationItems. This function is initialized to look like this:

- (NSArray *)configurationItems {

// To add configuration options via table cells at the bottom of the sheet, return an array of SLComposeSheetConfigurationItem here.

return @[];

}

So let’s create an SLComposeSheetConfigurationItem.

SLComposeSheetConfigurationItem *item;

- (NSArray *)configurationItems {

item = [[SLComposeSheetConfigurationItem alloc] init];

// Give your configuration option a title.

[item setTitle:@"Item One"];

// Give it an initial value.

[item setValue:@"None"];

// Handle what happens when a user taps your option.

[item setTapHandler:^(void){

}];

// Return an array containing your item.

return @[item];

}

Here we set up item as a global variable so that later when we return data from the tap handler we can set its value to the value selected by the user. Running your share extension again, you should see something like this:

This looks great, but it doesn't really do anything yet. Now we want to transition to another view controller that will handle how we want the user to configure that item. Begin by adding a second view controller to your share extension. This is done by right-clicking (or control-clicking) on the share extension's directory in your project explorer and selecting New File. From here, create a view controller class as you would for your parent app. Once you have your new view controller, you should go into ShareViewController.h and import your new view controller's header so you have access to it.

Now when you tap your configuration item, it will transition you to your new view controller. This view controller is completely blank by default, but you can build a UI for it programmatically just as you would for a regular view controller within your parent app. The ShareViewController also has a navigation controller built in, so the back button is automatically added to your configuration view controller.

After creating your configuration view controller, you'll probably want to pass that information back to the ShareViewController so you can upload it to your back end. This is done using delegates. First, in your configuration item view controller's header, you'll want to add a delegate protocol so that your header looks like the following example:

That is all you need to do in your configuration item view controller, but there is a bit more setup required in the ShareViewController. In your ShareViewController.h you need to add the delegate protocol to your view controller's interface like so:

At this point, you should have a share extension that now has a configuration item to add a bit of additional information collection from your parent app. Now we need to verify that what our user is posting is valid.

Verifying user input

There are various ways to verify what your users are trying to upload. The first type of content to check is the items that your user wants to upload. The example app I'm creating here is only meant to upload a single photo, so I'll run through how to limit your extension so that it will only be available when a single photo is selected. In your share extension's Supporting Files directory, there is a property list called Info.plist. At the bottom of this plist, there is a dictionary called NSExtension. If you expand this dictionary and the subsequent dictionary NSExtensionAttributes you'll find multiple other objects, but the one we're interested in is the NSExtensionActivationRule.

Begin by changing this object to a dictionary, and then add an object to it. To limit to only images, you want to name the new object NSExtensionActivationSupportsImageWithMaxCount and give it the “Number” type. Setting this key value to 1 will limit your extension to only showing up when the user has selected a single photo. The final plist should look like this:

Next, we'll use the isContentValid function to check whether or not the message your user has added in the extension complies with your standards. This method is called every time the user changes the content of the content text field (contentText). The following is a basic implementation of this function that limits the number of characters a user can have in his or her message.

At this point, you're getting pretty close to having a fully functional share extension. Your user interface should be finished, the extension should only show up for the content you want it to, and it should be able to do some basic content validation. Now you're ready to actually upload the information to your Bluemix back end.

Uploading to Bluemix

The first step to uploading your data to Bluemix is to connect to your back end. Begin by including IBMBluemix.framework and IBMData.framework in your share extension. These frameworks are part of the Bluemix SDK and will provide necessary functions and classes to connect to your back end. In addition to the SDK frameworks, you'll also need to add the libsqlite3.dylib library to your project. Now you just need to import the IBMData header and the IBMBluemix header in your ShareViewController.h. After all your frameworks and libraries are linked, you can begin writing the code to connect and upload to your back end.

The first thing you'll need to do is add a viewDidLoad function to the ShareViewController. This is where we'll connect to and initialize the Bluemix services. The following code is a very simple way to do this.

-(void)viewDidLoad {

// Connect to BlueMix

NSString *applicationID = @"";

NSString *applicationSecret = @"";

NSString *applicationRoute = @"";

[IBMBluemix initializeWithApplicationId:applicationID

andApplicationSecret: applicationSecret

andApplicationRoute: applicationRoute]; // There is a more secure way to store these in a plist, but this works for the example.

[IBMData initializeService];

}

If you also want to pass in information from your parent app, or validate the user, this is the function to do it in. Now comes the most important function in the share extension, didSelectPost. As its name suggests, this function is called when the user taps the post button in the top right corner of the extension view. Here is the code from the example's didSelectPost function.

UIImage *photo;

- (void)didSelectPost {

// This is called after the user selects Post. Do the upload of contentText and/or NSExtensionContext attachments.

Most of this code should be relatively straightforward, with the exception of the first block where the photo is loaded from the NSExtensionContext. The way an extension's data it set up is with a hierarchy of items and attachments. This block of code navigates this hierarchy, attempting to find an item attachment that is an image. Since earlier we limited our extension to only be available when a single photo is selected, we know that the image we find is the image we want to upload. The UIImage is made global so that it can be assigned within the completion block of loadItemForTypeIdentifier. The rest of the function is creating an IBMDataObject, adding all of our data to it, and then saving the data object to the back end. Finally, we use the extension context to close the share extension view.

Conclusion

Share extensions are an incredibly useful tool to expand your app's functionality with little to no hassle. I didn't cover everything you can do with a share extension in this post, but I hope that it at least gave enough information to get you started on designing a great extension for your app. As mentioned before, more information about app extensions can be found in Apple's official App Extension Programming Guide.

What can we do about this? The goal of mobile development is to get faster, to become more iterative and to increase agility, while maintaining or even reducing costs.

Here is the good news. While mobile development remains a fairly new area, still growing in maturity, there are already some well-established practices that can be applied to mobile to build security into your mobile solution from the start.

1. Automate application scanning

The key to maintaining rapid development cycles is to automate the scanning of the mobile application as part of development builds. That way security testing isn’t left to the end of the development phase but is integral to the iterative development and testing cycle. This increases the speed of development, reduces the cost of fixing issues and improves the security testing coverage.

Scanning tools, such as IBM Security AppScan Source, provide great coverage of security issues, such as the Open Web Application Security Project, OWASP. Importantly, these tools are also maintained and kept up to date with new security issues on a regular basis. It isn’t left to the developer to become an expert in each and every vulnerability as they are discovered.

2. Use proven architectures

All engaging mobile applications need to have access to real data and perform real transactions. This requires secure integration to cloud and on-premises systems. The top OWASP mobile risk is defined as “weak server-side controls.” This is a collection of the well-known web application security issues.

How do we provide secure access to this data? There is already a well-known deployment pattern, and we can use a lot of the learning that we have obtained over recent years with application servers and other middleware.

Don’t build a custom mobile gateway. Consider the security requirements for your solution, and use existing middleware that is hardened and proven.

One of the benefits that mobile has over traditional web security is that it can provide additional context to the request for data. We know what network, what location, whether the device is compromised (using IBM Security Trusteer Mobile SDK) and so on. This can provide input into our authorization decision by determining a risk factor. All this provides a great assurance of a secure infrastructure.

3. Encrypt sensitive data

It is also important to consider the security of the data. Gone are the days when security remains safe and secure behind enterprise firewalls. Data is going mobile, and it needs to be handled accordingly. Combine that with the fact that the mobile device and the mobile application can be compromised, and you can see how important it is to make sure that the data remains secure.

Only store the data you absolutely need. Don’t keep anything that is too sensitive, such as credit card numbers, on your device. Consider writing purging algorithms that periodically tidy up the data held offline.

Encrypt sensitive data when it does need to be stored. Technologies such as IBM MobileFirst Platform can provide an encrypted native database called JSONStore, which has strong encryption. This addresses the second highest risk identified by OWASP, “insecure data storage.”

Summary

As I mentioned, a lot of standards, styles and techniques for developing mobile applications are still maturing, but that doesn’t mean that security must be immature. There are great platforms and technologies available that can take the burden of building and maintaining secure mobile applications, mobile infrastructures and data away from the developer.

Do you have tips or techniques that you use to build good security into your development processes? Leave comments here, or contact me on Twitter at @jmarshall1.

This blog post is contributed by Yusuke Kobayashi, an IT Specialist for the IBM Japan Services Organization.

No one can avoid the big wave of mobile that we’ve seen in recent years. Some readers of this blog post might be enterprise application developers who are now facing a need for mobile application development. In this post, I will show you the differences between enterprise applications and mobile applications, and I’ll introduce some tips to overcome development barriers using an award-winning integrated development environment (IDE) for enterprise application development. I hope this will make it easier for you to learn as you become a mobile developer.

The paradigm shift from server side to client side in UI development

Java Platform Enterprise Edition (Java EE) technology, such as JavaServer Pages (JSP) and Java Servlets, or frameworks like JavaServer Faces (JSF) and Struts, might be familiar to all enterprise application developers. These technologies are processed on the server side. To be specific, when receiving a request from a client, the server creates the corresponding page on the server side and returns it as a response. In this way, user interface (UI) generations and transitions are handled on the server side in enterprise applications.

However, mobile users in recent years do not have the patience to wait for slow request and response times. You also probably don’t want to wait.

These server-side technologies are therefore not applicable for mobile application development. For mobile, it is necessary to load the page all at once (for example, during initial startup), and you must reduce unnecessary communication at run time. Only the required data is retrieved asynchronously when needed, and then a part of a page is replaced dynamically. To meet these needs, the server-side technology REST and client-side technology AJAX are used, especially in recent rich Internet applications, including hybrid mobile web applications.

Mobile-specific features

Mobile applications are quite different from traditional applications. It is not simple to migrate traditional applications to mobile. Traditional enterprise applications were designed to be used with a big screen, mouse and keyboard. Meanwhile, mobile devices have much smaller screens, and the data displayed might be quite limited. The user interface is becoming more and more important.

Mobile devices employ not only touch operation but a variety of inputs such as microphone, geo-location sensor, motion sensor, near field communications (NFC), fingerprint sensor and attached devices like barcode readers.

Four IDE support features

1. Remote Procedure Call (RPC) Adapter Services: This feature will convert existing services made by Enterprise JavaBeans or Plain Old Java Objects (POJO) to RESTful services, which communicate using JSON, XML or other languages asynchronously. This leads to reuse of your existing assets to services for mobile.

2.Model-driven REST service development: You may not have any experience with REST development, but you may have a lot of experience with design using Unified Modeling Language (UML). By applying the REST profiles and stereotype offered by Rational Software Architect to UML models, and then running UML-to-Java transformation, you will get the Java API for RESTful Web Services (JAX-RS) template code quickly.

3.WYSIWYG UI development (what you see is what you get): Since Rational Application Developer supports famous JavaScript libraries such as JQuery Mobile and Dojo Mobile, you can start writing UI codes to JQuery or Dojo templates (for example, layout including header, footer and some icon buttons like a native mobile application). And then you can easily put UI parts onto the layout using drag and drop.

4.Cordova support: Cordova is a platform for launching native APIs from JavaScript APIs. If you develop a mobile application using Cordova, you must know a series of commands—for example, Cordova create, platform add, plugin add, prepare, emulate and so on. Rational Application Developer makes these operations easier using GUI operations.

These features can help you to lower the threshold to become a mobile developer. However, the more you understand mobile applications, the more concerns you may have about mobile. For example, you may worry about secure data storage, secure data transfer, backend connectivity and so forth. In that case, IBM MobileFirst Platform Foundation, which specializes in mobile, will help you. As the applications made by IBM MobileFirst Platform are based on Cordova too, you will easily migrate your codes from Rational Application Developer or Rational Software Architect to IBM MobileFirst Platform.

If you have used this award-winning IDE, you should try these features. I’m sure it will help you to take your first steps forward as a mobile developer. Please share your thoughts with me on Twitter @yusukek829.

This blog post is contributed by Spencer Hockeborn, a mobile and cloud technologies developer in the IBM Software Group.

Application developers have to consider many things when testing their apps, including easy-to-operate user interfaces, visual flair, consistency and speed. App speed becomes increasingly important when the app loads and displays remote data. The developer can bypass these slow network calls during testing by replacing the remote calls with local sample data. When it comes to testing, developers look toward simple tests that are fast but also effective. The stubbing method is very popular for creating simple tests; however, a common programming mistake is to assume that all tests can be run with stubbed data, completely bypassing testing with remote data. The unfortunate result can be a final product with inefficient network calls and poor data caching, resulting in slow performance for the user.

Say you are a developer for an airline working on an iOS app that gives flight attendants information on their upcoming and past flights. We can call this app “FlightCrew.” Within FlightCrew is a method that grabs the flights from a remote database and splits them up into past and future flights, and it needs to be tested. See the Swift implementation below.

You only want to test this particular method and how it handles the data, and you want it done fast (besides, being the thorough developer that you are, you have already created test methods to verify your basic network calls). No problem: you can just replace that pesky database query with a call to grab some local JSON files containing some made-up flights.

XCTAssert(LoginViewController.upcomingFlights.count == 1, "Should be at lease one upcoming flight")

XCTAssert(LoginViewController.upcomingFlights[0].compare(currentTime) == NSComparisonResult.OrderedDescending, "Upcoming flight should be in the future")

XCTAssert(LoginViewController.pastFlights.count == 1, "Should be at least one past flight")

XCTAssert(LoginViewController.pastFlights[0].compare(currentTime) == NSComparisonResult.OrderedAscending, "Past flight should be in the past")

}

The above test runs quickly, and the method sorts the flights as you would expect. Running the application in the simulator turns out perfect, so you call the method good and move on.

Fast forward to your app’s deployment and ... defect, defect, defect! You start getting complaints that the app is way too slow. Turns out your app is making some inefficient queries, loading large amounts of data and not caching any of the results. Although it is tempting to call the problem a hardware error, the true error comes from not testing with realistic amounts of data coming from a remote source.

Bulk sample data gives insight into app performance that a couple of local files cannot. It is certainly viable to use local files for initial testing, but when it comes down to how the app will run in the hands of the user, bulk remote data and how it's retrieved need to be considered. Testing with remote bulk data is a great way to see how an app will perform when querying for hundreds of data objects, as opposed to grabbing a few local JSON files. In the case of the FlightCrew app, we learn to use better queries, limit the amount of flights we pull and cache the data—all in an effort to optimize the app's performance. The limitations of query performance and the necessity for data caching became clear once remote, realistic data was used during testing.

There are a few mock data generators out there that will create as much sample data as you need (such as Mockaroo and GenerateData). Just provide a property name, a data type and a quantity, and a .csv file is spit out for you to download. The data can then be loaded into the back end and accessed later by the application. These generators are limited to the data that the owner uploads. Common data properties like names or cities are available, but specific properties like airport codes are not.

Creating the randomized data on your own is a more customizable option. Node.js extensions exist to create random Universally Unique Identifiers (UUIDs), random strings and random numbers, but more unique data can be generated by providing a list of possible samples and accessing that list through a random number function. FlightCrew uses this strategy when creating a group of sample flights from a node back-end service. All of the airport information comes from a list of airports in a JSON file loaded into the back end, accessed through the node's random number function. See the example below.

FlightCrew uses several of these custom lists to choose the remaining flight information, including arrival gates, departure gates and flight status. UUID generators and string generators are provided by open source node extensions “node-uuid” and “randomstring.” The app's random data generator also creates sample customers, passengers, crew members, airline employees and employee messages in addition to the sample flights.

Cron jobs can be used to create data periodically, or creation can be kicked off by a simple REST request. For example, to create the sample flights, a payload is sent in a post request to the node sample data generator. The payload describes how many flight plans are required, how many links in each flight plan and what class name the object should fall under in the database (in this case, “Flight”). Send the following POST:

The node app then begins the creation of all 300 flights using randomly selected data and saves them in the remote database. By writing the random data generator, we have established a way to make as much random data as we need, whenever we need it, by the click of a button.

Custom data generators also give the opportunity to establish relationships with other objects. Every flight needs passengers, and each passenger object needs customer information. When an object is saved within a database, it is assigned a unique ID. Different objects can then be linked through properties containing the related objects' database IDs. These IDs can also create linked lists between objects of the same class. For example, flight attendants fall under the “Crewer” class, and the “Crewer” class contains a “next_crewer” property. FlightCrew then uses this property to let the flight attendant know all the information about their past and future “Crewer” positions.

The important thing to remember is to cover all possibilities when writing tests for your app. Querying for one or two objects may run quickly, but when it comes time for the real use cases, those queries may be slow. Bulk remote data will provide a way to cover this base, with options to create your own data or use open source services to do so.

This blog post is contributed by David Marshak, who focuses on IBM's MobileFirst Platform, Bluemix Mobile Services, and strategic partnerships in the mobile space.

I am confident that 2015 will be dubbed the year of the wearable. The introduction of the Apple Watch will validate the ever-growing number of devices and use cases that we currently see on the wrists, lapels and even faces of early adopters. Wearables are the first real wave of the Internet of Things (IoT), where virtually everything will have a connection to everything else. The reason wearables lead the IoT is that they have a killer application: personal health. Tracking steps, miles, heartbeats and sleep has both perceived and real benefits to a wide variety of individuals.

Classes of wearables

Wearables come in two classes: dedicated wearables and wearable accessories.

Dedicated wearables are stand-alone (generally single-purpose) devices, meaning they can operate by themselves without continuous connection to a smarter device such as a mobile phone.

Dedicated wearables are not limited to the many step-tracking wristbands that have become the emblem of the health-conscious, tech-savvy set. One interesting example that I have seen is SunSprite, a small lapel-clipped device that measures and tracks how much light you are getting and lets you know if you need to get outside more or use some sunscreen. Another lapel device is Lumo Lift, which warns you when your posture is bad.

These devices clearly fall into the health category. But there are two other types of wearable applications that hold great promise. I call these access and payments wearables. Access wearables allow people to enter or leave areas without having to use a key, badge or other pocketable artifact. This could be an employee badging into a corporate building or a doctor entering an operating room; or it could be a child leaving a playground or yard. We already have a good parallel for wearable payments with transponders for cars going through tollbooths. This can easily be extended to people using mass transit, entering a theater or riding a taxi. Interestingly, the best example of both is the same device: the Disney MagicBand. This wristband is both the key to your room at a Disney hotel and a way to instantly pay for items at the Disney theme park.

Wearable accessories are devices that require connection to a smart device (such as your phone) for communication and data storage. They are generally multipurpose devices, the smart watch or smart glasses being the best examples. Wearable accessories are poised to replace some of the dedicated wearables, particularly in the area of health.

What this means for mobile applications

From a mobile app development point of view, dedicated wearables tend to be closed systems. The company that owns the device tends to own the application or applications that are enabled. However, some companies might be able to provide unpublished application programming interfaces (APIs).

Let's say you want to build an app that warns you if you are starting to fall asleep when driving. It would be very cool to use something like the Lumo Lift to trigger the warning, and the company’s website does mention private APIs, so you might be in luck. But in most cases, a device would need to be modified and APIs would have to be opened up. So unless you are heavily investing in the devices themselves, you should probably focus more on wearable accessories.

Wearable accessories tend to be open systems, with APIs available to add capabilities to and/or pull data from the device, as well as developer support. There are now growing ecosystems around iOS and Android wearables, and soon we’ll likely see mobile application platforms, such as IBM MobileFirst Platform, to support wearables.

Key considerations for wearables

If you are planning to incorporate wearable accessories into your mobile application strategy, first consider whether your target users will actually wear the device when you need them to. In other words, is the wearable accessory always with the user? The answer isn't just a simple yes or no. It needs to be compared to the current "always-with-you” device: your mobile phone.

Let's look at the smartwatch. Do you wear a watch? I do, and I almost always have it on (when I also have my phone). However, my kids do not wear watches. Their phone is their watch, and it’s farfetched to think that they’ll start wearing one (however cool) to get information that they already have on their phones. That said, we who do wear watches will likely want more features before we consider that our primary device. The phone will still be the default, go-to experience.

A second consideration is what should be written to phone experience versus device experience. Aside from the inelegance of having duplication on both devices, we do not yet have any best practices on what we should run where. Low-level considerations such as battery life, storage and communications are important factors. More significant will be when the user experience is actually different—for example, how much of a benefit is it to swipe your watch (versus taking out your phone) to pay for your coffee?

Until we better understand the benefits and desired user behavior and outcomes for wearables, I would recommend that the main focus remain on the phone.

Ultimately, we may find one or more perfect wearables, but today the phone is always primary (and even required), and the wearable remains a nice to have—or in the case of the Apple Watch, a very nice to have!

To share your thoughts on wearables, please connect with me on Twitter @DavidMarshak.

This blog post is contributed by Nick Gibson, an analytics developer for IBM Passes.

We’re always excited to play with the hottest features from each new version of iOS, but the recent rollout of iOS 8 is especially important to us given this year’s announcement of a new IBM-Apple partnership focused on the mobile enterprise. Swift—Apple’s new programming language—is arguably one of the most interesting features in iOS 8, and people are already starting to ask questions about how to use the Mobile Cloud Services on IBM Bluemix from a Swift context.

One of the first things unique to Swift is how to import the MQA framework into your project. Although the MQA frameworks—and indeed all Mobile Cloud Services SDKs—are written in Objective-C, Swift supports full interoperability with Objective-C code. You’ll just need to add a bridging header file to your project and specify the MQA frameworks you want to use. For example, here is our bridging header, called “bluelist-mobiledata-swift-Bridging-Header.h”:

#import <IBMBluemix/IBMBluemix.h>

#import <IBMData/IBMData.h>

#import <Q4M-Pre-Production/APHLogger.h>

#import "MQAExceptionHandler.h"

The first two lines make the core Bluemix SDK and the Mobile Data SDK visible to Swift code. The third performs the same bridging operation for the MQA framework. We’ll get to the last line in just a moment.

You’ll also need to add this new bridging header to your project’s build settings, as shown in the following screen capture:

Now that you have access to the MQA frameworks from Swift, you can instrument the service inside your app. That is where we encounter our second hurdle. In Objective-C, we need to add the following line to our AppDelegate in order to enable crash reporting:

NSSetUncaughtExceptionHandler(&APHUncaughtExceptionHandler);

Unfortunately, this line doesn’t work in Swift because Swift does not (as of yet) support passing function pointers. And because we cannot create an Objective-C pointer to a Swift function nor call an Objective-C pointer from Swift, we’re forced to use a workaround. Specifically, we need to create a new Objective-C class we’ll call “MQAExceptionHandler.” Here’s the header:

#ifndef bluelist_mobiledata_swift_AppDelegate_h

#define bluelist_mobiledata_swift_AppDelegate_h

volatile void exceptionHandler(NSException *exception);

extern NSUncaughtExceptionHandler *exceptionHandlerPointer;

#endif

Xcode creates the if-define line automatically when you add an Objective-C class to your Swift project. All we’ve done is first declare a function called exceptionHandler” that takes a pointer to an NSException, and then declare an NSUncaughtExceptionHandler pointer.

Again, nothing too remarkable. We can implement the exceptionHandler() method however we want and then create an Objective-C pointer to that method.

Now we can go back to our AppDelegate and enable crash reporting using our workaround:

NSSetUncaughtExceptionHandler(exceptionHandlerPointer)

And that’s it! We can continue to instrument MQA in our Swift application without any problems. If you’d like to jumpstart your own project with our source code, navigate over to JazzHub and download it!

I hope you found this instructive. If you did, check back to this blog from time to time as we will continue to explore the intricacies of iOS 8 and IBM Mobile Cloud Services.

This blog post is contributed by Danny Fundinger is a Mobile Payments enthusiast on Mobile Payments and Mobile Wallets at IBM Global Business Services in Germany.

Over the last few years, whenever I’ve spoken with clients about mobile payments or wallets and near-field communications (NFC), I have repeatedly heard the same response: “we would be interested, if only the iPhone would also support it.” Since this autumn, this excuse has vanished. Apple Pay is now available, and, indeed, it supports NFC.

I am deeply impressed with Apple Pay so far; Apple seems to have done many things right. Not only does it have the superior user experience that you expect from Apple; it also has state-of-the-art security and privacy with a secure element and tokenization, coverage of proximity and remote payments cases, full wallet integration and cooperation across the payments ecosystem. Apple is very conscious about which parts of the ecosystem it can control and which it cannot. Hence, it’s no surprise that the network of partners is already huge.

The challenges ahead are still significant. In the US, the first launch market, the coverage of NFC terminals is low. The number of merchant establishments accepting electronic payments in the US is around 7 million (which is only 35 percent of all 20 million merchant establishments in the retail and hospitality sector). But only 220,000 of those stores accept NFC payments, or as little as 3.1 percent. This is far from being a critical mass. Making payments is a routine task for all of us, and behavioral patterns change slowly.

Early iPhone 6 users will eagerly wait to pay for the first time with their phones, and when they find the first NFC-capable acceptance terminal, they will be impressed by the ease of use. But what happens next? In more than 96 percent of payment cases, NFC payments are not accepted. The level of frustration can quickly reach the tipping point when users don’t bother asking anymore and simply use a credit card or cash—the payment patterns users are already accustomed to. Though NFC payments are quicker and easier, users will give up trying after a couple of times, even ones who are in the payments business like me.

Solving the issue of low NFC adaption in the retail world is a highly complex task. Even though Apple has a premium position and the market awareness to push adoption, there are also strong forces against it. Retailers in the US struggle with EMV migration and don’t want to get even more dependent on the international card schemes underlying Apple Pay. Transaction fees of 2 to 3 percent are a massive burden for merchants. The MCX initiative, founded by retailers as an alternative to Visa and MasterCard, might not be successful and appealing to the user, but the alliance still has the market power to seriously damage or even abandon other mobile payments initiatives in the US, including Apple Pay.

Interestingly, the situation in Europe is completely different. Due to market regulation of interchange fees by the EU, fees on Visa and MasterCard payment transactions will be capped at 0.2 to 0.3 percent, which is a fraction of the US fees. Hence, European retailers are more likely to support Visa and MasterCard transactions. In European countries with strong national card schemes, like girocard in Germany, the international schemes will even have the potential to gain significantly larger market shares. This sounds like fertile ground for Apple Pay—but maybe only at first glance. As much as the retailers benefit from regulation, the banks will suffer. Their revenue will be drastically cut down. Considering that Apple requests 0.15 percent cut of purchases, the banks would lose half of their remaining transaction fees’ turnover. There is not much left for a profitable business case, and it is highly doubtful that many banks will support Apple Pay under these circumstances. Hence, in Europe probably the banks, and not the retailers like in the US, might become a showstopper for Apple Pay.

So, will the Apple Pay revolution fade out? Certainly not. In the worst case, Apple Pay will change the mobile payments market as much as Google Wallet did. Google Wallet’s approach pushed new innovations into the market that were broadly adopted by many other players for their NFC payment solutions. Apple Pay will likely be more successful due to excellence in execution, and it could play a big role in helping to overcome at least some of the current market hurdles for mobile payments.

The payments market has already been shaken up this autumn; it will never be the same again. Every stakeholder in the ecosystem is somehow impacted by Apple Pay, and this fires dynamics that cannot be stopped. The revolution has started.

14. Adjust the main.js, hybrid.js, MainPage.js, Page1.js and Page2.js as shown in the attached project source to allow interaction with the native UI.

15. To enable the Android back button in our navigation, we use the android.R.id.home system resource and send a click event to the JavaScript code with an ID of “backButtonClicked.” See the implementation in HelloWorklight.java Android activity.

The combined application does not support Option3/Action #3 from the blog post, and the HTML back buttons of the multi-page application do not reflect in the action bar.

This blog post contributed by Michael Wuerdemann, who works with banks, insurance companies and other clients on their collaboration strategy.

Many mobile devices come with an email client that is built in to the device. These mail apps are well integrated into other apps with notifications, reminders and—finally yet importantly—as a target for the “open with” feature that lets you send any file as an attachment through email.

In this post, I would like to discuss why IBM, like many other vendors, provides a separate app to access email, contacts and calendar information. Many companies are using a separate app because it is not only about email anymore. IBM Verse for iOS, for example, integrates chat, web meeting and analytics capabilities as well as company-focused applications like SAP using a feature called “embedded experiences” from the OpenSocial standard. Today, employees expect an integrated, digital workplace, even when they are working on mobile devices.

Must haves and state-of-the-art features

When I am on the go, built-in apps provide me with access to some basic must-have information I need:

Emails

Calendar entries

Corporate address book

In addition to this, I use apps with more state-of-the-art features in order to:

Get presence awareness information (who is available?)

Start or join a text-based chat

Host or attend web meetings

Access my social enterprise network

Access my files (documents and media files)

Most companies prefer not to store their confidential documents or sensitive personal information about clients or employees in the cloud. IBM, for instance, protects intellectual property and personal data by using its own infrastructure (cloud and on-premises based) and software to protect this environment. Therefore, most IBM users currently have a mixture of built-in apps and apps provided by IBM.

How to be mobile and remain productive: IBM’s secret sauce

One problem of using numerous applications to get your work done is that your IT department has to manage them, but this isn’t a big issue if you are using a mobile device management solution. The bigger problem is the effect on your productivity if you have to keep an eye on many apps to stay up to date on your inbox, activity stream, meetings, documents and so on.

To solve that problem, IBM has integrated all of its collaboration products. For example, if you want to share a file in your meetings app, you do not have to download it from your social network first; you can just add it to your meeting’s library from “My Files.” As another example, my IBM Sametime Meetings app is aware of my IBM Connections account and provides access without any extra login.

The logical next step: IBM Verse

Wait—how can we integrate our broad spectrum of collaboration tools into another vendor’s app? Moreover, how can we take advantage of IBM’s analytics capabilities to organize and prioritize the flood of emails?

The only way to do this was to build our own mail app for IBM Verse, our latest mail and calendar user interface (UI) based on IBM Domino.

IBM Verse integrates real-time communication based on IBM Sametime or IBM Connections Cloud, the enterprise social network based on IBM Connections, as well as analytics to make suggestions from your social graph. In addition, IBM Verse for the desktop adds functions like “mute” or “post to blog,” and of course we expect the IBM Verse for mobile devices to provide the same productivity tools.

To me, IBM Verse is an example of how modern mobile apps should be built, with the following capabilities:

Awareness of other complementary apps, providing single sign-on and avoiding redundancy

Integration of all capabilities in one user interface, without the need to switch apps

Intelligent design that’s easy to learn and use, including suggestions based on users’ behavior

If you want to discuss IBM Verse or mobile collaboration in general, don’t hesitate to connect with me on Twitter @wuerdemann. I would love to learn more about your point of view!

This blog post is contributed by Bruce Armstrong, an IBM Portfolio Manager in Software Group for Application Infrastructure Middleware working on all aspects of mobile and System z.

For those of you looking for a screaming server-side JavaScript environment, your search is over. IBM recently made available IBM SDK for Node.js Version 1.1* for Linux on System z. It is ideal for high-performance JavaScript server applications or to consolidate many server applications to one system to save time and money.

So what makes System z ideal? Let’s list some of the reasons:

Simplicity and speed in one: Node.js is a single-threaded processing model. Its simple design is to manage the event processing of real-time web applications very efficiently. IBM System z is the fastest general-purpose processor available today at 5.5 GHz. Combine Node.js processing design with System z speed and you have an environment well suited for JavaScript applications.

Simultaneous operations: Processor speed is just one indicator of computer performance. It is important to understand that System z is a collection of general purpose and specialty processors in one box. The specialty processors used for input/output (I/O) to storage devices and network communications operate independently, but in coordination with the general processors. Node.js was designed for this type of environment where processing is not blocked waiting on slower I/O operations. The ability of Node.js to spin off processing to these special processors provides enhanced workload throughput on System z.

Connections, connections, connections: Node.js scalability comes from its ability to maintain thousands (tens of thousands) of connections. System z is built to support thousands of concurrent connections. There are several techniques for supporting large numbers of connections, ranging from having multiple network adapters to having multiple instances of Linux for System z and having many gigabytes—up to terabytes—of memory. System z capacity is yet another “sweet spot” for Node.js.

Adjacency to enterprise data and transactions: System z can provide another advantage to JavaScript applications that need access to enterprise data and transactions. System z can be logically divided into separate processing environments and linked together by high-speed networking communications called HiperSockets. To the applications running on System z, HiperSockets appears as a standard TCP/IP network but is actually memory-to-memory communication with drastically improved performance. JavaScript applications can use HiperSockets to access data and transactions in other logical machines inside the box.

So what does all this mean in the real world? Internal testing has shown System z with Node.js to perform 29 to 63 percent higher** compared to similarly configured Intel hardware environments. The 29 percent performance improvement was achieved when running the Acme Air benchmark. A 63 percent improvement was in throughput on an HTTP server hosting simple "Hello World" content. It is important to note that these results were obtained in a controlled environment with relatively simple test cases. It nonetheless shows the possible performance benefit for JavaScript applications on System z.

So how best to get started? IBM SDK for Node.js Version 1.1.0.9 is equivalent to the latest Joyent Node.js Version 0.10.33. You can download node binaries for Linux for System z from developerWorks, and the code is also available from these repositories:

Back by popular demand......it's time for an update to the original MQA Study Group!

New client value features were added to MQA since it's launch and attend this brief event to find out how to leverage them!

Agenda:
* 15-20 minute overview (name change, new features)
* Followed by Q&A
* And a homework assignment to help you make it real by applying your learning right away!

This event is Part 1 of 3::
* Part 1 - New Q4 client value features in 20 minutes or less! 6 November 2014, 9AM ET USA
* Part 2 - a similar event for Australia-specific time zones (new features for Australian appstores) 20 November 2014, 5PM ET USA

This blog post contributed by Klaus-Peter Schlotter, a member of the IBM Software Services for Websphere team based in San Diego, California.

IBM Worklight allows you to write hybrid mobile applications using your favorite JavaScript framework. jQuery, Dojo and Sencha Touch can be preselected in the application creation wizard, and other frameworks can be added manually.

But what if you start creating mobile applications or you have only worked with native mobile environments? Which framework should you use?

In a recent project with an independent software vendor (ISV) I found out that choosing a framework that is not suitable to the developers can slow down application development dramatically and generate a bad impression of hybrid mobile app technology.

Therefore I will use the following guidelines in my future education sessions:

jQuery: If you start developing mobile applications with IBM Worklight and do not yet have experience with one of the available frameworks, jQuery might be the perfect fit for you. There is a large community on the Internet supporting this framework, and, even better, there is a lot commercial literature available that gives a good introduction to various aspects of mobile application development. IBM is now a corporate member.

Dojo: The Dojo framework is shipped with many IBM products such as IBM Domino, IBM Connections, IBM WebSphere Portal and others. If you have already created web applications that integrate with one of these products, you may have already used Dojo, and therefore it would be a good choice for you. There is a good chance that you have code available that you can reuse for your mobile projects.

IBM has provided a lot of code for the Dojo toolkit.

There is not as much third-party information available for Dojo as there is for jQuery, so it might take more time to get familiar with it.

Because of asynchronous module definition (AMD) in Dojo, it can be more complex to handle the JavaScript code in your application.

Sencha Touch is also a popular web framework that supports quite a number of mobile platforms. You can find plenty of good third-party information about Sencha Touch, but it is not so commonly used to integrate into IBM products.

When you select the right framework, nothing will stop you from creating powerful hybrid mobile applications with IBM Worklight.

Do you have any experience with these frameworks to share? Follow me on Twitter, @kpschlotter, to continue the conversation.