Masaryk University Faculty of Informatics

Developing a mobile application using multiplatform frameworks with a native output

Bachelor’s Thesis

Filip Drgoň

Brno, Fall 2017

Masaryk University Faculty of Informatics

Developing a mobile application using multiplatform frameworks with a native output

Bachelor’s Thesis

Filip Drgoň

Brno, Fall 2017

This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document.

Declaration

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

Filip Drgoň

Advisor: RNDr. Jaroslav Škrabálek

i

Acknowledgement

I would like to thank the supervisor of my bachelor’s thesis, RNDr. Jaroslav Škrabálek, for his helpful attitude, valuable insights, and his contribution to my thesis.

iii Abstract

The objective of this bachelor’s thesis is to research current available options in multiplatform application development, evaluate their qual- ities and shortcomings and present React Native as the currently best available solution.

iv Keywords

Multiplatform application, React Native, Android, iOS, Javascript, Xamarin, NativeScript, Native application, ...

v

Contents

1 Introduction 1 1.1 Thesis structure ...... 2

2 A mobile application 3 2.1 Defining a mobile application ...... 3 2.2 Basic requirements of a mobile application ...... 3 2.2.1 User interface requirements ...... 3 2.2.2 Cost-related requirements ...... 4 2.2.3 Further requirements ...... 6 2.3 Mobile application development types ...... 7 2.3.1 Native development ...... 8 2.3.2 Web development ...... 9 2.3.3 Hybrid development ...... 10 2.3.4 Comparison of different methods ...... 11

3 A multiplatform approach 13 3.1 Multiplatform development types ...... 13 3.2 A native multiplatform application ...... 14 3.2.1 Justifying the native multiplatform approach . . 14 3.3 Most notable multiplatform frameworks ...... 14 3.3.1 Xamarin ...... 14 3.3.2 Ionic 2 ...... 16 3.3.3 NativeScript ...... 17 3.3.4 React Native ...... 18 3.4 A comparison ...... 20 3.4.1 Developer’s perspective ...... 20 3.4.2 Pricing perspective ...... 22 3.4.3 User’s perspective ...... 23 3.4.4 Conclusion ...... 24

4 React Native – an in-depth look 25 4.1 JavaScript ...... 25 4.1.1 About JavaScript ...... 25 4.1.2 A short look on history ...... 26 4.1.3 Advantages & shortcomings of JavaScript .... 28 4.1.4 Transpilers ...... 30

vii 4.2 React ...... 30 4.2.1 JSX ...... 32 4.3 Under React Native’s hood ...... 34

5 A demonstrative application 37 5.1 Motivation & problem definition ...... 37 5.2 Analysis & structure design ...... 38 5.3 Implementation ...... 41 5.3.1 Implementation structure ...... 43 5.3.2 User scenarios ...... 45 5.4 Results & What’s next ...... 47

6 Conclusion 49

Bibliography 51

viii List of Tables

2.1 Comparison of the application development methods 12 3.1 Comparing the frameworks from a developer’s perspective 21 3.2 Comparing the frameworks from a pricing perspective 22 3.3 Comparing the frameworks from a user’s perspective 23

ix

List of Figures

2.1 Average application price on iOS store, June 2017[3] 5 2.2 Free and paid application distribution on iOS and Android, January 2017[4]. 6 2.3 Architectures of native, hybrid and web applications[5]. 8 3.1 Comparing traditional Xamarin and Xamarin.forms [9] 15 3.2 An example of TypeScript’s strong type enforcing 18 3.3 A schema of Hot Module Reloading in React Native 19 4.1 Netscape’s advocacy on JavaScript’s genesis[26]. 27 4.2 A schema depicting the sources behind JavaScript’s features[28]. 27 4.3 A simplified schema of React’s DOM Reconciliation[33] 31 4.4 A schema of the threading system React Native implements. 34 5.1 A schema of the proposed pricing regions for visitor parking in Brno[36]. 38 5.2 A proposed use case diagram of the resulting application. 39 5.3 A proposed deployment diagram of the resulting application. 40 5.4 A schema of the navigation structure in the resulting application 41 5.5 A screenshot depicting the project structure of the application. 44 5.6 Photographs of the sign in and sign up screens. 45 5.7 Photographs of the map screen and the modal for ticket purchase confirmation. 46 5.8 Screenshots of the settings screen, and the billing screen. 47

xi

1 Introduction

Nowadays, smart devices are seeing a steady increase in market share worldwide, having surpassed desktop share only recently (in mid- October 2016) [1]. With this in mind, it is crucial to optimize services heavily both for desktop and smart device usage, as not doing so results in heavy repercussions [2]. While developing an application aimed at the public, it is important to consider developing multiple access points for the application, such as a web interface and native applications specifically for the most popular mobile platforms (namely Google Android and Apple iOS). Focusing on services targeted at mobile devices, these are mainly distributed utilizing either responsive web applications, or native mobile applications. To minimize the expenses and effort required for developing a native application, utilizing multiplatform development comes into play as a valid choice. The goal of this thesis is to present the current options in develop- ing an application utilizing multiplatform development, specifically focusing on tools for developing native applications, for both major platforms, seamlessly and concurrently. The thesis takes into evalu- ation the reusability of code blocks and components for ease-of-use and comfortable development process, resulting in faster, cheaper and easier development process.

1 1. Introduction 1.1 Thesis structure

In its first part, the thesis focuses on defining a mobile application & its basic requirements, and comparing different approaches to mobile application development, including their advantages and detrimental effects. In the second part, the thesis aims at establishing a definition of multiplatform mobile application development. Furthermore, the the- sis discusses the multiplatform development types & multiplatform framework types. In the end, a profound comparison of several multi- platform frameworks is made, concluding which one would be best suited for modern multiplatform development. In the next part, the focus of the thesis is to provide an in-depth look on React Native and the technologies utilized with React Native. The thesis further discusses in detail their functionality, advantages, shortcomings and the reasoning behind choosing the technologies for the practical application. Finally, the thesis presents a demonstrative application written in React Native, with the motivation & problem definition, an analy- sis with a structure design, and an implementation showcase with photographs and use cases of the application. An evaluation of the development process is made, with a discussion on possible directions the resulting application could evolve into.

2 2 A mobile application

This chapter is focused on defining the term mobile application and discussing the basic needs for developing a mobile application. It will also introduce the different approaches in mobile application develop- ment, and the conveniences and imperfections of each development approach.

2.1 Defining a mobile application

The term mobile application is understood to be a type of executable software designed to run on a mobile device, e.g. a smartphone, or a tablet. Mobile applications were generally considered to be small, in- dividual software units with limited functionality. Nowadays, mobile applications are functionally-wise comparative to applications for per- sonal computers. Unlike applications for personal computers, mobile applications are typically obtained from a corresponding application store.

2.2 Basic requirements of a mobile application

Depending on the use case, an application’s requirements may dif- fer heavily, with the difference mainly being the required system re- sources & the device’s special functions.

2.2.1 User interface requirements A basic requirement for a mobile application is to be easily usable. An average PC is usually controlled using a keyboard and a mouse, in comparison to an average smart device, which is typically controlled using solely a touch screen spanning only several inches. An over- whelming majority of these devices is controlled using a finger, with the – formerly popular – stylus now being a disfavoured option. The limited screen size of a smart device is the main reason behind the user interface requirements – the control elements need to be suf- ficiently sized, allow for easy usage on a small-diameter device, and be reasonably placed. This would mean that the application’s user

3 2. A mobile application interface needs to conform to the platform specific Human Interface Guidelines1, using native components wherever possible – for exam- ple, a native touch keyboard, native icon set or a native menu. The reasoning behind this requirement is that users are generally already used to using these components, so if they are identical across several applications, the usage of the application feels less confusing.

2.2.2 Cost-related requirements A mobile application developer also has to consider the economic side of developing a mobile application. Financially-wise, mobile appli- cation development has a few characteristics divergent from web or personal computer development. Beneficial to the developer, several platforms limit the ways an application can be distributed – iOS or Windows Phone commonly allow installing an application only through the official store of the platform’s manufacturer2. In effect, it is much harder to obtain an illegal copy of an application as compared to a personal computer. On the other hand, it is typical to pay considerably more for a personal computer application than for a mobile application. This requires the developer to either be capable of selling a great amount of copies3, or use a different monetization method.. The figure 2.1 shows the average prices of an application inthe Apple App Store on June 2017. The source[3] mentions the average price to be approximately $1.02.

