MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨  OF I !"#$%&'()+,-./012345

Development of cross-platform cloud application with AngularJS and NodeJS

DIPLOMA THESIS

Matouš Havlena

Brno, Spring 2015 Declaration

I hereby declare that this paper is my original authorial work, which I have written on my own. All sources, references and literature used or excerpted during the elaboration of this work are properly cited and listed in complete reference to the due source.

Matouš Havlena

Advisor: Ing. RNDr. Barbora Bühnová, Ph.D.

ii Acknowledgement

I would like to express my special appreciation and thanks to my advisor Ing. RNDr. Barbora Bühnová, Ph.D. for her useful comments and remarks, and her commitment throughout the learning process of this master thesis. I would also like to thank my project external guide Stacy F. Hobson from IBM Research and all the people working on my team.

I would like to express special thanks to my beloved ones, who have supported me through- out the entire process, both by keeping me harmonious and by helping me to put the pieces together. I will be forever grateful for your love.

iii Abstract

The goal of this thesis is to implement a cross-platform mobile event application to be used by attendees during client workshops in IBM Research. The thesis documents the phases of the application development process, starting with the initial project description, through the requirements analysis and design, to implementation of the application. Special empha- sis is put on the design phase where mobile development approaches, technologies used during development, and application architecture are discussed.

iv Keywords event application, mobile hybrid application, cloud, Apache Cordova, REST, WebSocket, Node.js, AngularJS

v Contents

1 Introduction ...... 1 2 Project Initiation ...... 2 2.1 Project Background ...... 2 2.2 Project Purpose ...... 2 2.3 Project Scope ...... 3 2.4 Project Resources ...... 4 2.5 Project Stakeholders ...... 5 2.6 Project Risk ...... 5 3 Analysis ...... 6 3.1 Functional Requirements ...... 6 3.1.1 Event Application ...... 6 3.1.2 Administration Application ...... 7 3.1.3 SocialWall Application ...... 8 3.1.4 Use Case Diagram ...... 9 3.2 Non-functional Requirements ...... 9 3.3 Similar Solutions ...... 9 3.3.1 Guidebook ...... 9 3.3.2 Doubledutch ...... 11 3.3.3 CrowdCompass ...... 11 3.3.4 Bizzabo ...... 12 3.3.5 Conclusion ...... 13 4 Design ...... 14 4.1 Frontend ...... 14 4.1.1 Mobile Development Approaches ...... 14 Native ...... 14 Web...... 15 Hybrid ...... 15 Conclusion ...... 18 4.1.2 Round-Trip vs Single-Page Applications ...... 18 4.1.3 Hybrid WebView Frameworks ...... 19 Apache Cordova / PhoneGap ...... 19 Trigger.io ...... 21 Conclusion ...... 21 4.1.4 JavaScript Frameworks ...... 21 jQuery ...... 21 AngularJS ...... 22 Comparison of jQuery and AngularJS ...... 23 Conclusion ...... 25 4.1.5 Responsive Web Design and CSS Preprocessors ...... 25 Sass...... 26 LESS ...... 29 Conclusion ...... 29 4.1.6 UI Frameworks ...... 29 Ionic ...... 29

vi Famo.us ...... 31 Onsen UI ...... 31 Conclusion ...... 31 4.1.7 Frontend Architecture ...... 32 4.1.8 Design Mockups ...... 32 4.2 Backend ...... 33 4.2.1 IBM Bluemix as a Computing Platform ...... 35 4.2.2 Node.js as a Runtime Environment ...... 36 4.2.3 MySQL as a RDBMS ...... 37 4.2.4 MongoDB as a NoSQL DB ...... 38 4.2.5 Backend Architecture ...... 38 4.3 Overall System Architecture ...... 39 4.4 Entity-relationship Model ...... 40 4.5 REST API Model ...... 43 4.5.1 REST Methods for the Administration Application ...... 43 4.5.2 REST Methods for the Event Application ...... 44 4.6 WebSocket model ...... 46 4.7 Conclusion ...... 47 5 Implementation ...... 49 5.1 Administration Application ...... 49 5.1.1 User and Event Management ...... 51 5.1.2 Native Push Notifications ...... 51 5.1.3 Data Analytics ...... 53 5.2 Event Application ...... 54 5.2.1 iBeacon Micro-location ...... 54 5.2.2 Real-time Multi-user Collaboration ...... 56 5.3 SocialWall Application ...... 57 6 Conclusion ...... 59 6.0.1 Future Directions ...... 59 A Lab Equipment ...... 69 B Design Mockups ...... 70 C Accompanied Data ...... 79

vii 1 Introduction

Research & Development divisions of global technology companies can not afford to operate in isolation from the outside world, as they used to many years ago. Listening to clients is more important now than ever before. With markets becoming global and filled with startup companies that are able to deliver new solutions rapidly, Research & Development divisions of large companies must adapt. They must open themselves to the outside world, allowing researchers to meet with clients and exchange their insights and ideas and the challenges they face. Furthermore, they must be able to clearly communicate which particular capa- bilities they offer and what their area of expertise is. By doing so, researchers are able to better understand the needs and problems of their clients, and clients are able to understand the capabilities and solutions deliverable by Research & Development divisions. As a result, new ideas and solutions can emerge. In IBM Research, we try to create a collaboration space where clients and researchers can share their expertise and work together on new ideas. We intend to create a window in the imaginary wall that separates researchers and clients. With this goal in mind, we recently opened a lab where we run interactive workshops and allow clients to explore the capabili- ties of IBM Research. Part of this initiative is the creation of a mobile event application that allows for more interactive collaboration and better information sharing. We believe that the event application can fuel the process of innovation and collaboration during client workshops and allow us to leverage the cutting-edge technology available in our labs. The goal of this thesis is to implement a cross-platform mobile event application that would be used during client workshops. The text of this thesis documents the phases of the application development lifecycle, such as project initiation, requirements analysis, design, and implementation. The following chapter introduces the topic of the thesis in project management terms and briefly touches on areas such as project background, project purpose, project scope, and project risk. The third chapter covers the analysis of requirements. At the beginning, the functional requirements are defined and a use case diagram representing typical user interactions with the system is presented. The rest of the chapter is dedicated to non-functional requirements and similar solutions available on the market. The fourth chapter describes the design phase of the development process. It includes a description of the technology used together with the reasoning behind its selection. Follow- ing this, system architecture and entity-relationship diagrams are presented. Towards the end of the chapter, REST API and WebSocket model are described. The fifth chapter demonstrates how the most important parts of the application were implemented. I show several code snippets together with screenshots of the application.

1 2 Project Initiation

2.1 Project Background

This diploma thesis is written as part of my internship at IBM Thomas J. Watson Research Center in Yorktown Heights, USA. IBM Research is the Research & Development division of IBM and the largest industrial research organization in the world, with twelve labs in six continents. [1] “For more than sixty years, IBM Research has been the innovation engine of the IBM corporation. From helping the Apollo space missions land on the moon to the discovery of fractals; from the technology behind laser eye surgery to a question answering computer called Watson now being applied to health care.”[2] The thesis reflects on a project that implements a mobile event application. The project is undertaken in the THINKLab department. THINKLab is a worldwide network of labs specifically designed for inventing with clients. The goal of THINKLab is to match IBM Research’s innovation capabilities with the expertise of industry leaders who want to tackle challenges that cannot be solved through existing commercial products. The labs provide a space equipped with advanced visualization and interaction tech- nologies that make collaboration possible. Every THINKLab is equipped with an Oblong Mezzanine1 collaboration system and the custom made Galaxy Application built on top of the g-speak platform2. Oblong Mezzanine allows multiple users and their devices and data to be connected in one shared collaboration workspace. Spatial wands can then be used to manipulate data on multiple screens. The Galaxy Application was built specifically to demonstrate IBM’s research capabilities. It is a catalogue of research projects from where individual project presentations can be launched and displayed on several large screens. Spatial wands or touch gestures can be used to interact with the system. Pictures of the Mezzanine Oblong system and the Galaxy Application can be seen in Appendix A.

2.2 Project Purpose

THINKLab runs multi-day workshops with clients that want to discuss the challenges they face, brainstorm ideas that could potentially turn into new innovations, and make connec- tions with researchers. The challenge of the lab is to continuously improve the process of innovation and client engagements, and establish long-term partnerships with clients that have a desire to experiment with advanced technology. In order to tackle this challenge, the following needs must be fulfilled: • IBM needs: To have a deeper understanding of clients by interacting with them and to improve the client experience during workshops. • Clients need: To recognize IBM’s research capabilities and get in touch with researchers. To get personalized information that is relevant to their needs.

1. http://www.oblong.com/mezzanine/overview/ 2. http://www.oblong.com/g-speak/

2 2. PROJECT INITIATION

• They both need: To allow clients and researchers to collaborate in new and interactive ways to support the process of innovation. After several discussions, a decision was made to build a mobile application that would create a one-of-a-kind experience. By satisfying the needs mentioned previously, the applica- tion would fuel the energy of workshops, giving everyone immediate access to information that is being generated and allowing for personalized content. The idea of a mobile applica- tion was chosen as a result of the growing popularity of tablets and smart phones, as shown in Figure 2.1.

Figure 2.1: Business Insider: The Future Of Mobile [3]

The need for a mobile application can be also justified by the following text from Feeling is believing: The 5 emotions of successful event apps [4]: “Mobile experiences are the future of event communications. Offering attendees a mobile event app shows that you’re paying attention to what they want. You’ll be seen—and felt—as a brand evolving with today’s important trends.”

2.3 Project Scope

This project is being undertaken to develop a multi-platform mobile application that would enhance client engagements and help to improve the process of innovation. The application

3 2. PROJECT INITIATION should allow clients to collaborate in more compelling ways, provide interaction with the technology available in the lab and improve how information is spread and shared. The application will also collect data on user interactions to allow the continuous improvement of client workshops. The deadline for delivering the application is set to May 30th, 2015. Upon completion, the application will include the following features:

• user and event management;

• iBeacon micro-location;

• integration with Galaxy Application (catalogue of research projects);

• native push notifications;

• real-time multi-user collaboration;

• real-time activity feed;

• real-time Twitter integration;

• survey;

• data analytics.

The long-term goal is to build an application that would be used before, after, and during client workshops. Before clients visit the lab, the application would be used to collect data that would help to tailor the upcoming meeting according to their expectations and the challenges they face. After clients visit the lab, they would be provided with the information that was available to them during the workshops. This project is solely focused on the use of the application during client visits, although the long-term goal should be kept in mind during the design phase. The detailed requirements of the project are described in the following Analysis chapter.

2.4 Project Resources

The development team consists of two designers and one developer. My role as a lead devel- oper is to be responsible for the system architecture, infrastructure decisions, and develop- ment. The user interface designers, skilled in web development technologies, are responsible for preparing design mockups and implementing them. All the technical functionalities, models, design mockups, and application screenshots presented in the thesis were designed and implemented solely by me. As the project pro- gressed, my responsibilities expanded. I wasn’t only responsible for the development of the application, but my list of tasks also included preparation and implementation of the user interface, creation and management of the development and production environments, automation of deployment, negotiation with the security team, and integration with other systems.

4 2. PROJECT INITIATION

2.5 Project Stakeholders

The following are entities that have an interest in the given project:

• Workshop attendees

– Clients – IBM employees (Researchers, Consultants, Subject-matter experts)

• Workshop hosts (IBM employees)

• Development team

– Lead developer – User interface designers

• Director of the lab – executive sponsor of the project

2.6 Project Risk

The matrix includes project risks and their probability and impact in the project’s cost and schedule. Risks with a higher risk score should be handled first by a team member. Risk score is calculated as a multiplication of probability, cost impact, and schedule impact.

Risk Probability Cost im- Schedule Risk score Action by (1-4) pact (1-4) impact (1-4) Confidential data 1 4 1 4 (1*4*1) Developer breach Lead Limited network 4 1 2 8 (4*1*2) Developer access due to Lead security restrictions

Table 2.1: Project risks

Probability level Description Value Very high Issue, 70-99% chance 4 High Almost certain, 50-70% chance 3 Medium Fairly likely, 30-49% chance 2 Low Unlikely, less than 30% chance 1

Table 2.2: Probability levels

5 3 Analysis

The definition of requirements is a crucial part of the overall software development lifecycle. It describes what the system under development should do. Poorly defined requirements or requirements that do not reflect real needs can cause the project to fail or scope creep. Therefore, sufficient effort should be made to understand stakeholders’ needs. At the beginning of the project, several stakeholders were interviewed in order to cap- ture their needs and understand their points of view. We also held several brainstorming sessions with our internal team that helped us to prioritize the work and dismiss some of the irrelevant requirements. The functional and non-functional requirements are as follows: functional requirements represent the features and behavior of the system; non-functional requirements place con- straints on the system. The plan for implementing functional requirements is detailed in the Design chapter. The plan for implementing non-functional requirements is detailed in the Overall System Architecture section.

3.1 Functional Requirements

