An intelligent system for contextual notifications solution

IN

DEGREE PROJECT

ELECTRICAL ENGINEERING, SECOND

CYCLE, 30 CREDITS

,

STOCKHOLM SWEDEN 2016

An intelligent system for

contextual notifications

solution

Abstract

Handsets have experienced a tremendous growth over the past few years, with users have more and more options in applications. The push notification has replaced the email grown in importance as a new bridge for application service provider to engage with users. The essential purpose of push notifications is to enable an app to inform its users that it has something for them when the app is not running in the foreground. For example, a message or an upcoming ap-pointment [1]. However, in practice, the notification channel would get flooded by commercials regardless of which platform that was used. Aimless push notifi-cations would only result in pushing the users away from the applinotifi-cations. This leads to the rise of the concept of contextual notifications, sending notifications at the right place, right time, regarding the right piece of information to the targeted audience. The concept of contextual notifications is not entirely new, yet the power of contextual notifications has not been fully developed, especially for video on demand applications. By sending more personal, contextual noti-fications to the user, it could prevent users from not opening the application or even deleting the application. Moreover, since users nowadays are used to hav-ing a large range of options in browshav-ing videos over different platforms as well, contextual notifications for cross platforms are also of interest. Users can use their companion mobile devices to interact with the video that is being played on the first screen, even the two devices are different platforms, the companion device still can receive the relative contextual notification about the video on the first screen.

The thesis work presents the result of the exploratory study and design development, then a discussion and conclusion will is presented based on the result. The development consists of three main parts. First of all, a high-level design and a framework are proposed based on pre-study of Accedo Appgrid product and the other existing system. Secondly, an implementation on proof of concept of contextual notifications server is performed. Thirdly, a demonstration application is implemented in order to test the proof of concept contextual notification server.

In the end, the functional evaluation is presented and a conclusion can be made that the contextual notification solution is achievable.

Abstrakt

Under de senaste ren har elektroniska apparater som surfplattor och mobil-telefoner utvecklats b˚ade teknikm¨assigt och i popularitet, och anv¨andare har nu allt flera valalternativ mellan mobila applikationer. Push notiser har er-satt e-posten och ¨ar en kommunikationsl¨ank mellan applikationsutvecklare och anv¨andare. Push notisens huvudsakliga syfte ¨ar f¨or utvecklaren att kunna up-plysa anv¨andaren om ny information ang˚aende applikationen, ¨aven om applika-tionen inte ¨ar ig˚ang f¨or tillf¨allet. I praktiken har det d¨aremot inte varit prob-lemfritt; anv¨andare har blivit ¨over¨osta av kommersiella notiser oavsett vilket operativsystem som anv¨ants. Notiser utan relevant information och utan speci-fika m˚al har lett till att anv¨andarna f¨orbiser notiserna. Detta problem har varit utg˚angspunkten i utvecklingen av kontextuella notiser, det vill s¨aga notiser som ¨

ar skickade under passande omst¨andigheter och med relevant information till vissa inriktade anv¨andare. Konceptet med kontextuella notiser ¨ar visserligen inte nytt, men tekniken kan dock utvecklas mer, i synnerhet f¨or notiser vid videotj¨anster. Att skicka personliga och relevanta notiser till anv¨andare kan f˚a anv¨andarna att anv¨anda applikationen mer frekvent. Att utveckla kontextuella notiser som kan operera ¨over flera operativsystem ¨ar ocks˚a en prioritet i denna utveckling eftersom det inte ¨ar ovanligt att anv¨andare idag anv¨ander sig av flera operativsystem p˚a sina olika elektroniska apparater. Tanken ¨ar att anv¨andares olika apparater ska kunna interagera med varandra; exempelvis att med mo-bilen kunna kontrollera en video som spelas upp p˚a en surfplatta, ¨aven om de tv˚a olika apparaterna anv¨ander sig av olika operativsystem.

Denna avhandling kommer att presentera resultaten av en utforskande studie och designutveckling kring kontextuella notiser. Utvecklingsstadiet best˚ar av tre delar; inledningsvis ett f¨orslag till en h¨ogniv˚a-design och ett ramverk baserat p˚a f¨orstudier kring produkten Accedo Appgrid och andra existerande system, d¨arefter f¨oljer ett f¨ors¨ok till implementation av en kontextuell notisserver, och slutligen demonstreras ett exempel p˚a hur den implementerade applikationen anv¨ander sig av den kontextuella notisservern.

Slutligen kommer tekniken att utv¨arderas och slutsatsen dras att kontextuella notiser ¨ar en genomf¨orbar l¨osning.

Acknowledgment

I would like to express my gratitude to the following individuals to those who have encouraged, inspired, supported, assisted me during the master thesis. I would like to thank Viktoria Fodor as my examiner at KTH for offering supports and feedback.

I would also like to express my gratitude to Accedo Broadband AB for offering me this opportunity to conduct my master thesis within in an exciting working environment and supports. Especially, I thank Raphael Duhayon as my supervisor at Accedo, who offers me the feedback and support during the thesis. Also, thanks to Marko Helin for the explanation and support.

Finally, I would like to express my greatest gratitude to my family and my friends for the support and encouragement during the thesis work.

Menghao Zhang Stockholm, February 2015

Contents

1 Introduction 1 1.1 Background . . . 1 1.1.1 Contextual notifications . . . 1 1.1.2 Cross-platform notification . . . 2 1.1.3 Ethical issues . . . 2 1.1.4 Accedo . . . 3

1.2 Purpose and Aim . . . 3

1.3 Scope & Limitations . . . 4

1.4 Methodology . . . 4

1.4.1 Preliminary study . . . 5

1.4.2 Solution proposal . . . 5

1.4.3 Implementation and Evaluation . . . 5

1.5 Terminology . . . 5

1.6 Structure . . . 6

2 Background 7 2.1 High level system description . . . 7

2.2 Contextual notifications . . . 7

2.2.1 Contextual information . . . 8

2.2.2 Push notification . . . 8

2.3 Cross-platform . . . 11

3 Accedo Appgrid 13 3.1 Primary use case . . . 13

3.2 Appgrid plugins . . . 14

3.2.1 Current architecture of Appgrid native push plugin . . . . 15

3.2.2 Appgrid native push plugin detail . . . 16

4 Development 18 4.1 System architecture . . . 18

4.2 Event processing . . . 19

4.2.1 High level solution proposal . . . 19

4.3 Implementation . . . 21

4.3.1 Proof of concept of back end system . . . 21

5 Result 35

5.1 Functional evaluation . . . 35

5.1.1 Trigger events use case . . . 35

5.1.2 Schedule events use case . . . 37

5.1.3 Summary of the result . . . 38

5.2 Discussion . . . 39

6 Conclusion 40 6.1 Summary of the thesis . . . 40

6.2 Future work . . . 41 Appendix A Device matching of contextual notification system 45 Appendix B Implementation of Multipeer Connectivity 47

List of Figures

2.1 The architecture of push notifications by Apple [1]. . . 9