1. Called User Interface Guidelines on Android 2. There are ways to surpass these limitations, although rarely used by an average user. 3. To be able to pay for the application development and upkeep costs.

4 2. A mobile application

Figure 2.1: Average application price on iOS store, June 2017[3] .

Mobile applications also affect the user’s view on software financ- ing. While the model of a one-time purchase of an application is still prevailing on personal computers, mobile applications tend to be ei- ther very cheap, or free, with financing being solved typically bya freemium model. This includes in-app purchases, or a subscription model. This trend is shown in both figure 2.1 and figure 2.2. The for- mer shows the cheap average pricing of mobile applications, while the latter displays the trend of developers releasing either free or very cheap applications.

5 2. A mobile application

Figure 2.2: Free and paid application distribution on iOS and Android, January 2017[4].

2.2.3 Further requirements

It is important for the mobile application to be fluid and smooth, so the user experience is comfortable. On personal computers, the users tend to be used to the response times of the applications, whereas on mobile devices, most users expect a fluid, quick and stable experience. Hence a mobile application has to react without delay to the user’s input, and cannot, in any way, affect other functions of the devicee.g. ( an application blocks the user from accepting a phone call). A mobile device is typically powered by a battery with a limited capacity. Therefore an application running on the device should aim to use the least amount of battery possible – for example by using system resources only when absolutely necessary, avoiding unneces-

6 2. A mobile application

sary operations and calculations, or keeping a network connection for longer than necessary. An application has to be able to respond intelligently to a myriad of outside effects, like a battery discharge, a device turn-off, a force-quit, unstable data connection or inaccurate data from a GPS sensor. This would mean – in the case of the first three mentioned – that the user does not lose any data, or is not denied entry after a later re-launch of the application.

2.3 Mobile application development types

While developing a mobile application, it is good practice to split the resulting application into smaller partitions. Initially, the main two partitions are:

» Back-End (server part) – typically implements an API (Appli- cation Programming Interface) for easier access towards server services, e.g. editing and accessing data, authentication, or com- plex operations unfit to be performed on the client’s device.

» Front-End (client part) – typically presents a set of User Inter- faces, which implement the services provided by the server, through its API. This part is usually specific to each particular client device type, as opposed to the server part.

It is important to mention that a mobile application does not neces- sarily have to have a back-end service, e.g. a simple game application would have no use of a server. The main focus of this thesis is on the Front-End part of the ap- plication, particularly on how to develop one using multiplatform development. The Front-End segment is considered as either a web interface, or a mobile application for Android & iOS, while the Back- End segment is perceived as an already finished product, providing an API for the Front-End segment to utilize. While developing the web interface, it is good practice to choose a development method to follow prior to starting the mobile application development. Currently, there are three different approaches in mobile application development - web, native, and hybrid development.

7 2. A mobile application

Figure 2.3: Architectures of native, hybrid and web applications[5].

2.3.1 Native development Developing an application natively is recognized as developing a separate application for each platform independently. While natively developing an application, a developer is forced to use the tools re- quired for the specific platform, e.g. a specific programming language (Java, Kotlin, Swift, ...), or a specific development environment (like Xcode).

Advantages

» Optimized User Interface – The User Interface is optimized for each platform, according to its specific design guidelines.

» High fluidity and responsiveness – The application is substan- tially more fluid and responsive than a web application, which contributes positively towards user experience.

» No Internet connection required – While only applying to some applications, native applications by default do not en- force a necessary access to the Internet while in use.

8 2. A mobile application

Drawbacks » Separate development – Native applications require separate development for each platform. » Costly development – By having to maintain several imple- mentations across all supported platforms, the development and maintenance costs suffer. » Complicated maintaining – Being typically deployed on an application store, the developer cannot confide in the user up- dating after every update, which makes maintaining older ver- sions a necessity. Although the developer could force the user to update by denying access to the application until the update is finished, this forced approach is not very liked among users.

2.3.2 Web development The mobile application is constituted of a web page, optimized for being used both on touch-enabled mobile devices and desktop com- puters. The application adapts according to the device it is accessed by, and it is accessed solely by the web browser of the device. This de- velopment approach usually utilizes HTML, CSS and JavaScript, and is also labeled as responsive web design. Advantages » Single application for all platforms – Developing a single web application to meet all the required conditions, instead of sev- eral, similar, versions across all platforms. » Lower development costs – Since there is no need to develop a specific application for each platform, the development cost is lowered significantly. » Simple deployment and maintaining – It is necessary to main- tain only one source code. Updating the application is per- formed by deploying the new application on the server, which is arguably much simpler, and economical, than having to dis- tribute the application on several platforms. The update is in- stantaneous and without user interaction.

9 2. A mobile application

Drawbacks

» User Interface is unoptimized – The user interface differs con- siderably on iOS and on Android, which is usually unaccounted for in web applications.

» Lower fluidity and speed – A web application cannot utilize the full potential of the device, possibly resulting in a mediocre user experience, with fluidity and performance issues.

» Required Internet connection – To connect to a web applica- tion, an Internet connection is required.

2.3.3 Hybrid development Hybrid applications are considered as a meeting point between native and web development approaches. They are a combination of these two methods, focused on solving the shortcomings presented by both aforementioned techniques. From the end user’s point of view, the application acts identically to a native application, meaning that it is available on an application store, installs itself in the device and updates through the application store. Looking at the application from the developer’s point of view, the application is developed using web technologies – HTML, CSS and JavaScript, while being contained in a native wrapper. On application start-up, the wrapper creates a WebView – a full-screen minimal web browser, and loads the web application inside the browser. This ap- proach allows re-use of source code across different applications and platforms, reducing development costs. While developing hybridly, it is still necessary to develop an ap- plication separately for each targeted platform. Facilitated by reusing the majority of code base across all platforms, the application still requires to be maintained on several platforms at once. To help with simultaneous development on multiple platforms at once, several tools, such as Marmalade or Phonegap, provide help with developing and distributing the resulting application.

10 2. A mobile application

Advantages

» Platform-specific UI – A simple UI is adaptable depending on the platform the application is deployed on (through the native wrapper)

» Code reuse – Code reuse helps with smoother and faster de- velopment process

» Lower development costs – By reusing a majority of the code base, the development costs are smaller in comparison to native development.

Drawbacks

» Lower fluidity and speed – A hybrid application cannot utilize the full potential of the device, typically resulting in a deterio- rated user experience, with fluidity and performance issues.

» Complicated maintaining and deployment – The application needs to be deployed on platform-specific application stores, which complicates the updating and deploying processes.

» Complicated debugging – By having to use varying WebViews for each platform, debugging the application might prove prob- lematic. Their implementations differ heavily platform-to-platform, and version-to-version4.

» Potentially higher energy consumption – Not being able to micro-optimize the application on low level could potentially lead to unwanted battery drainage.

2.3.4 Comparison of different methods There are several main traits shared by all methods of application development. The table 2.1 provides a concise comparison of how well the methods succeeded at each specific point.

4. A possible workaround is using Cordova Crosswalk, which implements an identi- cal WebView on every platform, but increases the application size by approximately 50MB.

11 2. A mobile application

Features Native Web Hybrid User Interface Great Average Good User Experience Great Average Average Development Time High Low Average Costs High Low Average Deployment Complicated Simple Complicated Maintaining Varies Varies Varies Off-line Mode Yes No Yes* * Off-line mode support varies framework-to-framework

Table 2.1: Comparison of the application development methods

Before summarizing the table’s results, it is necessary to reason why maintaining is said to vary on each singular platform. It is very difficult to specify the complexity of application maintaining based singularly on the development approach; a well-designed native ap- plication could be considerably easier to maintain than a web or a hybrid application. On the other hand, a poorly thought-out native application would suffer from complicated maintaining procedure in comparison to a hybrid or a web application. To summarize the table, it is evident that native approach’s main strength comes from a great user interface and user experience, at the cost of higher development costs. Each development approach serves a different purpose, and outshines the others in specific situations.

12 3 A multiplatform approach