The solution should consist of three separate applications: the Event Application, the Ad- ministration Application, and the SocialWall Application. The Event Application will be used by workshop attendees. The Administration Application is intended to be used by workshop hosts, top management, and other internal employees. The SocialWall Applica- tion will be a web application visualizing social interactions related to the lab or particular events and, therefore, will be used by anybody physically present in the lab. Separate ap- plications need to be created because we want to minimize the security risk resulting from unauthorized access to confidential data and internal systems. The following sections cover the specific requirements for each application.

3.1.1 Event Application • Authentication and login -– Registered users should be able to login to the application and see information relevant to the events associated with their account.

• Agenda – Users should be able to see event agendas. An agenda can consist of multiple days.

• People – Users should be able to see profiles of all attendees and be able to add and remove them from their personal list of connections.

• Research projects – Users should be able to see the list of research projects. The list can be filtered according to industry and other meta data provided by an external tool. Users can obtain a short description (abstract) of a particular research project and can launch the project presentation on one of the displays inside the lab. They can man- ually choose which screen to display the research project on or let the application automatically choose the closest screen (using iBeacons micro-location technology).

6 3. ANALYSIS

Users can add research projects to their list of favorites. Users can take notes on par- ticular research projects. Users can rate research projects (using multiple checkboxes such as “Informative”, “Inspiring”, “Confusing”).

• Personal profile – Users should be able to access their personal profile, which shows their connections, favorite research projects, and notes.

• Information about the lab – Users should be provided with information about IBM Re- search and the lab they are visiting.

• Survey – Users should be able to complete a simple survey that is created in the Ad- ministration Application.

• Native notifications – Users can receive notifications through the native push notifica- tion system (GCM1 for Android, APN2 for iOS). Appropriate action should be trig- gered when a user responds to a notification (for example, a survey page opens).

• Real-time collaboration – Users should be provided with a collaboration space (page) where they can create, edit, and delete sticky notes and see sticky notes created by other users in real-time. The application should provide a simple voting system that would allow for ranking (prioritization) of the created sticky notes. The collaboration space should also provide a list of users currently working in the space.

• iBeacon micro-location – Applications should be able to detect iBeacons installed in the lab that are in near or immediate proximity.

3.1.2 Administration Application • Manage administrators – Administrators should be able to add, edit, and remove other administrators. Only administrators are privileged to access the Administration Ap- plication.

• Manage clients – Each client represents a company. An administrator should be able to add, edit, and remove clients. The following information about each client should be stored: company name, city, country, state.

• Manage user accounts – Users represent workshop attendees and are privileged to ac- cess the Event Application. They must be associated with a client. A user can either be a client’s employee or an IBM employee. The following information about each user should be stored: first name, last name, e-mail, client, role name, role category (such as C-level Manager or Software Engineer), department.

• Manage user roles – For analytics purposes, we need to know which roles are held by users. Therefore, we need to be able to define a list of predefined categories (such as

1. Google Cloud Messaging for Android – https://developer.android.com/google/gcm/index. html 2. Apple Push Notification Service – https://developer.apple.com/library/ios/ documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ ApplePushService.html

7 3. ANALYSIS

C-level Manager or Software Engineer) and associate a particular role category with a user.

• Manage events – Each event represents a workshop and other client meeting. Admin- istrators should be able to add, edit, and delete events. Events are associated with clients and industries. Additional information that should be stored about each event includes the start date and end date.

• Manage industries – For analytics purposes, we need to associate events with specific industries. Therefore, we should be able to define a list of industries.

• Manage list of users attending an event – Each event includes a list of attending users. Those users must either be associated with a particular client attending the event or be IBM employees.

• Manage agenda – Each event has an agenda that consists of activities. We should be able to add, edit, and remove activities. An agenda can be created for multiple days.

• Push notifications – We want to be able to send native push notifications to mobile devices that are registered with a specific event.

• Manage real-time collaboration spaces – We should be able to set up collaboration spaces. A collaboration space is a page where multiple users can create sticky notes and see sticky notes created by other users in real-time. Multiple collaboration spaces can be assigned to one event. Collaboration spaces should allow for simple voting and the ongoing results of the voting should be available in the form of a bar chart.

• Manage surveys – We should be able to create multiple surveys for a particular event. Surveys consist of several questions. Each question will have a specific form (an open- ended question with a free form text response, a rating question with a response on a scale from 1 to 5). A functionality to open and close a survey should be provided. When a survey is set to open, users attending the event should receive a push notifi- cation.

• Manage iBeacon locations – The application should provide with a simple administra- tion of iBeacons installed in physical space. We want to be able to manage a list of locations where each of them is identified by one or multiple iBeacons (this method is often called geofencing). A location will be described by a name and a description. Each iBeacon is described by its UUID and its major and minor number.

• Analytics – The administration should provide basic data analytics. Visualizations such as bar charts, pie charts, line charts, and map charts should be provided.

• Authentication through LDAP – Administrators should be authenticated using LDAP.

3.1.3 SocialWall Application • Twitter integration — The application should obtain tweets related to the lab or partic- ular events from Twitter Streaming API.

8 3. ANALYSIS

• Real-time visualizations — The received Twitter data should be visualized in real-time on big screens available in the lab. The most recent text tweets and media tweets with pictures should be displayed. Tweets with geolocation information should be visualized on a map.

3.1.4 Use Case Diagram A use case diagram represents typical user interactions with the system and is considered for high-level requirements analysis. It consists of actors, use cases, and relationships. An actor represents the user’s role in the system and a use case describes the goal that the user intends to achieve. Use case diagrams also help to reveal system boundaries. Figure 3.1 contains a use case diagram of the system under development.

3.2 Non-functional Requirements

• The application should be available on multiple mobile platforms (iOS, Android).

• The application should use existing services available on the IBM Bluemix cloud plat- form.

• The application should be primarily designed for iPad Air, but provide enough flex- ibility to be designed for different devices and different screen sizes. Clients coming to the lab will be provided with IBM-owned iPads.

• The application needs to be compliant with IBM security policies.

• The application needs to be compliant with IBM design guidelines.

3.3 Similar Solutions

Even though our project is very unique, and some requirements are directly connected with the lab equipment, it can still be beneficial to explore other mobile event applications avail- able on the market and see what advanced features they offer. This could give us a better understanding of other functionalities that could be implemented into the application.

3.3.1 Guidebook

Guidebook3 offers a paid configurator that allows one to create his own event application step-by-step. The application is then built and published. Figure 3.2 shows a screenshot from the configurator. Guidebook offers the following advanced features: [5]

• native push notifications;

• surveys & polling.

3. http://www.guidebook.com

9 3. ANALYSIS

Figure 3.1: Use Case Diagram

10 3. ANALYSIS

Figure 3.2: Guidebook Configurator [5]

3.3.2 Doubledutch

Doubledutch4 works on very similar principles as Guidebook. It provides a configurator where one can set up his own event application. Figure 3.3 shows the configurator. The application offers the following advanced features: [6] • location-based messages using iBeacons; • native push notifications; • surveys & polling; • QR and barcode scanner.

3.3.3 CrowdCompass

CrowdCompass5 offers a more complex solution. The company creates custom native ap- plications for Android and iOS and supports other devices with HTML5. CrowdCompass offers the following advanced features: [7] • location-based messages using iBeacons; • native push notifications;

4. http://doubledutch.me 5. http://www.crowdcompass.com

11 3. ANALYSIS

Figure 3.3: Doubledutch Configurator [6]

• surveys & polling;

• QR and barcode scanner;

• direct messaging between attendees;

• social wall that allows real-time interactions to be shown on a big screen;

• social game that brings gamification to the event.

3.3.4 Bizzabo

Bizzabo6 takes a slightly different approach. The company aims to build a networking ap- plication that would become a standard for events of all shapes and sizes. Instead of build- ing custom applications for its clients (often called white label), Bizzabo provides a platform where one can register his events. The attendees then download the Bizzabo mobile applica- tion and sign up for the events. Figure 3.4 shows the Bizzabo Management System. Bizzabo offers the following features: [8]

• native push notifications;

• surveys & polling;

• direct messaging between attendees.

6. https://www.bizzabo.com

12 3. ANALYSIS

Figure 3.4: Bizzabo Management System [8]

3.3.5 Conclusion There are several mobile event applications available on the market. Most of them offer standard functionalities such as an agenda builder, a list of attendees, surveys and polling, one-on-one messaging, and native push notifications. Although we are planning to build the same functionalities, our scope is narrowed to the specific needs of our lab such as in- tegration with our internal systems and visualization equipment. Nevertheless, the analysis of existing similar solutions serves as a good illustration of what event attendees might be looking for and how we could improve client engagements.

13 4 Design

Languages, tools, and technologies used during development are key factors in making applications different from one another. This chapter describes mobile development ap- proaches, the differences between single-page and round-trip models, and the technologies and tools used during implementation. Once decisions are made on which tools and tech- nologies to use, the overall system architecture, entity-relationship model, and REST API and WebSocket models are created.

4.1 Frontend

This section discusses decisions regarding the tools and technologies related to the presen- tation layer of the application. The frontend is considered as an interface between the user and the backend system.

4.1.1 Mobile Development Approaches Mobile application development can be a very complex and challenging task due to the variation of mobile platforms (iOS, Android, Windows Phone). As a result, different devel- opment approaches have emerged and we must make an informed decision about which one to use.