2.2 The steps of push notifications, originally from Apple [1]. . . 9

2.3 The push notification format, originally from Apple [2]. . . 10

2.4 Third party provider sending cross platform notification with one API. . . 11

3.1 The general deployment process for cross-platforms application [3]. 14 3.2 Deployment with one interface of Appgrid [3]. . . 14

3.3 Current architecture of push notification using Appgrid. . . 15

3.4 High level design for use case [4]. . . 16

4.1 Proposed architecture of contextual push notification using Appgrid 19 4.2 Framework of the proposed server. . . 20

4.3 High level structures. . . 22

5.1 Require for register for contextual notification. . . 35

5.2 Trigger event use case. . . 36

5.3 Remote Control by companion device . . . 37

List of Tables

2.1 Parameters of Item [2] . . . 11

4.1 Parameters of POST register . . . 24

4.2 Parameters of POST watching . . . 25

4.3 Parameters of POST busyness . . . 26

4.4 Parameters of POST schedule task . . . 27

4.5 variable of DELETE schedule task . . . 28

4.6 Parameters of POST/DELETE favorite tag . . . 30

4.7 variable of GET favorite tag . . . 30

Chapter 1

Introduction

1.1

Background

This section covers some short background information on the topics of this thesis. The section can be divided into four parts. The first part gives a quick glance of the contextual notifications. The second part describes the concept notification in cross-platform circumstance. The third part is the potential ethical issues leads by the contextual notifications. The last part is the brief description of Accedo company.

1.1.1

Contextual notifications

Handset applications have experienced a tremendous booming over the past few years, with users having more and more options in applications. For ser-vice providers, engaging with users has already become the business with the highest priority (engagement means revenue). For example, the latest episode of the most beloved TV series could be available in different video on demand applications at the same time, but the first application that can inform users will gain the lead of this competition. In other words, an effective notification approach is a critical key for engagement.

According to the survey from [5], the most preferable way for receiving no-tifications is through applications. More than half of the survey’s study targets (over 1000 students) prefer to receive notifications via a mobile application. 24% of them selected to use web pages while 16% of the students selected a web application. On the other hand, only 1% of them choose SMS and mailing lists as their favorite method. It is obvious that sending notifications to a mobile application has become the most popular interaction technique between service providers and their users. Thanks to the push technology, which has grown to become a mainstream enabler for pervasive mobile applications that have to timely deliver updates to users [6], the service provider can now actually closely engage with its users. All in all, as [7] identified, ”Push notifications grow in importance as a bridge between application publishers to not only communicate with but also to re-engage with the users”.

Ideally, push notifications would be a perfect way to inform and interact with users. However, since notification traffic’s increasing pace is unprecedented, the user would soon be overwhelmed with marketing techniques, which lead to the

user missing vital information and reminders [8]. As a result, aimless push notifications could only push the user away from the applications.

This proposes the concept of contextual notifications, sending notifications at the right place, right time, regarding the right piece of information to the targeted audience. For instance, the service provider could send a notification with a special discount to users that haven’t used the application for three months to win the users back. In the meantime, to avoid spamming, such discount notification should be sent to the most suitable device for the user.

Altogether, the gains of contextual notifications could be described in three different points. First of all, for service providers, the gains from enabling contextual notifications are significant, the provider now is able to closely engage with users, and do not need to worry about overwhelming the push notifications. Secondly, as for the users, they could rely on contextual notifications to remind themselves of important updates instead of worrying about spamming messages. At last, the network provider could also gain out of contextual notification. The less number of aimless messages occupying the channel, the more efficient will the network provider be in pushing notifications.

1.1.2

Cross-platform notification

The concept of contextual notification is not completely new, but the power of contextual notifications have is not yet fully developed, especially for video service applications under multiple platforms circumstances. For users, it has become more and more popular that individuals have plurality devices with different systems. For example, one could use smart TV watching series at home, while using iPhone or Android when commuting. It is pointless that users have to check the same notifications again. Besides, for the service provider, applications have to be deployed into different platforms. Whereas, thanks to different APIs of different platform, sending the same message to every platform require a massive amount of effort for deployment and configuration.

Therefore, a solution that supports sending contextual notifications to dif-ferent platforms, such as iOS, Android, etc, is required.

1.1.3

Ethical issues

The purpose of contextual notifications is to enhance the user experience. How-ever, contextual notification could raise ethical issues.

First of all, the contextual notifications could have ethical significance in terms of dissemination and use of information. Especially, for video on de-mand(VoD) applications using the contextual notifications, using notification to facilitate crime and violence, unauthorized dissemination of copyrighted or otherwise protected material should not be permitted [9].

Secondly, the privacy issues should be put into consideration as well. For the application that requires the personal information from the users, it is impor-tant to avoid using information that can harm others or their properties [10]. For example, the information such as personal habits, browse history, could be collected to provide recommendation service. The current location would be collected in order to provide navigation service. Same as the contextual notifica-tions system, the system must collect users personal information about personal habit and current interaction between users and their device, and information

about the device. Only with the permission from the user the information can be collected. The users should have the right to reject the request terms from the service provider and terminate the service. As for service providers, they have to promise to only use the information in providing better user experience purposes and they should not leak the information to others.

1.1.4

Accedo

This thesis project is performed at the Accedo company. Accedo is the market leading enabler of TV application solutions, working behind the scenes of some of the world’s leading brands for media companies [11]. The main products Accedo Appgrid R _{(referred to as Appgrid) is a cloud-based solution that helps}

content providers, service providers to manage their applications, across multiple platforms [12]. Appgrid offers an administration graphic interface and a robust API to let application publishers access to application meta-data, assets and application configurations and to post application events over a wide range of platforms, such as website, mobile, tablets, Smart TV, game consoles, set-top boxes, etc.

Appgrid native push, as a plugin of Appgrid, allows application publisher to create and schedule the push notification via graphic user interfaces and robust API to arbitrary users across different platforms. Moreover, Appgrid na-tive push allows service providers to Broadcast notification to different country based on Geo-information. Whereas, the Appgrid Native push plugin currently does not support contextual notifications, more specifically, the current system have no awareness of which user is currently using the device, the system only which device is registered for the push notification service, but did not know the behavior of user. For example, a user register push notification with a iPhone and iPad, the two devices are belongs to same user. However, the system would have no awareness of the two devices are related each other. As a result of that, when sending the push notification to users, this same user would receive two identical notification on both iPhone and iPad which would significantly affect the user experience of Appgrid Native push service.

1.2

Purpose and Aim

Accedo explained the native push plugin as follows: ”The Accedo Appgrid plu-gins are a set of standalone modules defined to be used together with Appgrid, the Native Push plugin for Appgrid makes it possible to broadcast native push notifications to iOS and Android devices. The registration and message broad-casting is created with the unified API provided by this plugin” [13]. What is more, service provider could even specify uuid to send to all devices of a cer-tain user. Whereas, the uuid is a rather generic field, which identifies a unique device, but the provider have limited knowledge of the user behinds the device, neither which user would like to receive what kind of notification nor which de-vice is currently more likely to willing to receiving push notification. To video service application as an example, the user would like to receive notifications of description about the current program when viewing video, but the user would not like to be interrupted, so sending to same device as watching video is not the best alternative. A solution to this multi-screen use case is pushing notification