This chapter focuses on justifying a multiplatform approach to mobile application development. First, a distinction between similar multi- platform approaches is made. Following, the chapter suggests several popular frameworks for this type of mobile application development. Finally, a profound comparison is made, concluded with deciding which framework will be used for the practical section of the thesis. The term multiplatform application is understood as an application containing multiple entry points across different platforms. A platform could be, for example, a specific operating system of a mobile or desktop device, or a web interface. In other words, a multiplatform application is an application available from all the targeted platforms with only minor modifications[6].

3.1 Multiplatform development types

We essentially distinguish two multiplatform development approaches; one being a hybrid multiplatform approach, while the other is a native multiplatform approach. A hybrid multiplatform approach is basically the hybrid approach mentioned in the previous chapter. This approach is utilized, for ex- ample, by Apache Cordova/Phonegap. On the other hand, a native multiplatform approach differs from the hybrid in that the resulting application is a fully native application, utilizing both native API calls to the device’s functionalities and native components. It is important to mention that results of various native multiplatform frameworks diverge heavily in their "nativity". This approach is utilized, for example, by Xamarin, or React Native.

13 3. A multiplatform approach 3.2 A native multiplatform application

A native multiplatform application is an application that is not im- plemented in the platform’s native language, rather using another programming language that is generally unsupported by the platform [7]. It is common that a development environment handling the native application bundling is provided by a third party. The resulting prod- uct is an application using native API, with near-native performance.

3.2.1 Justifying the native multiplatform approach A native multiplatform development approach shares most advan- tages with hybrid development approach, but also expands on these advantages by adding some of its own. Primarily, native multiplatform approach solves the biggest issue of hybrid applications, the lowered fluidity and responsiveness. it also resolves the WebView issue of either being forced to rely on a good WebView implementation, or use a plu- gin like Cordova Crosswalk for a separate implementation – increasing size in return. Native multiplatform applications avoid the WebView altogether, instead relying on the usage of only native components.

3.3 Most notable multiplatform frameworks

The ensuing frameworks were picked mainly for their overall popu- larity, and for their well-executed approaches.

3.3.1 Xamarin Xamarin is a set of tools for application development, created by the Xa- marin company. It is based on Mono, which is an open source project implementing several tools used in .NET for multiplatform devel- opment. Because of its Mono roots, Xamarin utilizes C# as its main language. Although the Xamarin toolbox includes tools aimed at spe- cific platforms, like the Xamarin.iOS orXamarin.Android, the main spot- light will be aimed at Xamarin.forms. While tools for specific platforms like Xamarin.iOS usually achieve around 70% of code sharing, Xam- arin.forms is said to be able to achieve up to 100% shared code base[8].

14 3. A multiplatform approach

A simple comparison of Xamarin’s different tools is shown in figure 3.1.

Figure 3.1: Comparing traditional Xamarin and Xamarin.forms [9]

In the past, Xamarin utilized its own IDE1, Xamarin Studio for ap- plication development and deployment. It also had a limited starter edition, which allowed full usage up to a certain size of compiled code, which limited the developer’s capabilities. The starter edition also did not allow usage of Xamarin.Forms. Recently, Xamarin has been acquired by Microsoft Corp., resulting in several major changes. Biggest changes would be the full integration of Xamarin tools with Visual Studio, and the removal of some starter edition limitations, instead making Xamarin open-source[10]. Among the few services still only available to premium members is Xamarin Test Cloud, a cloud service which allows the developer to perform automated tests on thousands of various devices[11]. Xamarin Test Cloud’s pricing model starts at $99 per month with one simulta- neous device and one device hour per day, with growth in both as the pricing increases. A Xamarin application is compiled into a native binary, instead of being interpreted. On Android, Xamarin ships the Mono runtime bundled with the application, resulting in JIT2 compilation typical for

1. Integrated Development Environment 2. Just In Time

15 3. A multiplatform approach

Android applications. On iOS, Mono is used again, but instead compiles the application AOT3 into a native executable[12].

3.3.2 Ionic 2 Ionic is an open-source framework created by Drifty Co. for mobile ap- plication development using only HTML5, CSS and JavaScript. With over 32,000 stars on GitHub[13], a vibrant, active community and well-made documentation with clear examples[14], Ionic is being called the most popular hybrid mobile development framework. Ionic’s power comes from utilizing the Angular framework, the Apache Cor- dova framework, and SASS. Angular is an open-source JavaScript framework, sponsored and maintained by Google LLC, that utilizes the MVC4 architecture model. Angular’s purpose was to simplify development and testing of web applications, using the MVC architectural model. Angular extends the basic HTML syntax by adding custom attributes, classes and ele- ments. These customized markers, called Directives, result in Angular’s compiler attaching custom behaviours to the relevant DOM5 nodes. Apache Cordova is an open-source JavaScript mobile application de- velopment framework, based on the original PhoneGap. After Adobe’s acquisition of the original PhoneGap[15], they have donated PhoneGap to The Apache Software Foundation under the name Cordova. Cur- rently, Adobe is developing its PhoneGap ecosystem, which is based on the Cordova engine, but implements additional functionality. Cordova implements a set of APIs that create a bridge from JavaScript to native code, used for accessing the smart-phone’s native resources directly. Cordova has a set of pre-made plugins for accessing – for example – the microphone or the accelerometer by default. The out-of-the-box avail- able APIs are consistent across several platforms, including Android, iOS, Windows Phone, and even Blackberry.

3. Ahead of Time 4. Model–View–Controller – https://msdn.microsoft.com/en-us/library/ ff649643.aspx 5. Document Object Model – A tree-like structure of all HTML elements of a web-page

16 3. A multiplatform approach

SASS (Syntactically Awesome Style Sheets) is a CSS pre-processor that extends CSS’s features. SASS, popular because of its simple syn- tax and powerful features, compiles SASS (.scss) files into CSS files. Among its major innovations are things like importing & extending of other .scss files, HTML-like nesting of CSS selectors, variables, mixins6, and math operators. Recently, Drifty Co. has released a newer version of Ionic, labeled Ionic 2, to mark the transition from the Angular framework to its newest iteration, Angular 2+. The transition resulted in a major performance increase and code complexity decrease. To conclude, Ionic implements the Angular framework for its pow- erful approach to creating web applications, the Cordova framework for its powerful native APIs, and the SASS pre-processor for its many quality-of-life additions to basic CSS.

3.3.3 NativeScript NativeScript is an open-source, native multiplatform framework. It is centered around utilizing JavaScript, CSS and XML, with an option to use the Angular framework already mentioned above. It was created and is currently supported by Telerik AD. NativeScript allows the de- veloper to create native Android & iOS applications, with Windows UWP support being planned. The resulting application has native-like performance and user experience[16]. A major feature of NativeScript is the native API reflection. Instead of using a separate bridging layer between NativeScript and specific mobile platforms, NativeScript uses reflection to build up a mapping of the entire ecosystem[17]. Using this reflection, NativeScript is able to invoke native code easily – for example – instantiating a Java object and calling its methods (seen in listing 3.1) [18]. 1 let time= new android.text.format.Time(); 2 time.set( 1, 0, 2015 ); 3 console.log( time.format("%D")); Listing 3.1: An example of NativeScript’s reflected API usage.

6. Reusable blocks of style, used, for example, to assert all vendor prefixes

17 3. A multiplatform approach

Declaring a user interface in NativeScript is usually done using XML files, which the NativeScript compiler then uses to call upon native UI elements for each specific platform. NativeScript supports utilizing either pure JavaScript, or using TypeScript with the Angular framework. TypeScript is an open-source superset7 of the JavaScript language developed by Microsoft Corp., providing many additional features to the basic language. Among these features are interfaces, compile- time type-checking (as seen in figure 3.2), generic types, and type annotations – JavaScript is loosely typed by default. TypeScript has gained favor amongst developers used to working with high level Object Oriented Languages, mainly because of strong type enforcing, interfaces & and many other object-oriented quality-of-life additions.

Figure 3.2: An example of TypeScript’s strong type enforcing

3.3.4 React Native React Native is an open-source, multiplatform framework for building native applications with JavaScript & React. It has been created and is supported by Facebook, Inc. React Native allows the developer to pro- duce native Android & iOS applications, with an extension enabling development for Windows UWP8. React Native utilizes its own specific language – JSX – an XML-like syntax extension to ECMAScript with- out any defined semantics[19]. It is typically transpiled9 into JavaScript