Native Native applications are written in the native language of the platform (Objective-C for iOS, Java for Android, C#/.NET for Windows Phone). They have direct access to native services, such as cameras, through the API provided by the platform’s SDK. The platforms SDKs also provide user interface components such as animations, dialogs, gestures, tabs, or menus, and, as a result, each platform has its own unique look and feel. The main advantage of native applications is their performance. Native code is compiled and runs at a low level, allowing developers to build computing intensive applications or applications with complex animations. A disadvantage of native applications is their porta- bility – they can only run on the platform they were developed for. From the user interface perspective, no two platforms have the same or even similar paradigm, therefore most of the code will have to be rewritten with little able to be shared. In a nutshell, native code devel- opment can be a very complex task that requires developers skilled in each of the platforms. On the other hand, it offers the best in terms of performance. [9, 10] “What makes things even more complicated are the differences among the actual plat- form SDKs (software development kits). There are different tools, build systems, APIs, and devices with different capabilities for each platform. In fact, the only thing these operat- ing systems have in common is that they all ship with a mobile browser that is accessible programmatically from the native code.” [11] In general, native development approach is usually used when we need to build the following: [9]

• high performance applications (i.e. heavy image processing);

14 4. DESIGN

• complex UIs with lots of animation;

• games (i.e. 3D).

Web Web applications are accessed through the device’s browser and are usually developed in HTML and JavaScript. Web applications are easy to maintain as there is only one instance of the application being accessible from several platforms. Another benefit of using web applications is that the global standard created by W3C1 provides backward compatibility in such a way that HTML4 applications will work in HTML5-compatible browsers. The same cannot be said about applications developed for iOS 7 that are run on iOS 8. [12] Web applications are not installed locally on the device (are not distributed via app stores) and must be accessed from the Internet. This becomes a problem in places where there is no or poor Internet connection. Their graphical user interface is completely ren- dered in the browser and dependent on the type and version of the browser used, requiring more thorough testing. The biggest drawback of the web approach is the lack of integration with device services such as bluetooth, a microphone, or camera. Although HTML5 comes with Geolocation API (gps) and Orientation API (accelerometer), and allows for image uploads using a built-in camera, its support in today’s browsers is still only partial. [13] Although W3C is actively working on standards for client-side APIs that would allow browsers to access device ser- vices such as a calendar, contacts, or battery status, it will be some time before the majority of browsers adopt them. [14] The last point to mention is performance. “Native apps do not have the web runtime barrier to deal with. They run close to the metal and can take advantage of performance boosters like GPU acceleration and multithreading.”[15] Poor performance used to be a big drawback of web applications, but a lot has changed in the last years. As one can see in Fig- ure 4.1 and Figure 4.2, performance of mobile devices as well as interpretation of JavaScript and graphic rendering has improved significantly. [16, 17] In general, the web development approach is usually used when we need to build:

• multi-platform applications;

• applications that do not need access to device services such as cameras or bluetooth;

• non-intensive computing applications;

• applications that do not need to be distributed through app stores.

Hybrid The hybrid approach combines the advantages of the native and web approaches. Hybrid applications are installed on the device in the same way as native applications. The only dif- ference is that they are built with a combination of web technology, such as HTML, CSS, and JavaScript, and are hosted inside the application’s WebView (one can think of the WebView

1. http://www.w3.org/

15 4. DESIGN

Figure 4.1: Benchmark of mobile devices – scores are calibrated against a baseline score of 2500, which is the score of an Intel Core i5-2520M @ 2.50 GHz (higher scores are better) [18] as a browser window that runs in fullscreen within the native application). This enables the application to access device services even though it is implemented as a web application. Hybrid applications have the advantage of portability to different platforms. However, compared with web applications, they can still access device services which are restricted to access from inside mobile browsers. Hybrid applications consists of two parts – the web applications written in HTML, CSS, and JavaScript and hosted in WebView, and a wrapper that opens the WebView and provides JavaScript APIs for platform specific services such as an accelerometer or bluetooth. Figure 4.3 shows an architecture of the hybrid application As web technologies are becoming well standardized and familiar to many developers, it makes the development of hybrid applications more rapid and easier to maintain. Hybrid frameworks like Apache Cordova let one build the application for more than one platform just by adding a line of code. Developers do not like to get locked into proprietary platforms and hybrid applications allow them to reuse their existing web development skills. The main problem with hybrid applications is their performance. As mentioned in the previous section, the problem is becoming less significant as devices are becoming more powerful and JavaScript interpretation engines are becoming smarter and more optimized. At the time of writing this thesis, Apple introduced the new WKWebView that will improve

16 4. DESIGN

Figure 4.2: Performance of popular JavaScript engines based on Octane benchmark (lower scores are better) [19] the performance of hybrid applications running on the iOS platform by 20%.[20] Since ver- sion 4.4, Android has used the powerful Chromium web engine for its WebView and since version 5.0 has the ability to update WebView independently of the Android platform, re- sulting in the latest WebView version installed on all devices with Android version 5.0+. [21, 22] All the recent improvements indicate that the mobile platforms take hybrid devel- opment seriously and will keep optimizing their WebViews in order to provide even better performance. In general, the hybrid approach is usually used when one needs to build:

• multi-platform applications;

• applications that need to access device services such as cameras or bluetooth;

• non-intensive computing applications;

• applications that need to be distributed through app stores.

It is important to mention that hybrid applications do not have to be built using web technologies. For example, the Xamarin project allows the application to be developed in C# and compiled to native applications. [23] The drawbacks are that one still need to build the UI for every platform the application is targeting, developers need to be skilled with C#, it supports only iOS, Android, and Windows Phone platform, and the community of de- velopers is relatively small. Another project, Titanium, translates JavaScript directly into the native code of the device. The downside is that only iOS, Android, and Blackberry platforms are supported, and that many developers consider titanium to be very buggy, which leaves applications with unpredictable behavior. Consequently, I decided not to write about these technologies, even though they might be a good fit for some projects.[24, 25, 9]

17 4. DESIGN

Figure 4.3: Architecture of a hybrid application

Conclusion This section has described the different approaches to mobile application development. Each approach has its particular advantages and disadvantages (Table 4.1 provides an overall comparison). It is important to realize that the decision about which approach to use can have a huge impact on the overall architecture of the application. If we take into account the requirements mentioned in the Analysis chapter, the goal of the project is to build an appli- cation that would be available on multiple mobile platforms and have access to native device services. We can expect that the application will not have to do any heavy computation nor extensive image processing. Due to this, as well as the skills and size of the development team, we decided that building a hybrid application would be the best fit for our project.

4.1.2 Round-Trip vs Single-Page Applications As Adam Freeman describes in his book Pro AngularJS [27], at the early stage of the web, applications were developed to follow a round-trip model. In this model, the browser sends an initial request to a server and receives an HTML document. All user interactions on the document (such as form submissions) result in requesting and receiving a completely new HTML document. In the round-trip model, the browser tends to be a thin client that only renders HTML documents as all the application logic is happening on the server side. The round-trip model has several drawbacks. Higher performance requirements are put on the server as this is where most of the application logic resides. Larger network band- width is needed because duplicate content – such as headers and page layout – is being transferred with each response. This all results in a slower response time. Single-page applications work differently. At the beginning, the browser sends an initial request to a server and receives a HTML document. But the following user interactions lead to Ajax requests that request only small fragments of data to be transferred. Instead of trans- ferring the whole HTML document and re-rendering the user interface, Ajax requests only

18 4. DESIGN

Native Hybrid Web Cost Commonly the highest of Similar to pure web costs, Lowest cost due to sin- the three choices if develop- but extra skills are required gle codebase and common ing for multiple platforms for hybrid tools skillset Code reusabil- Code for one platform only Most hybrid tools will en- Browser compatibility and ity / portabil- works for that platform able portability of a single performance are the only ity codebase to the major mo- concerns bile platforms Device access Platform SDK enables ac- Many device APIs closed to Only a few device APIs like cess to all device APIs web apps can be accessed, geolocation can be accessed, depending on the tool but the number is growing UI consistency Platforms comes with famil- UI frameworks can achieve UI frameworks can achieve iar, original UI components a fairly native look a fairly native look Distribution App stores provide market- App stores provide market- No restrictions to launch, ing benefits, but also have ing benefits, but also have but there are no app store requirements and restric- requirements and restric- benefits tions tions Performance Native code has direct ac- For complex apps, the Performance is based on cess to platform functional- abstraction layers often browser and network con- ity, resulting in better per- prevent native-like perfor- nection formance mance Monetization More monetization oppor- More monetization oppor- No store commissions or tunities, but stores take a tunities, but stores take a setup costs, but there are percentage percentage few monetization methods

Table 4.1: Native vs. Web vs. Hybrid: 7 factors of comparison [26] allow the data that is needed to be transferred and plug it into existing elements that are being displayed to the user. This means that the initial HTML document is never reloaded. The single-page model also has some drawbacks. Ajax calls are performed asynchronously and usually add more complexity to the application. Single-page applications need more powerful browsers since most of the application logic is happening in the browser. Today, most of the applications fall somewhere between the two. For our project, we decided to use the single-page model because we want to deliver a seamless user experience with fluid transitions and short response times.

4.1.3 Hybrid WebView Frameworks In this section I briefly describe two hybrid WebView frameworks – Apache Cordova and Trigger.io.

Apache Cordova / PhoneGap

Apache Cordova2 is an open source hybrid framework for building native mobile applica- tions using HTML, CSS, and JavaScript. In a nutshell, it is a set of APIs that allow JavaScript functions that map to native code or plugins to be called, creating a bridge from web into native code. Cordova provides powerful low-level API allowing developers to do almost anything a

2. https://cordova.apache.org

19 4. DESIGN native application can do. It comes with a set of pre-made easy-to-use plugins to access, for example, the camera or compass. The provided APIs are consistent across multiple device platforms, supporting iOS, Android, Blackberry, Windows Phone, Palm WebOS, Bada, and Symbian. [28] Cordova has a large active community and provides more than 900 third-party plugins. Following is a list of the out-of-the-box plugins: [29] • Battery Status – Monitor the status of the device’s battery. • Camera – Capture a photo using the device’s camera. • Console – Add additional capability to console.log(). • Contacts – Work with the devices contact database. • Device – Gather device-specific information. • Device Motion (Accelerometer) – Tap into the device’s motion sensor. • Device Orientation (Compass) – Obtain the direction that the device is pointing. • Dialogs – Visual device notifications. • FileSystem – Hook into native file system through JavaScript. • File Transfer – Hook into native file system through JavaScript. • Geolocation – Make the application location-aware. • Globalization – Enable representation of objects specific to a locale. • InAppBrowser – Launch URLs in another in-app browser instance. • Media – Record and play audio files. • Media Capture – Capture media files using device’s media capture applications. • Network Information (Connection) – Quickly check the network state and cellular net- work information. • Splashscreen – Show and hide the application’s splash screen. • Vibration – An API to vibrate the device. • StatusBar – An API for showing, hiding and configuring the status bar background. It is necessary to mention the difference between Apache Cordova and PhoneGap as these two names are sometimes confused. PhoneGap is a former product of Nitobi startup that was acquired by Adobe in 2011. Shortly after the acquisition, Adobe decided to donate PhoneGap’s source code to the Apache Software Foundation under the name Cordova and continued building proprietary services around its PhoneGap ecosystem. Today, PhoneGap is a distribution of Apache Cordova where Cordova plays the role of an engine that powers Phonegap. In other words, PhoneGap is Cordova plus extra proprietary Adobe services. [30, 31]

20 4. DESIGN

Trigger.io

Trigger.io3 is a lightweight alternative to PhoneGap, allowing developers to build native mobile applications using HTML, CSS, and JavaScript in the same way as PhoneGap. The project claims to have up to five times faster bridging technology than PhoneGap. [32] Al- though the Trigger.io project looks promising, it has several drawbacks. At the time of writ- ing, it only supports iOS and Android platforms and provides 30 plugins. Its community is significantly smaller compared with Cordova/PhoneGap. Moreover, it is a commercial product that comes with a free 14-day trial. [33, 34]

Conclusion I have briefly described the two major hybrid frameworks that use WebViews and provide bridging technology from JavaScript code to native code. Apache Cordova/PhoneGap is the most widely used framework when it comes to the development of hybrid applications, providing an extensive library of third-party plugins and a handful of out-of-the-box plu- gins consistent across multiple mobile platforms. Trigger.io is a commercial product that positions itself as a lightweight alternative to PhoneGap. The product claims to provide sig- nificantly faster bridging technology, although it lacks a bigger repository of plugins. Due to this and the fact that Trigger.io does not offer any third-party iBeacon plugin, we decided to use the Apache Cordova framework for the project.

4.1.4 JavaScript Frameworks Given the boom of web development libraries and frameworks, choosing the right ones for the project can be a daunting task. In this chapter, a brief comparison of two most commonly used JavaScript toolsets – jQuery and AngularJS – is provided. jQuery jQuery4 is a JavaScript library that allow developers to “write less, do more” [35]. Briefly said, jQuery offers a very mature and efficient way of querying, accessing, and modifying elements in Document Object Model (DOM) and simplifies things such as event handling, animation, and Ajax. In addition, jQuery has an extensive repository of plugins created by its large community. The jQuery library offers the following features: [36]

• HTML/DOM manipulation,

• CSS manipulation,

• HTML event methods,

• effects and animations,

• AJAX and other utilities.

3. https://trigger.io 4. https://jquery.com

21 4. DESIGN

Besides the core library, jQuery can be extended by jQuery UI and jQuery Mobile li- braries. jQuery UI is a set of user interface interactions, effects, widgets, and themes. jQuery Mobile is a user interface framework built on top of both jQuery and jQuery UI. It allows developers to build responsive web sites or applications that work on smartphones, tablets and desktop devices. [37, 38] jQuery Mobile has several weaknesses: [9, 27]

• It creates additional mark-up.

• It offers bad performance. Before it applies CSS, it runs a load of JavaScript, adding large numbers of classes all over the place.

• It provides many controls/functions, but only a very small part of them are used in applications, which causes a lot of waste of performance.

• It can be hard to write and manage large applications and thorough unit testing can be a challenge.

• It does not come with out-of-the-box functionalities, such as templating, data-binding, or dependency management, which are often necessary for the development of com- plex applications. However, third-party libraries such as Mustache, Knockout, Em- berJS, BackboneJS, or RequireJS can provide these functionalities.

I believe that jQuery and jQuery Mobile are great tools that have definitely earned their place – specially when it comes to round-trip applications or simpler projects that involve DOM manipulations and do not involve data manipulation. When more complex appli- cations need to be developed, additional libraries can help to deal with templating, data- binding, or dependency management. However, these libraries usually add another layer of complexity and can negatively impact the overall performance of the application.

AngularJS

AngularJS5 is an open source JavaScript framework sponsored and maintained by Google. “The goal of AngularJS is to bring the tools and capabilities that have been available only for server-side development to the web client and, in doing so, make it easier to develop, test, and maintain rich and complex web applications.” [27] AngularJS extends HTML by custom elements, attributes, classes or comments (called directives). Directives are markers on a DOM element that tell the AngularJS’s HTML compiler to attach a special behavior to that DOM element or even transform the DOM element and its children. [39] Following are the features offered by AngularJS: [9, 27, 39]

• two-way data binding between views and models, which eliminates DOM manipu- lation;

• built-in templating engine;

• cut-down version of jQuery called jqLite;

5. https://angularjs.org

22 4. DESIGN

• MVC pattern support that helps to divide the application into three distinct areas: the data (model), the logic that operates on that data (controller), and the logic that displays the data (view); • dependency management; • deep-link routing that allows the state of the application to be encoded in the URL so it can then be restored to the same state; • built-in services for RESTful server communication. AngularJS also has some drawbacks: • It needs up-front investment in development before initial results can be seen. • It extends HTML with additional elements, which can seem like an odd idea. AngularJS is a framework that can be used to build complex and high performance client-side web applications in a clean MVC way. By doing so, it places an emphasis on building applications that are maintainable, testable, and easily extendable.

Comparison of jQuery and AngularJS Some people may argue that jQuery and AngularJS are not comparable because they differ significantly from each other and jQuery is a library while AngularJS is a framework. In any case, they are the two most widely used JavaScript toolsets in web development and, therefore, I believe a brief comparison needs to be done in order to help us to decide which of them is more suitable for our project. It is important to note that jQuery and AngularJS can be used together, but as far as performance is concerned, only one of them should be used in our application. In this chapter, I have talked about single-page and round-trip models. Now it is time to compare jQuery and AngularJS in the context of these two types of models. Every time a new HTML document is loaded in AngularJS, the HTML elements have to be compiled, data bindings have to be evaluated, and directives need to be executed. This re- sults in an initial overhead that takes some time depending on the complexity of the HTML document and associated JavaScript code, the quality of the JavaScript engine used in the browser, and the processing capability of the device. It is evident that we want to minimize this overhead and, therefore, we want to load new HTML documents as infrequently as pos- sible. Consequently, AngularJS excels in a single-page model when a new HTML document is loaded only when the application is accessed for the very first time. [27] jQuery is a library that does not come with any out-of-the-box features supporting the development of complex applications. Even though third-party tools can be used to deliver on capabilities such as MVC pattern support, templating, and deep linking, AngularJS offers these out-of-the-box while maintaining much smaller footprint. If performance is one of the main concerns, jQuery is generally a better choice for simpler projects that use the round-trip model. As the project is moving closer to the single-page model and is becoming more complex, AngularJS is the right choice. Figure 4.4 shows the area where AngularJS is a better fit than jQuery. “Use AngularJS for more complex single- page web apps, when you have time for careful design and planning and when you can easily control the HTML generated by the server.” [27]

23 4. DESIGN

Figure 4.4: AngularJS is well-suited to single-page and complex web applications [27]

jQuery AngularJS Abstracts the DOM Yes Yes Unit Test Runner Yes Yes Deferred Promises Yes Yes Cross-Module Communica- Yes Yes tion Animation Support Yes Yes AJAX / JSONP Yes Yes RESTful API No Yes Integration Test Runner No Yes MVC Pattern Support No Yes Templating No Yes Two-way Data Binding No Yes Dependency Management No Yes Deep-Link Routing No Yes Form Validation No Yes Localization No Yes File Size 96 KB 126 KB

Table 4.2: Comparison of jQuery and AngularJS capabilities [40]

Table 4.2 compares the capabilities of both tools. [40] The capabilities missing by jQuery could be substituted by the following third-party tools:

• Knockout for MVC Pattern Support, Deep-Link Routing, and Data Binding (56 KB);

• Underscore for Templating (16 KB);

24 4. DESIGN

• RequireJS for Dependency Management (15 KB);

• jQuery Validation Plugin for Form Validation (22 KB).

It is worth noting the file size of each of the tools (all sizes stand for minified versions). jQuery used with the third-party tools mentioned above would amount to 205 KB while still not covering all the capabilities of AngularJS, which comes in at 126 KB. As file size certainly is not the only factor when it comes to benchmarking, the drawback from using several third-party tools should be as it can bring more complexity to the application and thus result in a bigger footprint.

Conclusion I briefly described the characteristics of both most widely used JavaScript toolsets in web development. After that, I compared them in the context of a single-page and round-trip model, and analyzed the capabilities they offer in the development of complex applications. The outcome of this comparison is that AngularJS is a good choice for complex projects as it offers capabilities such as MVC pattern support, templating, and deep-link routing. More- over, the nature of how AngularJS is executed makes it excel in single-page applications, allowing for better performance. jQuery, on the other hand, is a powerful tool that excels in situations when simple applications need to be developed rapidly. Its minimal initial work- load makes it a good fit for round-trip applications. As mentioned in the Round-Trip vs Single-Page Applications section, our goal is to build a single-page application that would deliver a seamless user experience with fluid transi- tions and short response times. By taking into account the complexity of the application and single-page requirement, we decided to use AngularJS as a JavaScript framework for our application.

4.1.5 Responsive Web Design and CSS Preprocessors As we are planning to build a mobile application using web technologies, we need to build a solid foundation of tools that would help to create a design that looks great at any size. Even though our main focus is to design the application for iPad Air, we want to build a responsive design that adapts to any screen size and delivers on great user experience across a wide range of devices (from desktop monitors to mobile phones). “Rather than creating disconnected designs, each tailored to a particular device or browser, we should instead treat them as facets of the same experience. In other words, we can craft sites that are not only more flexible, but that can adapt to the media that renders them.”[41] As Ethan Marcotte explains in his book Responsive Web Design [41], it takes the following core ingredients to create a responsive design:

• a flexible, grid-based layout;

• flexible images and media;

• media queries, a module from the CSS3 specification.

I do not intend to get deeper into responsive web design, but I believe it is important to keep in mind the preceding ingredients when deciding on the technologies and tools we

25 4. DESIGN want to use. Based on my previous experience, creating a responsive web design for a large application can be a very challenging task resulting in complex CSS styles that grow in size and are hard to maintain. Therefore, we plan to use a CSS preprocessor and frameworks that ease the process of implementing web design in CSS. A CSS preprocessor is a layer between the stylesheet that one authors and the .css file that is provided to the server. It extends the CSS language by adding features that make the development process easier and the CSS code maintainable. [42]

Figure 4.5: Compilation of styles from preprocessor syntax to plain CSS

Sass

Sass6 (Syntactically Awesome Style Sheets) is a meta-language on top of CSS that offers more power than is allowed by flat CSS. It comes with a simple and elegant syntax and features that are useful for creating manageable stylesheets. Moreover, Sass’ syntax is a superset of CSS3, meaning any valid CSS3 document is also a valid Sass document. The Sass preprocessor runs on Ruby and uses a command-line program to compile Sass files, that usually use the .scss file extension, into CSS. Following is the list of features with example code snippets: [42, 43]

• variables – Variables are used to store any CSS value that could be reused throughout the stylesheets.

1 $primary-color: #333;

2 body{ color: $primary-color;}

• nesting – CSS does not support nesting, Sass lets one nest CSS selectors in a way that follows the same visual hierarchy of HTML.

1 nav ul{ 2 margin: 0; 3 padding: 0;

4 list-style: none; 5 li{ 6 display: inline-block; 7 a{ 8 display: block;

9 &:hover{ 10 color: #666;

6. http://sass-lang.com

26 4. DESIGN

11 } 12 } 13 } 14 }

• partials and import – Partials are files that contain CSS styles that one wants to include in other Sass files. This allows stylesheets to be modularized. See Figure 4.6 for an example.

Figure 4.6: Example of Sass partials

• mixins – Mixins are reusable blocks of styles that come in very handy when it comes to vendor prefixes. They allow one to declare styles such as box-shadows or gradients once and reuse them anywhere else in the code.

1 @mixin border-radius($radius){

2 -webkit-border-radius: $radius; 3 -moz-border-radius: $radius; 4 -ms-border-radius: $radius; 5 border-radius: $radius; 6 }

7 .box{ @include border-radius(10px); }

• extend/inheritance – Extend allows one to share a set of CSS properties between one selector and another, reducing the amount of repetitive code.

1 .message{ 2 border: 1px solid#ccc; 3 padding: 10px;

4 color: #333; 5 } 6 7 .success{

27 4. DESIGN

8 @extend.message; 9 border-color: green; 10 } 11 .error{ 12 @extend.message;

13 border-color: red; 14 }

• operators – Sass allows standard math operators such as +, -, *, /, and % to be used.

1 .content{ 2 float: left; 3 width: 600px / 960px * 100%; 4 }

Compass and Bourbon Frameworks Sass is a powerful tool that can make complex stylesheets manageable and can significantly reduce duplicate code. Mixins, variables, and partials allow to build CSS frameworks that tend to abstract away the complexity of difficult CSS3 stacks and provide a codebase for often-repeated patterns. Compass7 is one such framework built on top of Sass. “Compass offers many pre-written CSS patterns, which will be updated as the properties evolve and vendor prefixes can be stripped away. Compass also makes image sprites and typographic systems easier to han- dle.” [42] For example, Compass includes a box-shadow mixin that takes four arguments and generates CSS properties with appropriate vendor prefixes. If the vendor prefixes change in the future, updating Compass handles the situation. For example, the box-shadow mixin provided by Compass:

1 #box-shadow-custom{ 2 @include box-shadow(red2px2px 10px);

3 } generates the following vendor-prefixed stylesheets:

1 #box-shadow-custom{ 2 -moz-box-shadow: red2px2px 10px; 3 -webkit-box-shadow: red2px2px 10px; 4 box-shadow: red2px2px 10px; 5 } Bourbon8 is a lightweight mixin library that offers better performance than Compass. [44] Similar to Compass, Bourbon helps one to forget about vendor prefixes as mixins auto- matically take care of them. On the other hand, Compass is a much larger set of tools with a larger user base offering a set of helper mixins and support for CSS sprites, and comes with several extensions such as grid frameworks Susy and Singularity, or a breakpoint-slicer that eases the process of writing media queries.

7. http://compass-style.org/ 8. http://bourbon.io

28 4. DESIGN

LESS

LESS9 is another popular CSS preprocessor that is very similar to Sass. It supports the same set of features such as variables, nesting, mixins, and others. The main difference between LESS and Sass is how they compile documents. LESS is a JavaScript library and, therefore, it compiles documents on the client-side. This can be very handy during development, as no command line is needed to compile the documents. Like Sass, LESS document can also be compiled with a command-line program. [45] Both LESS and Sass offer almost identical features; however, Sass has one big advantage – the Compass framework mentioned before. LESS does not provide any viable alternative to Compass, making it less robust in its functionality.

Conclusion While CSS preprocessors are not required for development, they can save a lot of time and make the development of complex applications much easier and more maintainable. I briefly described the two most common CSS preprocessors – Sass and LESS. Although they both offer similar functionality, Sass can be extended by the Compass framework, which provides many useful features. Therefore, we decided to use Sass with the Compass framework for our project.

4.1.6 UI Frameworks There are many user interface frameworks available to help one build hybrid mobile ap- plications. They offer a set of mobile-optimized HTML, CSS, and JavaScript components, as well as gestures and tools for building highly interactive applications. As we previously decided to use AngularJS as our prime JavaScript framework, we consider only UI frame- works that are built on top of AngularJS. For this reason, frameworks such as jQuery Mobile, Sencha Touch, or Kendo UI are not covered in this section.

Ionic

Ionic10 is an HTML5 mobile application development framework that comes with very native-styled mobile UI elements. Although Ionic is a young framework with its first al- pha being released in late November 2013, its becoming a very popular framework with a fast-growing community of developers. [46] Ionic’s goal is to close the gap between what native SDK on iOS or Android provides and is not available on the web. It offers a set of beautifully designed UI elements, layouts, and animations that make the development of hybrid applications easy and fast. Besides this, Ionic is built on top of AngularJS, which allows for minimal DOM manipulations and hardware accelerated transitions, making Ionic applications fast. Ionic comes with Sass and Apache Cordova under the hood, allowing for easy UI customizations and integration with device native services. [47] The whole motivation behind Ionic could be explained by one of the slides from Adam Bradley, co-creator of Ionic. Figure 4.7 displays the gap Ionic targets – the missing web SDK.

9. http://lesscss.org 10. http://ionicframework.com

29 4. DESIGN

Figure 4.7: Ionic’s goal is to deliver the missing web SDK [48]

“Ionic not only comes with well documented markup and CSS, but also JavaScript design patterns to help one build some serious apps with similar concepts to iOS and Android. We wanted to let developers create the same kind of pow- erful UI interactions seen in native apps, like side menus and navigation con- trollers. We wanted to free hybrid apps from the URL bar and move towards more generic and powerful View Controller concepts.”[49]

Figure 4.8 shows multilayer architecture of Ionic applications.

Figure 4.8: Multilayer architecture of Ionic applications

Besides all the great built-in features such as pull-to-refresh or infinite scroll, Ionic also offers a very powerful CLI (command-line interface) that takes development to a whole new level. It allows one to create, test, and deploy application onto any platform. One can use features such as Ionic Lab that allows building and testing iOS and Android versions side- by-side, or LiveReload that instantly updates application every time changes in the source code are made, even if the application is running on a mobile device. This means one do not

30 4. DESIGN need to rebuild the application for a particular platform every time there are some changes in the source code. [50] Ionic also comes with a great documentation and an open source icon library featuring over 440 icons. Besides this, the Ionic team have built the Ionic View application that allows one to distribute the application to testers and developers without having to go through app stores. They have also created Ionic Creator, an application that lets developers to build their applications with simple drag-and-drop components. And that is still not all, the team is planning to release the Ionic Push feature, which gives Ionic applications the ability to send native push notifications to devices on any platform. [50] As Adam Bradley announced at ng-conf 2015 [51], Ionic is planning to support the new version of AngularJS – AngularJS 2.0. With this in mind, and the fact that the company recently raised $2.6M [52], I believe that Ionic have a bright future in the mobile development world.

Famo.us

Famo.us11 takes a different approach as it completely rebuilds the browser rendering en- gine. As Hoc Phan wrote in Full-stack Mobile App With Ionic Framework [9]: “...instead of cod- ing typical html/css, you have to create surface (or div) and modifier (or class) in Javascript objects. The reason behind this approach is because the DOM management in the browser is very clunky in terms of event inheritance. This causes a lot of redundancy in event process- ing, which results in lagging UI, especially where there is a long list of rendered objects.” Famo.us is considered to be difficult to learn but excellent when it comes to performance. It uses a completely different approach to mobile development as the UI is completely writ- ten in JavaScript. Famo.us includes an open source 3D layout engine fully integrated with a 3D physics animation engine, allowing smooth complex UIs and 3D games to be built. Famo.us is one of the youngest frameworks, thus it lacks a bigger community, detailed doc- umentation, and real examples and show cases. But it is definitely a promising project that is growing quickly and in a good direction. [53, 54]