to the mobile device while user browsing video on the other pairing screen. The thesis project will focus on exploring if and how contextual notifications system can be implemented with the function of existing Appgrid native push plugin. More specifically, the aim for the thesis is to building a system, in order to automatically push contextually relevant notification to the users using multiple screen. In addition, a demo application is implemented to test the proposed system.

With the thesis purpose and aim as a basis, the relevant targets that the thesis should cover are:

• Investigate the requirements of the system, and define a high level frame-work for building a new system.

• Implement a proof of concept(PoC) of system that, combined with App-grid, could automatically provide contextually relevant push notifications to users.

• Build a demonstration application to test the system and provide a func-tional evaluation base on the application.

1.3

Scope & Limitations

Due to the time limitation and to be able to achieve a sufficient technological depth in the thesis, the broad subject of contextual notification must be set to a narrow. The following limitations are set up for the thesis:

• The generic push notification of Appgrid plugin is boosted by push service provider Pushwoosh, so the development will keep using the current push service provider.

• The communication between the system and push service provider is through REST API so that the solution could still work with different push service provider. If the push service provider is changed, the system only needs to change the format of JSON request message.

• The research of use case for this project will focus on VoD application. • The use case will be implemented and work as a PoC system. To test

the PoC system, a demo application will be implemented for test the PoC system. Research and development will mainly focus on iOS devices. • The time for developing demo applications is limited and the goals is not

production ready, hence is the functional PoC of contextual notification system have a higher priority than developing the content and solving possible bugs of demo.

1.4

Methodology

The thesis process is highly influenced by the following agile development method-ologies, both preferred by myself and Accedo. The process is behaved in an incremental and iterative manner which could be divided into four phases:

• The preliminary study, Exploring the use cases and requirements for build-ing the system.

• Development of the solution and design. • Implementation and improving the solution. • Evaluation of implementation.

1.4.1

Preliminary study

In the beginning of the thesis, the preliminary study is conducted, which in-cludes two approaches, literature review, understanding and testing on the ex-isting system. The first task of this phase is initiating with the concept of contextual notification, which can be separated into contextual information and push notifications by reading the related articles. The second task is finding out the requirement of stakeholders, what services could be presented to the client and could be delivered by the provider. Last but not least, after a grasp of this field, a deep learning into the push notification technologies is conducted. A study over infrastructure of notification services and the state of the art of push notification technique is executed. The study of notification technology including a review of Apple developer instruction and documentations from the service provider (Pushwoosh) used by Appgrid. Also a study of existing relevant framework of contextual notification system is necessary.

The more detail background and technique background are provided in chap-ter 2 and chapchap-ter 4 in detail.

1.4.2

Solution proposal

With necessary knowledge accumulated in the previous pre-study phase, the proposal of building a system which can provide automatically contextually relevant push notifications was formed. The details of the solution proposal will be presented in chapter 4.

1.4.3

Implementation and Evaluation

The implementation phase is the most important part of the thesis work. As de-scribed, the implementation phase began right close to solution proposal phase. The implementation phase will be introduced in detail in chapter 4. After the implementation phase is the evaluation of results, which will be presented in chapter 5 as well.

1.5

Terminology

• Agile - is a set of software development methods which promotes adaptive planning, evolutionary development, early delivery, continuous improve-ment, and encourages rapid and flexible response to change [14]. During the thesis project, the periodic meeting with supervisor is conducted, the developers in Accedo company are active in providing their professional ideas and aids.

• Iterative manner - is performed during the thesis process. A revise of solution design and implementation are conducted along with each time after an evaluation goes through.

1.6

Structure

The rest of the thesis consists the following chapters.

• Chapter 2 - presents background of this study and current technologies of related fields.

• Chapter 3 - presents current Accedo Appgrid solution and technology in detail.

• Chapter 4 - presents the solution and implementation detail of the back-end system and PoC application.

• Chapter 5 - presents the detail of the implementation and demo result. • Chapter 6 - presents the main conclusions and future work from this thesis.

Chapter 2

Background

In order to achieve a better understanding of the field of contextual notification and its current technologies, a literature review was conducted. This chapter will elaborate the result of reviews.

2.1

High level system description

The VoD application is used as an example to explain the stakeholders of con-textual notifications and relationship between them.

• Application publisher and service provider - the party which provide the main content of the application.

• Third party provider - the party that powering the service provider. Ac-cedo is also a third party provider in powering the user experience of the cross platform application.

• End user - the consumers who use the application provided by the service provider and the extra service, such as push notification, powered by the third party provider.

The contextual notifications system proposed in the thesis plays a role as third party provider, which will not only connect to service provider and end user, but also connect to other third party provider. For example, the push service provider, which is used to powering the application in sending push notification to each device.

2.2

Contextual notifications

In order to avoid spam, the number of notifications should be as less as possible. More specifically, the notification should only contain the information that is contextual relevant to the user’s behavior that makes the user willing to receive the push notifications and only target to the device that is possibly ready to receive. Moreover, to further reduce the potential spamming, instead of sending push notification to all the available devices, targeting to the most suitable device of each user would be a more appropriate. In this case, the throughput

of the push channel can be further reduced and the user experience can be improved in the meantime.

To better explain the concept of contextual notifications, the contextual notifications can be divided into two parts based on each word. The contextual information and push notifications.

2.2.1

Contextual information

In English dictionaries, context has a linguistic meaning, referring to the sur-rounding text and words, and a non-linguistic meaning, referring to the meaning derived from the text and words [15]. In computer science, context has been explored to simulate human context reasoning, the contextual information is searched for and extracted from the context knowledge base [16]. In this thesis project, the concept of contextual information is referring to information related to a user’s current behavior when interacting with a VoD application.

For example, when a user starts a video program, the contextual information in the VoD application could be the description in the video guide, the current session used to remotely control the video playback or the information of other device belongs to the same user. The goal of the system is to extract the information of this specific behavior and deliver the extra contextually relevant information to the user.

2.2.2

Push notification

Nowadays, most of applications follow the client/server model. The application is installed on the device of client and communicates with the server regarding the user’s action. Meanwhile, the server side keep maintaining and updating the data and response to the request from users. In general, the client side would periodically communicates with the server in downloading data, in other words, polling data from the server.