7. Any JavaScript code is also compilable in TypeScript 8. https://github.com/Microsoft/react-native-windows 9. Transformed into another language with a similar level of abstraction

18 3. A multiplatform approach

using Babel10. With JSX and React Native, the developer uses declar- ative UI components which compile into native elements for each specific platform. One of React Native’s prominent features is Hot Reloading – a way to reload the application quickly11 while retaining the application’s state. This obviously only benefits the developers, by allowing them much faster interaction with the developed application, which in turn results in a faster production cycle. Previously, Live Reload has been used in React Native, which allowed similarly quick application reloading, but did not retain application state. This could be an irritation while developing a – for example – feature present only multiple screens away from the application’s entry point, or while tweaking minor details in UI design. Instead, Hot Reloading injects new versions of the edited files into the running application. A simple schema ofthe concept of Hot Reloading is displayed in figure 3.3.

Figure 3.3: A schema of Hot Module Reloading in React Native

Directly tied to the Hot Reloading feature is React Native’s easy error handling & debugging. On a non-standard action occurrence within the application, developer is promptly – thanks to the Hot Reloading fea- ture) – provided with an error screen displayed as a full screen report with both the error message and the relevant stack trace. Accessing

10. https://babeljs.io/ 11. Under 1 second[20].

19 3. A multiplatform approach these JavaScript logs is generally possible by using the react-native log-android or react-native log-ios commands, respectively on Android and iOS. Another option would be utilizing a web browser that supports Chrome Developer Tools. First, the developer enables Re- mote JavaScript debugging in the application, which in turn allows for connecting to the application through the web browser. In the browser, we can view the application’s logs and use all standard debugging features native to web development. These features include viewing current values of variables, utilizing break-points to pause the appli- cation at critical points, or stepping through a method’s execution line-by-line. It is also important to mention that React Native boasts a very large, ever-growing, community compared to the other mentioned frame- works. This results in more contributors, more relevant questions with proper answers on Stack Overflow12, and more open-source libraries to simplify the development process.

3.4 A comparison

To better differentiate between separate features of the aforementioned frameworks, a division of these features into several sections is nec- essary. The attributes are split based on viewpoints to help discern between their specific qualities. These viewpoints are, namely, the de- veloper’s viewpoint, the pricing viewpoint, and the user’s viewpoint.

3.4.1 Developer’s perspective Before presenting a concise comparison of the developer’s perspective in the form of a table, it is critical to first establish the evaluated points and their meanings.

» Ease-of-Use conveys the overhead necessary before, and after, the actual development. This includes things like IDE setup, project setup, application building & application (re)deployment.

12. https://stackoverflow.com/

20 3. A multiplatform approach

» Quality-of-Life signifies the improvements and advantages the specific framework has developer-wise, as compared to other frameworks. This could mean the specific programming approach, the difficulty of integration with native components or applications, or various improvements that reduce downtime and speed up the developer’s work – like Hot Reload in React Native, or Live Reload in Ionic 2.

» Community indicates the overall size of the community around the framework. The community size would be directly propor- tional to things like the volume of third-party libraries, the number of related questions (and solutions) on websites like Stack Overflow, or the momentum of the framework.

» Extras represent any extra features the framework has com- pared to the others, be it Xamarin’s Test Cloud feature, or any other feature that facilitates the development cycle.

Framework Ease-Of- Quality-of- Community Extras Use Life Xamarin Difficult Medium Large Test Cloud Ionic 2 Easy Medium Medium Codepusha NativeScript Medium Low Medium Sidekickb React Easy High Large Codepush Native a https://microsoft.github.io/code-push/ b https://www.nativescript.org/nativescript-sidekick

Table 3.1: Comparing the frameworks from a developer’s perspective

21 3. A multiplatform approach

3.4.2 Pricing perspective Before presenting a concise comparison of the pricing perspective in the form of a table, it is critical to first establish the evaluated points and their meanings.

» Developing Costs denote the relative development costs, which are affected by the framework’s specific approach to multi- platform development, or by the re-usability of code base across multiple platforms.

» Framework Pricing hint at whether the framework is paid or free.

» Deployment Costs symbolize the costs incurred by deploying the application on several platforms, updating the application, and application maintaining. Although the costs of deployment should generally be framework agnostic, the difference comes mostly from the costs caused by updating & maintaining the application.

Framework Developing Framework Deployment Costs Pricing Costs Xamarin Medium Free* High Ionic 2 Low Free Low NativeScript Low Free* High React Native Medium Free Low * With paid modules.

Table 3.2: Comparing the frameworks from a pricing perspective

22 3. A multiplatform approach

3.4.3 User’s perspective Before presenting a concise comparison of the user’s perspective in the form of a table, it is critical to first establish the evaluated points and their meanings.

» Performance represents how well the framework performs computation-heavy or animation-heavy operations. The main metric here would be the frame rate of the resulting application whilst performing complicated operations.

» Nativity denotes how well the framework’s output application complies to the set of features and design approaches specific to every platform.

» Size indicates the relative size of the application, compared to a native application. The most important factor here would be how small the necessary framework-specific code is.

Framework Performance Nativity Size Xamarin High High Big Ionic 2 Low Low Medium NativeScript Medium High Big React Native High High Medium

Table 3.3: Comparing the frameworks from a user’s perspective

23 3. A multiplatform approach

3.4.4 Conclusion Concerning the developer’s perspective, React Native comes out as a winner, mainly due to its simple setup13, well-made quality-of-life additions (like Hot Reload), and arguably the biggest community out of the presented frameworks. It’s important to note that while Xamarin’s Test Cloud feature does help with testing the application heavily, the Codepush feature usable both by Ionic 2 and React Native simplifies the deployment of updates. Both of these features help the developer with very different problems, hence they are difficult to compare. Regarding the pricing perspective of the framework, Ionic 2 comes out ahead, with its low development costs (caused by a virtually 100% shared code-base), free framework pricing and low deployment costs (mostly affected by Codepush). A close follow-up would be both React Native and NativeScript, with the former having less shared code, but simpler deployment and the latter having a larger shared code-base, but more costly deploying of updates. It’s important to note that dis- cussing shared code-base is specific on an application-to-application basis. All of these frameworks are capable to achieve an almost-100% shared code-base, in an ideal situation. As to the user’s perspective on the framework, React Native comes out as the winner, with very good performance, great nativity and a relatively small size (in comparison to the other frameworks). While Xamarin’s compilation model could be considered superiour, React Native achieves at least identical performance with the usage of asyn- chronous threading. To sum up the conclusion, it is clear that React Native comes out as a superior framework, with both great developer & user experiences, and coming in as a close second in the pricing perspective. While Ionic 2 does come out as a potentially cheaper framework to develop with, its other shortcomings make it difficult to use in high-quality applications.

13. https://github.com/react-community/create-react-native-app

24 4 React Native – an in-depth look

Following the results of the comparison made in the previous chap- ter’s finale, this chapter is focused on presenting an in-depth lookon React Native. Initially, the chapter presents an overview of JavaScript as a language, looking at its history, current state, advantages & short- comings. Afterwards, the chapter talks about the technology powering React Native – React. In the end, the chapter discusses React Native’s under-the-hood specifics.

4.1 JavaScript

4.1.1 About JavaScript JavaScript is a high-level, multi-paradigm language with a dynamic type system. JavaScript is considered to be one of the three core tech- nologies behind web development, present on more that 94% of all websites[21]. JavaScript is based on the ECMAScript standard, with its current version being ECMA-262[22]. An important trait of a programming language is it being either a compiled, or an interpreted language. This characterization was purposefully omitted in the previous section; JavaScript is a language that can be both compiled and interpreted. JavaScript engines – like V8 or Rhino – utilize a concept known as JIT Compilation. When a piece of JavaScript code is interpreted several times, the engine marks this code as warm. As the code gets warmer (meaning that the code is interpreted repeatedly), the engine compiles the code, and utilizes this compiled code instead of re-interpreting the same code repeatedly. As explained in listing 4.1, the main aim of the JIT Compiling is to enhance the performance.

25 4. React Native – an in-depth look