Onsen UI Onsen UI is an Ionic competitor that is built on top of AngularJS. Like Ionic, it also provides a set of UI elements that allows one to focus on the business logic of the application instead of inventing the wheel oneself. However, there are some small differences when compared with Ionic. First, Onsen UI uses a responsive layout, allowing for classic web development. Ionic, on the other hand, is not intended to be used for classic web development. Second, Ionic is a much more serious framework as it comes with powerful CLI and other useful tools that make development and deployment very smooth and fast. Third, Onsen UI has a much smaller community. [54, 55]

Conclusion I described three popular UI hybrid frameworks. Besides the fact that we want to use a UI framework that is built around AngularJS, we also concluded that we want to use Sass

11. http://famo.us

31 4. DESIGN as a CSS preprocessor and Apache Cordova as a hybrid WebView framework. These deci- sions leave us with two options – Ionic or Onsen UI. Since Ionic comes with larger active community and powerful CLI, we decided to use Ionic as a UI framework for our mobile application.

4.1.7 Frontend Architecture Figure 4.9 shows the frontend architecture consisting of the technology we decided to use for the development.

Figure 4.9: Frontend architecture

4.1.8 Design Mockups After deciding on frontend frameworks and toolsets, we want to create preliminary mock- ups of the user interface. However, there are a few sources we should be familiar with first: • IBM corporate design and guidelines (logos, colors, fonts);

• design of Ionic UI elements;

• iOS Human Interface Guidelines12.

12. https://developer.apple.com/library/ios/documentation/UserExperience/ Conceptual/MobileHIG/

32 4. DESIGN

Our preliminary mockups are created for the iPad Air display in portrait mode (1536 x 2048px). The following ten design mockups were created by me:

• Your Feed mockup displays personalized activity feed and notifications.

• Agenda mockup displays event agenda with separate tabs for each day.

• Projects mockup displays a grid of research projects and a search bar.

• Project mockup displays information about a particular research project in a popup window.

• People mockup displays a list of attendees with tabs that allow one to filter attendees by a company.

• Messages mockup displays direct messaging between two attendees.

• Collaboration mockup displays a collaboration space with a set of sticky notes and a list of online collaborators. Each tab represents a particular collaboration space that is available to the user.

• About Us mockup displays information about the lab and IBM Research. Information is split into several tabs.

• Survey mockup displays one particular survey question with the answer.

• SocialWall mockup demonstrates what real-time information could be displayed on big screens during a client event. The mockup is divided into nine parts as the screen wall system in the lab.

Figure 4.10 shows a design mockup of the Your Feed page. The rest of the mockups can be seen in Appendix B. For the user interface, we decided to use a left sidebar menu that is permanently visible for devices of tablet size in both portrait and landscape mode. The submenu, when neces- sary, is displayed as a tab menu under the header bar (see Appendix B). A light blue color was selected as a key color that highlights important states and indicates interactivity, giving the application a consistent visual theme.

4.2 Backend

In the first part of the Design chapter I described several frameworks and toolsets that can be used in the development of mobile hybrid applications. Those frameworks provide func- tionalities that can be used in the development of the frontend part of the application. In this part of the Design chapter, we decide on server-side technologies such as the comput- ing platform, runtime environment, databases, and source code management.

33 4. DESIGN

Figure 4.10: Design mockup of the Your Feed page

34 4. DESIGN

4.2.1 IBM Bluemix as a Computing Platform

IBM Bluemix13 is a cloud platform that supports several runtime environments, such as Java, Node.js, Python, or Ruby, and offers a set of services that can extend the functionalities of applications. IBM Bluemix comes with integrated DevOps services that allow the user to build, run, deploy, and manage applications on the cloud. It is based on the open source architecture of Cloud Foundry14, which supports the full application development lifecycle, allowing the user to manage several deployment environments and use advanced automatic builders. Cloud foundry comes with a powerful CLI that can be used in the deployment and man- agement of applications. Besides this, it is integrated with IBM JazzHub – an application lifecycle management tool that offers source code management and project planning based on Scrum methodology. IBM Bluemix is a great cloud platform that abstracts lower-level infrastructure and makes application deployments effortless, allowing developers to focus on the code. It offers a con- stantly growing set of tools, services, and runtimes, so developers can get up and running very quickly. Following is an example list of some of the services available on IBM Bluemix: [56] • Push – Push service allows one to send information to all application users or to a specific set of users and devices. One can let users to subscribe to specific tags or topics for notifications. Once users have been engaged, analysis of the number of devices that are registered to receive notifications, the number of notifications sent, and the platforms of devices that are receiving notifications can be created.

• Mobile Application Security – This service manages application access and implements a basic application security framework for the Mobile Cloud services. It makes sure that unauthorized, compromised, or lost devices cannot longer reach the Mobile Cloud services and data.

• Mobile Quality Assurance – Helps to capture tester and live-user experiences, including context-aware crash log and in-app bug reports, in-app user feedback and insightful and streamlined quality metrics. Automatically generates aggregated crash logs from pre-production and production environments, provides one with a feedback about his application directly from the customers, and mine application ratings and reviews to extract actionable insights.

• Mobile Data (powered by Cloudant) - Provides simple to use SDKs that give access to a scalable, fully managed database via familiar object-oriented APIs.

• Auto-scaling – The Auto-Scaling service enables one to automatically increase or de- crease the computing capacity of the application. The number of application instances are adjusted dynamically based on the Auto-Scaling policy defined.

• Monitoring and Analytics – Gain the visibility and control one needs over the applica- tion. Determine the response time application users see, understand the performance

13. https://www.bluemix.net 14. http://www.cloudfoundry.org

35 4. DESIGN

and availability of the application components, and leverage analytics to keep the application up and performing well. • MongoLab –A fully-managed cloud database service featuring highly-available Mon- goDB databases, automated backups, web-based tools, 24/7 monitoring, and expert support. • MySQL – A database-as-a-service for MySQL powered applications.

4.2.2 Node.js as a Runtime Environment

Node.js15 is an open source, cross-platform JavaScript Blocking I/O vs Non-blocking I/O [57] runtime environment for server-side and networking Blocking example applications. Node.js is built on top of the Google V8 An example of blocking is how some web servers like ones in Java or PHP JavaScript engine, which means Node.js applications handle requests. If your code does are written in JavaScript and use a similar syntax as something blocking, like reading some- front-end JavaScript applications, including objects, thing from the database, your code functions, and methods. [58] "stalls" at that line and waits for the op- Node.js comes with a built-in library that al- eration to finish. In that period, your machine is holding onto memory and lows applications to act as a web server. Thanks processing time for a thread that is not to its event-driven architecture and a non-blocking doing anything. In order to cater other I/O API that optimizes an application’s throughput, requests while that thread has stalled Node.js excels when it comes to real-time communi- depends on your setup. Your server cation. can spawn more threads to cater the request or, if you have a load balanc- The following are advantages of Node.js: [58, 59, ing setup, forwards requests to the next 60] available instance. This instills more • It is very lightweight and fast. setup, more memory consumed, more processing. • It is easy to configure and highly customizable. Non-blocking example In contrast, non-blocking servers like • It comes with the npm16 package manager that ones made in Node.JS, only use one contains 140.000+ packages that are available thread to service all requests. This might sound counter-intuitive, but the for free, and it handles dependencies excel- creators designed it with the idea that lently. the I/O is the bottleneck i.e. not com- putations. When requests arrive at the • It removes silos that existed between frontend server, they are serviced one at a time. and backend developers, making the devel- When the code serviced needs to query opment process more effective. Backend and the DB for example, it sends off a re- frontend teams can be merged into one unit. quest to the DB. However, instead of waiting for the response and stall, it • It allows one to build the application in sends the callback to a second queue and the code continues running. Now JavaScript “top-to-bottom”, even down to the when the DB returns data, the callback database level if NoSQL DB that stores objects gets queued in a third queue where in JSON (like MongoDB or Cloudant) is used. they are pending execution. When the This makes development and even hiring sig- engine is doing nothing (stack empty), nificantly easier. it picks up a callback from the third queue and executes it.

15. https://nodejs.org 16. https://www.npmjs.com

36 4. DESIGN

• It is capable of handling a huge number of simultaneous connections with high through- put. Therefore, it excels in building fast and scalable network applications. • It allows code to be reused across the client-side and server-side of the application. • Even though Node.js is initially designed without threads, one can still take advan- tage of multiple cores and spawn child processes using ChildProcess API. Node.js has one disadvantage – it is not designed for heavy computations as any CPU intensive operation annuls all of the throughput and any incoming request is blocked while the thread is busy crunching numbers.

Figure 4.11: Comparison between request handling in Node.js and a traditional server [60]

“How it works under-the-hood is pretty interesting. Compared to traditional web-serving techniques where each connection (request) spawns a new thread, taking up system RAM and eventually maxing-out at the amount of RAM available, Node.js operates on a single- thread, using non-blocking I/O calls, allowing it to support tens of thousands of concurrent connections (held in the event loop). A quick calculation: assuming that each thread po- tentially has an accompanying 2 MB of memory with it, running on a system with 8 GB of RAM puts us at a theoretical maximum of 4000 concurrent connections, plus the cost of context-switching between threads. That is the scenario you typically deal with in traditional web-serving techniques. By avoiding all that, Node.js achieves scalability levels of over 1M concurrent connections.” [60]

4.2.3 MySQL as a RDBMS

MySQL17 is the most widely used open-source relational database management system, which enables the delivery of reliable, high-performance, and scalable applications. MySQL

17. https://www.mysql.com

37 4. DESIGN is a powerful system that has been around since 1994. It is very stable, has a large commu- nity and is being used by many of the world’s largest organizations, including Facebook, Google, or Adobe. [61] Our application needs to store structured information about attendees, companies, events, and other entities. For this purpose, we want to use a relational database that would enforce referential and data integrity. There are several reasons why we decided to use MySQL over other relational databases:

• It comes with MySQL Workbench, a multi-platform tool that includes everything a database architect needs for creating complex ER models (forwards and reverse en- gineering, schema synchronization with the data model, server administration, SQL editor, and more).

• MySQL is a reliable and proven technology that is definitely going to meet the de- mand for our application (we do not expect more than a few hundreds of concurrent users, nor a big amount of user generated content).

• Object-relational mapping (ORM) package for Node.js exists (Bookshelf, Node ORM, Sequelize).

We choose a relational database as the primary data source over a non-relational one be- cause the relational database enforces a schema (imposes integrity constraints on a database) that ensures that the data persists in a declared format. Together with other data integrity and referential integrity checks, relational databases allow one to put more constraints on the data he stores, preventing unexpected data manipulations from happening.

4.2.4 MongoDB as a NoSQL DB MongoDB is an open-source document database, also classified as a NoSQL database. Mon- goDB stores data in JSON documents and uses a JSON-based query format. “A MongoDB deployment hosts a number of databases. A database holds a set of collections. A collection holds a set of documents. A document is a set of key-value pairs. Documents have dynamic schema. Dynamic schema means that documents in the same collection do not need to have the same set of fields or structure, and common fields in a collection’s documents may hold different types of data.” [62] One of the requirements for our application is to receive and store tweets from Twitter Streaming API and visualize insights on big screens available in the lab. MongoDB is a good fit for this task as tweets are represented as JSON documents and can be stored separately from other application data. There are several MongoDB ODMs (Object Document Mappers) available for Node.js such as Mongoose or Mongorito.

4.2.5 Backend Architecture Figure 4.12 shows the backend architecture built on top of the IBM Bluemix platform.

38 4. DESIGN

Figure 4.12: Backend architecture built on top of the IBM Bluemix cloud platform

4.3 Overall System Architecture

Figure 4.13 shows the overall architecture of the application consisting of the following IBM and third-party tools:

• Twitter Streaming API is used to retrieve public tweets related to the client event.

• Push Notifications Gateways are services that allow the user to send native push noti- fications to particular devices. GCM (Google Cloud Messaging) is used for Android devices and APNs (Apple Push Notification service) is used for iOS devices.

• Pusher API18 is an end-to-end service that allows us to build real-time applications. We use this service for building the real-time multi-user collaboration space.

• IBM Bluepages API allows us to authenticate users against the IBM internal LDAP server. This is used for the authentication of administrators.

• G-speak Systems are running visualizations on big screens inside the lab. Mobile de- vices should be able to directly connect to these systems and interact with them.

18. https://pusher.com

39 4. DESIGN

• IBM Galaxy Command API is used to launch presentations of research projects on the large screens available in the lab.

• IBM Faces API is used to retrieve information about IBM employees and their pictures.

