Part 2: How to setup Push Notifications in iOS

Introduction

In the first part of the blog series on push notifications, you have been provided an overview of what push notifications are all about, basic pre-requisites for implementing push notifications in iOS, key takeaways and some of challenges pertaining to push notifications. This blog is a continuation of the earlier blog which focusses on the configuration aspects of push notifications.

As outlined in the first part of this blog series, Apple introduced push notifications to let applications respond to events, even if the applications aren’t running in the forefront. Push notifications notify an application about vital events and to enable the engagement of the users.

Pre-requisites

Before we start configuring push notifications, let’s recall some of the basic pre-requisites, already covered in my earlier blog.

Put it in a simplest manner, you need two things to get started with the process of sending push notifications:

1. Requirement of a physical device (since iOS simulator doesn’t support push notifications)
2. Requirement of a paid iOS developer account; only paid accounts can provision applications to run on a physical device.

I. Project Setup

1. Click Single View Application template to open Xcode to create a new project, based on the single view application template.

2.  In the Choose options for your new project: screen:

• Type push in the Product Name box.
• Type a company identifier and class prefix in the respective boxes.
• Click iPhone from the Devices box.

II. Registration

1. Open TSPAppDelegate.m and update the application:didFinishLaunchingWithOptions: as shown below.

Here, you are calling registerForRemoteNotificationTypes: on the application object, passing in the notification types you are                                  interested. This ensures that the operating system now knows that the application is configured to receive push notifications.

(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
               // Register for Remote Notifications
               [application registerForRemoteNotificationTypes:(UIRemoteNotificationTypeAlert | UIRemoteNotificationTypeBadge |                                          UIRemoteNotificationTypeSound)];

               return YES;
               }

The operating system contacts the Apple’s servers and gets a “device token” to uniquely identify the device from which the application is running. This device token is used by your server infrastructure to send push notifications. This is accomplished by sending the device token along with the actual push notification to Apple’s servers. Apple servers take the charge of distributing the push notifications to the appropriate devices.

Make a note that the device token differs for each application and it can even alter over time for the same application. Apple therefore recommends asking for a device token every time the application is launched and send the device token to your backend to ensure that the device token is up to date.

The following methods tells your application whether the registration for remote notifications is successful or not:

•  application:didRegisterForRemoteNotificationsWithDeviceToken:
• application:didFailToRegisterForRemoteNotificationsWithError

As of now, implement these methods as shown below.