1 for(i = 0;i < 1000;i++ ){ 2 sum +=i; 3 } 4 //AJIT Compiler notices that the addition code will be run repeatedly, so instead of interpreting, the code gets compiled directly into machine code; removing the necessity to interpret the code 1000 times . Listing 4.1: An example of JIT compiler inside a JavaScript engine. As a multi-paradigm language, JavaScript supports several pro- gramming styles, and even combines them; be it event-driven, func- tional, or an imperative paradigm. Although initially only aimed to be a client-side language for web browsers, JavaScript is currently also being used on web servers[23], databases[24], and in some non-web programs like PDF software[25].

4.1.2 A short look on history Back in 1993, the University of Illinois released the first popular graph- ical web browser named NCSA Mosaic. Following this, a company called Mosaic Communications was founded in California’s Mountain View by several authors of the original NCSA Mosaic browser. The company’s main aim was to create a browser similar to NCSA Mosaic, but better in every way. The browser was internally called "Mozilla"1, and was released under the name Mosaic Netscape in the third quar- ter of 1994. After gaining popularity on the Internet2, the company decided to re-name the browser to Netscape Navigator, and itself to Netscape Communications, as to avoid a potential lawsuit by the origi- nal creators. In the following years, Netscape started believing that the web needs to become more dynamic, by using a simple language which would be easy to use by web designers to assemble and communicate with components conveniently. Specifically, Netscape provided the following explanation:

1. A combination of "Mosaic" and "Godzilla". 2. Being the most used browser in the 1990s.

26 4. React Native – an in-depth look

Figure 4.1: Netscape’s advocacy on JavaScript’s genesis[26].

Afterwards, the company decided to hire Brendan Eich, whose goal was to embed the Scheme language into Netscape Navigator[27]. Shortly following his acquisition, Netscape started negotiating with Sun Microsystems about utilizing the Java language in Netscape Navigator. Consequently, the company decided to develop their own language which had to "look like Java", ruling out languages as Python, Perl, or Scheme. The company required a working prototype rapidly, to defend the genesis of this new language. Eich was able to write a prototype in May of 1995, in just 10 days.

Figure 4.2: A schema depicting the sources behind JavaScript’s fea- tures[28].

27 4. React Native – an in-depth look

Although originally developed under the name Mocha, the lan- guage was renamed to LiveScript when shipped with the beta release of Netscape Navigator 2.0 in September 1995, followed by another re- naming to JavaScript a few months later. Almost a year later, Netscape started cooperating with Ecma International to create a standardized specification based on Netscape’s work[29]. This cooperation led to the release of ECMAScript language specification – published in the first version of ECMA-262 standard in June 1997[30] – of which JavaScript is the most popular implementation.

4.1.3 Advantages & shortcomings of JavaScript JavaScript, as any other programming language, comes with its own set of conveniences & flaws that are important to mention.

Advantages

» Dynamically typed – JavaScript uses at-runtime type check- ing and implicit type conversion where necessary. This could be taken as both an advantage and a shortcoming; the for- mer in smaller & medium-sized projects, the latter in larger & enterprise-sized projects.

» Simple debugging – Debugging a JavaScript application is usu- ally made simple using a well-equipped browser like Google Chrome, which already implements tools for debugging – the Chrome DevTools – out of the box.

» Platform agnostic – Given that JavaScript is generally processed (using a JavaScript engine like V8 or SpiderMonkey), the result- ing interpreted (or compiled) code is typically platform agnos- tic.

» Multi-paradigm approach – JavaScript supports the utilization of multiple paradigms, which liberates the developer to utilize whatever approach he deems the most appropriate to his spe- cific situation. Examples of various paradigms’ approaches are portrayed in listings 4.2, 4.3 and 4.4.

28 4. React Native – an in-depth look

1 let text="Hello World!"; 2 console.log(text); 3 //> Hello World! Listing 4.2: An example of imperative approach in JavaScript.

1 let text = () => console.log("Hello World!"); 2 text(); 3 //> Hello World! Listing 4.3: An example of functional approach in JavaScript.

1 function Text(){ 2 console.log( this.text); 3 } 4 5 Text.prototype={ 6 text:"Hello World!" 7 } 8 let foo= new Text(); 9 //> Hello World! Listing 4.4: An example of object-oriented approach in JavaScript.

Shortcomings

» Dynamically typed – As mentioned above, runtime type check- ing and implicit type conversion could be considered advan- tages in a smaller project, but become a hindrance in bigger- sized projects.

» Potential security issues – JavaScript scripts execute immedi- ately after the user enters a web page, which opens the door for potential malicious exploits of the user. Although modern web browsers are usually restrictive concerning these exploits, there are still ways to abuse the user.

» Compatibility – Different browser engines could execute iden- tical JavaScript snippets differently, causing hard-to-track incon- sistencies. Fortunately, this issue is typically solved by utilizing a transpiler.

29 4. React Native – an in-depth look

4.1.4 Transpilers

Transpilers – or transcompilers – are an important part of the JavaScript ecosystem. A transpiler, is a tool that reads source code written in one programming language, and outputs the equivalent code in another language[31]. The usage of transpilers is twofold. On one hand, they are used with languages like TypeScript or CoffeeScript, to help implement different specific concepts that are absent in JavaScript. The other usage is to utilize features from newer editions of the ECMAScript specifications, which are not necessarily supported by all browsers. Every browser uses a different JavaScript engine, with different performance charac- teristics, and varying implementations of the ECMAScript standard, which forces the developer to either write old JavaScript code, or to utilize a transpiler to take care of the issue. Transpilers also play an important role in the decision-making of the TC39 committee[32] – the committee responsible for designing the ECMAScript standard. The committee considers a feature’s imple- mentation in a transpiler to determine whether the feature should be implemented in the ECMAScript standard. Arguably the most popular JavaScript transpiler is Babel, which sup- ports transpiling both standardized ECMAScript language, and several cutting-edge ECMAScript versions – labeled as stages.

4.2 React

React is an open-source JavaScript library used for building user in- terfaces. It was created and is maintained by Facebook, Inc. The main motivation of React was to create a library with great speed and fluid- ity of user interfaces, which reacts immediately to any changes, but only updates the components that require an update. React utilizes so-called components as a main building block. Each component is either a JavaScript function (a stateless compo- nent), or a JavaScript class (a stateful component). A stateless compo- nent returns the HTML markup directly, whereas a stateful compo- nent extends the React.Component class and implements the render() method, which returns either another component, or HTML markup.

30 4. React Native – an in-depth look

React typically requires a root component that is rendered to a

tag with its ID set to "root". React makes use of the uni-directional data flow. In other words, in vanilla3 React, the data received by a component cannot be directly changed, but can be used as variables in its methods or attributes. On the other hand, a component can receive a callback function to change this data in the component above, and receive the updated data afterwards. This ensures that data only moves downwards, whereas function callbacks only move upward the component tree.

Figure 4.3: A simplified schema of React’s DOM Reconciliation[33]

Another important feature React provides is the Virtual DOM. DOM4 is a programming interface representing the HTML document as a tree-like structure of nodes and objects. This allows the devel- oper to edit the nodes programatically[34]. A major flaw of traditional DOM manipulation is its resource-heavy computation. React instead

3. Without any other Node modules 4. Document Object Model

31 4. React Native – an in-depth look utilizes the Virtual DOM; an abstract representation of the DOM that is synchronized with the real DOM whenever necessary. This syn- chronization process is called Reconciliation, and is explained in depth in React’s documentation[35]. Whenever the developer modifies the DOM with React, instead the Virtual DOM is modified. Then, React starts the Reconciliation, which compares the DOMs, locates the differ- ences and transforms the original DOM in the most effective way. This results in both faster reactivity and a better developer experience5. It is important to specify that React is not a framework, but a Javascript library instead. The distinction comes with respect to the MVC software architecture model, where the "Model" maintains data and the application logic, "View" represents the visualized data & user interface, and "Controller" accepts input and passes it to the other two parts. In this architecture, React takes the role of the "View" component of the MVC model, since e.g. working with a database requires use of a different technology altogether.