Figure 4.13: Overall system architecture

4.4 Entity-relationship Model

Based on the application requirements, the preliminary ERD diagram was created in MySQL Workbench. The diagram can be seen in the Figure 4.14. The data model should be compliant with the Third Normal Form, which minimizes data redundancy and eliminates insertion, update, and deletion anomalies. Entity names come with “da_” prefix. The following is a brief description of the entities:

40 4. DESIGN

Figure 4.14: Entity-relationship model 41 4. DESIGN

• da_lab – represents one of the global labs;

• da_client – represents a company;

• da_event – represents an event and is associated with a particular lab and a client (company);

• da_user – represents an attendee, is associated with a particular client (company) and a user role;

• da_user_to_event – n:m relationship between events and users, represents an “attend- ing” relationship between a user and an event;

• da_user_role – represents a generic user role that is used for analytics purposes (such as C-level Manager or IT Architect);

• da_industry – represents an industry; each event is associated with a particular indus- try;

• da_ibeacon_location – represents a physical location that we want to geofence with sev- eral iBeacons; is associated with a particular lab;

• da_ibeacon – represents a physical iBeacon; is associated with a particular location;

• da_push_notification – represents a native push notification that has been sent to all attendees of a particular event;

• da_agenda_item – represents a part of the event;

• da_notification – represents a notification that is displayed to a user in a notification feed; is associated with a user and an event;

• da_message – represents a message sent from one attendee to another one; is associated with an event;

• da_feed_activity – represents an item on the event activity feed;

• da_survey – represents a survey; is associated with an event;

• da_survey_question – represents a survey question; is associated with a particular sur- vey;

• da_survey_answer – represents an answer to a survey question from an attendee; is associated with a survey question and a user;

• da_story – represents a research project;

• da_story_note – n:m relationship between stories and users; represents a note taken on a particular story by an attendee; is associated with an event;

• da_story_favorite – n:m relationship between stories and users; represents a “favorite” relationship between a user and a story; is associated with an event;

42 4. DESIGN

• da_story_rating – n:m relationship between stories and users; represents a rating cre- ated by an attendee; is associated with an event;

• da_user_favorite – n:m relationship between users; represents a “connected” relation- ship between two attendees;

• da_collaboration_space – represents a collaboration space where users can collaborate in real-time; is associated with an event;

• da_collaboration_space_item – represents a sticky note created by a user; is associated with a particular collaboration space;

• da_collaboration_vote – represents a vote on a collaboration space item created by a user;

• da_log – represents a log that monitors user activities such as logins;

• da_administrator – represents an administrators who is allowed to log in to the admin- istration.

4.5 REST API Model

This section describes the REST interface that needs to be implemented. REST methods are described separately for both Event and Administration applications since each of them will run on a separate Node.js server. The SocialWall application is not covered here.

4.5.1 REST Methods for the Administration Application The table below contains information about the REST interface that needs to be implemented for the Administration Application. One may notice rows where ALL is stated as a method. This means that all four GET, POST, PUT, and DELETE methods can be used for the partic- ular URI, and when PUT and DELETE methods are used, an attribute in the curly brackets {:attribute} is expected.

Method(s) URI Service Description POST /session/login Authenticate an administrator and create a session GET /session/logout Log out the administrator and destroy the session ALL /secure/clients/{:clientId} CRUD operations for clients ALL /secure/ibeacon_locations/{: CRUD operations for iBeacon ibeaconLocationId} locations ALL /secure/ibeacons/: CRUD operations for iBeacons ibeaconLocationId/{:ibeaconId} ALL /secure/users/{:userId} CRUD operations for users ALL /secure/labs/{:labId} CRUD operations for labs ALL /secure/events/{:eventId} CRUD operations for events

43 4. DESIGN

POST /secure/events/:eventId Add an event attendee DELETE /secure/events/:eventId/:userId Remove an event attendee ALL /secure/surveys/{:surveyId} CRUD operations for surveys ALL /secure/survey_questions/: CRUD operations for survey surveyId/{:surveyQuestionId} questions ALL /secure/agenda_items/:eventId/ CRUD operations for event {:agendaItemId} agenda items GET /secure/push_notifications/: Get a list of sent push notifica- eventId tions for a particular event POST /secure/push_notifications/: Create and send a native push eventId notification to all attendees of a particular event ALL /secure/industries/{: CRUD operations for industries industryId} ALL /secure/user_roles/{: CRUD operations for user roles userRoleId} GET /secure/stories Get a list of stories (research projects) GET /secure/stories/favorite Get a list of stories with associ- ated users who favorited them GET /secure/stories/rating Get a list of stories with associ- ated ratings GET /secure/stories/notes Get a list of stories with associ- ated notes ALL /secure/collaboration_spaces/: CRUD operations for collabora- eventId/{:collaborationSpaceId} tion spaces GET /secure/collaboration_space/: Get a list of collaboration space collaborationSpaceId/votes items with related votes

4.5.2 REST Methods for the Event Application The table below contains information about the REST interface that needs to be implemented for the Event Application.

Method URI Service Description POST /session/login Authenticate a user and create a session GET /session/logout Log out the user and destroy the session GET /secure/events Get a list of events available for the cur- rent session GET /secure/events/:eventId Get the event information with associ- ated surveys, users, and client descrip- tion

44 4. DESIGN

GET /secure/surveys Get a list of surveys available for the cur- rent session GET /secure/surveys/:surveyId Get information about particular survey with related questions and answers POST /secure/surveys/:surveyId Save survey answers GET /secure/stories Get a list of stories (research projects) GET /secure/stories/favorite Get a list of favorite stories for the cur- rent session POST /secure/stories/favorite Add a story to the favorite list DELETE /secure/stories/ Remove story from the favorite list favorite/:storyId GET /secure/stories/rating Get a list of story ratings created by the current user POST /secure/stories/rating Save a story rating GET /secure/stories/notes Get a list of story notes created by the current user POST /secure/stories/notes Save a story note PUT /secure/stories/notes/: Update the story note storyNoteId GET /secure/ibeacons/: Get information about the iBeacon loca- ibeaconUUID/: tion related to the particular iBeacon ibeaconMajor/: ibeaconMinor GET /secure/galaxy/stories Get a list of stories from IBM Galaxy Command API POST /secure/galaxy/stories Launch a story presentation on a big screen through IBM Galaxy Command API GET /secure/user_favorite Get a list of users that the current user follows POST /secure/user_favorite Start following a user DELETE /secure/user_favorite/: Stop following a user userFavoriteId GET /secure/collaboration_ Get a list of collaboration spaces avail- spaces/:eventId able for the current session GET /secure/ Get a list of collaboration space items to- collaboration_space/: gether with votes related to the specified collaborationSpaceId collaboration space POST /secure/ Save a new item to the collaboration collaboration_space/: space collaborationSpaceId

45 4. DESIGN

DELETE /secure/ Delete a particular collaboration space collaboration_space/: item collaborationSpaceId/: collaborationSpaceItemId PUT /secure/ Update a particular collaboration space collaboration_space/: item collaborationSpaceId/:id POST /secure/ Give a vote to the collaboration space collaboration_space/: item collaborationSpaceId/: collaborationSpaceItemId/ vote POST /secure/ Remove a vote from the collaboration collaboration_space/: space item collaborationSpaceId/: collaborationSpaceItemId/ unvote POST /secure/messages/:eventId Create and send a message to another at- tendee GET /secure/notifications/: Get a list of notifications for the current eventId user GET /secure/activity_feed/: Retrieve the activity feed for the event eventId

4.6 WebSocket model

This chapter contains a list of WebSocket events that need to be implemented in the appli- cation. We plan to use two tools for building real-time applications – Pusher and Socket.io. Socket.io19 is an open-source library that enables real-time bi-directional communication be- tween web clients and a server. We plan to use Socket.io for simple real-time communication. Pusher is a commercial end-to-end product that provides many useful built-in functionali- ties. We decided on Pusher because it provides out-of-the-box presence channels that allow subscribers to see who else is subscribed to the same channel. We plan to use this feature for the collaboration spaces. The following table contains information about the events that need to be implemented using WebSockets.

Tool Channel Event Data Description Pusher cs_channel_ voting_open empty Voting in a collabora- {collaboration_ tion space is open space_id}

19. http://socket.io

46 4. DESIGN

Pusher cs_channel_ voting_ empty Voting in a collabora- {collaboration_ closed tion space is closed space_id} Pusher cs_channel_ item_added collaboration New item was added {collaboration_ space item to a collaboration space_id} space Pusher cs_channel_ item_deleted collaboration An item was deleted {collaboration_ space item from a collaboration space_id} space Pusher cs_channel_ item_updated collaboration An item in a collabo- {collaboration_ space item ration space was up- space_id} dated Pusher cs_channel_ votes_ votes Votes in a collabora- {collaboration_ updated tion space were up- space_id} dated Pusher presence-cs_ pusher: user User entered collabo- channel_ member_added ration space page {collaboration_ space_id} Pusher presence-cs_ pusher: user User left collaboration channel_ member_ space page {collaboration_ removed space_id} Socket.io twitter tweet tweet Tweet from Twitter Streaming API was received Socket.io twitter tweet_with_ tweet Tweet with GPS lo- location cation from a Twtiter API was received Socket.io activity_feed_ activity_ activity New item to the activ- {event_id} added ity feed was added Socket.io notifications_ notification_ notification New notification for {event_id} added the event was added Socket.io notifications_ notification_ notification New notification for a {event_id} added_{user_ user was added id}

4.7 Conclusion

This chapter covered many design considerations. In the first part I wrote about different mobile development approaches and decided to pursue the hybrid approach. Then I com- pared single-page and round-trip applications and picked the single-page model for our application. After that I compared several Hybrid WebView frameworks and decided to use

47 4. DESIGN

Apache Cordova. The following section covered the most widely used JavaScript frame- works – jQuery and AngularJS. The latter was chosen due to it being a better fit for our ap- plication. The next couple of sections focused on the user interface, where I made a decision to use Sass as a CSS preprocessor, Compass as a mixin library, and Ionic as a UI framework that is built on top of all the tools we decided on before, such as Apache Cordova, AngularJS, and Sass. The second part of the chapter deals with the technologies and tools used on the server- side. We decided to use IBM Bluemix as a computing platform, Node.js as a runtime envi- ronment, MySQL as a primary relational database, and MongoDB as a NoSQL database for JSON documents. The rest of the chapter introduces the overall system architecture, the entity-relationship model, and the REST API and WebSocket models.

48 5 Implementation

This chapter covers the implementation phase of the application development lifecycle. All technology used during implementation was discussed in the Design chapter. The following subsections demonstrate how the most challenging parts of the application were developed. I would like to point out that even though the application is developed primarily for the Apple iPad Air, some of the screenshots displayed in this chapter were taken from the iPhone 6. This is because it is easier to fit smaller pictures in this printed version of the thesis. Furthermore, one might notice that some parts of the pictures are blurred. This is to protect data confidentiality. Larger application screenshots can be found in accompanied data archive.

5.1 Administration Application

The Administration Application is implemented using the Ionic framework, AngularJS and Node.js server connected to the MySQL database. Node.js is used to implement the REST API interface described in the previous chap- ter. Authentication to the application is implemented using Passport1 and LDAP2 packages available in Node Package Manager. Bookshelf3 is used as an Object-relational Mapper for MySQL database and maps MySQL rows to the following JavaScript objects:

• da_administrator -> Administrator

• da_client -> Client

• da_ibeacon_location -> IbeaconLocation

• da_ibeacon -> Ibeacon

• da_user -> User

• da_event -> Event

• da_user_to_event -> UserEvent

• da_survey -> Survey

• da_survey_question -> SurveyQuestion

• da_agenda_item -> AgendaItem

• da_push_notification -> PushNotification

• da_industry -> Industry

• da_log -> Log

1. https://www.npmjs.com/package/passport 2. https://www.npmjs.com/package/LDAP 3. http://bookshelfjs.org

49 5. IMPLEMENTATION

• da_user_role -> UserRole • da_story -> Story • da_story_favorite -> StoryFavorite • da_story_rating -> StoryRating • da_story_note -> StoryNote • da_collaboration_space -> CollaborationSpace The following is an example of the code that uses User ORM object and implements GET method for the /secure/users REST interface that returns a list of users:

1 app.get('/secure/users', function(req, res){

2 new model.User().fetchAll({withRelated:['user_role']}).then(function(data) {

3 if (data) res.send(data); 4 else res.send(503); 5 }); 6 }); Listing 5.1: GET method that retrieves a list of users from the database And this is the JSON object returned by the service:

1 [{ 2 client_id: 16, 3 user_department:"IT Department",

4 user_email:"[email protected]", 5 user_first_name:"Mat", 6 user_id: 23, 7 user_is_ibmer: 0, 8 user_last_name:"Havlena", 9 user_registered:"2015-03-07T06:00:32.000Z",

10 user_role:{ 11 user_role_id: 5, 12 user_role_name:"Researcher"}, 13 user_role_original: null, 14 user_show_intro: 1 15 }

16 ... 17 ] Listing 5.2: Example of a JSON object returned by the REST service Other REST APIs are implemented in a similar way. For example, the POST method that creates a new user:

1 app.post('/secure/users', function(req, res){ 2 req.body.user_created_by= req.user.administrator_id;

3 new model.User(req.body).save().then(function(data){ 4 if (data) res.send(data); 5 else res.send(503); 6 }); 7 }); Listing 5.3: POST method that creates a new user

50 5. IMPLEMENTATION

5.1.1 User and Event Management Most of the user and event management functionalities are implemented in the Administra- tion Application. The application allows us to manage clients (Figure 5.1), users and roles (Figure 5.2), and events (Figure 5.3). These capabilities are delivered through a set of REST services provided by the Node.js server, as demonstrated at the beginning of this chapter.

Figure 5.1: Client management in the Administration Application

5.1.2 Native Push Notifications Push notifications can be used to send relevant content to the event attendees even when the application is running in the background. The notification can be broadcasted to: [63]

• all registered mobile devices;

• a subset of devices or device platforms;

• specific device user IDs;

• devices that are subscribed to specific tags.

We implement the native push notifications functionality using the Push service that is available on the IBM Bluemix platform. When a user logs in to the application, the device is registered with the service and subscribed to a tag representing the event they are attending. The following code demonstrates how a device subscribes to the Push service.

51 5. IMPLEMENTATION

Figure 5.2: User management in the Administration Application

1 var ibmpush= IBMPush.getService(); 2 var tag="event-"+data.event_id;