However, what if the service provider has new data to the client. How should the client side become aware of the new data, when the client is not running or running in background? The answer to the question would be push notification. Push notification mechanisms referred in [6] ”Push notification is conceptually an event-based mechanism where remote servers push events, as and when they occur, to smartphone client apps.” For each player in the operation system business, they all have their own elaboration. According to the description from Apple: ”A remote (push) notification is a short message that a provider has delivered to the operating system of a device or computer; the operating system, in turn, can inform the user of a client app that there is data to be downloaded, a message to be viewed, and so on.” [1] As the term push denoted, the notification message was actively pushed to the client application from the server side, differing from its opposite, a pull design, in which the server passively listen for information requested by the client. For instance, when something is updated on the server side, for push design, a push message is all they need for inform the client. However, there is no way for the server to inform a client for pull design, unless the client requests for the update. Here is the architecture of Apple push notification.

Figure 2.1: The architecture of push notifications by Apple [1].

As it can be seen from Figure 2.1, the provider sends notification information to APNs (Apple Push Notification service) [1]. After that the APNs pushes the notification to the client device to inform about new data on the server side. Similarly, Android applications use GCM (Google Cloud Messaging) [17]. As for the applications using Unity Plugin in developing, Unity have their own push server to achieve push notifications. Unity is a tool for powering the developing process of entertainment applications [18], such as 3d graphic games in different platforms.

Take Apple for example, as it can be seen from the Figure 2.2, which can be divided into two parts, the first one is the process for enabling a device to receive push notifications, which is from 1 to 4. The other part is the process for sending the push notification, which is from 5 to 7.

For the first part, the steps are as follow. Firstly, a SSL connection is set up between APNs and user device. Secondly APNs generates a deviceToken for this unique device which can be considered as an identifier of the device. Thirdly the deviceToken is delivered to the client application in the device. Finally the deviceToken is sent to the service provider, and the device is now able to receive the notifications.

Figure 2.2: The steps of push notifications, originally from Apple [1].

be delivered, the service provider would send the notification message together with the deviceToken to the APNs. Then the APNs will push the notification based on the deviceToken provided before. Finally, after the device receives the push notification, the device would let corresponding client application to alert the user with new notifications.

One feature worth mentioning is the silent push notification. By setting a message as silent, Apple allows the provider to push the notification to the client’s device without triggering the alert. The silent remote notification is a perfect tool for cases where providers do not need to notify the user that some-thing has changed. Such technique can be used to enhance the user experience in push notifications combined with background fetch. Especially, when users receive the same notifications in different devices from the provider and the user has already responded in one device, the provider should retrieve the remaining identical notifications from the user’s other devices. In this case, the retrieve action is performed secretly, such actions should not trigger the alert, nor re-quire the user’s immediate attention. From the users perspective, the users are not require to press the close button to delete the notifications, not even aware of the push and retrieve action of the notification.

This could have been the solution for contextual notifications in terms of not spamming the users. However, such push and silent retrieve action would in-crease the traffic in the notification channel, and the fact that different platforms use different format in achieving the silent push notification make this option unavailable, only using silent push notifications can not support the needs of cross-platform application.

Besides, each platform have their own format of notifications. The format of Apple push notifications is shown in Figure 2.3.

Figure 2.3: The push notification format, originally from Apple [2].

As it can be seen from Figure 2.3, the format is made up of Command, Frame length and Frame data three parts, while the Frame data is consist with a series of Items [2]. The Items is composed of Item ID, Item length, Item data in order, which is partially listed in Table 2.1, including device token, pay load JSON data and identifier etc. Whereas, Android and Windows phones use different formats for push notification messages, so for a large application, it would take huge efforts for sending one message with different kinds of format.

Item ID Item Name Length Data

1 Device token 32 bytes The device token in binary form, as was registered by the device.

2 Payload less than or equal to 2 kilobytes

The JSON-formatted pay-load.

3 Notification identifier

4 bytes An arbitrary, opaque value that identifies this notifica-tion. This identifier is used for reporting errors to your server.

Table 2.1: Parameters of Item [2]

2.3

Cross-platform

As briefly mentioned in the previous section, the solution of each service provider seems to work, but the solution of each service provider seems work, but not good enough. The fragmentation of operating systems is due to the fact that all major roles on the market has developed their own non-standard APIs for send-ing push notifications towards their devices. The difficulty for cross platform use cases also includes using unique programming languages for each operat-ing systems. Especially, for the cross-platform application without usoperat-ing those special cross-platform development tools such as Unity or Cordova/PhoneGap, the service provider have to send information targeting each platform’s specific API.

These applications require a sophisticated event notification system which delivers the messages across platforms. There are several approaches available to handle this problem. The key feature is using a mutual API, despite of the operation system, to communicate between service provider and client side application.

Figure 2.4 illustrates a mutual API that adopted by the third party push service provider, which receive unified format message from the service provider, and then translate the unified message to each remote push notification centers respectively, for example, APNs is used by Apple and GCM is used by Android. The third party service works as a middleware between the provider and the system specific push service center; it listens to the request from the provider and then automatically distributes it to the corresponding push service cen-ter. This third party provider will take the responsibility for translating and transmitting data to different push centers, thereby, the goal for the provider becomes obvious, just simply to deliver the unified format message to the third party push provider.

Chapter 3

Accedo Appgrid

Accedo Appgrid is a cloud based cross-platform application solution [19]. In other words, it is a powerful middle ware that takes care of the all the difficul-ties for service providers when deploying an application on multiple platforms. Appgrid allows publishers to gain full control over applications, including con-figuring application asset and analyzing usage patterns etc. Besides, application providers can send editorial notifications to engage users through push notifi-cation plugin, or look-up geographical intelligence and embedded social media authentication and much more.

3.1

Primary use case

The primary use case of Appgrid is to let the publisher use one platform to con-trol all its applications through one interface, where the publisher could make content and configuration changes immediately from Appgrid. In general, main-taining a cross-platforms application require a group expert for each different platform. Even modifying a simple text color of theme would require a group people working together, let alone changing the layout of an entire application for a campaign or other promotions. As shown in Figure 3.1, the developer have to create packages for each platform and submit them to respective application stores. Finally after the submission time and processing time from the operator at application store side, the new layout is finally presented to the users.

Figure 3.1: The general deployment process for cross-platforms application [3].

By using the Appgrid, as it can be seen from Figure 3.2, the application gets data through the unique interface of Appgrid, the configuration takes effect almost instantly.

Figure 3.2: Deployment with one interface of Appgrid [3].

3.2

Appgrid plugins

The Accedo Appgrid plugins are a set of stand alone modules defined to be used together with Appgrid [20]. The application publishers can use these modules according to their requirements. The plugins range from GeoIP look-up,

pay-ment wizard and Native push notifications. Among these plugins, the native push plugin is the one used to provide push notification service.

After enabling this plugin, the providers are allowed to register devices, send and schedule the notification to certain targeted audiences (e.g. ’country’, ’region’, ’applicationGroup’) through either admin UI or REST API [20]. For the client side code for receiving notification, they simply just keep using the native notification APIs as usual, but for registration and broadcasting the message is through the unified API provided by the plugin.

3.2.1

Current architecture of Appgrid native push plugin

Figure 3.3 shows the current architecture of native push plugin, in which either front-end client application directly communicate with the Appgrid or use a proxy between Appgrid and client side application. For example, the client side application would communicate with the application server, then the application server, as a proxy, delivers the data to the Appgrid.