4.2.1 JSX JSX is a React-specific syntax extension that enhances the ECMAScript standard with the usage of XML-like tags. JSX is built out of elements and components. Elements are the JSX equivalents of ordinary HTML tags (e.g.

, or

), and components are references to React components. The listing 4.5 demonstrates React’s declarative nature, simple com- ponent composing and scalability while still maintaining high read- ability, relative simplicity and good re-usability of components & code. The listing 4.6 demonstrates how babel transpiles JSX into standard- ized JavaScript code.

5. e.g. there is no need to utilize selectors or create and maintain listeners.

32 4. React Native – an in-depth look

1 // Initial class declaration 2 class Warning extends React.Component{ 3 render(){ 4 return

Be careful,{ this.props.name}!; 5 } 6 } 7 // Rendering the class at the"root" node 8 ReactDOM.render(, root ); 9 // ResultingHTML 10

Be careful, Freddie!

Listing 4.5: An example of JSX usage in React.

1 let nav=( 2

3
• Home
4

5 ); 6 //Using Babel, theJSX gets transformed into regular JavaScript. 7 var nav= React.createElement("ul", 8 { id:"nav"}, 9 React.createElement("li", 10 {classname:"item"}, 11 React.createElement("a", 12 { href:"#"}, 13 "Home" 14 ) 15 ) 16 ) Listing 4.6: An example of Babel processing of JSX into JavaScript.

33 4. React Native – an in-depth look 4.3 Under React Native’s hood

React Native implements a concept called React Native bridge. The bridge is essentially a connection between multiple threads React Native uti- lizes in the resulting application. These threads are typically the JavaScript thread, and the native threads. The power of React Native comes from efficient splitting of the application between the JavaScript thread and the native threads.

Figure 4.4: A schema of the threading system React Native implements.

The JavaScript thread typically contains the application’s business logic. The native threads are composed of a main user interface thread that takes care of the native components React native utilizes, and several possible background threads which take care of background tasks as necessary. To clarify, the native modules are typically injected into the JavaScript thread as global variables, allowing their simple & quick instantiation. Because of this logic splitting, application freezes rarely happen with React Native, since the user interface is being drawn by a native thread. To further explain the idea of React Native’s bridge, it is impor- tant to understand that the aforementioned Reconciliation technique is utilized, although with modifications to fit the mobile application. The calls passing through the bridge are typically asynchronous and batched, as to limit the bridge calls to a minimum. The bridge could be considered the main bottleneck of a React Native application, and keeping its usage to a minimum is necessary to have a native-like application.

34 4. React Native – an in-depth look

An example of a improperly utilized bridging functionality could be a JavaScript implementation of a Swipable module. Presume a JavaScript component that allows sideways swiping of its children, while chang- ing its opacity and offset depending on the length of the swipe. An implementation in JavaScript would result in the following:

1. A native touch event is generated in the native thread.

2. The native touch event passes through the bridge to the JavaScript thread.

3. The JavaScript thread receives the event and uses the contained information to calculate the proper offset and opacity of the component, updating its state.

4. These calculations are henceforth sent back through the bridge to the native thread.

5. The native thread processes the data received through the bridge and performs the necessary changes to the user interface.

This approach seems harmless at first, but could easily bottleneck the bridge with unnecessary calculations that could have been handled on the native thread instead. In the end, the animation will probably not be fluid at a 60 frames per second refresh rate. To solve this problem, the developer should instead build his own native module that accepts the styling function for swiping events & the children to be drawn as properties. This way, there is no unneces- sary communication bottlenecking the bridge, since the native thread already knows how to offset and style the child components. A similar approach allows for fluid animation and a responsive application. To summarize, React Native’s main power comes from the possibil- ity to utilize native modules interchangeably with its own, wherever necessary, to maintain a quality application.

35

5 A demonstrative application

This chapter focuses, initially, on explaining the main motivation be- hind the demonstrative application, and the solution the application should demonstrate. Afterwards, an analysis of the proposed solution, with structure design, is formulated. Following is the application’s implementation, finished by concluding the results and determining what would be the next steps for the application.

5.1 Motivation & problem definition

The city of Brno plans to launch a version of the resident parking system in the few following years. Initially planned for the fall of 2017, the resident parking system was postponed up to year 2019. With fairly complicated pricing models based on zone of residency, zone of work and visiting zones, an application to simplify the parking system as much as possible would help the citizens of Brno to transition into the resident parking system as smoothly as possible. The residential parking system plans to divide the citizens into three categories:

» Resident - A person whose place of permanent residence is in one of the specified zones. In all the other zones, the person is considered to be a visitor.

» Abonnent - A person, or a legal entity, whose place of work is in one of the specified zones. In all the other zones, the person, or the legal entity, is considered to be a visitor.

» Visitor - A person who does not have the right for neither residential, nor abonnential parking.

With the residential and abonnential parking systems not being fully fleshed-out, the solution should be mainly aimed at people whom are considered visitors. Since the visitor’s pricing model & parking zones were already proposed by the city of Brno, the solution had a semi-solid ground to build upon.

37 5. A demonstrative application

Figure 5.1: A schema of the proposed pricing regions for visitor park- ing in Brno[36].

The main aim of the solution should be the simplification of the ticket buying process, with some quality-of-life additions like tickets timed by the minute, a way to look at past tickets & transactions, and a way to buy tickets for multiple separate cars. The solution should be able to determine the user’s position, and depending on the region the user is in, utilize a different pricing model for the ticket.

5.2 Analysis & structure design

React Native was previously concluded as the superior multiplatform framework to use currently, so naturally, the application would be written in it. Based on the problem definition written above, a simple use-case diagram, seen in figure 5.2 was constructed to help with application structure design. Considering the requirements of the solution, I have evaluated the options, and determined that using a React Native bootstrap service seemed as an optimal approach. Expo will be utilized to simplify the work flow & take care of components that would require native code instead.

38 5. A demonstrative application

Figure 5.2: A proposed use case diagram of the resulting application.

Expo is a free and open source toolchain built around React Native to help building native applications without any native knowledge[37]. Expo is heavily updated and maintained; every month, a new SDK1 is released, with more features ready out-of-the-box and less need to resort to native code. While making the developer’s work flow easier by providing many native functionalities, Expo also helps the devel- oper with application deployment and building. It provides a service similar to CodePush mentioned before, and allows the developer to build an iOS application without utilizing Xcode, or having to have a Mac altogether. In conjunction with Expo, CRNA2 will be utilized to bootstrap the project’s start. CRNA already includes the Expo platform out-of-the-box. Another problem that needed solving was how the authentication & data storage is going to be solved. I have opted to utilize Firebase – a mobile and web application development platform by Google LLC. The platform, among other things, provides support for several back-end services, such as user authentication, two database options or a stor-

1. Software Development Kit 2. Create React Native App

39 5. A demonstrative application age option[38]. The main aim of Firebase is to provide basic back-end functionalities without having to set up a dedicated back-end service. Firebase provides its own JavaScript library to communicate with the back-end services, although an option to communicate through a REST API is achievable using a helper library like node-firebase-rest[39]. It is necessary to mention that the RESTful API provided by the aforemen- tioned library does not provide an option for a practical, persistent connection. Although still technically achievable, the official Firebase library will be utilized instead, mainly because of it being well-tested and optimized for similar use cases. Based on these previous decisions & acknowledgements, a deploy- ment diagram is made. The diagram 5.3 displays the basic relations and communication methods between the used technologies. It also displays the modules that are being utilized from the Firebase service.

Figure 5.3: A proposed deployment diagram of the resulting applica- tion.

40 5. A demonstrative application 5.3 Implementation

Given that this was my first experience using React Native, I have arrived upon several problems both with implementing the specifics of the solution, and the technologies mentioned above. At first, the CRNA utility, coupled with Expo, helped me start up the project in minutes. The first issue that needed solving was to determine how rout- ing is going to be handled. The official React Native documentation presented three libraries for routing: native-navigation3, react-native- navigation4, and React Navigation5. I decided to look at the official Expo documentation, where the last library is mentioned as recommended. Following this recommendation, I’ve opted for the React Navigation library to take care of navigating the application. The aforementioned library presents several navigators – React Native components which define the application’s navigation structure. The resulting applica- tion’s navigation structure can be seen in figure 5.4. The rectangular nodes represent the different views the application contains, where the yellow node always represents the default screen the navigator leads to, and the blue nodes represent the other options of where the navigator allows the user to navigate to.

