MASARYK UNIVERSITY FACULTY OF INFORMATICS Developing a mobile application using multiplatform frameworks with a native output BACHELOR'S THESIS Filip Drgon Brno, Fall 2017 MASARYK UNIVERSITY FACULTY OF INFORMATICS Developing a mobile application using multiplatform frameworks with a native output BACHELOR'S THESIS Filip Drgon Brno, Fall 2017 This is where a copy of the official signed thesis assignment and a copy of the Statement ofan 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. A l l 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 Skrabalek, 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 qualities 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 ] 1 5 3.2 A n 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 Read'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 midOctober 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 developing an application utilizing multiplatform development, specifically focusing on tools for developing native applications, for both major platforms, seamlessly and concurrently. The thesis takes into evaluation the reusability of code blocks and components for ease-of-use and comfortable development process, resulting in faster, cheaper and easier development process. 1 i . 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 thesis discusses the multiplatform development types & multiplatform framework types. In the end, a profound comparison of several multiplatform 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 analysis with a structure design, and an implementation showcase with photographs and use cases of the application. A n 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 development, 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, individual software units with limited functionality. Nowadays, mobile applications are functionally-wise comparative to applications for personal 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 differ heavily, with the difference mainly being the required system resources & the device's special functions. 2.2.1 User interface requirements A basic requirement for a mobile application is to be easily usable. A n 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. A n overwhelming 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 sufficiently 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 example, 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 application 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 in the Apple A p p 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 Average prices for apps in the Apple App Store as of July 2017 (in U.S. dollars) 1.25 1.02 Figure 2.1: Average application price on iOS store, June 2017[3] Mobile applications also affect the user's view on software financing. While the model of a one-time purchase of an application is still prevailing on personal computers, mobile applications tend to be either very cheap, or free, with financing being solved typically by a 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 former 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 Distribution Free vs. PaidApps (i OSvs. Android) 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 device (e.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. A n 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 (Application Programming Interface) for easier access towards server services, e.g. editing and accessing data, authentication, or complex operations unfit to be performed on the client's device. » Front-End (client part) - typically presents a set of User Interfaces, 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 necessarily 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 application, 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 BackEnd 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 Mobile App Technology Stacks Your App 4, t Operating System & Device Your App Embeddedl Native I H 3 " f „ Web Views I Ul Views I ^ o t k Native Wrapper App 4- t Operating System & Device Your App 4- t Web Browser J, ? Operating System & Device Native App "Hybrid" App Web App 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 required 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 substantially 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 enforce 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 implementations 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 updating after every update, which makes maintaining older versions 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 computers. The application adapts according to the device it is accessed by, and it is accessed solely by the web browser of the device. This development 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 several, 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 maintain only one source code. Updating the application is performed by deploying the new application on the server, which is arguably much simpler, and economical, than having to distribute the application on several platforms. The update is instantaneous and without user interaction. 9 2. A MOBILE APPLICATION Drawbacks » User Interface is unoptimized - The user interface differs considerably 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 application, 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 approach allows re-use of source code across different applications and platforms, reducing development costs. While developing hybridly, it is still necessary to develop an application 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 development 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 deteriorated 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 problematic. 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 identical 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 application could be considerably easier to maintain than a web or a hybrid application. O n 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 multiplatform 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 example, 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 implemented 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 product 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 advantages 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 plugin 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 popularity, and for their well-executed approaches. 3.3.1 Xamarin Xamarin is a set of tools for application development, created by the Xamarin company. It is based on Mono, which is an open source project implementing several tools used in .NET for multiplatform development. Because of its Mono roots, Xamarin utilizes C# as its main language. Although the Xamarin toolbox includes tools aimed at specific platforms, like the Xamarin.iOS orXamarin.Android, the main spotlight will be aimed at Xamarin.forms. While tools for specific platforms like Xamarin.iOS usually achieve around 70% of code sharing, Xamarinforms 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. Traditional Xamarin approach * • • With Xamarin.Forms: more code-sharing, native controls Figure 3.1: Comparing traditional Xamarin and Xamarin.forms [9] In the past, Xamarin utilized its own IDE1 , Xamarin Studio for application 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[ll]. Xamarin Test Cloud's pricing model starts at $99 per month with one simultaneous 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. O n 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 application 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 Cordova framework, and SASS. Angular is an open-source JavaScript framework, sponsored and maintained by Google LLC, that utilizes the M V C 4 architecture model. Angular's purpose was to simplify development and testing of web applications, using the M V C architectural model. Angular extends the basic H T M L syntax by adding custom attributes, classes and elements. These customized markers, called Directives, result in Angular's compiler attaching custom behaviours to the relevant D O M 5 nodes. Apache Cordova is an open-source JavaScript mobile application development 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. Currently, 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 available 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 H T M L 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 syntax 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 powerful 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 developer 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]. l e t t i m e = new a n d r o i d . t e x t . f o r m a t . T i m e ( ) ; t i m e . s e t ( 1 , 0 , 2 0 1 5 ) ; c o n s o l e . l o g ( t i m e . f o r m a t ( " % D " ) ) ; Listing 3.1: A n 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 X M L 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, compiletime 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. c o n s t add = ( a d d l : number, add2: number): number => { r e t u r n a d d l + add2; }; c o n s o l e . l o q ( a d d ( l , " t w o " ) ) ; | TS2345:Argument of type "two"' is not assignable to parameter of type 'number'. Figure 3.2: A n example of TypeScript'% 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 produce 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 without 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 declarative 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 quickly1 1 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 of the concept of Hot Reloading is displayed in figure 3.3. MODULE SYSTEM , PACKAGER ;'• Patches module system WATCHMAN Notifies file change HMR PLUGIN Sends IIMR upca:e HMR RUNTIME 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 feature) - 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 Remote 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 application 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 frameworks. 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 necessary. The attributes are split based on viewpoints to help discern between their specific qualities. These viewpoints are, namely, the developer'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 proportional 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 compared to the others, be it Xamarin's Test Cloud feature, or any other feature that facilitates the development cycle. Framework Ease-Of- Use Quality-of- Life Community Extras Xamarin Difficult Medium Large Test Cloud Ionic 2 Easy Medium Medium Codepusha NativeScript Medium Low Medium Sidekickb React Easy Native High Large Codepush a h t t p s : / / m i c r o s o f t . g i t h u b . i o / c o d e - p u s h / b h t t p s : / / w w w . n a t i v e s c r i p t . o r g / n a t i v e s c r i p t - s i d e k i c k 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 multiplatform 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 Costs Framework Pricing Deployment 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 setup1 3 , 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 discussing shared code-base is specific on an application-to-application basis. A l l 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 asynchronous 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 chapter's finale, this chapter is focused on presenting an in-depth look on React Native. Initially, the chapter presents an overview of JavaScript as a language, looking at its history, current state, advantages & shortcomings. 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 technologies 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]. A n 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 - A N IN-DEPTH LOOK f o r ( i = 0 ; i < 1 0 0 0 ; i + + ) { sum += i ; } // A J I T C o m p i l e r n o t i c e s t h a t t h e a d d i t i o n c o d e w i l l b e r u n r e p e a t e d l y , s o i n s t e a d o f i n t e r p r e t i n g , t h e c o d e g e t s c o m p i l e d d i r e c t l y i n t o m a c h i n e c o d e ; r e m o v i n g t h e n e c e s s i t y t o i n t e r p r e t t h e c o d e 1 0 0 0 t i m e s Listing 4.1: A n example of JIT compiler inside a JavaScript engine. As a multi-paradigm language, JavaScript supports several programming styles, and even combines them; be it event-driven, functional, 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 graphical 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 quarter 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 original 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 - A N IN-DEPTH LOOK We aimed to provide a "glue language" for the Web designers and part time programmers who were building Web contentfrom components such as images, plugins, and Java applets. We saw Java as the "component language" used by higher-priced programmers, where the glue programmers—the Web page designers—would assemble components and automate their interactions using [a scripting language]. 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^]. 27 4. REACT NATIVE - A N IN-DEPTH LOOK Although originally developed under the name Mocha, the language was renamed to LiveScript when shipped with the beta release of Netscape Navigator 2.0 in September 1995, followed by another renaming 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 checking and implicit type conversion where necessary. This could be taken as both an advantage and a shortcoming; the former in smaller & medium-sized projects, the latter in larger & enterprise-sized projects. » Simple debugging - Debugging a JavaScript application is usually 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 resulting 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 specific situation. Examples of various paradigms' approaches are portrayed in listings 4.2, 4.3 and 4.4. 28 4. REACT NATIVE - A N IN-DEPTH LOOK 1 l e t t e x t = " H e l l o W o r l d ! " ; 2 c o n s o l e . l o g ( t e x t ) ; 3 // > H e l l o W o r l d ! Listing 4.2: A n example of imperative approach in JavaScript. 1 l e t t e x t = () => c o n s o l e . l o g ( " H e l l o W o r l d ! " ) ; 2 t e x t () ; 3 // > H e l l o W o r l d ! Listing 4.3: A n example of functional approach in JavaScript. 1 f u n c t i o n T e x t ( ) { 2 c o n s o l e . l o g ( t h i s . t e x t ) ; 3 } 4 5 T e x t . p r o t o t y p e = { 6 t e x t : " H e l l o W o r l d ! " 7 } 8 l e t f o o = n e w T e x t () ; 9 // > H e l l o W o r l d ! Listing 4.4: A n example of object-oriented approach in JavaScript. Shortcomings » Dynamically typed - As mentioned above, runtime type checking and implicit type conversion could be considered advantages in a smaller project, but become a hindrance in biggersized projects. » Potential security issues - JavaScript scripts execute immediately 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 identical JavaScript snippets differently, causing hard-to-track inconsistencies. Fortunately, this issue is typically solved by utilizing a transpiler. 29 4. REACT NATIVE - A N 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 characteristics, 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 implementation in a transpiler to determine whether the feature should be implemented in the ECMAScript standard. Arguably the most popular JavaScript transpiler is Babel, which supports transpilingboth 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 interfaces. It was created and is maintained by Facebook, Inc. The main motivation of React was to create a library with great speed and fluidity 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 component), or a JavaScript class (a stateful component). A stateless component returns the HTML markup directly, whereas a stateful component extends the React.Component class and implements the renderO method, which returns either another component, or HTML markup. 30 4. REACT NATIVE - A N 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 dataflow. 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. Virtual DOM State Change • Compute Diff • Re-render Browser DOM Figure 4.3: A simplified schema of Read's DOM Reconciliation[33] Another important feature React provides is the Virtual DOM. D O M 4 is a programming interface representing the HTML document as a tree-like structure of nodes and objects. This allows the developer 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 - A N IN-DEPTH LOOK utilizes the Virtual DOM; an abstract representation of the DOM that is synchronized with the real DOM whenever necessary. This synchronization process is called Reconciliation, and is explained in depth in Read'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 differences 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 Read-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 Read's declarative nature, simple component composing and scalability while still maintaining high readability, relative simplicity and good re-usability of components & code. The listing 4.6 demonstrates how babel transpiles JSX into standardized JavaScript code. 5. e.g. there is no need to utilize selectors or create and maintain listeners. 32 4. REACT NATIVE - A N IN-DEPTH LOOK 1 // I n i t i a l c l a s s d e c l a r a t i o n 2 c l a s s W a r n i n g e x t e n d s R e a c t . C o m p o n e n t { 3 r e n d e r () { 4 r e t u r n < d i v > B e c a r e f u l , { t h i s . p r o p s . n a m e } ! < / d i v >; 5 } 6 } 7 // R e n d e r i n g t h e c l a s s a t t h e " r o o t " n o d e 8 R e a c t D O M . r e n d e r ( < W a r n i n g n a m e = " F r e d d i e " / > , r o o t ) ; 9 // R e s u l t i n g HTML 10 < d i v > B e c a r e f u l , F r e d d i e ! < / d i v > Listing 4.5: A n example of JSX usage in React. 1 l e t n a v = ( 2 < u l i d = " n a v " > 3 < l i c l a s s N a m e = " i t e m " > < a h r e f = " # " > H o m e < / a > < / l i > 4 < / u l > 5 ) ; 6 / / U s i n g B a b e l , t h e J S X g e t s t r a n s f o r m e d i n t o r e g u l a r J a v a S c r i p t . 7 v a r n a v = R e a c t . c r e a t e E l e m e n t ( " u l " , 8 { i d : " n a v " }, 9 R e a c t . c r e a t e E l e m e n t ( " l i " , 10 { c l a s s n a m e : " i t e m " } , 11 R e a c t . c r e a t e E l e m e n t ( " a " , 12 { h r e f : " # " } , 13 " H o m e " 14 ) 15 ) 16 ) Listing 4.6: A n example of Babel processing of JSX into JavaScript. 33 4- REACT NATIVE - A N 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 utilizes i n 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. JavaScript Thread The Bridge 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 important 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 - A N IN-DEPTH LOOK A n 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 changing its opacity and offset depending on the length of the swipe. A n 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 unnecessary 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 possibility 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 behind 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 parking 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 Parking 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 developer 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 A p p 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 aforementioned 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 deployment 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. Parking Application <> ^] Parking Application <> ^] Parking Application V 4Firebase Interface <> D Local Secure Storage 4Firebase Interface Firebase API • .1. /Firebase Server Firebase Interface J Firebase Interface J <> Authentication Firebase Interface J <> ^] Realtime database <> 0 Database Storage 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 routing is going to be handled. The official React Native documentation presented three libraries for routing: native-navigation3 , react-native- navigation4 , and React Navigation5 .1 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 application'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. Signed Out Application Root Signed In Application Root (^Ttack Navigator^} Sign In Sign Up ^J~ab N a v i g a t o r ^ orgotten Passworc Map ^ S t a c k N a v i g a t o r ^ Settings Credit Card J c e n c e Plates Past Tickets 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 of Brno7 . 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 option 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 React 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, shown in 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 c o n s t o r i g i n a l S e n d = X M L H t t p R e q u e s t . p r o t o t y p e . s e n d ; 2 X M L H t t p R e q u e s t . p r o t o t y p e . s e n d = f u n c t i o n ( b o d y ) { 3 i f ( b o d y === ' ' ) { 4 o r i g i n a l S e n d . c a l l ( t h i s ) ; 5 } e l s e { 6 o r i g i n a l S e n d . c a l l ( t h i s , b o d y ) ; 7 } 8 }; Listing 5.1: The solution to Firestore's bug on React Native Concerning Firebase, I've also made use of its authentication module. After examining the capabilities of the Expo toolkit, I have implemented 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 requirements 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 folders. 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 nodejmodules 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 w M Parkin Brno ~/Desktop/BC/Parkiri Brno • M .expo • M nodemodules library root t Msrc • Mauth t l l components • iisignedln • map • l l settings • MsignedOut • l l login • M img • M router • Hutils fo.babelrc 3 .flowconfig 3 .gitignore y .watchmanconfig raApp.js r&app.json raApp.test.js tEipatkage.json i README.md 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 dependencies, which are required for correct application functionality. These dependencies are typically installed using npm or yarn9 using a simple command like npm i or yarn i n s t a l l . They are installed into the aforementioned nodejnodules 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. • • U 3 10:20 O * 'A 3 10:22 1 Sign In 1Parkin Brno A Password... Signup A Password... A Password... Forgot your password? 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 Parkin ticket Your ticket has been running for 1498 minutes. Moravská zemská a O 1 °< o • 1 ' o • 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 tickets1 0 . 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. Start: 14:12 Tariff: 1 End: 15:12 46 5- A DEMONSTRATIVE APPLICATION while the "Log Out" button allows for simple user sign out functional- ity. I O y m 9 .!•> 14:59 1 Settings Parking R Billing info > Q Registration Plates > M Tickets > User ^ Profile > 3 Sign Out a * < o • @) 9 "4 •£> 14:59