Figure 3.3: Current architecture of push notification using Appgrid.

As it can be seen from the Figure 3.3, the native push plugin uses a push services provider(pushwoosh) to achieve the message delivery to end user, in this way the native push notifications plugin separates the application publisher and the push service provider. For former, the plugin is the third party middleware that takes care of difficulties. Appgrid could use different push service providers for different applications in terms of sending rate and multi-languages support for different areas etc. For the latter, Appgrid is the provider that delivers the standard format notifications to them.

3.2.2

Appgrid native push plugin detail

As it shown in Figure 3.4, a high-level view for the use case for the plugin. The universal flow of using native push notification plugin was four steps as follows:

• The device registers at APN or GCM for push device token.

• After having received the token, the device sends the token to the Appgrid native push API with hardware ID.

• Appgrid will register to the push notification third party service provider with client’s tag(e.g. country, region).

• The author could send instant or schedule notifications to target audiences via Appgrid native push API.

Figure 3.4: High level design for use case [4].

To sum up, the current Appgrid native push plugin is a push notification solution for Appgrid consumers, the notification author could use this plugin to manually send push notifications to selected device. However, as it described in the previous chapter, the notification author has no awareness of who the user behind the device is. Besides, the author needs to manually write for each

notification message, each notification will not recurrent. All in all, the current system design is not enough for automatically sending contextual notifications to users.

Chapter 4

Development

4.1

System architecture

The goals of the contextual notification systems are: • Collecting contextual information from users. • Pairing the devices under the same user.

• Selecting a user’s most suitable device for receiving push notifications. Considering the goals, the current design of Appgrid native push plugin is not enough for sending contextual notifications. Therefor, it is proposed that a contextual notification server is added into the current design. Together with the Appgrid native push plugin, the user can register and receive contextual push notifications. Such a system should listen to requests from clients from all different platforms. More importantly, the system should gather contextual information from each user, and all devices that belong to the same user should be recorded under the same user name. In this way, the system can pair the companion device for receiving the push notification.

Figure 4.1 shows the proposed architecture. The system should not only use the Appgrid plugin API, but also expand existing its abilities. The front-end application should communicate with the system as well. In future works, the system can be integrated into the existing Appgrid native push plugin.

Same as the current design, the proposed system consists of four parts, as can be seen in Figure 4.1. The application in the figure is using a back-end sys-tem consisting of Appgrid and the contextual notification server, as well as the database and the push service provider. Since the application is using the cur-rent Appgrid native push plugin, it is already able to register and receive push notifications. So for contextual push notifications, the infrastructure should re-main the same as the current system is already available for user registering push notifications. Whereas, other interactions should go through the new con-textual notification server. After the concon-textual processing the information will be stored into the database and deliver the message to the push service provider, which is the same as the current design pushwoosh. The push service provider is in charge of pushing the notification to the client application.

Figure 4.1: Proposed architecture of contextual push notification using Appgrid

4.2

Event processing

After reviewing related contextual notification systems and features of the cur-rent Appgrid, a high level framework of the contextual notification server is proposed. Similar to the current design of native push plugin, the server should be accessed through RESTful APIs.

4.2.1

High level solution proposal

Figure 4.2 proposes the framework of the contextual notification server inspired by [8], which not only takes advantage of the features of Appgrid but also considers the stakeholders’ requirements. The server should work closely with the existing Appgrid plugin, and should not affect the current function of it. The server would only affect the users that register for contextual notification services.

Figure 4.2: Framework of the proposed server.

The server first collects data from users, then target users that match the relevant criteria and send notification to their most suitable device. Which device that is most suitable for receiving a push notification depends on different events, which will be described later in this chapter. The server then generate the notification. In order to perform this three-step process the server needs to be separated into three parts. As it can be seen in Figure 4.2, the server has been divided into listening events, processing events and sending events.

• Listening events - to listen and transfer a request to the corre-sponding parts of the system. The request can come either from end users or from the service provider. The listening events section involves two kinds of tasks: trigger events and schedule events. Trigger events indicate events that are caused by some certain actions that need to be handled immediately. For example, when a user starts a video program, the server would listen to this specific event and respond to the event by sending a push notification, for example a video guide and remote con-troller, to the companion device. Schedule events indicate events that need to be handled in a specific time or a specific time interval. These kind of events are usually generated by the service provider. For example, a new TV series will be available during the next three months. The ser-vice provider could then schedule a recurrent event for the following three months.

• Processing events - handling the request to the system. The processing events section is divided into two parts corresponding to the different events from the listening events section. The trigger event is han-dled directly by the system, while the scheduled event will be hanhan-dled at

the specific time according to the recurring task’s starting time, finishing time and the actual time. For example, the starting time of a task can be 2016-01-01 15:00 and the finishing time can be 2016-04-01 15:00, while the actual time of the event can be every Monday at 14:00. More specifically, the server would find all users that match the criteria of this specific event on every Monday at 14:00 between January and April.

• Sending events - sending the request to the corresponding de-vices. The sending events section can be divided into three parts, with the first two parts working closely together. The first part examines the user’s status on his or her different devices, while the second part selects the most suitable device to receive push notifications. The second part is currently a rule-based filter. The filter will screen differently for different events. For example, if the purpose of the push notification is to deliver a video guide and a remote controller, the filter will select the idle com-panion device as target. However, if the push notification wants to alert the user about the nearby earthquake, the filter would select the device that is currently being used for pushing the notification. In order to more efficiently finish the second part’s task in the future, it could use machine learning to predict a user’s behavior. The filter will screen differently for different events at the first and second section. For example, if the purpose of the push notification is to deliver a video guide and a remote controller, the filter will select the idle companion device as target. However, if the push notification wants to alert the user about the nearby earthquake, the filter would select the device that is currently being used for pushing the notification.

Finally, the contextual notifications are generated and delivered to the push service provider.

4.3

Implementation

The implementation section is divided into two parts. The first part will present the PoC of contextual notification server and its communication with the database and push service provider4.1. In the second part a demonstration application will be introduced in order to testing the contextual notification server.

4.3.1

Proof of concept of back end system

There are two approaches to implement the proposed framework. One way is to build up the system in Java, while the other one is to use Node.js when realizing. Node.js is a JavaScript run-time built on Chrome’s V8 engine, which is an asynchronous event driven framework [21]. The two tools, Java and Node.js, have similarities; both of them could be used to build up a server, whereas, each approach has their own specialty. Accordingly to the description of [22] and considering the requirements of this thesis (communicating with MongoDB database and push service provider which both require JSON in query). Node.js is the most suitable tool for this thesis due to the functionality in supporting

JSON which is the nature of JavaScript and the fast response because the nature of Node.js asynchronous is event driven.

Figure 4.3: High level structures.