3 ibmpush.registerDevice(data.user_email, data.user_id," handlePushNotificationArrival").done(function(response){

4 console.log("Device successfully registered with Push Notifications"); 5 6 ibmpush.subscribeTag(tag).done(function(response){ 7 console.log("Device subscribed toa tag:", tag);

8 }, function(err){ 9 console.log("Device couldn't subscribe toa tag"); 10 }); Listing 5.4: Subscription to native push notifications by tag name If examined thoroughly, one can notice that the push.registerDevice() function con- sumes "handlePushNotificationArrival" string as one of its parameters. This is a name of the callback function that gets fired when the notification is received by the application. The following is an example of code that displays the alert window with the notification message.

1 handlePushNotificationArrival= function(msg){ 2 $ionicPopup.alert({ 3 title:'Notification', 4 template: msg.alert 5 });

6 }; Listing 5.5: Example of a callback function that handles delivered notifications

52 5. IMPLEMENTATION

Figure 5.3: Event management in the Administration Application

We have built more complex callback functions that trigger specific actions associated with different notifications. Also, we use the badge number feature to display the number of notifications that the user has not responded to as part of the application icon. Besides notifications that are sent automatically (for example when a survey is open), the Administration Application also comes with a simple feature that allows administrators to send notifications manually to all users attending a particular event. The following is an example of the code that sends notifications from Node.js server:

1 ibmpush.sendNotificationByTags(message, tags, settings).then(function () { 2 console.log("Notification sent successfully to these tags:", tags); 3 }, function(err){ 4 console.log("Failed to send notification to these tags:", tags); 5 }); Listing 5.6: Example a code that sends push notifications

5.1.3 Data Analytics The data analytics part of the Administration Application provides a set of visualizations that deliver event and user insights (Figure 5.4). The visualizations are created using a D3ResponsiveGraphs4 library I recently created. The library is publicly available on GitHub.

4. https://github.com/matoushavlena/D3ResponsiveGraphs

53 5. IMPLEMENTATION

Figure 5.4: Data analytics in the Administration Application

5.2 Event Application

The Event Application is implemented using Ionic framework, AngularJS, and Node.js server connected to the MySQL database. Node.js is used to implement the REST API interface described in the previous chapter. Authentication to the application is implemented using the Passport5 package available in Node Package Manager. Bookshelf is used as an Object-relational Mapper for the MySQL database and maps MySQL rows to the JavaScript objects in the same way as in the Admin- istration Application.

5.2.1 iBeacon Micro-location iBeacon is an indoor positioning system that uses Bluetooth Low Energy (BLE). BLE benefits from a new protocol that dramatically reduces energy consumption, allowing iBeacons to transmit continuously on a single button cell battery for a few of years (usually 2-3 years). As with the classic Bluetooth, BLE has a range of up to 100 meters. [64] iBeacon is a low-cost, passive device that can notify nearby devices of its presence by

5. https://www.npmjs.com/package/passport

54 5. IMPLEMENTATION transmitting messages over radio frequencies in short time intervals. The distance that the iBeacon covers ranges from centimeters to hundreds of meters (depending on the configu- ration and the environment). Every iBeacon is configured with the following attributes: • UUID – an identifier that distinguishes ones iBeacons from others (we use this to identify all iBeacons used in our labs globally); • major number – is used to group a related set of iBeacons (we use this number to group iBeacons by the lab location); • minor number – is used to identify individual iBeacons. iBeacons only work in an advertising mode, meaning that they can only send data pack- ets and cannot receive any data. The data packets sent by iBeacons can be received by other devices such as smartphones or tables. These data packets can be transmitted in intervals from 20 ms to 10 seconds and the shorter the interval, the more energy the iBeacon con- sumes. The strength of the transmitted signal can be used to determine how far away the receiving device is located from the particular iBeacon.

Figure 5.5: iBeacon micro-location – communication schema

For our project, we used iBeacons from Kontakt.io6 and a cordova plugin created by Peter Metz7. The following is a snippet of the JavaScript code used to receive information about nearby iBeacons:

1 var delegate= new cordova.plugins.locationManager.Delegate();

2 3 delegate.didRangeBeaconsInRegion= function (data){ 4 data.beacons.forEach(function(beacon){ 5 console.log("Minor:"+beacon.minor+", Proximity:"+beacon.proximity); 6 };

7 }; 8 9 var uuid='XXXXXXXX-YYYY-XXXX-YYYY-XXXXXXXXXXXX'; 10 var identifier='com.ibm.research';

6. http://kontakt.io/ 7. https://github.com/petermetz/cordova-plugin-ibeacon

55 5. IMPLEMENTATION

11 var major = 1; 12 var beaconRegion= new cordova.plugins.locationManager.BeaconRegion( identifier, uuid, major);

13 14 cordova.plugins.locationManager.setDelegate(delegate);

15 cordova.plugins.locationManager.requestWhenInUseAuthorization(); 16 cordova.plugins.locationManager.startRangingBeaconsInRegion(beaconRegion). fail(console.error).done(); Listing 5.7: Example of a code that implements iBeacon ranging

iBeacons are used to locate users inside the lab and allow them to control systems in their close proximity. For example, when they are standing in front of a screen, they can launch a research project presentation on the screen from the application.

5.2.2 Real-time Multi-user Collaboration Real-time multi-user collaboration is implemented as a page where people can post sticky notes in real-time and vote on them. The real-time functionality is implemented using Pusher. The WebSocket events emitted by Pusher are described in the Design chapter. Figure 5.6 shows the application in the stage, when users can add and edit sticky notes. The top bar shows a list of collaboration spaces. The bottom bar shows users currently collaborating in the active collaboration space.

Figure 5.6: Real-time multi-user collaboration in the Event Application

Figure 5.7 displays the application during voting stage, when every user has 3 votes that can be split among the sticky notes. The voting results are then displayed in real-time in the Administration Application (the bottom part of the picture).

56 5. IMPLEMENTATION

Figure 5.7: Voting in the collaboration space

5.3 SocialWall Application

The SocialWall Application is implemented using AngularJS, Socket.io, and the Node.js server connected to the MongoDB database. Integration with Twitter Streaming API is im- plemented using the Twit8 package available in Node Package Manager. The following is the code that tracks tweets with ibmresearch hashtag and emits two WebSocket events.

8. https://www.npmjs.com/package/twit

57 5. IMPLEMENTATION

1 var stream= Twit.stream('statuses/filter',{'track':['#ibmresearch']}); 2 3 stream.on('tweet', function(tweet){ 4 if (tweet.language=='en') io.emit('tweet', tweet); 5 if (tweet.coordinates) io.emit('tweet_with_location', tweet);

6 }); Listing 5.8: Code snippet that tracks tweets and fires WebSocket events in real-time

Figure 5.8 shows two screenshots of the SocialWall Application that receives and displays tweets in real-time.

Figure 5.8: SocialWall Application

58 6 Conclusion

The goal of this thesis was to implement a cross-platform mobile event application that would enhance client workshops in IBM Research. The thesis was divided into four chapters that match the phases of the software development lifecycle – project initiation, analysis, design, and implementation. Throughout the chapters, I managed to identify and capture the application require- ments, discuss the technologies and tools used during development, design the application architecture and data model, and implement the final solution. The final outcome of this thesis is a set of three fully working applications – the Event Application used by event attendees during workshops, the Administration Application used by IBM employees to manage the events, and the SocialWall application that displays social insights on a wall screen system. At the time of finishing this thesis, I successfully managed to implement most of the re- quirements. The application has become an essential part of client workshops, helping us to improve the process of collaboration and ideation and providing attendees with informa- tion related to the event. Besides this, it also allows us to gain a deeper understanding of our clients by analyzing their interactions and other related data.

6.0.1 Future Directions The development of the application continues with the intention to deploy the application to a broader set of global locations. The team of developers has recently grown as we are plan- ning to incorporate more features such as personal recommendation system, event gamifica- tion, LinkedIn integration, whiteboard collaboration, or integration with cognitive systems available on IBM Watson Developer Cloud1. Personal recommendation system would recommend research projects to attendees based on their personal profile. It would take into account industry, job role, and other relevant data. For example a CEO of a company from banking industry would be provided with different recommendations when compared to an IT Architect from agriculture industry. In terms of event gamification, we would like to focus on the scavenger hunt type of a game, when attendees would be provided with a list of specific actions, that when accom- plished, would transform into points and unlocked badges. Actions could be social activities such as taking a picture with a colleague, connecting with other people, answering questions raised by other attendees, or making geolocation check-ins at particular places in the lab. This would deliver an unique event experience and motivate attendees to work together. LinkedIn integration would help us to ease the process of registration as well as network- ing, as attendees wouldn’t have to exchange business cards nor e-mail addresses since the application would allow them to connect directly through their LinkedIn accounts. When the event is finished, they would also be provided with a list of people they met, so they could easily follow-up on their discussions. We are also planning to enrich the application with some of the research capabilities pro- vided through IBM Watson Developer Cloud. For example, the Personality Insights project would allow us to discover attendees’ cognitive and social characteristics based on their lin-

1. http://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud

59 6. CONCLUSION guistic analysis. That would help us to enhance the recommendation system and understand what projects are favorited by people with certain characteristics. Another project, Concept Insights, could help to reveal underlying concepts of user-input words. This would allow us to enrich the way how the searching in research projects works. For example, when an attendee searches for the keyword "Scrum", the search results would also include projects associated with the keyword "Agile Development".

60 Bibliography

[1] IBM. IBM Research. URL: http : / / www . research . ibm . com / labs / watson/ (visited on 03/30/2015). [2] IBM. IBM Research : History of Progress. URL: http://www.research.ibm.com/ featured/history/ (visited on 03/30/2015). [3] T. Danova. The Future Of Mobile. URL: http://www.businessinsider.com/ the-future-of-the-mobile-industry-2014-11#-1 (visited on 03/30/2015). [4] Crowd Compass. Feeling is believing: The 5 emotions of successful event apps. URL: http : / / www . crowdcompass . com / pdf / feeling - is - believing - five - emotions-of-successful-event-apps.pdf (visited on 03/30/2015). [5] Guidebook. Mobile Conference & Event Apps. URL: https://guidebook.com/ event-apps/ (visited on 03/30/2015). [6] Doubledutch. Mobile Event App, Plus Powerful Analytics. URL: http : / / doubledutch.me/event-app.html (visited on 03/30/2015). [7] CrowdCompass. Mobile Apps for Events. URL: http://www.crowdcompass.com/ app-features/ (visited on 03/30/2015). [8] Bizzabo. Event App & Networking Platform for Events. URL: https : / / www . bizzabo.com/event-experience (visited on 03/30/2015). [9] H. Phan. Full-stack Mobile App With Ionic Framework. Hoc Phan, 2014. [10] S. Truman. App Development: Learn Androids & iPhone App Development FAST! Az Elite Publishing Inc., 2014. ISBN: 973-332-00389-3. [11] A. Charland and B. LeRoux. “Mobile Application Development: Web vs. Native”. In: Data 9.4 (2011). URL: https://queue.acm.org/detail.cfm?id=1968203. [12] B. Lawson. HTML5: The Facts And The Myths. 2010. URL: http : / / www . smashingmagazine.com/2010/09/23/html5-the-facts-and-the-myths/ (visited on 03/30/2015). [13] E. Bidelman. Capturing Audio & Video in HTML5. 2013. URL: http : / / www . html5rocks . com / en / tutorials / getusermedia / intro/ (visited on 03/30/2015). [14] W3C. Device APIs Working Group. 2015. URL: http://www.w3.org/2009/dap/ (visited on 03/30/2015). [15] M. Mahemoff. HTML5 vs Native: The Mobile App Debate. 2011. URL: http://www. html5rocks.com/en/mobile/nativedebate/ (visited on 03/30/2015). [16] K. Millikin and F. Schneider. A New Crankshaft for V8. 2010. URL: http://blog. chromium . org / 2010 / 12 / new - crankshaft - for - v8 . html (visited on 03/30/2015). [17] P. Chandna. Hardware-Accelerated Chrome 7 60x Faster than Previous Versions. 2010. URL: http : / / www . maximumpc . com / article / news / hardware - accelerated _ chrome _ 7 _ 60x _ faster _ previous _ versions (visited on 03/30/2015).

61 BIBLIOGRAPHY

[18] Primate Labs. iPhone, iPad, and iPod Benchmarks. 2014. URL: http://browser. primatelabs.com/ios-benchmarks (visited on 03/30/2015). [19] AreWeFastYet: tracking performance of popular JavaScript engines. URL: http:// arewefastyet.com/#machine=11 (visited on 03/30/2015). [20] TJ VanToll. Why iOS 8’s WKWebView is a Big Deal for Hybrid Development. 2014. URL: http : / / developer . telerik . com / featured / why - ios - 8s - wkwebview - is - a - big - deal - for - hybrid - development/ (visited on 03/30/2015). [21] M. Firtman. Android 4.4 KitKat, the browser and the Chrome WebView. 2013. URL: http://www.mobilexweb.com/blog/android- 4- 4- kitkat- browser- chrome-webview (visited on 03/30/2015). [22] R. Coles. Beta Channel for the Android WebView. 2015. URL: http : / / blog . chromium . org / 2015 / 02 / beta - channel - for - android - webview . html (visited on 03/30/2015). [23] Xamarin. Introduction to Mobile Development. URL: http : / / developer . xamarin . com / guides / cross - platform / getting _ started / introduction_to_mobile_development/ (visited on 03/30/2015). [24] A. Dallera. Why you should stay away from Appcelerator’s Titanium. 2011. URL: https: // usingimho.wordpress .com/ 2011/ 06/14 /why - you- should- stay-away-from-appcelerators-titanium/ (visited on 03/30/2015). [25] K. Whinnery. Comparing Titanium and PhoneGap. 2012. URL: http : / / www . appcelerator.com/blog/2012/05/comparing-titanium-and-phonegap/ (visited on 03/30/2015). [26] M. Pronschinske. The State of Native vs. Web vs. Hybrid. 2014. URL: http://java. dzone . com / articles / state - native - vs - web - vs - hybrid (visited on 03/30/2015). [27] A. Freeman. Pro AngularJS. 1st ed. Expert’s Voice in Web Development. Apress, 2014. ISBN: 1430264489. [28] Apache Cordova. URL: https://cordova.apache.org/ (visited on 03/30/2015). [29] Plugin APIs. URL: http://cordova.apache.org/docs/en/4.0.0/cordova_ plugins_pluginapis.md.html#Plugin%20APIs (visited on 03/30/2015). [30] M. Lynch. The Last Word on Cordova and PhoneGap. 2014. URL: http://blog. ionic.io/what-is-cordova-phonegap/ (visited on 03/30/2015). [31] Comparing Titanium and PhoneGap. 2012. URL: http://phonegap.com/2012/ 03/19/phonegap-cordova-and-what%E2%80%99s-in-a-name/ (visited on 03/30/2015). [32] C. Dunn. Why Trigger.io doesn’t use PhoneGap – 5x faster native bridge. 2012. URL: http://trigger.io/cross-platform-application-development-blog/ 2012 / 02 / 24 / why - trigger - io - doesnt - use - phonegap - 5x - faster - native-bridge/ (visited on 03/30/2015). [33] Trigger.io Modules. URL: https://trigger.io/modules/_/featured/ (visited on 03/30/2015).

62 BIBLIOGRAPHY

[34] P. Rudolph. Hybrid Mobile Apps: Providing A Native Experience With Web Tech- nologies. 2014. URL: http : / / www . smashingmagazine . com / 2014 / 10 / 21 / providing- a- native- experience- with- web- technologies/ (visited on 03/30/2015). [35] jQuery. URL: https://jquery.com/ (visited on 03/30/2015). [36] jQuery Introduction. URL: http : / / www . w3schools . com / JQuery / jquery _ intro.asp (visited on 03/30/2015). [37] jQuery Mobile. URL: https://jquerymobile.com/ (visited on 03/30/2015). [38] jQuery UI. URL: https://jqueryui.com/ (visited on 03/30/2015). [39] AngularJS - Superherois JavaScript MVW Framework. URL: https://angularjs. org/ (visited on 03/30/2015). [40] D. Lamb. jQuery vs. AngularJS: A Comparison and Migration Walkthrough. 2014. URL: https://www.airpair.com/angularjs/posts/jquery-angularjs- comparison-migration-walkthrough (visited on 03/30/2015). [41] E. Marcotte. Responsive Web Design. A Book Apart, 2011. ISBN: 978-0-9844425-8-4. [42] D. Cederholm. Sass for Web Designers. A Book Apart, 2013. ISBN: 978-1-937557-13-3. [43] Sass Basics. URL: http://sass-lang.com/guide (visited on 03/30/2015). [44] H. Giraudel. Sass Frameworks: Compass or Bourbon? 2014. URL: http : / / www . sitepoint . com / compass - or - bourbon - sass - frameworks/ (visited on 03/30/2015). [45] J. Hixon. An Introduction To LESS, And Comparison To Sass. 2011. URL: http:// www.smashingmagazine.com/2011/09/09/an-introduction-to-less- and-comparison-to-sass/ (visited on 03/30/2015). [46] G. Grisogono. 5 Best Mobile Web App Frameworks: Ionic (AngularJS). 2014. URL: http://moduscreate.com/5-best-mobile-web-app-frameworks-ionic- angulalrjs/ (visited on 03/30/2015). [47] All About Ionic. URL: http://ionicframework.com/docs/guide/preface. html (visited on 03/30/2015). [48] A. Bradley. Ionic + AngularJS: Superpowers for Mobile App Development. 2015. URL: http://adamdbradley.github.io/ionic-present/ (visited on 03/30/2015). [49] A. Bradley. Where does the Ionic Framework fit in? 2013. URL: http : / / blog . ionic . io / where - does - the - ionic - framework - fit - in/ (visited on 03/30/2015). [50] Ionic: Advanced HTML5 Hybrid Mobile App Framework. URL: http : / / ionicframework.com/ (visited on 03/30/2015). [51] A. Bradley. Ionic and Angular Superpowers for Mobile App Development - Adam Bradley. 2015. URL: https://www.youtube.com/watch?v=wvr11fvCeu4 (vis- ited on 03/30/2015).

63 BIBLIOGRAPHY

[52] S. Perez. Drifty Grabs $2.6 Million To Turn Web Developers Into Mobile App Makers. 2015. URL: http://techcrunch.com/2015/03/30/drifty- grabs- 2- 6- million-to-turn-web-developers-into-mobile-app-makers/ (visited on 03/30/2015). [53] damo.us. URL: http://famo.us/ (visited on 03/30/2015). [54] T. Gleichger. Hybrid UI framework shootout: Ionic vs. Famo.us vs. F7 vs. OnsenUI. URL: https://www.airpair.com/ionic-framework/posts/hybrid-apps- ionic-famous-f7-onsen (visited on 03/30/2015). [55] Onsen UI - A Custom Elements-Based HTML5 UI Framework. URL: http://onsen. io/ (visited on 03/30/2015). [56] IBM Bluemix - Next-generation Cloud App Development Platform. URL: https:// console.ng.bluemix.net/ (visited on 03/30/2015). [57] What is non-blocking or asynchronous I/O in Node.js? URL: http : / / stackoverflow.com/questions/10570246/what-is-non-blocking-or- asynchronous-i-o-in-node-js (visited on 03/30/2015). [58] A. Mardan. Practical Node.js: Building Real-World Scalable Web Apps. Apress, 2014. ISBN: 1430265957. [59] About Node.js. URL: https://nodejs.org/about/ (visited on 03/30/2015). [60] T. Capan. Why The Hell Would I Use Node.js? A Case-by-Case Tutorial. URL: http: //www.toptal.com/nodejs/why-the-hell-would-i-use-node-js (visited on 03/30/2015). [61] Why MySQL? URL: https : / / www . mysql . com / why - mysql/ (visited on 03/30/2015). [62] Introduction to MongoDB. URL: http : / / www . mongodb . org / about / introduction/ (visited on 03/30/2015). [63] IBM Bluemix. Getting started with Push. 2015. URL: https://www.stage1.ng. bluemix.net/docs/#services/push/index.html#gettingstarted (vis- ited on 03/30/2015). [64] M. Havlena. iBeacons – How do they (technically) work? 2014. URL: http://www. havlena . net / en / location - technologies / ibeacons - how - do - they - technically-work/ (visited on 03/30/2015).

64 List of Figures

2.1 Business Insider: The Future Of Mobile [3] 3 3.1 Use Case Diagram 10 3.2 Guidebook Configurator [5] 11 3.3 Doubledutch Configurator [6] 12 3.4 Bizzabo Management System [8] 13 4.1 Benchmark of mobile devices – scores are calibrated against a baseline score of 2500, which is the score of an Intel Core i5-2520M @ 2.50 GHz (higher scores are better) [18] 16 4.2 Performance of popular JavaScript engines based on Octane benchmark (lower scores are better) [19] 17 4.3 Architecture of a hybrid application 18 4.4 AngularJS is well-suited to single-page and complex web applications [27] 24 4.5 Compilation of styles from preprocessor syntax to plain CSS 26 4.6 Example of Sass partials 27 4.7 Ionic’s goal is to deliver the missing web SDK [48] 30 4.8 Multilayer architecture of Ionic applications 30 4.9 Frontend architecture 32 4.10 Design mockup of the Your Feed page 34 4.11 Comparison between request handling in Node.js and a traditional server [60] 37 4.12 Backend architecture built on top of the IBM Bluemix cloud platform 39 4.13 Overall system architecture 40 4.14 Entity-relationship model 41 5.1 Client management in the Administration Application 51 5.2 User management in the Administration Application 52 5.3 Event management in the Administration Application 53 5.4 Data analytics in the Administration Application 54 5.5 iBeacon micro-location – communication schema 55 5.6 Real-time multi-user collaboration in the Event Application 56 5.7 Voting in the collaboration space 57 5.8 SocialWall Application 58 A.1 Oblong Mezzanine, Source: oblong.com 69 A.2 Galaxy Application, Source: Twitter 69 B.1 Design mockup of the Agenda page 70 B.2 Design mockup of the Projects page 71 B.3 Design mockup of a particular project 72 B.4 Design mockup of the People page 73 B.5 Design mockup of the Messages page 74 B.6 Design mockup of the Collaboration page 75 B.7 Design mockup of the About Us page 76 B.8 Design mockup of the Survey page 77

65 LISTOFFIGURES

B.9 Design mockup of the SocialWall application 78

66 List of Tables

2.1 Project risks 5 2.2 Probability levels 5 4.1 Native vs. Web vs. Hybrid: 7 factors of comparison [26] 19 4.2 Comparison of jQuery and AngularJS capabilities [40] 24

67 Listings

5.1 GET method that retrieves a list of users from the database ...... 50 5.2 Example of a JSON object returned by the REST service ...... 50 5.3 POST method that creates a new user ...... 50 5.4 Subscription to native push notifications by tag name ...... 52 5.5 Example of a callback function that handles delivered notifications ...... 52 5.6 Example a code that sends push notifications ...... 53 5.7 Example of a code that implements iBeacon ranging ...... 55 5.8 Code snippet that tracks tweets and fires WebSocket events in real-time . . . 57

68 A Lab Equipment

Figure A.1: Oblong Mezzanine, Source: oblong.com

Figure A.2: Galaxy Application, Source: Twitter

69 B Design Mockups

Figure B.1: Design mockup of the Agenda page

70 B.DESIGN MOCKUPS

Figure B.2: Design mockup of the Projects page

71 B.DESIGN MOCKUPS

Figure B.3: Design mockup of a particular project

72 B.DESIGN MOCKUPS

Figure B.4: Design mockup of the People page

73 B.DESIGN MOCKUPS

Figure B.5: Design mockup of the Messages page

74 B.DESIGN MOCKUPS

Figure B.6: Design mockup of the Collaboration page

75 B.DESIGN MOCKUPS

Figure B.7: Design mockup of the About Us page

76 B.DESIGN MOCKUPS

Figure B.8: Design mockup of the Survey page

77 B.DESIGN MOCKUPS

Figure B.9: Design mockup of the SocialWall application 78 C Accompanied Data

The following data is attached to the thesis:

• text of the thesis in LATEX and PDF format; • images and diagrams used in the text.

79