(void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken {
NSLog(@”Did Register for Remote Notifications with Device Token (%@)”, deviceToken);
}

(void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error {
NSLog(@”Did Fail to Register for Remote Notifications”);
NSLog(@”%@, %@”, error, error.localizedDescription);

Both methods are declared by the UIApplicationDelegate protocol. This protocol also declares another method, application:didReceiveRemoteNotification:, which is invoked when the application receives a remote notification.

The application:didReceiveRemoteNotification: method delivers you the payload of the push notification as an NSDictionaryobject. Your application needs to decide how it should respond to the push notification.

If you run your application, then the application:didFailToRegisterForRemoteNotificationsWithError: method will be invoked.

III. Configure SSL Certificate creation

To complete the next step, you need to sign into your iOS developer account at Apple’s iOS Dev Center.

The following are the steps to accomplish this:

1. In the Certificates, Identifiers and Profiles screen, click Identifiers under the iOS Apps section.

2.  Click the + button on the top right corner and type an App ID description to help you identify the App ID later.

3.  Click Explicit App ID, instead of Wildcard App ID from the App ID Suffix box.

4.  If you want the application to receive remote notifications, type com.tutsplus.push (instead of com.tutsplus) in the Bundle ID box.

5.  Under App Services, click Push Notifications. Click Continue to submit the form and finally click Submit to create the App ID.

6.  From the list of App IDs, select the one you just created and click Edit.

7.  Scroll down until you see the section that covers push notifications, where you can view two buttons labeled Create Certificate as shown below:

 IV. Create an SSL certificate

1. Select Keychain Access on your development machine.
2. From the Keychain Access menu, click Certificate Assistant > Request a Certificate From a Certificate Authority. Double-check to ensure that no key is selected in Keychain Access, when you select this option.
3. In the Certificate Assistant screen, type the email address and a common name to help you identify the certificate later and click Saved to disk.
4.  Click Continue and save the certificate signing request to your hard drive. This way you’ve created a certificate signing request as well as public and private keys. You can view the keys in the Keychain Access (as shown in the screen shot below).

5.  Revert to the iOS Dev Center and click Create Certificate.

6.  Next click Continue, click Choose File to upload the certificate signing request and click Generate to generate the SSL certificate.

7.  Now download the certificate and double click on it to install it in Keychain Access.

8.  Double-check that the certificate is added to Keychain Access and linked to the appropriate private key.

V. Create a provisioning profile

Before you proceed to test your push notifications setup, you need to create a provisioning profile for your application.

1. From the iOS Dev center, click Development in the Provisioning Profiles section.
2. Click the + button on the top right corner and click iOS App Development under the Development section.

3.  Click Continue and select your App ID from the list

4.  Select the certificates you want to include in the provisioning profile and click Continue.     

              Note: Make sure your test device is also included.

5.  Type an appropriate name for your provisioning profile and then click Generate.

6.  Download the provisioning profile and drag it in Xcode to add it.

7.   Update your target’s building settings in Xcode to use the new provisioning profile.
8.   Build and run your application to ensure that everything is proper and works accordingly, as desired.

If you encounter any issues while running your application, double-check to ensure that the bundle identifier of your application                   matches with the App ID (bundle identifier is case sensitive).

If you have followed all the steps as outlined above, your application should generate a prompt message as follows:

9.  If you tap OK, your application will ask the operating system for a device token. In case if it is successful, the application:
didRegisterForRemoteNotificationsWithDeviceToken: method of the UIApplicationDelegate protocol is invoked, handing you the device token. Since we have already included a log statement to this method, the device token should also be logged to the console in Xcode.
Push[2182:60b] Did Register for Remote Notifications with Device Token ()
}

VI. Ensure proper backend is in place

Now that you have successfully accomplished all the above steps, the final step is to make sure that you have a backend in place to ensure that your application can send the device token to it. This is required to test whether your push notifications you had send have successfully arrived or not. That backend can then connect with Apple’s servers to send push notifications. This is the simplest part of the configuration, especially when you are using a service like Parse or Urban Airship.

Conclusion

I hope this blog has provided you an overview of the configuration setup for successfully sending push notifications from your device. This configuration setup is not at all difficult as some developers perceive, though there are certain challenges involved in understanding the concepts of keys and properly generating the certificates.

If you would like to request a demo of Innovapptive’s Native, HTML5 or Hybrid apps, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.

Part 1: Getting started with Push Notifications in iOS

Getting started with Push Notifications in iOS

This is the first part of the three part blog series of push notifications functionality in Apple devices that helps you in getting started with push notifications in iOS including the concepts of push notifications, its functionality,  its key takeaways and limitations. The second part of the blog series focuses on configuration aspects of push notifications, while the last part of the series talks about configuration aspects of push chat.

Introduction

Push notifications enables your application to notify a user of new messages or events, even when the user is not actively using your application. On Android devices, when a device receives a push notification, your application’s icon along with a message shows up in the status bus. A push notification is a short message that consists of the device token, a payload and a few other bits and bytes.

Thus push notification technology is quite common for smart phone users, though there might be certain variations from application to application or from one phone model to another one.

Why do you need push notifications?

In iOS, apps have limited functionality to process everything in the background. Apps are only allowed to perform a limited set of activities to ensure that the battery life is conserved. However, in certain instances, when something intruiging happens and  you wish to let the user know about this, even if they are currently using your app, then how will you go about it?

To take care of such instances, Apple provided a solution, wherein instead of your app continuously checking for events or doing background processing, you can write a server-side component to do this instead.

This implies that when an interesting event occurs, the server-side component can send a push notification, which can do three things:

• Display a short text message
• Play a short sound
• Set a number in a badge on the app’s icon

This blog lets you understand how to make a simple app that uses Apple push notification service (APNS). The first step to accomplish this is to configure your app to receive push notifications and test message.

How push notifications work? (A brief overview)

Getting push notifications to work on your app is a bit tedious and a challenging process, though you may ultimately relish and enjoy your fruits of labour.

It consists of a series of stages, which is outlined in the following figure:

1. The app enables push notifications, wherein the user has to confirm whether he intends to receive these notifications or not.
2. Upon confirmation, the app receives a “device token”. You can assume this device token as the address that push notifications will be sent to.
3. The app sends the device token to your server.
4. If an interesting event occurs in your app, the server sends a push notification to the APNS.
5. APNS sends the push notification to the user’s device.

Once the user’s device receives the push notification, it displays an alert, plays a sound and/or updates the app’s icon. The user has the flexibility to launch the app from the alert itself; the app has the information of the push notification and can handle it as it sees appropriately. Now a question might arise in your mind? Do we still need push notifications in the age of local notifications and multitasking?

Local notifications have certain limitations, wherein they are solely meant to scheduling timed events and unlimited background processing in only available to apps that process VOIP, navigation and background audio. However, if you still want to notify the users about external events, while the app is closed, you still require push notifications.

Pre-requisites for configuring push notifications:

 To configure push notifications on your app, you need to ensure the following requirements:

• An iPhone or an iPad: You need to test push notifications on your device, as they do not work in the simulator.

• An iOS Developer Program membership: You have to make a new App ID and provisioning profile for each app that uses push and at the same time, make an SSL certificate for the server. You can accomplish this at the iOS provisioning portal.

• A server that is connected to the internet: Since push notifications are always sent by a server, you need to have a server that is connected to the internet. For development, purpose, use your Mac as the server and for production use, you need virtual private server (VPS) like Linode.

How does a push notification look like?

Payload, which is part of a push notification is the most important aspect that we would be interested, as it consists of the actual data you will be sending across.

Your server should provide this payload as a JSON dictionary. The payload for a simple push message will be displayed like this:

{

               “aps”:

               {

                               “alert”: “Hello, world!”,

                               “sound”: “default”

               }

}

There are myriad ways to configure the JSON payload like you can change the sound that is played, provide a localized text and you can even insert your own fields. Push notifications are intended to be small with payload size not exceeding 256 bytes.

Some key limitations

• Push notifications are not reliable:

There also seems to be a possibility that push notifications might not be actually delivered, even if the APNS server accepts them. You cannot track the status of the push notification, once you have sent it to APNS. The delivery time may also vary – from seconds to even up to half an hour.

There might be some other instances like the user’s iPhone may not be able to receive push notifications all the time. They could be on a WIFI network that does not allow connections to be made to APNS, since the required ports may be blocked or the phone could be switched off. APNS attempts to deliver the last notification it received for that device when it reverts online, but it will only try for a limited period. Once it times out, the push notification will be lost forever!

• They can be an expensive proposition:

Incorporating push functionality to your app is fairly easy and inexpensive if you own the data; however, if you a lot of users or data you need to poll, it may become a costly proposition.

• Requirement of a certificate for APNS

In order to enable push notifications in your app, it needs to be signed with a provisioning profile that is configured for push.  Apart from that, your server needs to sign its communications to APNS with an SSL certificate.

The second part of this blog series outlines the functionality and procedures for configuring the push notifications on your iPhone or an  iPad.

If you would like to request a demo of Innovapptive’s Native, HTML5 or Hybrid apps, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.

Odata for SAP Mobile: Offline Capabilities Using Delta Queries

What is Offline OData Client SDK?

Offline capabilities using Delta Queries is an emerging concept in SAP and this blog provides an overview of Offline OData client SDK and key implementation aspects of Delta Token functionality.

As of releases 2.x.x., the SUP OData Client SDK was primarily for applications transacting online with live back-end data. However, there was an option provided to temporarily cache or persist small amounts of data for the applications to resume to work seamlessly if there exists any drop in connectivity over a short period of time. Accordingly, starting from SAP Mobile Platform (SMP 3.0), the existing offline capabilities are enhanced further, wherein the application that works online 99% of its running time can now work seamlessly like an offline/online application. The notable difference is that the application can perform changes to the data when there is no connectivity and later those changes can get propagated to the back-end with order respected.

Hence, to ensure that the client SDK performs like a typical offline enabled library, changes were executed not only to incorporate a persistent cache, but also have a request queue to store the change requests (HTTP(s), as OData SDK still deals with REST over HTTPs) in that order in which they were created, when the application was not connected to the desired server. This feature was not supported in SUP versions 2.x.x. The best part here is that all offline capabilities have been included as a part of the client SDK itself with no additional work needed from the server side.

Now, let’s take a typical business case. Let’s assume you have downloaded a large collection of products and we have cached this product list. How can we update it?

In order to take care of this aspect, the Delta Query functionality has been introduced starting from SAP Netweaver Gateway 2.0 SP07.

Overview of Delta Query Support

Delta query protocol defines a pull-model protocol for clients to get changes for a store. Clients can poll the store for changes periodically or as required or capable stores can provide change notifications to the client when changes are available to be pulled.
This delta query is particularly relevant for projects where performance is critical, wherein loading takes place continuously every time, when full payload is not acceptable, say for instance for projects where the client often polls to get the latest data and any updates. Hence, for client and server performance, it can be very helpful to always display the current state in a poll-interaction, but with the lowest overhead on both client and server.

Implementation of Delta Queries & Delta Token functionality
An OData service can implement delta queries. This implies for each GET request to the OData service, the service will responds with the data, along with an additional delta link. This delta link is a combination of an identifier and a timestamp. Next time, whenever the device wants to request data, it will send a GET request including the delta link, wherein the ODataService will respond to only those objects that were new, updated or deleted (according to the timestamp inside the delta link). This way, you will drastically save time for getting the data and also on the device for parsing the data. The response can be merged to the existing data by using the cache object. However, you need to note that the developer of the OData service has to implement this delta query functionality, either by using Delta Exchange Tables (retrieved from the Syclo framework) or by its own (for example, by calling a BAPI, which gets the timestamp as input and returns the corresponding items).

Implementation of Delta Token functionality
OData exposes collection of records as EntitySets. These EntitySets supports varied options like sorting, filtering or paging to reduce the amount of the data that is sent across the wire.

In this context, paging can be considered as a very robust option to minimize the size of the payload and enhance performance. In order to use paging on client side, the OData request need to specify the $skip and $top tokens. If you work with server-driven paging, you need to use the $skiptoken.

However, some applications prefer to use client side caching, instead of paying. In such scenarios, SAP NetWeaver Gateway provides Delta Tokens that enables you to reduce resource consumption on the server and wire, when the same request is sent multiple times from the same client. The OData Delta Token lets clients to use caching when retrieving entity sets.

Accordingly, the client gets only the modified records, once all the initial records are retrieved. Hence, the initial request will return all records and a Delta Token. The consequent request consisting of the exact query options sends the Delta Token from the initial request. The response will then consist only the modified records. However, if no records have been modified, since the initial request, then the response will not contain any records.

There are two main approaches to implement Delta Token functionality such as:

1. Syclo Exchange Framework based approach: It calculates deltas at modification time, wherein the ABAP system tracks relevant changes, as they occur. At request time, the deltas are already prepared, making them available. Though this approach needs higher development efforts, however, it’s more scalable and ensures an optimized overall performance.
2. Delta determination at request time approach: In this type of approach, the system compares old and new states to check which records have been modified/deleted. Here, though the implementation effort is small, it however does not optimize the backend performance. This implies, if you have more records in the full collection, the response time of the request tends to get longer.
However, with both the approaches, the payload of the response is minimized, though the first approach seems to be more prudent, as it ensures optimization of the backend performance.

For more information on Innovapptive’s Portfolio of SAP Certified Mobile Applications, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.

Data modeling in SAP Gateway for OData Services

Data Model Definition

OData services require a data model definition, referred as model provider class. For client development projects, the development process mandatorily commences with a previously-defined data model, which is outside-in approach. Based on your specific requirements, you can define a data model in the following formats:

• Define new data model
• Import
• Redefine Service
• Include Service

Let’s have a brief overview of each format:

Define new data model

This model offers optimum flexibility, wherein it requires manual definition of individual data model elements and their properties.

What are data model elements?

Within the tree view of the Service Builder, you can use the data model folder structure to create and edit the individual data model elements. The data model consists of various sub-folders for each of the element types as listed below:

• Entity Types
• Complex Types
• Associations
• Entity Sets
• Association Sets
• Function Imports

You can create and define any of the above data elements, directly in the data model folder of your project. Once you create a new model element, it is inserted in the relevant predefined sub-folder within the data model folder.

There are three types of methods for creating a new data model:

• Double click the specific data model element in the data model folder and enter the relevant information.
• Right click the data model folder, click Create and then click the data model element you want to create.
• Expand the data model folder, right click the data model element you want to create and then click Create.

Import

You can use any of the 3 methods to accomplish the import process:

• DDIC structure (ABAP Data Dictionary)
• Data source (RFC/BOR interface)
• Data Model

DDIC structure (ABAP Data Dictionary)

This structure minimizes the time required to create entity and complex types in your data model.
In order to minimize the time required to create complex types and entity types in your data model, SAP NetWeaver Gateway Service Builder provides the Import DDIC structure function that lets you import an existing ABAP (DDIC) structure and later reuse this data to create new complex types and entity types with minimal effort.

You can import the following DDIC structures into the Service Builder:

• Search Help
• Views
• Database tables
• Structures

Data source (RFC/BOR interface)

This lets you to reuse existing remote function calls (RFC)/business object repository (BOR) parameters to create entity types with minimal effort. Hence, you can tap into a multitude of RFCs and business application interfaces (BAPIs) from the BOR. Once you have imported an existing interface definition, you can map the operations from the same RFC or BAPI to get the service operations you require, eliminating the need to write additional ABAP source code.

Data model

It enables you to reuse an existing data model for more than one service. The file import function is incorporated to enable import of data model files, as defined by external model editors such as Visual Studio (edmx files) and metadata file types (xml) into the Service Builder to create a data model. You can import such files into the Service Builder for the 2 types of projects, such as:

• Service with SAP Annotations
• Service with Vocabulary-Based Annotations

You can use this feature in the following scenarios:

• To import a metadata/edmx file for a new project in certain instances where you create a project and import a file.
• To import a metadata/edmx file for an existing project that already has a data model created (re-import).

Redefine service

It lets you redefine existing SAP NetWeaver Gateway services or services created from a framework within your SAP system landscape (Ex: Service Provider Interface (SPI), SAP Business Information Warehouse (BW Query), Generic Interaction Layer (GenIL).

Using the Redefine service, you can reuse the diverse business objects and services, existing in your SAP system landscape. Apart from that, it connects existing service operations, eliminating the need to create an individual service implementation. Accordingly, you can skip the service implementation phase. The Service Builder enables you to redefine both OData services created in NetWeaver Gateway and external services like SPI, BW Query, GenIL that have been created with the help of varied backend frameworks.

Include service

You can use this service to incorporate an existing SAP NetWeaver Gateway service without the need to recreate its data model. For enhanced usage, it lets you integrate one or more existing services in a new service. You can even skip the service implementation phase, if you choose to include one or more existing services.
Including an OData service

At the time of creating an association, there may be instances when you wish to link to an existing model without the necessity to recreating it. In such scenarios, you can use the Including OData Service function to include models in the Service Builder and then create associations using the included models.

Let’s take an example of a purchase order. To create a purchase order, we require list of vendors and products. For the purchase order service, two types of master data are required such as vendor and product. You can utilize the Include Model function, since the vendor and product services already exist, enabling you to reuse them.

If you would like to request a demo of Innovapptive’s SAP Certified Mobile Aplications, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.

OData: Implementing Multiple Origin Composition in SAP

Multiple Origin Composition (MOC) is a new and an emerging concept in SAP that describes the ability to collect data from different backend systems, integrate them into a single service and update diverse backend systems, while using the same user. Thus a service can be made available for various system aliases. For instance, you could have two identical systems, one that is located in US and one in Japan and accordingly integrate them. You can also use MOC to CREATE calls and the metadata. At present, CREATE calls cannot be processed in all the configured backend systems, but only in the default system. However, before we jump into the actual implementation of MOC, we need to understand few constraints (limitations) for implementing MOC, which are as follows:

• This feature is only supported in standard mode.
• This feature is applicable only for entity sets with an annotation of addressable=true.
• Implementing this feature generates a different version of the service, if the SAP_Origin field is added.

MOC implementation In order to implement MOC, follow the below outlined steps: I. Customize your service to support MOC.

1. Open the SAP NetWeaver Gateway system and activate the desired service.
2. Open the transaction SPRO and click SAP Reference IMG.
3. Click SAP NetWeaver > Gateway > OData Channel > Administration > General Settings > Activate and Maintain Services to open Activate and Maintain Services screen to add the system aliases for the appropriate backend systems and then define the desired default system. In order to do so, follow the below sub-steps:

• In the Service Catalog list, click the desired service. The service appears in the ICF Nodes section on the lower left corner of the screen.
• In the ICF Nodes section, click Standard Mode ICF Node.
• In the System Aliases section, click Add System Alias to add the system alias.
• Choose New Entries or select an existing entry and click Copy.
• In the Service Doc. Identifier field, type the ID of the service document, along with an underscore and the 4-digit version number (for example, _0001).
• In the SAP System Alias field, type the appropriate system alias.

             Note: You need to define only one system as the default.

• Repeat as required to add the desired backend systems.

Note The default system is used whenever the service is not called as MOC. In case, you have defined more than one default system alias, then the first system is used as the default.    

II. Test the service.

1. In the SAP NetWeaver Gateway system, open the SAP Reference IMG in transaction SPRO and click SAP NetWeaver Gateway > OData Channel Administration > General Settings > Activate and Maintain Services to open the Activate and Maintain Services screen.
2. Click the filter icon to search for the desired service.
3. Select the desired service and under ICF Nodes, click Call Browser.
4. Ensure that the SAP_Origin field is visible in the service’s metadata.

Parallelization of Multiple Origin Composition When using multiple origin composition, you can find out the minimum number of backend systems and the maximum number of parallel backend calls. For accomplishing this, you have an IMG activity available. To do this, follow the below step:

• In the SAP NetWeaver Gateway system, open the SAP Reference IMG in transaction SPRO and navigate to SAP NetWeaver > Gateway > OData Channel > Composition > Define Parallelization for Multiple Origin Composition.

You can apply this parallelization of READ_ENTITYSET for several backend systems to get the optimized performance. In the IMG activity, you can set the following configuration parameters:

1. The values that you can have for the minimum number of backend systems are:

• 0: No parallelization
• n: Parallelization will only be performed from n backend systems onwards

2.  The maximum number of parallel backend calls is mandatorily based on the current resources of the SAP NetWeaver Gateway hub system. Added to that, you can use the parameter: Maximum Number of Parallel Backend Calls to limit the usage of the current system resources. The default value zero (0) implies that it only depends on current system resources.Performance Improvement In case of serialization, the duration of a READ_ENTITYSET within a hub system is the aggregate of all backend calls. On the contrary, the duration in parallel mode is just the maximum duration of all backend calls, implying a minimal overhead for parallelization. Parallelization and Skiptoken If server paging is realized for any backend data providers, then the OData consumer will only get results up to this backend with skiptoken included. The next call with skiptoken or any other call with skiptoken will not be parallelized, as the result has to be resumed by the backend system that had returned this skiptoken earlier. Changesets Changesets are also supported in the context of MOC. All changeset operations for one backend are collected and sent to this backend through one RFC. If you would like to request a demo of Innovapptive’s SAP Enterprise Mobile solutions, please click on the link. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.