Figure 4.3 illustrates the high level structures of the proposed contextual notifications, which is an extension of the current high level use case Figure 3.4. The system listens to the request either from the end user or from the service provider. Then the contextual notification system would process the request and find the matching users and their most suitable devices. Finally, the system delivers the message to the push service provider in a unified format. The push service provider will take care of the task of pushing notifications.

Use cases

As Figure 4.2 illustrated, the system should listen to two kinds of events. The PoC of contextual notification system listens to one pre-defined event for each trigger event and schedule event category, while the pre-defined event can be added as needed.

Trigger events can be described as events that need to be handled immedi-ately. For example, when a user starts a video program it starts a stream of tasks: the program will ask the PoC system to send a notification. The user receives and taps the notification, which opens up a video program guide and a remote controller to companion device of same user.

Schedule events can be described as events that are handled in a specific time or time interval. For example, the service provider wants to inform the user that there will be a TV series starting the following week, and that the TV series will be updated every Monday night. The service provider could then schedule a recurrent event that send notifications to all users that match the

criteria for this event, for example all users that are subscribed to similar TV series.

Device matching & Request sending

After having received the request, the system will record how occupied certain devices are. This is to match devices in the future. The device matching process is then conducted. This process will follow the pre-defined rules to pick up the most suitable device for receiving a push notification. The system would find the idle device with the smallest screen size. The reason for choosing the device with the smallest screen size is based on the fact that the smaller the screen is, the higher probability it is that a user would check the device. Even though finding the best matching algorithm is not the topic of this thesis, it could be improved in future works. The matching process could use machine learning to predict a user’s most suitable device using collected data about the user’s habits. After getting the devices list for pushing notification, the system would send a JSON format message to the push service provider. The code of device matching and sending request to push service provider are presented at Appendix A.1. The code can be generalized as follow:

1 // s e a r c h the d e v i c e s at the d a t a b a s e , o n l y s e l e c t the d e v i c e s u n d e r s a m e u s e r w i t h l o w e r b u s y n e s s v a l u e t h a n p r i o r i t y v a l u e . 2 t h e s i s T e s t . r e g i s t e r U s e r . f i n d ({ u s e r s [ u s e r ] , b u s y n e s s :{ $ l o w e r O r E q u a l s : p r i o r i t y }} , f u n c t i o n ( err , d o c u m e n t s ) { 3 var t e m p D o c ; 4 d o c u m e n t s . f o r E a c h (f u n c t i o n( d o c u m e n t ) { 5 if (! t e m p D o c ) { 6 s w i t c h ( d a t a . s t a t u s ) {

7 // C o r r e s p o n d i n g to the e x a m p l e of t r i g g e r event , f i n d the b e s t device , w h i c h s h o u l d be a d e v i c e is s m a l l e r t h a n c u r r e n t w a t c h i n g d e v i c e 8 c a s e " w a t c h i n g ": 9 if ( D E V I C E _ S I Z E [ d o c u m e n t . d e v i c e ] < D E V I C E _ S I Z E [ d a t a . d e v i c e ]) 10 t e m p D o c = d o c u m e n t ; 11 b r e a k;

12 // C o r r e s p o n d i n g to the e x a m p l e of s c h e d u l e event , f i n d the b e s t d e v i c e for u s e r . 13 c a s e " s c h e d u l i n g ": 14 t e m p D o c = d o c u m e n t ; 15 b r e a k; 16 d e f a u l t: b r e a k; 17 } 18 }e l s e { 19 // f i n d the a v a i l a b l e s m a l l e s t d e v i c e . 20 if ( D E V I C E _ S I Z E [ d o c u m e n t . d e v i c e ] < D E V I C E _ S I Z E [ t e m p D o c . d e v i c e ]) t e m p D o c = d o c u m e n t ; 21 }; 22 if ( t e m p D o c && d o c u m e n t s C o u n t == d o c u m e n t s . l e n g t h ) { 23 s e n d L i s t . p u s h ( t e m p D o c . u s e r N a m e ) ; 24 d e v i c e s L i s t . p u s h ( t e m p D o c . r e g i s t r a t i o n T o k e n ) ; 25 }; 26 s e n d P u s h N o t i f i c a t i o n . . . . 27 }) 28 }) ;

APIs

This sub-section describes the APIs of the contextual notification server. Ideally, the application server would act as a proxy, the data from the client application would go to the application server, then the server delivers the data to the back-end system. Nevertheless, implementing a client/server demo application is not the highest priority assignment for this thesis research. This being said the client side demo application would directly communicate with the PoC server. The application server is omitted in this demonstration and the PoC server partially plays a role as an application server. This is the shortcut for both implementation and demonstration purposes.

The port 3000 is used for Accessing APIs, thus, the endpoint for communi-cation with PoC system should be

http://hostIPAddress: 3000

The following subsection will present the methods that are adopted by the contextual notifications.

Register device

The registration is required before using contextual notification service.

1 P O S T / r e g i s t e r

Listing 4.2: Device registering

Table 4.1 shows the required parameters of register device method. Parameter Type Required Description uuid String true Unique User

Identi-fier.

userName String true Register user name. registrationToken String true Registration token received from. push network provider (e.g. GCM, APN). hardwareId String true A unique identifier

for the device hard-ware.

device String true The type of device (e.g. iPhone, iPad). deviceType String false The OS of de-vice (e.g. iOS, Android).

Table 4.1: Parameters of POST register

This registration method is different from the existing registration request to Appgrid native push plugin, this POST register method should be used when the user would like to use the contextual notification service.

1 {

2 u u i d : " 8 A5F044C -8 C88 -4 FE3 - BA9F - 6 9 2 D B 3 D 3 9 0 2 5 ", 3 u s e r N a m e : 123 ,

4 r e g i s t r a t i o n T o k e n : " b 9 0 e b 5 6 2 d c a f 4 c 6 c 6 6 9 a 3 9 0 f 0 9 e 1 f b b 8 1 6 e f 3 0 4 f 7 e d 0 6 d a 1 3 8 d 5 d e 3 d a 9 d 6 5 af6 ", 5 h a r d w a r e I d : " T e s t M A C A d d r e s s ", 6 d e v i c e : " i P a d ", 7 d e v i c e T y p e : " ios " 8 }

Listing 4.3: The example of register method

Send the video guide and remote controller to a companion device Above illustrates an example of a trigger event. After receiving watching POST method, the contextual notification server will try to pair the device with an-other possible companion device. The system would send a push notification to the companion device with information of which video the user is currently watching, as well as the device’s hardware ID. This is so that the companion device could use the information to set up the video guide and remote control with the current watching device. The system would select the idle device with the smallest size.

1 P O S T / w a t c h i n g

Listing 4.4: Send video guide and remote controller

Table 4.2 shows the required parameters of watching method.

Parameter Type Required Description uuid String true Unique User

Identi-fier.

watching String true The video currently watching.

Table 4.2: Parameters of POST watching

1 {

2 u u i d : " 8 A5F044C -8 C88 -4 FE3 - BA9F - 6 9 2 D B 3 D 3 9 0 2 5 ", 3 w a t c h i n g : " V i d e o N a m e "

4 }