Figure 5.4: A schema of the navigation structure in the resulting appli- cation

3. http://airbnb.io/native-navigation/ 4. https://github.com/wix/react-native-navigation 5. https://reactnavigation.org/

41 5. A demonstrative application

Afterwards, I had to determine what map is going to be used for the resulting application. Since Expo already implements the react- native-maps6 out-of-the-box, the decision was an easy one to make. Following this, a decision had to be made about the approach to how the region overlay was going to be displayed over the map. Even more importantly, how is the region overlay going to be stored & processed. Having only a picture of the map overlay to start with, I’ve first checked the public datasets of the city ofBrno7. Regrettably, none of the datasets proved to be useful, so I have opted to utilize the Google Maps Roads API’s Snap to Roads utility. Unfortunately, this service is mainly aimed at tracking a vehicle’s route, so several manual adjustments had to be made to the resulting JSON8 object, as to adhere to the original region boundaries. Another decision had to be made concerning the Firebase platform’s database options. Firebase currently provides two different options, the Realtime Database and the beta version of Cloud Firestore. After examining both options, the Cloud Firestore seemed like a better op- tion for my use case. Hence I’ve decided to utilize the Firestore as my database of choice, but ran into issues quite quickly. Unfortunately, the JavaScript implementation of Firestore does not play well with Re- act Native. Having a specific bug happen only on Android, Firestore is unable to communicate with the Firebase service. Although the official Firebase team does know about this issue and is actively working on a fix, as of today, the bug is still occurring. The bug fix, shownin listing 5.1, seemed like an impractical workaround to me. Because of this (and other issues with setting up the Firestore in my React Native application), I have decided to use the Realtime Database instead. This version of Firebase’s database module, albeit having less functions, is already well-tested on most platforms, including in React Native.

6. https://github.com/react-community/react-native-maps 7. https://old.datahub.io/organization/statutarni-mesto-brno 8. JavaScript Object Notation

42 5. A demonstrative application

1 const originalSend= XMLHttpRequest.prototype. send; 2 XMLHttpRequest.prototype.send= function (body){ 3 if (body ===’’){ 4 originalSend.call( this); 5 } else { 6 originalSend.call( this , body); 7 } 8 }; Listing 5.1: The solution to Firestore’s bug on React Native

Concerning Firebase, I’ve also made use of its authentication mod- ule. After examining the capabilities of the Expo toolkit, I have imple- mented sign in using the typical e-mail & password combination, the Facebook social login, and the Google social login. However, to utilize these social login services in a deployed application, several require- ments need to be fulfilled, like having a valid privacy policy that has to be validated by Facebook. Understandably, I’ve opted to skip this, keeping the resulting application in "development" mode, meaning that only authorized Facebook accounts are allowed to use the social login.

5.3.1 Implementation structure The application implementation is divided logically into several fold- ers. The whole folder structure can be seen on figure 5.5. While being partly self-explanatory, I will try to clear out some non-intuitive folders’ use. The .expo folder contains necessary configuration files to allow Expo functionalities. The node_modules folder contains the installed dependencies, and will be further talked about later. The Auth folder contains all user authentication functionalities, including logging in, logging out, password reset, and signing in. This logic is implemented using the functionalities provided by Expo, simplifying the process substantially. The map and settings folders contain their respective screen implementations, along with the logic required to allow them to function. The login folder contains the screens available to the user while signed out, while most logic is contained in the auth folder

43 5. A demonstrative application

Figure 5.5: A screenshot depicting the project structure of the applica- tion. mentioned above. Router contains the routing logic necessary to make traversing the application feasible. App.js is the application’s entry point; It is the root of the routing system & manages the user’s credentials. The package.json contains several informations about the application, and a list of dependen- cies, which are required for correct application functionality. These dependencies are typically installed using npm or yarn9 using a sim- ple command like npmi or yarn install. They are installed into the aforementioned node_modules folder.

9. two most popular variants of package managers utilized by JavaScript developers

44 5. A demonstrative application

5.3.2 User scenarios Typically, after launching the application for the first time, the user is displayed a "Sign in" screen. The "Sign in" screen contains a way to sign in using the methods mentioned above, and two redirecting buttons; one leading to the "Forgotten password" screen, and one leading to the "sign up" screen. Both of these screens keep a similar design style to the "Sign in" screen, and are otherwise self-explanatory.

Figure 5.6: Photographs of the sign in and sign up screens.

If the user managed to sign in, a "Map" screen is displayed, with a slider menu on the bottom. This menu allows the user to pass between the two main screens of the application, the "Map" and the "Settings" screens. The "map" screen first prompts the user to activate location services (if they’re disabled), then displays the user’s current position, while also displaying the region overlays over the map of Brno. The user is presented with a button on the bottom part of the map, which allows him to start his parking ticket. Clicking this button again opens a modal window for the user, informing him of the cost of the ticket, and displaying a button for proceeding with the payment, and for canceling the payment (hence keeping the ticket running).

45 5. A demonstrative application

Figure 5.7: Photographs of the map screen and the modal for ticket purchase confirmation.

Following into the "Settings" screen, the user is presented with a menu that allows him to navigate into different sections of the settings. The menu is split into two parts; the "Parking" section, and the "User" section. The "Parking" section is made of three separate screens, the "Billing" screen, the "Registration Plates" screen, and the "Tickets" screen. The first screen is used for storing user’s credit card information to process payment for the tickets10. The second screen allows the user to view, add, edit & remove his registration plates. These are tied directly to the ticket. The third screen allows the user to view his past tickets, with information like overall price, or the start & end of the parking session. The "User" section contains the "Profile" screen, and the "Log Out" button. The "Profile" screen allows the user to change his password,

10. This information is stored in a secure storage, whose implementation differs on Android and iOS. I believe that for an application prototype, such secure data handling is sufficient.

46 5. A demonstrative application while the "Log Out" button allows for simple user sign out functional- ity.

Figure 5.8: Screenshots of the settings screen, and the billing screen.

5.4 Results & What’s next

Although some complications emerged while implementing the ap- plication, they were eventually resolved satisfyingly. The application provides a prototype of how Brno’s residential parking system could be simplified for visitors & people without permanent residence. It provides a proof of concept for a smart city solution that could even- tually be integrated into Brno. I believe that the application development was very efficient, al- lowing me to develop a working prototype in the scope of days. With only minor additions, this prototype could be very quickly adapted to the iOS platform. The application could potentially be utilized for real ticket purchas- ing, with some modifications. Primarily, actively communicating with the city of Brno is necessary to help with a proper analysis of the prob-

47 5. A demonstrative application lem, and with important decisions that need to be made concerning all parts of the ticket purchasing & checking process. Another necessity is an implementation of a proper back-end ser- vice. While Firebase is very usable for small projects, for a similar project’s scope, a dedicated back-end might be a better, more secure, choice.

48 6 Conclusion

The first chapter of the thesis focused on investigating the basic require- ments for mobile application development, presenting the various possible approaches to mobile development, and comparing their advantages & drawbacks. Afterwards, the thesis aimed at justifying the native multiplatform approach. Most notable multiplatform frameworks were presented, with an explanation of the technologies they utilize and how they function. A comparison between the aforementioned frameworks was made, using several perspectives to establish an objective viewpoint on each framework’s qualities. The chapter was concluded with a final decision as to which is the current leading framework. The following chapter is determined to provide an in-depth look into the technologies behind React Native – the winner of the frame- work comparison in the previous chapter. JavaScript and React are presented as the basic building blocks of the React Native framework, and a short venture into techniques used by React Native’s engine is made. Finally, a demonstrative application assignment is formulated, based on a problem definition provided by my advisor, RNDr. Škrabálek. An analysis and initial structure design is made, following with a re- count of several issues that needed resolving during the implementa- tion, and a recap of possible user scenarios of the resulting application. The chapter concludes with a quick assessment of the development process, and some propositions concerning the possible applications of the prototype demonstrative application. Overall, I believe that React Native has proven itself as a fairly ma- ture native multiplatform development framework, with a well es- tablished ecosystem and relatively simple application development lifecycle. React Native fills an empty space between native & hybrid approaches elegantly, taking the best of both worlds, while trying to keep the drawbacks to a minimum. My development in React Native was overall a very pleasant experience, although, as with every new technology, had some minor issues that needed operative problem solving. I have managed to create a viable, native-like application prototype in a matter of days. The application feasibly showcases a

