In this chapter, we will cover some advanced topics and provide you with complete knowledge of the implementation of features detailed here. If we summarize what we have covered so far, then we'd realize that we have worked on the basics of IBM Worklight. This includes components, frameworks, client- or server-side development, UI implementation, configuration, and development of IBM Worklight application and authentication concepts. Now, we will move on to some advanced development concepts using IBM Worklight Studio, which contains the WL Client API, a push notification mechanism, Cordova plugins, some UI common controls, encrypted cache, offline access, and JSONStore.

As you know, Worklight doesn't provide a proprietary development language or any model that the user has to learn specifically. It simply uses web technologies such as HTML, JavaScript, and CSS to implement IBM Worklight, a development concept of the hybrid mobile application. A completely deployable native app would be generated if you use mobile hybrid applications, and the application can use native components within an HTML page. It allows the SDK that includes mobile platform libraries through which you can access the native code.

After the development of the application, some advanced topics need to be covered to enhance the mobile application's functionalities to its maximum capabilities.

Push notification

Mobile OS vendors such as Apple, Google, Microsoft, and others provide a free of cost feature through which a message can be delivered to any device running on the respective OS. The OS vendors send a message commonly known as a push message to a device for a particular app. It is not required for an app to be running in order to receive a push message.

A push message can contain the following:

• Alerts: These would appear in the form of text messages
• Badges: These are small, circular marks on the app icon
• Sounds: These are audio alerts

Messages will appear in the notification center (for iOS) and notification bar (for Android). IBM Worklight provides a unified push notification architecture that simplifies sending push messages across multiple devices running on different platforms. It provides a central management console to manage mobile vendor services, for example, APNS and GCM, in the background.

Worklight provides the following push notification benefits:

• Easy to use: Users can easily subscribe and unsubscribe to a push service
• Quick message delivery: The push message gets delivered to a user's device even if the app is currently not running on the device
• Message feedback: It is possible to send feedback whenever a user receives and reads a push message

Device and platforms support

Currently, IBM Worklight supports push notifications on the following platforms:

• Android
• iOS
• Blackberry
• Microsoft

These OS vendors are named as push mediators in the push notification context.

Worklight push notification concepts and terminology

The following are some terms and concepts you should be familiar with:

• Event source: An event source is declared inside Worklight Adapter, which works as a channel to register mobile applications for push notifications. The following code snippet can be used to declare notification event source in adapter JavaScript code and must be declared as global level:

  WL.Server.createEventSource({
    name: 'PushEventSource',
    onDeviceSubscribe: 'deviceSubscribeFunc',
    onDeviceUnsubscribe: 'deviceUnsubscribeFunc',
    securityTest:'PushApplication-strong-mobile-securityTest'
  });

• Device token: Push mediators such as Apple or Google assign a unique ID to a specific device in order to deliver messages. The Worklight server uses these IDs in order to send push messages.
• User ID: Worklight collects a unique ID for a specific user through authentication or other unique identifiers such as a persistent cookie.
• Application ID: A Worklight application ID identifies a specific Worklight application.
• To send a notification: The following adapter function will be used to send a push notification message. Here, the adapter function is accepting two parameters, userId and notificationText, and finding the user subscription for a particular user ID and then notifying the device by responding to the notificationText message:

  functionsubmitNotification(userId, notificationText){
    varuserSubscription = 
      WL.Server.getUserNotificationSubscription('PushAdapter.PushEventSource', userId);
    
    if (userSubscription==null){
      return { result: "No subscription found for user :: " + userId };
    }
    
    WL.Logger.debug("submitNotification>>userId :: " + userId + ", text :: " + notificationText);
    
    WL.Server.notifyAllDevices(userSubscription, {
      badge: 1,
      sound: "sound.mp3",
      activateButtonLabel: "ClickMe",
      alert: notificationText,
      payload: {
        foo : 'bar'
      }
    });
    
    return { result: "Notification sent to user :: " + userId };
  }

• Subscribing/unsubscribing: A mobile app needs to subscribe for an event source in order to receive push messages. Worklight provides the WL.Client.Push.subscribe() API function to register the device against a push services mediator, and in return, it collects a device token. The following code shows how to use the API function to subscribe for an event source:

  WL.Client.Push.subscribe("myPush", {
      onSuccess: pushSubscribe_Callback,
      onFailure: pushSubscribe_Callback
  });

In order to subscribe to a device for push service, the user must approve it first. Upon the user's approval, the device registers itself with an Apple or Google push server to obtain a token value; it also sends a subscription request to Worklight Server. All of this is automatically done by the Worklight framework.

Worklight Server stores users' subscription information in a database. It stores device IDs, token, and event source details. Unsubscribing to a device can happen in either of the two ways: either by calling the WL.Client.Push.unsubscribe() API function or the push mediator, which informs Worklight Server that the device is permanently not accessible. An example code to unsubscribe to a device is as follows:

WL.Client.Push.unsubscribe("myPush", {
    onSuccess: pushUnsubscribe_Callback,
    onFailure: pushUnsubscribe_Callback
});

The following figure describes how the push notification works within Worklight:

Push Notification flow diagram

Note

When a request to unsubscribe to a device is received by Worklight Server, it automatically clears the corresponding device token and related attributes from the push tables.