Listing 4.5: The example of watching method

Set busyness value for a device

When a pre-defined event is triggered, the contextual notification server would record the status of each device. The service provider customize a scale of how busy the device is, a busyness value, and can then define how busy a device is from their own parameter. This parameter would be used to detect the status of a user’s different devices when it is time to handle a schedule event.

1 P O S T / b u s y n e s s

The busyness value parameter shows the current status for each and every device the user owns. This busyness value would be used in selecting the most suitable device. Table 4.3 shows the required parameters of set busyness method.

Parameter Type Required Description uuid String true Unique User

Identi-fier.

busyness Number true The busyness of the device.

Table 4.3: Parameters of POST busyness

Schedule recurrent task

Below illustrates the process of schedule events. The schedule POST method allows service provider to schedule a recurrent notification task for the push notification in the future. Each scheduled task has four status; waiting, run-ning, finishing and canceling. Normally, the life cycle of a task will go through waiting-running-finished or waiting-running-canceled. When a task is either be-ing finished or bebe-ing canceled, this entry task will be stored into the database.

1 P O S T / s c h e d u l e

Listing 4.7: Schedule recurrent notification task

Table 4.4 describes the required parameters for the schedule task method. Listing 4.8 depicts an example of the scheduled task: The task starts at 2015.12.14 and will repeatedly send a push notifications on Monday 19:30

to users following The Walking Dead(TWD). The push notification informs the users that the latest episode of The Walking Dead has now been released. The priority parameter indicated that only the device with lower than 0.5 busy-ness value would receive the notification. In other words, the contextual notifi-cation server would base on pre-defined rules, that finds the smallest size device with busyness parameter lower than busyness level 0.5. If all of a user’s devices all have a busyness value higher than 0.5, then the push notification will not be pushed to this user.

Parameter Type Required Description dayOfWeek Number

Ar-ray

true The day of week that the event will repeat.

hour Number true The hour for notifi-cation task.

minute Number true The minute for no-tification task.

tag String true The tag for

con-textual notification server to select the targeting users. message String true The notification

message.

startTime Date true UTC timestamp for when this notifica-tion starts.

endTime Date true UTC timestamp for when this notifica-tion ends.

taskName String true The name of the recurrence schedule task.

priority Number true The priority for user to receive the message(If higher than current busy-ness value the user will receive this push notification). Table 4.4: Parameters of POST schedule task

1 {

2 d a y O f W e e k : [1] , 3 h o u r : 19 , 4 m i n u t e : 30 , 5 tag : " TWD ",

6 m e s s a g e : " Hey , you can s w e e p to c h e c k the n e w s of The W a l k i n g D e a d ",

7 s t a r t T i m e : 2015 -12 -14 T19 : 0 0 : 0 0 . 7 5 7 Z , 8 e n d T i m e : 2016 -1 -16 T20 : 3 0 : 5 4 . 7 5 7 Z , 9 p r i o r i t y : 0.5

10 }

Listing 4.8: The example of schedule method

Listing 4.9 describes the method that is used to get all the information about every recurrent notification task. The response will contain an array of tasks that has still not finished. This method takes no parameter and will return an array with tasks.

1 GET / s c h e d u l e

Listing 4.9: get all recurrent notification task

Listing 4.10 shows the method to delete a specific task. The entry will be removed from the server and will be stored in the database for future analysis, just like the finished tasks.

1 D E L E T E / s c h e d u l e /{ t a s k N a m e }

Listing 4.10: delete the recurrent notification task

Variable Type Required Description taskName String true The name of the

task that need to be removed.

Table 4.5: variable of DELETE schedule task

Listing 4.11 shows the method used to get all the entries of schedule task with finished and canceled status.

1 GET / s c h e d u l e / f i n i s h e d T a s k s

Listing 4.11: get all finished or canceled notification task

As we can see in the Listing 4.12, this is an example of the task in running status, which can be obtained through the GET /schedule RestfulAPI provided by the back-end server. In this case, instead of waiting for the start time, the task has already started.

On the contrary, as Listing 4.13 indicated, when a task is either canceled or finished, the task entry will be stored into the database, which can be obtained through GET /schedule/finishedTasks RestfulAPI.

1 { 2 " t a s k s ": [ 3 { 4 " job ": { 5 " n a m e ": " T a s k 1 " 6 } , 7 " s c h e d u l e ": { 8 " n a m e ": " An i m p o r t a n t t a s k " 9 } , 10 " s t a r t T i m e ": " 2016 -01 -01 T10 : 1 4 : 5 4 . 7 5 7 Z ", 11 " e n d T i m e ": " 2016 -01 -31 T16 : 5 9 : 5 4 . 7 5 7 Z ", 12 " t a s k ": { 13 " d a y O f W e e k ": [ 14 1 , 15 2 , 16 3 , 17 4 , 18 5 19 ] , 20 " h o u r ": 1 , 21 " m i n u t e ": 49 22 } , 23 " i n f o ": { 24 " tag ": " TWD ",

25 " m e s s a g e ": " Hey , you can s w e e p to c h e c k the n e w s of The W a l k i n g D e a d ", 26 " p r i o r i t y ": 0.5 27 } , 28 " s t a t u s ": " r u n n i n g " 29 } 30 ] 31 }

Listing 4.12: Schedule task with running status

1 { 2 " _id " : O b j e c t I d (" 5 6 9 3 6 f e e 7 4 5 9 c d 6 e 1 d 9 a 9 1 2 9 ") , 3 " s c h e d u l e " : { 4 " n a m e " : " An i m p o r t a n t t a s k ", 5 " d o m a i n " : null , 6 " _ e v e n t s " : null , 7 " _ m a x L i s t e n e r s " : n u l l 8 } , 9 " s t a r t T i m e " : I S O D a t e (" 2016 -01 -01 T10 : 1 4 : 5 4 . 7 5 7 Z ") , 10 " e n d T i m e " : I S O D a t e (" 2016 -01 -10 T16 : 5 9 : 5 4 . 7 5 7 Z ") , 11 " t a s k " : { 12 " h o u r " : 1 , 13 " m i n u t e " : 49 , 14 " d a y O f W e e k " : [ 15 1 , 16 2 , 17 3 , 18 4 , 19 5 20 ] 21 } , 22 " i n f o " : { 23 " tag " : " TWD ",

24 " m e s s a g e " : " Hey , you can s w e e p to c h e c k the n e w s of The W a l k i n g D e a d ",

25 " p r i o r i t y " : 0.5 26 } ,

27 " s t a t u s " : " f i n i s h e d "

28 }

Listing 4.13: Schedule task with finished status

Modify favorite tags

In order to find out whether the targeted users could possibly be interested in an available TV series, the system should collect user’s habits (favorite tags), and then use them for the schedule event.

This method allows users to use different requests to modify the favorite tags for receiving schedule notifications. If a user has subscribed to a certain TV series, the user should be added to the list for receiving push notifications regarding this specific TV series.