49 6. Conclusion possible direction Brno’s parking system could take. I would conclude that React Native is a great development option for smaller & medium sized projects, and also for smaller companies without large, dedi- cated teams of native developers for each platform. React Native does not aim to make native development obsolete; instead, it uses React’s strengths to allow for high reusability & composability of native com- ponents, while still allowing the developer to develop a native module whenever necessary. At this specific subsection of mobile development is where React Native excels.

50 Bibliography

1. STATCOUNTER. Desktop vs Mobile vs Tablet Market Share World- wide [online] [visited on 2017-04-20]. Available from: http://gs. statcounter . com / platform - market - share / desktop - mobile - tablet. 2. CWS. 5 Statistics: Mobilegeddon’s Effect on Non-Optimized Web [on- line] [visited on 2017-04-20]. Available from: https://blog.cws. net/blog/2015/06/5-statistics-mobilegeddons-effect-on- non-optimized-websites.html. 3. POCKETGAMER.BIZ. Average prices for apps in the Apple App Store as of July 2017 (in U.S. dollars) [online] [visited on 2017-11-04]. Available from: https://www.statista.com/statistics/267346/ average-apple-app-store-price-app/. 4. AYET-STUDIOS. Free and paid app distribution for iOS in comparison to Android ○c ayeT-Studios [online] [visited on 2017-11-04]. Avail- able from: https://www.ayetstudios.com/blog/app-promotion/ mobile-app-promotion/promote-ios-app. 5. GLOBETROTTER. Hybrid Applications And Android Native Browser [online] [visited on 2017-04-23]. Available from: https: / / myshadesofgray . wordpress . com / 2014 / 04 / 15 / hybrid - applications-and-android-native-browser/. 6. CHRISTENSSON, P. Multiplatform Definition [online] [visited on 2017-04-20]. Available from: https://techterms.com/definition/ multiplatform. 7. POTOTSKA, I. Hidden Advantages of Cross-Platform Development with React Native [online] [visited on 2017-10-17]. Available from: https://yalantis.com/blog/native-vs-cross-platform-app- development-shouldnt-work-cross-platform/. 8. XAMARIN. The Xamarin platform [online] [visited on 2017-11-04]. Available from: https://www.xamarin.com/platform. 9. INTERTECH. Mobile Applications? Xamarin.Forms? Why? [online] [visited on 2017-11-04]. Available from: https://www.intertech. com/Blog/mobile-applications-xamarin-forms-why/.

51 BIBLIOGRAPHY

10. FRIEDMAN, Nat. Xamarin for all [online] [visited on 2017-11-04]. Available from: https://blog.xamarin.com/xamarin-for-all/. 11. XAMARIN. Mobile app testing made easy [online] [visited on 2017-11-04]. Available from: https://www.xamarin.com/test- cloud. 12. XAMARIN. Xamarin FAQ [online] [visited on 2017-11-04]. Available from: https://www.xamarin.com/faq#q3. 13. TEAM, Ionic. Ionic GitHub page [online] [visited on 2017-11-11]. Avail- able from: https://github.com/ionic-team/ionic. 14. TEAM, Ionic. Ionic documentation [online] [visited on 2017-11-11]. Available from: http://ionicframework.com/docs/. 15. RAO, Leena. Adobe Acquires Developer Of HTML5 Mobile App Framework PhoneGap Nitobi [online] [visited on 2017-11-11]. Available from: https://techcrunch.com/2011/10/03/adobe- acquires - developer - of - html5 - mobile - app - framework - phonegap-nitobi/. 16. TELERIK, Progress. About NativeScript [online] [visited on 2017-11-11]. Available from: https : / / www . nativescript . org / about. 17. TELERIK, Progress. NativeScript Under the Hood [online] [visited on 2017-11-11]. Available from: https://developer.telerik.com/ products/nativescript-inside-the-black-box/. 18. TELERIK, Progress. How NativeScript Works [online] [visited on 2017-11-11]. Available from: https://developer.telerik.com/ featured/nativescript-works/. 19. FACEBOOK, Inc. Draft: JSX Specification [online] [visited on 2017-11-20]. Available from: https://facebook.github.io/jsx/. 20. BIGIO, Martín. Introducing Hot Reloading [online] [visited on 2017-11-20]. Available from: https://facebook.github.io/react- native/blog/2016/03/24/introducing-hot-reloading.html. 21. W3TECHS. Usage Statistics for Websites, December 2017 [online] [visited on 2017-12-01]. Available from: https://w3techs.com/ technologies/details/cp-javascript/all/all.

52 BIBLIOGRAPHY

22. ECMA. Standard ECMA-262 [online] [visited on 2017-12-01]. Available from: https://www.ecma- international.org/publications/ standards/Ecma-262.htm. 23. FOUNDATION, Node.js. Node.js [online] [visited on 2017-12-01]. Available from: https://nodejs.org/en/. 24. FOUNDATION, The Apache Software. Apache CouchDB [online] [visited on 2017-12-01]. Available from: https://couchdb.apache. org/. 25. INCORPORATED, Adobe Systems. Javascript for Acrobat [online] [visited on 2017-12-01]. Available from: http://www.adobe.com/ devnet/acrobat/javascript.html. 26. HAMILTON, Naomi. The A-Z of Programming Languages: JavaScript [online] [visited on 2017-12-03]. Available from: https : / / www . computerworld . com . au / article / 255293 / a - z _ programming _ languages_javascript/. 27. EICH, Brendan. Popularity [online] [visited on 2017-12-03]. Available from: https://brendaneich.com/2008/04/popularity/. 28. SUCKOW-HOMBERG, Thorsten. Javascript - The Good, the Bad and the Ugly [online] [visited on 2017-12-03]. Available from: https: //www.slideshare.net/ThorstenSuckow/javascript-the-good- the-bad-and-the-ugly. 29. NETSCAPE. Industry Leaders to Advance Standardization of Netscape’s JavaScript at Standards Body Meeting [online] [visited on 2017-12-03]. Available from: https : / / web . archive . org / web/19981203070212/http://cgi.netscape.com/newsref/pr/ newsrelease289.html. 30. INTERNATIONAL, ECMA. ECMAScript: A general purpose, cross-platform programming language [online] [visited on 2017-12-03]. Available from: https://www.ecma-international. org / publications / files / ECMA - ST - ARCH / ECMA - 262 , %201st % 20edition,%20June%201997.pdf. 31. SENGSTACKE, Peleke. JavaScript Transpilers: What They Are & Why We Need Them [online] [visited on 2017-12-05]. Available from: https://scotch.io/tutorials/javascript-transpilers-what- they-are-why-we-need-them.

53 BIBLIOGRAPHY

32. RAUSCHMAYER, Dr. Axel. The TC39 process for ECMAScript features [online] [visited on 2017-12-06]. Available from: http://2ality. com/2015/11/tc39-process.html. 33. EISENMAN, Bonnie. Learning React Native: Building native mobile apps with JavaScript. 1st ed. O’Reilly Media, Inc., 2015. ISBN 9781491929049. 34. DOCS, MDN web. Introduction to the DOM [online] [visited on 2017-12-06]. Available from: https://developer.mozilla.org/en- US/docs/Web/API/Document_Object_Model/Introduction. 35. FACEBOOK, Inc. Virtual DOM and Internals [online] [visited on 2017-12-06]. Available from: https://reactjs.org/docs/faq- internals.html. 36. BRNO. Rezidentní parkování v nejužším centru města začne fun- govat na podzim [online] [visited on 2017-12-11]. Available from: https://www.brno.cz/brno- aktualne/co- se- deje- v- brne/ a/rezidentni- parkovani- v- nejuzsim- centru- mesta- zacne- fungovat-na-podzim/. 37. EXPO. Expo [online] [visited on 2017-12-11]. Available from: https: //expo.io/. 38. LLC, Google. Firebase [online] [visited on 2017-12-12]. Available from: https://firebase.google.com/. 39. node-firebase-rest [online]. Brno: fny, 2016–2017 [visited on 2017-12-12]. Available from: https://github.com/fny/node-firebase-rest.

54