1 P O S T / D E L E T E / f a v o r i t e

Listing 4.14: Modify favorite tag

Table 4.6 depicts the parameters of POST and DELETE favorite methods, the required parameters are the same for both methods. When the POST favorite

method is used for the first time, the entry for the user will be created in the database automatically.

Parameter Type Required Description userName String true The registered user

name for add/re-move tag.

favorite String true The tag that

require to add/remove. Table 4.6: Parameters of POST/DELETE favorite tag

Listing 4.15 demonstrates the path variable used by the method.

1 GET / f a v o r i t e /{ u s e r N a m e }

Listing 4.15: Modify favorite tag

Variable Type Required Description userName String true The registered user

name to get all the tags followed by this user.

Table 4.7: variable of GET favorite tag

Report for opening the push notification

When a user has clicked on a push notification, this data should be sent to the contextual notification server. The method for these kinds of reports is to calculate the click-through rate (CTR). This method is usually used when measuring whether an online advertising campaign has been successful or not, but can also be used to measure the opening rate of a push notification in this thesis [23]. The CTR equals to the numbers of clicks divided by the total number of pushed notifications.

1 P O S T / o p e n N o t i f i c a t i o n

Variable Type Required Description

data Object true The data in the

push notification, used as identi-fier for pushed notification

deviceToken String true The token used by the device for re-ceiving the notifica-tion. Identify the device that open the notification Table 4.8: variable of POST open notification

4.3.2

Demonstration application

In order to test the system, a demonstration application was implemented. The demo application mimics the VoD application that uses the proposed solution in receiving contextual notifications. iOS is the targeted platform for implementing the demo application.

Native iOS application

First of all, according to Apple [24] described, push notifications are not sup-ported in the iOS Simulator. In order to test the contextual notification server, the demo application must run on an actual device.

As presented above, in order to using the contextual notification server, the HTTP networking with JSON data is required for the communication between the contextual notification server and the client side demo application. There are varieties of client side HTTP libraries working with iOS devices. It is not necessary to implement another HTTP network tool from scratch. The library is being used by the demo application is named Alamofire, an Elegant HTTP Networking library written in swift for Apple application development [25]. This library can deliver formatted messages from client side applications to the server. Also used in this demo application is the SwiftyJSON library, combined with the Alamofire, the SwiftyJSON allows the application to handle the JSON re-quest and JSON response easily in swift, Listing 4.17 demonstrates the code of using Alamofire/SwiftyJSON in demo application for HTTP networking POST request and response.

1 c l a s s N o t i f i c a t i o n M e t h o d s { 2 s t r u c t P a r a m e t e r { 3 s t a t i c let B a s e U r l : S t r i n g = " h t t p : / / 1 7 2 . 1 7 . 5 0 . 9 : " 4 s t a t i c let A p p l i c a t i o n K e y : S t r i n g = " 5 4 1 2 e b 3 4 c e 3 4 5 4 c 0 7 7 0 9 4 1 3 9 " 5 } 6 s t a t i c f u n c p o s t ( m e t h o d m e t h o d : String , s e s s i o n : S t r i n g ? , p a r a m e t e r s : JSON , c o m p l e t i o n :( J S O N ) - > () ) { 7 if ( s e s s i o n != nil) { 8 let h e a d e r s = [" x - s e s s i o n ": s e s s i o n ! , " content - t y p e ": " a p p l i c a t i o n / j s o n "]

9 let r e q u e s t = N S M u t a b l e U R L R e q u e s t ( URL : N S U R L ( s t r i n g : P a r a m e t e r . B a s e U r l + m e t h o d ) ! , c a c h e P o l i c y : . U s e P r o t o c o l C a c h e P o l i c y , t i m e o u t I n t e r v a l : 1 0 . 0 ) 10 r e q u e s t . H T T P M e t h o d = " P O S T " 11 r e q u e s t . a l l H T T P H e a d e r F i e l d s = h e a d e r s 12 do { 13 r e q u e s t . H T T P B o d y = try N S J S O N S e r i a l i z a t i o n . d a t a W i t h J S O N O b j e c t ( p a r a m e t e r s . d i c t i o n a r y O b j e c t ! , o p t i o n s : N S J S O N W r i t i n g O p t i o n s () ) 14 } c a t c h { 15 } 16 A l a m o f i r e . r e q u e s t ( r e q u e s t ) . r e s p o n s e J S O N { ( req , res , j s o n ) in 17 j s o n . v a l u e == nil ? p r i n t (" f a i l to p o s t d a t a ") : { 18 let j s o n = J S O N ( j s o n . v a l u e !) 19 c o m p l e t i o n ( j s o n ) }() 20 } 21 } 22 } Listing 4.17: NotificationMethods.swift

The code above represent the POST method, the method would be used by the demo application to send POST requests with passed in parameters to the back-end system, and handle the response with the completion handler. The completion handler is passed in from the outside code, the handler is different according different POST request.

The steps of push notifications

First, as it shown in Listing 4.18, by following the requirements of Figure 2.2 the device have to ask APNs for device token when the application is launched.

1 c l a s s A p p D e l e g a t e : U I R e s p o n d e r , U I A p p l i c a t i o n D e l e g a t e { 2 var w i n d o w : U I W i n d o w ? 3 f u n c a p p l i c a t i o n ( a p p l i c a t i o n : U I A p p l i c a t i o n , d i d F i n i s h L a u n c h i n g W i t h O p t i o n s l a u n c h O p t i o n s : [ N S O b j e c t : A n y O b j e c t ]?) - > B o o l { 4 if a p p l i c a t i o n . a p p l i c a t i o n S t a t e != U I A p p l i c a t i o n S t a t e . B a c k g r o u n d { 5 let p r e B a c k g r o u n d P u s h = ! a p p l i c a t i o n . r e s p o n d s T o S e l e c t o r (" b a c k g r o u n d R e f r e s h S t a t u s ") 6 let o l d P u s h H a n d l e r O n l y = ! s e l f . r e s p o n d s T o S e l e c t o r (" a p p l i c a t i o n : d i d R e c e i v e R e m o t e N o t i f i c a t i o n : f e t c h C o m p l e t i o n H a n d l e r : ") 7 var p u s h P a y l o a d = f a l s e 8 if let o p t i o n s = l a u n c h O p t i o n s { 9 p u s h P a y l o a d = o p t i o n s [ U I A p p l i c a t i o n L a u n c h O p t i o n s R e m o t e N o t i f i c a t i o n K e y ] != nil 10 } 11 if ( p r e B a c k g r o u n d P u s h || o l d P u s h H a n d l e r O n l y || p u s h P a y l o a d ) { 12 p r i n t ( l a u n c h O p t i o n s ) 13 } 14 }

15 let t y p e s : U I U s e r N o t i f i c a t i o n T y p e = [. Alert , . Badge , . S o u n d ]

16 let s e t t i n g s = U I U s e r N o t i f i c a t i o n S e t t i n g s ( f o r T y p e s : types , c a t e g o r i e s : nil)