Masaryk University Faculty of Informatics
Cross-platform Mobile Application Development Comparison
Master’s Thesis
Bc. Michal Zopp
Brno, Fall 2020 Masaryk University Faculty of Informatics
Cross-platform Mobile Application Development Comparison
Master’s Thesis
Bc. Michal Zopp
Brno, Fall 2020 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.
Bc. Michal Zopp
Advisor: RNDr. Vít Rusňák, Ph.D.
i Acknowledgements
I would like to thank my advisor RNDr. Vít Rusňák, Ph.D. for his guidance, friendly approach and valuable advice during the creation of the applications as well as this thesis. I would also like to thank the professors and teachers of this faculty that gave me the broad outlook in the field of computer science.
ii Abstract
This thesis focuses on comparing mobile application development approaches from development, empirical, and user experience stand- points. It compares NativeScript and React Native frameworks, which are two common JavaScript frameworks for developing cross-platform applications. Finally, it compares these cross-platform development approaches with native development for iOS devices using the Swift programming language.
iii Keywords
Android, iOS, mobile application, React Native, NativeScript
iv Contents
1 Introduction 1
2 SkautIS – Information System of Junák 3 2.1 SkautIS Agendas ...... 3 2.2 SkautIS API and Web Services ...... 4 2.3 Testing Environment ...... 6
3 Mobile Application Development 7 3.1 Native Approach ...... 7 3.1.1 Native iOS Application Development ...... 8 3.1.2 Native Android Application Development . . . 12 3.2 Cross-platform Application Development ...... 16 3.2.1 NativeScript ...... 16 3.2.2 React Native ...... 19
4 Current NativeScript Mobile Application 24 4.1 Design ...... 24 4.1.1 Project Structure ...... 24 4.1.2 Agendas ...... 26 4.1.3 State Logic ...... 27 4.2 Issues ...... 28 4.2.1 Navigation ...... 28 4.2.2 Empty State ...... 29
5 Implementation of the React Native Mobile Application 32 5.1 Design ...... 32 5.1.1 Project Structure ...... 33 5.1.2 Agendas ...... 34 5.1.3 Navigation ...... 34 5.2 Implementation Details ...... 35 5.2.1 NPM Libraries ...... 35 5.2.2 API Calls ...... 36 5.2.3 Empty state and error response ...... 37 5.3 Future Improvements ...... 38 5.3.1 Application Reset ...... 38 5.3.2 Edge API Cases ...... 39
v 6 Implementation of the Swift Mobile Application 40 6.1 Design ...... 40 6.1.1 Project Structure ...... 41 6.1.2 Agendas ...... 42 6.1.3 Navigation ...... 42 6.2 Implementation Details ...... 43 6.2.1 Screen Implementation ...... 43 6.2.2 Charts ...... 44 6.2.3 API Calls ...... 45 6.3 XML Parsing Barrier ...... 46
7 Comparison and User Evaluation 48 7.1 Development Process Comparison ...... 48 7.1.1 Project Preparation ...... 48 7.1.2 Application Development ...... 53 7.1.3 Lessons Learned ...... 57 7.2 Empirical Comparison ...... 59 7.2.1 Project Size ...... 60 7.2.2 Application Size ...... 61 7.2.3 Clean Build Time ...... 63 7.2.4 Clean Start Time ...... 65 7.2.5 CPU and Memory Usage ...... 67 7.2.6 Lessons Learned ...... 70 7.3 Survey ...... 72 7.3.1 Participants ...... 72 7.3.2 Survey Structure ...... 73 7.3.3 Tested Tasks ...... 74 7.3.4 Overall Evaluation ...... 79 7.3.5 Lessons Learned ...... 80
8 Conclusion 82
Bibliography 84
A List of Electronic Attachments 87
B Installation Manual for Developed Applications 88
C Conducted Survey 89
vi D Charts From the Conducted Survey 94
vii 1 Introduction
Mobile development has become prevalent in recent years due to an increasing number of mobile users across the globe [1]. Although many corporations and independent projects are trying to enter the mobile operating system market, to bring a better experience to its customers, iOS and Android are the only two market leaders. Together they have 99.45% of mobile operating system market share with 72.92% and 26.53% respectively [2]. It seems that nowadays there is a mobile application available for anything we can think of. Application that calculates how high users can throw their phone (S.M.T.H.1), applica- tion that lets them control a bread slice (I am Bread2) or even a dating application for their pets (My Pet Dating3). These applications may be useless, in their essence. However, it paints the picture that the development process has become more accessible to people as these applications could be created as a joke and not have real-world usage. Junák – Czech Scouting is the largest recognised scout organisation in the Czech Republic. Its roots can be traced back to 1914. Its primary role is to organise and strengthen its community relationships, espe- cially for youth members. Junák also hosts several events throughout the year that are organised on many levels, such as local, regional, nationwide or even worldwide. For members of Junák, there exists an information system which helps them to access and manage important information about the organisation, its members and events. This sys- tem is called skautIS, and it is available at https://www.is.skaut.cz. Furthermore, a recent project Pocket skautIS brings some of its core features right into its members’ mobile devices. The application is available for download in the Google Play and App Store. This thesis aims to compare cross-platform development approaches and native development approach regarding technical specifications and empirical evaluations. Instead of some generic tutorial applica- tion, we have chosen the Pocket skautIS application because it presents many useful features to its users and has an active user base. We will
1. https://play.google.com/store/apps/details?id=com.carrotpop.www. smth&hl=en&gl=US 2. https://apps.apple.com/us/app/i-am-bread/id946903436 3. https://apps.apple.com/us/app/my-pet-dating/id1489555719
1 1. Introduction
be comparing the current Native Script cross-platform development approach used for the Pocket skautIS application with another pop- ular cross-platform development approach called React Native. We only focus on Android and iOS platforms (although mentioned cross- platform approaches can build to even more platforms). We have also chosen a pure native development approach for iOS platform using the Swift programming language and native iOS frameworks. These applications need to mimic the user interface and the be- haviour as close as possible to the current Pocket skautIS application in order for us to focus only on the differences. These two new appli- cations need to be implemented first in order for us to compare our experiences with the given development approach thoroughly. We have also conducted a survey that required the participant to install the current Pocket skautIS application and the newly developed ap- plication using React Native on their device. They were given a set of tasks resembling a common application use for the average user and questions surrounding the differences between the applications. In Chapter 2, we will present the current state of skautIS, what it offers to its users and the developers. Details for development ina native environment and the cross-platform development approaches of NativeScript and React Native are described in Chapter 3. Chapter 4 talks about the current Pocket skautIS application in more detail, espe- cially the code design logic used in the project. Next, Chapter 5 states implementation details for the cross-platform application explicitly made for this thesis. Chapter 6 discusses the design and implementa- tion detail for the iOS mobile application developed using the Swift programming language. This thesis’s core is in Chapter 7, where we introduce the development process comparison, our empirical compar- ison between NativeScript, React Native, and native Swift development approaches and the conducted survey. Finally, Chapter 8 concludes this thesis and all of the studied development approaches and gives a recommendation when choosing a mobile application development approach.
2 2 SkautIS – Information System of Junák
Junák - Czech Scouting with its 67 000 members is the biggest non- governmental organization for youth education in the Czech Republic. The organization has a hierarchical structure that follows the territorial- administrative arrangement in the Czech Republic. A scout troop is a base educational group. On average, it consists of 15 to 30 mem- bers, but bigger ones are no exception. Several troops form a scout unit that provides management services and facilities to its members. Units are organized in scout districts and scout regions. To simplify the organization management, Junák uses an information system skautIS. Even though anybody can create an account within skautIS, the full access will only be granted after the account is verified by troop or unit leaders. Many of the functionalities within skautIS are only available to users with specific roles that the user’s account has to have in order to access such functionality. In this chapter, we briefly present the skautIS information system and its main agendas. Next, we discuss its web services API (Applica- tion Programming Interface) and the testing version of skautIS, used for the development purposes.
2.1 SkautIS Agendas
SkautIS started as a system for simplifying the registration process of Junák’s members over a decade ago and is continuously being developed ever since. Currently, it contains multiple agendas including unit manage- ment, events, quality assessment, grants or benefits and many others. For the purpose of this thesis, we will only talk in more detail about the agendas implemented in the mobile Pocket skautIS application. These agendas are Profile, Unit and Services. Profile agenda contains user profile information and his/her avail- able skautIS roles. Every user can also look up other people in the skautIS environment here, either by searching his unit or the scout directory. Although these pieces of information can be found in the skautIS web application under one agenda, for the mobile application, they are located in two different sections. User information is located
3 2. SkautIS – Information System of Junák
in the Profile section, and searching for people is located in the People section. Unit agenda provides information about the user’s unit. This in- formation depends on what role the user currently has selected, as one user can be a member of more than one unit at a time. This unit information includes general information about units such as name, postal address, members in functions for unit and other related units (upper and lower). This agenda can be found in the Unit section of the mobile application.
Figure 2.1: Unit agenda in the testing environment of skautIS.
The last agenda implemented in the mobile application is Services. The user can view usage statistics of his/her phone number registered in the Scout Telephone Service, book scout bases (cottages or club- houses for rent), or borrow various tools and properties offered by other units (e.g., tools, climbing equipment, or big tents).
2.2 SkautIS API and Web Services
SkautIS has its API (Application Programming Interface) available publicly at the URL: https://ws.skautis.cz/. It enables developers
4 2. SkautIS – Information System of Junák
to integrate and use skautIS data in their applications. However, it is necessary to register and obtain a unique API key. The complete list of web services is available at https://test-is. skaut.cz/JunakWebservice/. The web services are categorized in agendas and together form the back-end services for the entire in- formation system. One of the more notable categories, which most users interact with, are OrganizationUnit, UserManagement, Message, Events and Telephony. The web services implement WSDL (Web Service Description Lan- guage), which acts as an interface and descriptive language of the offered services. The communication messages use SOAP (Simple Object Access Protocol), which is strictly defined, more robust and has good support for other standards (such as WSDL) [3]. The SOAP is a type of XML (Extensible Markup Language). The messages are sent over HTTPS (HyperText Transfer Protocol Secure). The HTTPS POST requests encapsulate critical information such as a token or user id and query. The server responds to these requests with a SOAP response with a predefined response structure (or an error message) based on such given parameters. The SOAP objects and their properties are encapsulated into SOAP:Body.
1
Figure 2.2: Example of a SOAP:Body request for user detail.
In order for the server to respond, we must send a request first, which contains userDetailInput object structure with properties such as ID_Login and ID (see Figure 2.2). An example response for such a request is shown in Figure 2.3. We can see that the response contains an object UserDetailResult with properties such as ID, UserName, ID_Person and others. After such response, we typically parse this data into an object later used for application behaviour determination or data presentation.
5 2. SkautIS – Information System of Junák
1
Figure 2.3: Example of a SOAP:Body response to user detail request.
2.3 Testing Environment
Since the production instance of skautIS contains sensitive user data, there is a clone instance, which offers equal capabilities in terms of API but provides dummy data instead. The Test skautIS environment is used mainly for user training and development purposes, which is also the case for this thesis. To log in to this test environment, we can either create an account or use one of the existing accounts available at https://napoveda.skaut. cz/skautis/testovaci. As the same server logic also applies to this testing server, if we create an account we also have to be assigned a role in order to see the data. Because of this, it is recommended to use the already mentioned testing accounts. When it comes to application development, one of the most help- ful tools is testing the interface, available at https://ws.skautis.cz/ testovani. With this form, one can quickly identify the right mes- sage parameters and reduce the time needed for message debugging. The main problem with the skautIS API calls is the lack of message documentation.
6 3 Mobile Application Development
There are many ways to develop a mobile application. We can divide the development approaches into three main categories: native, hy- brid and cross-platform. In our work, we focus on cross-platform and native development approach. The platform developers prefer native development as it has access to all of the available features provided by the given platform as well as an efficient app lifecycle. The main advantage of cross-platform development is its single code base, that can be used for to generate an mobile application on supported platforms by the framework. It also outperforms the hybrid approach as it uses native platform rendering capabilities instead of rendering capabilities of a web browser provided by the platform, in case of hybrid ones. As such, cross-platform applications provide comparable efficiency (at least in theory) to native ones written in Objective-C/Swift (iOS) or Java/Kotlin (Android OS). There are also PWA (Progressive Web Applications) which are considered only a browser wrapper and not a standalone application. Because of this, it suffers from the browser rendering deficiency. There are also some limitations regarding accessing various mobile sensors, which may not be available on some devices. Another downside is that it does not have good compatibility with iOS devices as it lacks the proper platform support, like native or cross-platform approaches have. In the reminder, we focus on the native and the cross-platform ap- proaches in more details, presenting their core features, development and technology stacks.
3.1 Native Approach
The native approach means developing with tools and programs de- signed (or endorsed) by the platform developers. For example, Ap- ple’s preferred programming languages are Objective-C and Swift. The company not only provides the compilers but the whole ecosystem for developers including the Xcode1 IDE (Integrated Development
1. https://developer.apple.com/xcode/
7 3. Mobile Application Development
Environment) and the whole pipeline for testing (TestFlight) and publishing (Apple Developer Console) the applications. Similarly, the native approach for Android application develop- ment includes Android Studio2 and supports Java and Kotlin pro- gramming languages. There are ways to get around using the endorsed programs. For example, Apple allows us to download Xcode command-line tools that let us bypass the native IDE (integrated developing environment) and enable programming primarily through the command line. An- droid suggests using JDK (Java Development Kit), Android SDK and Android SDK Platform for command line usage.
3.1.1 Native iOS Application Development
Objective-C is a programming language adopted by Apple in the year 1996. This was because Apple acquired NeXT for the purpose of using its operating system on their computers. Apple slowly but surely pushes Objective-C out of the picture nowadays. The programming language is still supported, but there is more emphasis on native development using Swift3, which was introduced in 2014. Objective-C and Swift can co-exist in the same project, but Swift has many syntax friendly features and improvements over Objective-C.
Swift Swift is an open-source programming language developed by Apple, known primarily as a language used for creating applications and software for their products. It was developed as a replacement for Objective-C due to its lack of modern language features. Some of Swift’s features were naturally influenced by Objective-C, such as dynamic dispatch or late binding [4]. Although Swift was designed to be comparable in performance to C-based languages, it also has a big emphasis on the safety part of the language. For example, variables are always initialized before use, arrays are checked for overflow and memory is managed automati- cally [5].
2. https://developer.android.com/studio 3. https://swift.org/
8 3. Mobile Application Development
One of the safety features of Swift is its use of nil notation. Objects with a value of nil cannot access its properties and methods. This will result in a compile-time error. However, Swift has a feature known as optionals. If we use a nil object, it forces us to indicate the compiler (with symbols ? and !) that we are confident and understand the behaviour of such action.
Xcode As mentioned, Xcode is the primary IDE for developing software for all Apple devices and operating systems (macOS, tvOS, watchOS, iPadOS). Xcode supports many popular programming languages such as C++, Java, Python but mainly Objective-C and Swift. It also has an integrated source code management (version control) based on Git4, profiling and debugging features, which allows the developer to control his source version from user interface and see the changes right in the code files. Xcode offers many features for its native development projects that may not be provided in other popular IDEs. For example, a crash or- ganiser enables the inspection of individual crashes of the applications available in the App Store. The provided information includes the thread stack, including the underlying errors and additional statistics, such as crash rates on different iOS versions and devices. These crash reports are also traversable as if the error occurred while developing the application. It also offers an interface building tool called Interface Builder5, which provides an easy, user-friendly way of designing the applica- tion user interface, enhanced with features such as basic interaction among the interface components (e.g., pushing specific view onto the navigation stack when a button is pressed). Furthermore, Xcode ver- sion 11 introduced SwiftUI6, which takes the interface building even further and provides a live preview of the application (see Figure 3.1). This is especially useful because we no longer need to compile the application in order to interact with the user interface.
4. https://git-scm.com/ 5. https://developer.apple.com/xcode/interface-builder/ 6. https://developer.apple.com/xcode/swiftui/
9 3. Mobile Application Development
Figure 3.1: Example of a simple SwiftUI project in Xcode.
iOS Architecture Structure
Apple divides its structure into four main layers (see Figure 3.2): Core OS, Core Services, Media and Cocoa Touch. Each layer has a specific purpose and hosts several frameworks in order to interact with them. Core OS layer is responsible for communicating with the hardware of the underlying device such as gyroscope, Bluetooth and external accessories. This layer also handles power management, security and many of the lower-level programming features. Core Services is responsible for providing network operations, auto- matic reference counting (also known in other languages as a garbage collector), string operations and other data formatting functionality. It also provides file access and threading features to programmers. Media Layer handles media playback as well as recording and edit- ing of audiovisual media. It is also responsible for rendering 2D and 3D graphics as well as animation. Cocoa Touch is a layer in which most of the user interaction hap- pens, handles gestures, touch events triggered by the user, overall visualisation aspect of the application and its behaviour.
10 3. Mobile Application Development
Cocoa Touch UIKit Media
Core Services Foundation Core OS
Hardware
Figure 3.2: Layer of iOS architecture.
Foundation Foundation is an Objective-C framework used extensively in many Swift projects mainly for its implementation of essential functions and data types [6]. This framework includes classes like:
• Object, • Array,
• String, • Dictionary,
• Number, • and many more.
Foundation’s framework essential functions include:
• date and time calculations, • text processing,
• sorting and filtering, • networking,
• data storage, • and many more.
UIKit Arguably the most important thing about a mobile application or any application aimed to satisfy the user in that sense is the user interface.
11 3. Mobile Application Development
In the iOS environment, this function is derived mostly from UIKit framework [7]. This framework provides the necessary infrastructure in iOS ap- plications. It supplies the event handling for Multi-Touch inputs in apps, most notably view and window architecture for implementing the user interface. UIKit’s framework most essential classes include: • View, • Label,
• ViewController, • Image,
• NavigationController, • and many more.
3.1.2 Native Android Application Development
Android7 is a free, open-source operating system intended for mobile devices. It was introduced in 2007 by Open Handset Alliance which was commercially supported by Google. Android is built upon Linux kernel with many libraries and APIs written in C and many application frameworks which include Java-compatible libraries. Android still natively supports programming in Java API, but lately, there have been many steps to encourage developers to switch to Kotlin. Contrary to popular belief, Android does not use JVM (Java Virtual Machine). Instead, it uses ART (Android Runtime) which transforms the application’s bytecode into native instructions. After this, the instructions can be executed by the Runtime Android Environ- ment. Java and Kotlin can co-exist in the same project, but Kotlin has many user-friendly features and syntax improvements that Java does not have.
Kotlin Kotlin is an open-source programming language developed by Jet- Brains8 (Czech software development company), known as a lan- guage for programming applications for Android devices. Although Google initially supported only Java for Android applications, they
7. https://developer.android.com/ 8. https://www.jetbrains.com/
12 3. Mobile Application Development
have shifted towards Kotlin in late 2017 and have been pushing and endorsing its use in Android Studio ever since [8]. Despite this, Kotlin is mostly known as a programming language for Android development. It can also be used for web development, data science and server-side development [9]. Kotlin also supports many similar developer-friendly features like Swift does. For example, run-time type inference that does not force the developer to specify the expression type at compile-time, or the null pointer exceptions and emphasis on the overall code safety. Even though the idea behind it is fundamentally shared between these two languages, the code execution differs. Thanks to Kotlin Mobile SDK, Kotlin can also be used to build an iOS application and can even use its native API, and thus can be considered for a cross-platform development [10].
Android Studio Android Studio is a native IDE made by JetBrains specifically for Android development. It is available on macOS, Linux and Windows operating systems. Its indirect predecessor was a plugin for Eclipse IDE called Eclipse Android Development Tools (E-ADT) which came to a halt in 2015. Android Studio offers many features popular in other IDEs such as syntax highlighting for many programming languages, code com- pletion or a code version control through Git. It also has an excellent Android Virtual Device (emulator) integration with a built-in user interface, where the developer can choose from many Google devices and its versions to run and debug the application. The emulator sup- ports mocking many features that are accessible only on physical devices, such as simulating location points as if the device was used in a car, simulating special predefined sequences of tilting the device, slow network simulation or even accessing the camera (in this case a webcam if one is accessible to the computer). Android Studio also supports many popular programming languages (e.g., Java, C++, Kotlin and Go). Like Xcode, Android Studio also has its tool for a visual representa- tion of elements and their relation to other elements. It is called visual layout editor, and it offers the developer to see (before compiling) how
13 3. Mobile Application Development
the given screen would look on a particular device. It also offers to set constraints for each element (e.g., its width, height or constraints related to other elements such as margin).
Figure 3.3: Example of layout editor in Android Studio.
A great feature included in the Android Studio is the APK9 Ana- lyzer. The analyzer helps to determine what components of the final projects take up the most amount of space. This is especially useful when trying to optimise and cut down on the final application size. The APK analyzer allows comparing two different versions of the same application even if they were not created using Android Studio.
Android Architecture Structure Android divides its platform into four main layers: Linux kernel, Hard- ware abstraction layer, Libraries, Application Framework and System Applications. These components are visually represented in Fig. 3.4. Linux kernel is the foundation for Android platform. It provides many functionalities on which the higher level relies on (e.g., ART).
9. APK (Android Package Kit) is a file format for applications that are meant tobe installed on Android devices
14 3. Mobile Application Development
System Applications Application Framework
Libraries ART Hardware Abstraction Layer Linux kernel
Figure 3.4: Layers of Android architecture.
Android takes advantage of many key security features and allows device manufacturers to develop drivers for known the kernel. Hardware Abstraction Layer provides an interface for hardware capa- bilities to the upper layer (Libraries). It is also responsible for commu- nicating with hardware such as camera, Bluetooth, audio and many device sensors. Libraries layer contains native C/C++ libraries including OpenGL, Webkit. One of the main library is ART responsible for running each application in its own virtual instance specialised for low memory consumption. Application Framework offers an entire feature set of Android oper- ating system, most notable parts of this components are View System, Activity Manager, Resource Manager and Content Provider. System Applications layer include preinstalled applications for mail, SMS, calendar, dialer and more. These applications function both as applications for users to provide such capabilities, but also for the de- veloper (e.g., invoke mail application with the predefined recipient).
Android Layouts
The building blocks for developing applications and their design for Android devices are its layouts. They define a user interface structure and its elements. All the layout elements are build upon the View and ViewGroup objects. The View typically defines something that the user
15 3. Mobile Application Development
can see, ViewGroup is a container that can define a layout structure of other Views or ViewGroups. Two of the most used layouts are Linear layout and Relative layout. The former organises its children into horizontal (or vertical) rows, depending on a given attribute. If the content is larger than the length of the screen, it creates a scrollable view. The latter enables the devel- oper to specify a relative location, relative to each child or other layout objects (with given constraints).
3.2 Cross-platform Application Development
The cross-platform approach to mobile application development fo- cuses on the idea that we use the same codebase to build applications on different platforms. In general, cross-platform application develop- ment widely depends on the chosen framework or toolset, since there is no clear path to the result like in the native approach. In this section, we present two popular JavaScript frameworks for mobile cross-platform development. Although they share a common language, there are fundamental differences in their development paradigm and usage.
3.2.1 NativeScript
NativeScript is an open-source framework developed by Progress that allows the developer to translate his JavaScript (or TypeScript) code into the native code for Android, iOS and web platforms [11]. Its main strength is that it allows for many plugins and customisa- tion for the developer right out of the box. It even lets the developer choose a back-end framework that he wants to use for his application development. Suppose he wants to build robust, well optimised appli- cation with full access to platform-specific API’s. For this he can choose Angular. On the other hand, if he likes the app to be lightweight, he can use Vue.js. This framework is built upon five major parts: Runtimes, Core Modules, CLI and Plugins [12]. Runtimes enable using JavaScript code for native API calls in the Android and iOS frameworks. For them to work this way, they use JavaScript Virtual Machines, Google’s V8 implementation for Android
16 3. Mobile Application Development
Figure 3.5: NativeScript framework – high-level overview.
and WebKit’s JavaScriptCore implementation for iOS (available only for iOS 7.0 or greater). Core Modules are responsible for the most important thing for the whole operation. They transform the underlying JavaScript code to the respected native code for the given platform. The second important feature is that they provide an XML-like way for defining UI elements in the code.
1
Figure 3.6: Example of XML-like definition of Native Script elements.
Figure 3.6 shows how one could make a simple label and a button in Native Script using an XML-like syntax. The label will show a string stored in the message property of the component. The specified button will show a string tap me and will trigger a function onTap() of the given component when a tap event on the button is triggered.
17 3. Mobile Application Development
Data Binding Data binding is a core concept of Native Script [13]. It allows the developer to specify a connection between the data model (i.e., prop- erties and values) and UI (i.e., View). Data binding can occur in three different manners: One-way, One-way to source and Two-way. One-way data binding is the most common method when we need to pass some visual information (stored in the model) to the UI for presenting. The data binding is placed inside the square brackets []. In Figure 3.7 the label text property is data-bound to the given component’s message property. Meaning that every time a message property changes, the label’s text property is also updated with the appropriate value.
1
Figure 3.7: Example of One-way data binding.
One-way to source data binding is best explained on an event like a button click. This type of binding updates the model as a response caused by some action in the user interface (like a button click). The binding is marked within round brackets (). In Figure 3.8, we can see a button which has a binding for tap action that triggers a onTap() function on the appropriate component.
1
Figure 3.8: Example of One-way to source data binding.
Two-way data binding combines two previously mentioned data bindings. A good example of this binding is using it on a text field, because we would want to bind our property to the text in the text field and for example, in the same time be notified when the user ended editing the text field. This binding is visualised inside the appropriate element with square brackets [] and round brackets () inside. In Figure 3.9, we can see a two-way data binding to the property text inside a text field component to be bound to the component’s message property.
18 3. Mobile Application Development
1
Figure 3.9: Example of Two-way data binding.
Native Script needs more than just a XML-like syntax, that is just for a specification on how the View should look like. Generally these View specifications (like in Figure 3.6) are stored ina .html file, the logic is in Typescript (.ts) or Javascript (.js) file named accordingly.
3.2.2 React Native
React Native is a JavaScript framework that runs on ReactJS. Both of them are open-source projects developed by Facebook Inc. ReactJS is a popular JavaScript library for building user interfaces without the typical extensive boilerplate [14]. Its power lies in the fact that the developer only needs to write the code once and easily build it for all platforms. React Native enables us to access native platform-specific APIs using JavaScript code. It also lets us specify the appearance and be- haviour of our UI seamlessly for every platform with one code. Be- cause of this, there may be times where the native components work differently on each platform [15]. For example (as this was the case with this project) alerts and alert styling. iOS natively allows an unlimited number of buttons inside its alerts, but Android only allows no more than three. The solution we used was platform-specific custom alerts. For iOS we used the native solution, and for Android, we used DialogAndroid from library react-native-dialogs [16]. This solution allowed us to have an unlimited number of buttons inside alerts for both platforms and thus make a similar user experience for every user despite their choice of platform.
JSX The most crucial component in React used heavily in React Native is probably JSX (JavaScript XML). The compiler transforms this XML- like structure into pure React code [17].
19 3. Mobile Application Development
Cat Cafe Menu ViewGroup Cat Cafe Menu
ImageView TextView Maru Maru Spot Spot Pouncival Pouncival Pouncival Rum Tum Tugger Rum Tum Tugger Tabby Tabby Tuna Tuna UIImageView UITextView Mrs. Norris Mrs. Norris UIView Choupette Choupette
Figure 3.10: Representation of native layout components for each plat- form.
1
Figure 3.11: JSX example of custom Button object.
1 React.createElement( 2 MyButton, 3 {color: 'blue', shadowSize: 2}, 4 'Click Me' 5 )
Figure 3.12: JSX code from Figure 3.11 transformed to JavaScript by compiler.
20 3. Mobile Application Development
We can use variables inside JSX just like we would in a standard JavaScript code. Anything between curly braces in JSX will transform into JavaScript expression, including event function calls. JSX is a part of a React library, so in order to use it in our project we have to import it like so: import {React} from ’react’;.
Properties By defining the object using JSX, we can then create the object with
1 const Car = (props) => { 2 return( 3
Figure 3.13: JSX code example that uses properties.
State We can also use properties inside to object that changes over time. For example, if we have one Car object that displays the car speed, but after a button is pressed, we would like to present speed property changes. To achieve such run-time changes and see the rerendered object, we need to use UseState, which is also a part of the React library. UseState offers two accessible properties, one for accessing the value and one for changing the value. In order to declare such proper- ties use syntax like this: const [speed, setSpeed] = useState(100). In this case we have also provided a initial value of speed = 100 by stating it in the parameters of useState(). With this in mind, we can present the car speed such as in Figure 3.14. Writing the code in this way lets can change the value of speed, for example by taping on a button, such as in Figure 3.15.
21 3. Mobile Application Development
1
Figure 3.14: JSX code example that uses useState().
1
Figure 3.15: JSX code example that gets the value from useState().
Layout and Styling React Native styling definitions looks like a simple CSS (Cascading Style Sheets) definitions. Style definition adopts many similar aspects from CSS and lets the programmer define a style as he would define a style for an element in CSS.
1 header:{ flexDirection: 'row', width: '90%', height: 1, backgroundColor: 'gray'}
Figure 3.16: CSS style definition for separator (header) in tables.
Figure 3.16 shows a real example used in the project. It defines a style for separator in a table in order to divide each table cell content. It also shows an important property flexDiretion for item positioning in relation to surrounding elements. This could be somehow familiar to a person who defined styles in CSS. Flexbox (Flexible Box) isan essential part of almost every web defining style. We can easily define layout in a readable way (in contrast to just defining layout as points and sizes on a surface). The content inside an element can be laid out easily with property named justifyContent, as shown in Figure 3.17. It shows three views with two of the most popular layout styles, the equal spacing between elements and all elements together flexed at the start. If we wanted to define the same layout but flexed in a horizontal direction, wewould just set flexDirection to horizontal and the laid out outcome would be the same (but in the horizontal direction of course).
22 3. Mobile Application Development
Figure 3.17: Justify content examples in Flexbox layout.
23 4 Current NativeScript Mobile Application
The Pocket skautIS is a cross-platform application implemented using the NativeScript framework. It aims at bringing selected functions of the skautIS information system into the mobile devices of its users. This section describes its features, current structure, what tools the projects utilises, its flaws, and where the future improvements could be made.
4.1 Design
The current version of the Pocket skautIS implements the following features:
• messages (message detail, • scout units details, deletion), • person search and per- • settings and expenses of son details (including con- phone numbers in Scout tacts), Telephone Network.
However, further features are being incrementally implemented. Not all of the features from skautIS are available in the application. This is because not all of the functions that skautIS offers make sense to implement in the mobile application for users. For example, searching for person contants is a great feature, and it makes sense to have such a feature available on a mobile device. However, features like view- ing grants or quality assessments do not make sense to be accessible through a mobile application. As Pocket skautIS is not a finished product and is still improving with the given technology and user input, many more features may be implemented in the future.
4.1.1 Project Structure
The project is structured into five main folders: constants, resources, pages, core and shared. Each folder has a different purpose and is self- defined from its name.
24 4. Current NativeScript Mobile Application
Project structure
constants resources pages core shared
Figure 4.1: Diagram of first layer of the Pocket skautIS project structure.
The constants folder comprises of the many unchangeable con- stants for the project to work. Most notably the application identifi- cation token, which is used to authenticate each server call and thus the server knows from which application the call came. Other notable constants in this segment are constants for day parsing, age segments or range types. The resources folder contains all of the needed platform resources in order to run the application. Mainly configuration files needed for given platform and pictures, such as application icons, menu icons or even a splash screen. Each platform has different constraints for such a configuration file, and they need to follow such standards. The pages folder is the largest one by the number of files. It con- tains all the necessary files for each screen (page) in the application classified by which page they belong. In every page, there are three main parts: containers (physical representation of the given view), enti- ties (input/output structures used in communication with the server) and state management (defining behaviour for each view and given state). Components used throughout the project can be found in the shared folder, for example, item-picker or the main menu. There are also many pipes in this folder. Pipes are used for formatting data pri- marily to a more user-friendly format, for example, dates are typically formatted in DD-MM-YYYY (day-month-year) format. In the core folder, there are mainly core functionalities used through- out the project. For example, entities (input/output structures) that are used in more places of the project. Service and all communica- tions with server and server responses are also defined here with appropriate state management surrounding these server calls.
25 4. Current NativeScript Mobile Application
4.1.2 Agendas
The project implements four agendas which can be found in the navi- gation bar at the bottom of the screen. The agendas are: Profile, Units, People and STS (Scout Telephone Service).
Figure 4.2: Profile (left) and Unit (right) agendas in the Pocket skautIS application.
Profile agenda is the default screen to which the user is redirected after logging in. It contains personal details (e.g., name, profile pic- ture), current active role and the list of recent messages. A user can access message details by tapping them. Unit agenda is the second section from the left. It shows (by de- fault) current unit which user has selected a role for in his profile. There are many unit details such as unit name, billing address, contact information, people in function and other related units. User can view other unit details by selecting the given unit, which will prompt the user to a new screen with the given unit details. The similar redirection will be triggered if the user taps on a given person, it will redirect him to the person detail screen.
26 4. Current NativeScript Mobile Application
Figure 4.3: People (left) and STS (right) agendas in the Pocket skautIS application.
In People agenda, the user can search for a particular person. By searching a query, the application will show a screen with results to the given query. These results are in the form of a list and cells contained the list. By clicking on a given cell, the user will be redirected to the given person detail screen. The last one is the STS agenda. Where the user can find statistics about his telephonic spending from the last three months of using it. It is grouped by telephonic number and aggregated by three months. There is also a bar chart which helps the user with visualisation of the presented spending. The right-most menu item invokes a side menu that contains gen- eral information about the application, currently selected screen and a logout button.
4.1.3 State Logic
State logic for mobile application is standard practice when more application classes (screens) need a common state to reflect on or
27 4. Current NativeScript Mobile Application
define their state’s logic. In such a case state logic is shared within these classes and always has just one state at a particular time. These classes need to subscribe to the state and, for example, define their logic when the state changes its value. A good real-world example would be an application that stores a state of a user profile (e.g., name, address or gender) and hastwo screens which reflect on such state (displaying current user name). Now if the name changes those screens need to know that the name was updated, and thus they do this by subscribing to the user profile state and define their behaviour (update the name to a new name) when the state is updated. Although the state management is present in almost every page sub-folder (in order to reflect state at a particular page), the whole ap- plication state management could be found in the core folder. Pocket skautIS project uses ngsx state management pattern library for An- gular [16]. This pattern is a common practice for more prominent applications and projects, which for now may be an over-complication for Pocket skautIS. However, as the application is continuously evolv- ing and is being developed, it is certainly a good foundation for the future.
4.2 Issues
Many applications suffer from problems, either by poorly chosen design pattern or wrongfully implemented functionality from the developer. In the next sections, we will further discuss potential prob- lems with this application that may impact overall user satisfaction and possible resolutions for these issues.
4.2.1 Navigation
The odd thing about Pocket skautIS navigation is that, when the user is browsing unit details in the Unit segment of the bottom navigation and taps on some person listed in the details. Person detail screen is pushed onto the navigation stack, which is a common practice. The problem is that the selected item on bottom navigation bar changes from Units to People. This is an odd practice. Navigation items
28 4. Current NativeScript Mobile Application
Figure 4.4: Demonstrating problem with bottom navigation in current Pocket skautIS application. should not switch on itself. They should be only switched by the user interacting with the navigation bar directly. It is demonstrated in Figure 4.4, where on the left we can see that the user is looking at a unit details in the Unit section, but after clicking a given person (Mesl Jan) in the person in function, the bottom navigation bar changes its selected item (see Figure 4.4 right).
4.2.2 Empty State
Standard practice for mobile application development is implementing an empty state for UI elements, particularly tables and texts. This is in order to make the user accustom to the fact that in a normal circumstance, there should be some data displayed on the screen. However, for some reason (e.g., the user has not provided appropriate data to the system) the application cannot show the data. Figure 4.5 demonstrates a lack of empty states of the UI elements in Pocket skautIS application. This figure shows an empty profile screen on the left and empty unit screen on the right. Empty places on screen
29 4. Current NativeScript Mobile Application are not always a bad practice, but in this case, the user could feel that the screen is not fully developed (while this is not the case, it just lacks the needed data for display).
Figure 4.5: Pictures from Pocket skautIS demonstrating lack of empty state.
The empty unit screen shows an empty template for the unit. There are Email/Web/Telephone placeholders but no actual data comple- menting them. We would suggest tackling this problem with an empty state that covers the whole screen and talks about the problem that occurred (e.g., "There are no data for your unit to be displayed, please fill them out first"). There is another flaw in Figure 4.5 (right). The problem lies inthe fact that unit detail is only shown when the user taps on the unit icon in the bottom navigation and the item is then selected. However, in the picture, we can see that the user has selected profile item in the bottom navigation. This unpredictable navigation behaviour could be linked to an empty state problem, as this is not the case when the user has unit details data available. A good example of an empty state is the profile picture (see Fig- ure 4.5). We can see that the user has not provided any custom picture
30 4. Current NativeScript Mobile Application
to the server. Thus the user has a placeholder (empty state) as a re- placement. This should also be the case in other UI elements.
31 5 Implementation of the React Native Mobile Application
This chapter presents the implementation details of the first mobile application built for this thesis. This application uses the React Na- tive framework (discussed in Sec. 3.2.2). To make the project easily understandable for anyone who takes a look at it (and does not have to know React Native) we have chosen a strategy, where everything that belongs, or is related to the given screen is in the same file as the screen definition itself. This approach also emphasises the ability of React Native to have everything all together. The screen file could include styling, API calls, screen definition, decision logic and many more. Of course, sometimes it does not make sense to keep redefining the same style of elements in every screen. Thus, the shared parts of the code (e.g., a root view styling definition) were separated and only used as a reference toa given styling file. This application was developed with an intent to resemble the Pocket skautIS application.
5.1 Design
The current Pocket skautIS application is heavily influenced the React Native application interface design. This was done in order to mimic the visual aspect and behaviour of the current application. Thus we could only focus on the main differences between application devel- opment and outcomes in the comparison part of this thesis. Figure 5.1 illustrate the similarities between the two applications on the main profile screen. We can observe that both layouts ofthe screens are almost identical (except for the page title missing in the React Native application). However, we can observe noticeable differences when comparing individual elements. For example, a profile picture has a circular shape in the Native Script application, while the React Native one has a square shape. We made such subtle changes in the visual appearance
32 5. Implementation of the React Native Mobile Application
Figure 5.1: Profile screens for React Native and Native Script applica- tions. purposefully to avoid confusion about which application the user is currently using.
5.1.1 Project Structure
Contrary to the user interface design, the project structure is notably different from the original Pocket skautIS project. The main project structure consists of three subfolders: constants, communication and screens. Constants folder contains application-wide constants such as skautIS server URLs, user keys for information storing, colour palette and global style formats. Communication folder contains an API call parsers, user authenti- cation and input/output structures used within the server communi- cation. The screens folder contains all the appropriate visual screen def- initions and decision logic for its components. The folder is further
33 5. Implementation of the React Native Mobile Application
Project structure
constants communication screens
Figure 5.2: Diagram of first layer of the React Native application project structure.
divided into four sections that contain appropriate screen definitions for the given sections.
5.1.2 Agendas
In order to extensively compare the cross-platform mobile develop- ment, this application needs to mimic the behaviour of the current Pocket skautIS application. This means that it also has to implement all the underlying agendas that are implemented in the application. To provide equivalent functionality to the Pocket skautIS, we have implemented all features in each agenda, except for some features in the STS agenda. This is because, at the time of creating this application, not all of the necessary data was present in the STS agenda in the Test skautIS. Nevertheless, this does not have an effect on the comparison, because we are comparing them on the same testing environment, so if the data is not available, it will not be displayed even in the current Pocket skautIS application.
5.1.3 Navigation
In the React Native application, there is one navigation menu present at the bottom navigation bar, as shown in Figure 5.3. The user can navigate to any section by tapping the appropriate icon, which will
34 5. Implementation of the React Native Mobile Application
replace the current navigation stack with the one corresponding to such section.
Figure 5.3: Bottom navigation bar of the React Native application.
The application will never redirect the user by taping a selected element in a section, that will redirect him to the other section and then push a particular screen onto the navigation (a problem which sometimes occurs in the current Pocket skautIS application, mentioned in Section 4.2). If the user wants to step back in the navigation (by taping the previous section in the bottom navigation bar or an arrow in the top left corner), the application will not reset its current navigation stack but will preserve its context and show the previous screen.
5.2 Implementation Details
Implementing the Pocket skautIS application using the React Native framework was a straightforward process with only a handful of bar- riers we needed to overcome. The back-end part is inspired by the existing Pocket skautIS application due to the similar approach and common JavaScript programming language. However, the front-end (UI) part was built from the ground up using standard React Native libraries for most of the UI elements. Although sometimes we were not satisfied with them, and thus we opted for the ones created by its community. In order to use community-based libraries in our project, we used the NPM1 (Node Package Manager).
5.2.1 NPM Libraries
The whole list of library dependencies could be found at the root folder of the project structure in file package.json. Further, we present examples of the three most significant UI libraries we used in this project.
1. https://www.npmjs.com/
35 5. Implementation of the React Native Mobile Application
Icons The most used library throughout the project is react-native- ionicons [18]. The library provides icons across the whole application. In order to use icons, we put the XML-like syntax specifying the icon identifier such as
Dialogs We wanted to present an alert messages with multiple op- tions (buttons) available to the user. Since native alerts on both plat- forms (iOS and Android) work differently (see Section 3.2.2, we opted for the use of the native React library for iOS platform and the com- munity library react-native-dialogs for Android OS [19].
Charts React Native does not offer native support for displaying charts. Since we wanted to show the user a representation of some data, not only in the form of a text, but also visually, we needed some library for a simple chart showcase. We used react-native-chart- kit [20], which provides many customisable chart templates. We used pie chart mainly for visualisation of unit’s registration numbers and bar chart spending visualisation.
5.2.2 API Calls
Almost every screen in this application uses API calls to retrieve data, that is then presented on the screen in the form of a text or a chart. To achieve the best user experience, we need to trigger the API call before the screen is presented (so in time the screen is presented, some data could already be loaded). If the data is not loaded by the time the screen is presented, the application shows a standard loading indicator. The API server uses SOAP standard in every API call (for both input and output structures). This is not that typical solution for API calls in mobile applications. Javascript can only convert its objects into JSON (JavaScript Object Notation) by default, so we had to make some tweaks in order for the React Native application to work with such SOAP standard. Figure 5.4 shows an example API call. This code retrieves messages for the user from the server. The data to send to the server resides in
36 5. Implementation of the React Native Mobile Application
1 fetch('https://test-is.skaut.cz/JunakWebservice/Message.asmx',{ 2 method: 'POST', 3 headers: { 4 'Content-Type': 'text/xml; charset=utf-8', 5 SOAPAction: 'https://is.skaut.cz/MessageAllWeb' 6 }, 7 body: getEnvelope(input, 'MessageAllWeb'), 8 }).then((response) => response.text()) 9 .then((response) => { 10 parseString(response, function (err, result) { 11 parsed = parseResult(result, output); 12 }); 13 });
Figure 5.4: Simplified example API call that returns all messages to given user.
the input object, where we can find properties like APP_ID, userToken or read property, which indicates if we want to retrieve all messages or just the ones user has not read yet. The code is simplified, because not every API call on the test server has the same response structure. Thus additional parsing needs to be done before we can parse the result in a general way using function parseResult(). Function parseString() (also seen in the Figure 5.4 on line 10) is a function from library called react-native-xml2js, that helps with transforming XML into JSON.
5.2.3 Empty state and error response
This application supports empty states and server error responses to better inform the user about the state at which his request is. For example, every list in this application has an empty state, which is shown to the user when a request has been successfully parsed, but there are no list items to display (see Figure 5.5, left). Many requests could also end with an error. E.g., when a given user does not have permissions for such action or the request is malformed. The application tries to check every response for such an error first, and when found, the application displays an alert with appropriate text (see Figure 5.5, right).
37 5. Implementation of the React Native Mobile Application
Figure 5.5: Empty state (left) and error response (right).
5.3 Future Improvements
This application was primarily created with the intent to compare the development approach of React Native to NativeScript (see Chap- ter 7). Despite its primary intention, it can also be used for future improvements or even potentially replacing the current Pocket skautIS application. With this in mind, there are two areas that the React Native appli- cation could be improved: an application reset and edge API cases.
5.3.1 Application Reset
The server can respond to any API call with an error message indicat- ing that the user token has expired (in other terms, this means that the user has been logged out). The application is refreshing its user token every twenty minutes (user token lasts thirty minutes), which is a standard practice among mobile applications. This is in place, so the user does not have to log in (and receive another token) when he currently uses the application.
38 5. Implementation of the React Native Mobile Application
However, if the user has not interacted with the application for more than thirty minutes, there is currently no way to refresh that user token. Thus the user has to go through the login process again in order to use the application. This behaviour is in place because of strict security reasons. Thus, if the application receives an error indicating that the user has an expired token, the application resets to its initial state. This could be done in a better way even with current navigation setup in the project. Instead of using hard reset for the application, we would delegate the information that we want to show the initial login screen to the appropriate navigation stack, that would than pragmatically segue back to the initial state.
5.3.2 Edge API Cases
Another area where we suggest future improvements is API edge cases handling. For now, there is only limited API call verification for each response. Essentially, we only check the user’s permissions and the token expiration. If some needed permission is missing, we only display a general message. We need to do it in this way because the server does not send a user-friendly text that could be presented instead. There are two possible ways to overcome this problem. First, to implement the error states, its types and structures on the server-side. Second, to implement an extensive error handling in the API parsing code of the application. Both options provide a similar outcome, that would be a more robust error handling from the application. However, we would suggest that the server could define and implement some error structures so that the application could check if the predefined error occurred. Such predefined error could then be shown to the user in the form of an alert, or not at all. This could be done in the form of a property sent from the server, which would indicate whether the alert needs to be shown or not.
39 6 Implementation of the Swift Mobile Appli- cation
This chapter presents the implementation details of the second mobile application built for this thesis. It was an iOS application programmed using the Swift programming language. The decision to implement a native iOS application over the Android one was made because the thesis author has extensive knowledge of the iOS development environment from prior work experience. Implementing a native application for the thesis was also needed for the comparison of cross-platform and native approach. To not overwhelm this thesis with implementations, we have chosen only to implement a subset of functions that the cross-platform application offers. These were mainly People and Unit agendas, as they hosted most of the data content.
6.1 Design
The application design is similar to the current Pocket skautIS applica- tion. We have tried to mimic the colour pallet used in this application as best as we could. We used the same picture resources.
Updates View Sees
Model User
Manipulates Controller Uses
Figure 6.1: Model-View-Controller diagram.
This iOS application uses an MVC (Model-View-Controller) pat- tern. A standard pattern for developing user interface applications. The MVC separates views from the application logic and a controller for decision making. Figure 6.1 shows a simple diagram showcasing dependencies among each of the development pattern sections.
40 6. Implementation of the Swift Mobile Application
The basic idea behind theView sections is that it only displays the data given to the View from the Model. The View than updates its UI components to appropriate data from the Model that is then shown to the user. The Model is responsible for handling the data. Such handling could include API calls, data management or even functions triggered after gesture handling. These triggers should be only called from the Controller, and after processing such request, the Model should update and send the information about the update to the View. The Controller is responsible mainly for handling the user interac- tion and passing that data to the appropriate Model. In many cases of real MVC application development, the Controller is also responsible for handling navigation. With MVC in mind, the user only sees what the View is presenting to him and can only interact with the Controller. This helps to make the application more robust, future proof, easily scalable, and with this, each section has its given purpose.
6.1.1 Project Structure
The project is structured into three main parts: Screens, Communi- cations and Extensions. All of them reside in the project root di- rectory. There is also a Constants.swift file which contains various application-wide constants (e.g., token, colours and strings). Screens folder consists of all the necessary views, controllers and models that make up the whole application. Almost for every screen, there is also an associated controller and view model. These together enforce the MVC pattern throughout the application. Some of the objects do not need every component. E.g., TabViewController.swift is responsible for bottom tab navigation and does not need a specific view or view model as it only has a static representation. Communications folder contains API service and Authentication. API service is responsible for sending and receiving API calls along with mild error handling. Authentication is responsible for user token handling and refreshing. There are also input and output structures located in this folder. Extensions folder contains extensions to classes that make the pro- gramming experience better, e.g.,ColorExtension.swift which helps
41 6. Implementation of the Swift Mobile Application with easy initialisation of colour object using hexdecimal notation. UserDefaultsExtension.swift is also important because it defines easy access to stored properties, which are accessible even after the application is killed.
6.1.2 Agendas
We have only chosen two of the agendas: People and Units. As for these two agendas, the application tries its best to mimic (only in UI sense, development process and patterns used are different) the current Pocket skautIS mobile application, for the purpose of comparing them. We have chosen these two agendas because many tables, images, and information could have different visual and behavioural charac- teristics in native and cross-platform development.
6.1.3 Navigation
For this application, we have chosen to separate the navigation into two individual parts. First one is the login navigation, which takes the user through the login process. If the login process ends successfully, the user is redirected to the main application navigation. This is beneficial when the application is restarted, and the user has still valid login token. As a result, the login process is hidden, and the user lands on the main application navigation. Similarly, if the user logs out (either through error form API call or a user triggered logout), the application will prompt the user back to the login process navigation.
1 func osobyTap() { 2 guard let id = viewModel?.detail?.ID else { return } 3 let viewModel = ClenoveJednotkyViewModel(id: id) 4 let controller = ClenoveJednotkyViewController(viewModel: viewModel) 5 navigationController?.pushViewController(controller, animated: true) 6 }
Figure 6.2: Navigation push example from the project after the user taps on unit functions.
42 6. Implementation of the Swift Mobile Application 6.2 Implementation Details
For development, we have used the latest Xcode version 11.7 (at the time of the development). We settled on targeting only devices that have iOS version 12.0 or higher, this was, at the time of development, the iOS version supported by the majority of user’s phones (90% of iOS users has at least iOS version of 13.0) [21]. In contrast to the cross-platform application using React Native framework, this project only uses native iOS solutions directly. It uses Swift 5 as a programming language. There are only two frameworks used within the project: UIKit and Foundation (more details about the frameworks are in Section 3.1). There is also Cocoapods used within this project. Cocoapods is a dependency manager for Swift and Objective-C projects that houses many useful community libraries [22]. We have only chosen Charts library, to present registration data as an interactive pie chart [23]. Native elements were used in every screen, and we only applied minor adjustments to them. We have only specifically changed the font, font size and colour. However, we did not reuse the same icons from the current appli- cation, because we believe that, for the visual purposes, iOS handles pdf formats for icons better as supposed to plane image formats like png and jpeg. It is mainly because the pdf formats are vectorised, and thus they can be scaled better. These icon files were used from the material design created by Google [24].
6.2.1 Screen Implementation
Although storyboard has many advantages, we have chosen to define screen layouts in this application only programmatically. This decision was made because defining it this way gives us more flexibility forall the devices that could be used for running this application. Programmatically defining a layout is done by activating con- straints (an example from the project is shown in Figure 6.3). There are many ways to define constraints programmatically, but we chose the form of anchors. In this case, we define four primary anchors (leading, trailing, top and bottom) in relation to other views. In the example above, we align the tableView to be aligned to the whole parent view.
43 6. Implementation of the Swift Mobile Application
1 NSLayoutConstraint.activate([ 2 tableView.leadingAnchor.constraint(equalTo: leadingAnchor), 3 tableView.topAnchor.constraint(equalTo: topAnchor), 4 tableView.trailingAnchor.constraint(equalTo: trailingAnchor), 5 tableView.bottomAnchor.constraint(equalTo: bottomAnchor) 6 ])
Figure 6.3: Programmatical definition and activation of constraints.
After which we can assign this constraint view onto its view controller, which can be pushed into a navigation stack, like in Figure 6.2.
6.2.2 Charts
We have used Charts library to visualise registration structure in the unit detail. The pie chart is easy to use and has made the registration screen more vivid (see Figure 6.4).
Figure 6.4: A pie chart representing groups in a registration section.
If we have the library imported, we can create an object PieChartView and with only a minor tweaks such as enabling legend and setting the colours we can add this to the view hierarchy and set the appropriate constraints (this can be done because PieChartView is a child of View). Figure 6.5 shows a real example from our code. This function is defined on a view that has PieChartView as a child. By calling this function, it will convert the given entries into PieChartDataSet that is then configured and converted into PieChartData. After this, this data is set to chart’s data property for display. These entries are gathered
44 6. Implementation of the Swift Mobile Application
from the appropriate view model, and this function is called only when the view model updated its data.
1 func addEntries(entries: [PieChartDataEntry]?) { 2 guard let entries = entries else { return } 3 let dataSet = PieChartDataSet(entries: entries, label: nil) 4 dataSet.colors = chartColors 5 dataSet.drawValuesEnabled = false 6 chart.data = PieChartData(dataSet: dataSet) 7 }
Figure 6.5: Adding entries to PieChartView for display.
6.2.3 API Calls
The API calls are implemented using the native Foundation library. It uses the standard URLSession in order to make and run tasks. Tasks are set up using a standard URLRequest which specifies all the properties needed for a given request to satisfy the server.
1 session.dataTask(with: request) {(data, response, error) in 2 if let error = error { 3 print("Error took place \(error)") 4 return 5 } 6 if let data = data { 7 let parser = XMLParser(data: data) 8 parser.delegate = result 9 parser.parse() 10 } 11 }.resume()
Figure 6.6: Actual API call in the swift application.
Because the API calls are asynchronous, we need to respond to them by using a completion block. This completion block is triggered after the task has successfully received a response (or an error) from the server. It is then checked for the error and as Figure 6.6 shows it is later used for parsing.
45 6. Implementation of the Swift Mobile Application
We have implemented a generic API call function that will take an input structure, output structure and a service name. With this, we can easily trigger an API call from code by using only one line, such as in Figure 6.7. The code requests a user detail data from the server based on the input structure stored in person instance.
1 API.shared.call(object: person, result: output, serviceName: organizationUnit)
Figure 6.7: Example of generic API call from the application.
6.3 XML Parsing Barrier
Swift has native support for parsing the JSON data into a given struc- ture. This can be done asynchronously. However, parsing an XML data is not common, and its support is limited to only primitive structures. As a solution, we have used native parser from the Foundation library called XMLParser. We have also chosen to parse on a level of the output object, which means that the object will parse the given data to itself (based on the property names after the object creation).
1 class UserDetailResult: BaseResult { 2 @objc var ID: String = "" 3 @objc var ID_Person: String = "" 4 @objc var Person: String = "" 5 }
Figure 6.8: User detail object with its properties.
We have created a class named BaseResult, which serves as a starting point for every output class we want to fill using the API call. Thus every class from the output needs to inherit from BaseResult. BaseResult is responsible for parsing the given data into the ob- ject’s properties. After the class processed the whole data from the parser, it then triggers a completion block indicating that the structure was parsed and is ready for use.
46 6. Implementation of the Swift Mobile Application
Our approach is possible, thanks to the KVC (Key-Value Coding), introduced to Swift from its original parent programming language Objective-C. KVC enables the code to go through all of the child’s objects properties in a for-cycle. We can then recursively map the names from the XML to the names of the properties and assign the right value from the XML.
47 7 Comparison and User Evaluation
This chapter focuses on the comparison of the current Pocket skautIS and the two implemented applications from the development side as well as user perspectives. The applications differ in various aspects, as described in the previous chapters. Therefore, we should also antic- ipate different results in such comparisons. The chapter is divided into three parts. First, we present the empir- ical comparison from the developer’s viewpoint. Next, we compare the technical parameters and criteria such as project size, build and start times, or CPU and memory usage. Finally, we discuss the online survey focused on user perspectives.
7.1 Development Process Comparison
This section summarizes our development processes. This empirical comparison is only supported by our own opinions and experiences with the given development approach. Although most of the informa- tion in this section is the author’s subjective opinion, we believe it is an excellent addition to the technical comparison. Each subsection is divided into specific areas. We compare all three development approaches (NativeScript, React Native, Swift) in each area. We will also give our perspective in every subsection on which development approach we think has the most significant advantage to its competitors. Note that the thesis author has four-year professional experience with the native iOS development and is also skilled in Android pro- gramming applications. The experience with the React Native devel- opment is new and gained during the work on the thesis.
7.1.1 Project Preparation
Setting up a project for development is the initial step of every project. It differs among platforms and frameworks. Notably, the iOS develop- ment is entirely possible only on Apple devices with macOS, and the other platforms provide only a limited experience (e.g., no IDE). In contrast, the Android project can be set up on any operating system,
48 7. Comparison and User Evaluation
including the Android device emulators. This is partly thanks to that Android platform is built using Java programming language that has multi-platform support in its core policy (due to the presence of ART). With this in mind, we will assess each development process from the perspective of using a Mac computer. This decision was made because the Mac operating system offers support for every develop- ment approach mentioned in this thesis, mainly supporting building native mobile applications for iOS, as it is not available on any other operating system.
Development Stack Setup NativeScript In order to setup NativeScript we firstly need to install Node.js and after that install NativeScript directly using its package manager npm install nativescript [25]. After this setup, we have two options on how to proceed. If we want to develop a build on our computer, we need to install Android and iOS requirements. This is done by using a ruby curl command1, after which we can check if we have installed everything with tns doctor. Alternatively, we do not have to install anything more. We can download the playground application on our physical device and send the code over the net- work. In order to install other libraries, we have to use npm install, which installs all libraries in our package.json file, or use npm in- stall ’package_name’ to install and add new ones to the project. If we want to use our project for iOS development, we also need to run pod install for the libraries to be accessible on iOS devices.
React Native React Native also has a simple, easy and quick way for starting a project and the more extensive way in order to build and debug on our computer [26]. The simple way only requires Node.js installed and with this using a command npm install expo-cli. Af- ter installing Expo client application on our physical device, we can send the code over the network. If we want to develop and build on our computer, we have to install node and watchman packages avail- able from Brew2. After this, it depends on what platform we want to
1. ruby -e "$(curl -fsSL https://www.nativescript.org/setup/mac)" 2. package manager primarily used for macOS
49 7. Comparison and User Evaluation
develop. For Android, we need to install Android Studio and Android SDK (at least version 29.0.2). If we want to run our project on the iOS device, we need Xcode (at least version 9.4) and Cocoapods. Simi- larly to NativeScript, React Native also uses npm for the installation of libraries, so the same commands are used for this approach.
Swift Native development using Swift only requires us to download and install Xcode on our computer. This can be done solely through macOS App Store or Apple’s developer portal (where we can down- load various versions of Xcode). The great thing about this is that there are no other requirements for building (Swift support comes with the downloaded Xcode). Installing libraries for native use in Swift is similar to the previously mentioned method. It also uses Cocoapods for installation of third-party libraries. Apple’s official libraries do not have to be installed. They are available for use out of the box. If we want to install third-party libraries, we need to first initialise Co- coapods with pod init command. That creates a pod file where we write all the dependencies (libraries) our project uses. After that, we can execute pod install and import them right in our code.
Evaluation We believe that the most user-friendly way for setting up a project is the native development using Xcode and Swift. It also uses only Cocoapods package manager as the NativeScript and React Native also uses npm on top of it. However, none of the approaches mentioned above was particularly challenging or troublesome for any experienced computer user. The React Native is, in our opinion, the most time consuming when it comes to installation as it requires many commands and programs.
Project Setup NativeScript After a successful installation, we can create a project with simple command tns create ’project_name’, which generates a scaffold with all the necessary files for running the application. Alter- natively, we can create a project with a template command tns create ’project_name’ –template tns-template-blank-ng, which generates the necessary files and creates the first blank entry screen.
50 7. Comparison and User Evaluation
React Native Depending on what installation path we chose, we have to create the project separately. If we chose the easy way, we need to initialise the project with expo init ’project_name’. Alter- natively,we initialise the project with npx react-native init ’project_- name’, which initialise the project for local build and running. If we want to use some template (e.g., TypeScript) in our initialisation, we can do it by including the template name after switch –template.
Swift If we have installed the Xcode correctly, we can easily create a new project by selecting File and option New Project in the Xcode’s user interface. This prompts us with a user interface where we select our preferences, such as programming language (Swift or Objective- C) or an initial application structure (e.g., single view application, bottom navigation).
Evaluation As for the project setup, we think that the most developer- friendly approach is a native development using Xcode. From all of the approaches, only the native one offers a user interface for project setup, as the other approaches only offer CLI setup with fewer options for customisation.
Project Build NativeScript NativeScript application can be run either with tns preview or tns run andoird/ios. Running the second command will start the building process and will run the application either on a connected device, that has running permissions enabled, or will start an emulator and run the application there (if we had installed emulator correctly). If we opt for tns preview we will be prompted with a QR code that can be scanned with NativeScript playground application on our physical device. By doing this, our device and local build will sync, and we will be able to see the application on our device. With tns preview we also have an extra feature available called livesync. This feature monitors any changes to the code files, and if it detects any changes, it will refresh our application. Thus we have to run the command only once, and we will see every change take effect in seconds.
51 7. Comparison and User Evaluation
React Native React Native has similar building properties as Na- tiveScript and shares a lot of the same steps. If we have opted for the easy way in the installation process, we need to run command npm start or expo start. Similarly, this will prompt a QR code that can be scanned in order to run the application on the device. To start the application for a local development we need to use npx react-native run-ios/run-android. Running this command will start the installed metro server and run the application on it. Our application will then only act as an interpreter to the server created and will reflect its state. So the application on our device only acts as a wrapper, and on the inside, everything is transferred to the server running on our develop- ment computer. After the server initiates, we are also prompted with the URL where we can access this. This URL can also be opened via a traditional web browser. React Native also uses watchman to refresh its server when a code file is updated. This also ensures that we only have to run the build command once.
Swift For native development using Swift and Xcode, there is only one way to build and run applications. We can select a build that we have defined in our project (we can have more builds, suchas development, release, quality assurance and others) and select a device or emulator that we would like to run this application on. If we have made any change to the code files and want to reflect this change to the application, we would need to rerun the application. There is also storyboard editing (UI definition for how application visualy looks) natively available in Xcode that can give us an idea of how will the application look before we run it on a device or emulator.
Evaluation We believe that NativeScript offers the best solution, as there is an ability of a live preview of the application as well as the option to build the application for our device locally. The livesync function is also an excellent addition for development as there is almost instant feedback when a file is changed. We value React Native asthe least appealing approach from these three, even though it offers many similar features to NativeScript. Not that it is particularly bad (all of the approaches offer some user-friendly features), but the building process could be somewhat counter-intuitive for a novice developers.
52 7. Comparison and User Evaluation
7.1.2 Application Development
From a development standpoint, there are few key differences. Mainly the most significant difference is that the native solution uses anIDE (in iOS case Xcode) which has a lot of developer-friendly program- ming features that are basically non-existent when programming for a cross-platform application (based on our case of NativeScript and React Native). Minor features such as syntax highlighting or code completion can be (to a certain extent) substituted with the usage of an IDE like Visual Studio Code. However, there are no IDEs supported by the developer that have more developer features. More outstanding features such as retracable debugging, visual inspector, a crash report organiser or an application profiler are also not present in the cross-platform approaches. Some of these feature differences could be attributed to the fact that JavaScript is an interpreted programming language. In contrast, Swift is a compiled programming language and has a native integration in Xcode. Interpreted programming languages typically lack the support for extensive debugging processes and visual debugging.
Available Documentation NativeScript We view that the NativeScript documentation is on a high level. It is mainly bound to the developer site, where there are also detailed examples for almost any problems we might en- counter during the development process [27]. Often, there is also the text surrounding the given solution as to why it works that way. As NativeScript can have more back-end configurations, there are also documentations specifically for these configurations, which we find useful (e.g., NativeScript and Vue.js [28]). NativeScript also has an extensive section on frequently asked questions, where we might find quick answers for common developer questions (e.g., usage of C++ libraries).
React Native React Native does also have good documentation avail- able for the developers. On top of normal function and class docu- mentation, it mainly also consists of text answers that provide more
53 7. Comparison and User Evaluation
knowledge on the given subject [29]. However, in many cases, we feel that the developers did not provide a great explanation, and we would have to opt for the community to answer our questions. This was mainly on GitHub pages for issues or Stack Overflow.
Swift Because Swift is natively integrated into Xcode, when it comes to documentation, everything we would need is for us accessible in the IDE. We can right-click a given element from the text editor and select the Show Quick Help, which prompts us with a small window with the shortened documentation for the appropriate function, class or a library. The full documentation is available in the Developer Docu- mentation window with an interactable user interface, or it is available at Apple developer site [30]. This documentation is highly detailed with links for other documentation pages. Swift programming lan- guage has its own well-written documentation available only outside of Xcode [31].
Evaluation For this section, we would have to pick NativeScript as it has the best source of documentation for the developers out of these development approaches. We would rank React Native last, mainly due to the lack of documentation and complementary material from the developers.
Debugging The Application NativeScript We need to take some additional steps in order to start debugging in NativeScript. There are two ways to debug: us- ing Chrome Dev Tools or using Visual Studio Code [32]. Visual Studio Code can be used to debug and step through TypeScript code as if it was a standard debugger we are used to when using a compiled programming language. Other than this there is only one way to come close to debugging in NativeScript, and that would be using console logging with console.log(’object’).
React Native React Native offers more debugging capabilities than NativeScript. Probably the most significant is a version of visual inspec- tor, that we can prompt when we start the application from Chrome
54 7. Comparison and User Evaluation
and inspect individual elements [33]. This feature is also available in the development build on the device when user taps on Show In- spector in the application debug menu. There is also Chrome Dev Tool available for use in order to set breakpoints and debug the code (although it requires library installation in order to take advantage of this feature fully). React Native also offers console logging.
Swift Xcode offers all of the mentioned features above out ofthe box. It handles breakpoints and traversing in code for debugging purposes. It also offers excellent visual debugger where we can see all the elements presented on the screen at the given point also with their constraints and what properties the objects have.
Evaluation In our opinion, Xcode offers the best debugging capabil- ities right out of the box. They are also easily visualised and accessible in the IDE with integrated functions. We think that NativeScript offers the least when it comes to debugging options. After the installation it is basically without debugging features, the only solution is to use console logging or install these third-party features.
Making a Release Build NativeScript To make a release build within NativeScript, we first need to have a signing certificate so we can sign our application. This is done in order to ensure the identity of the developer and pub- lisher of the application. Android and Apple have different certificate standards, building processes and also outputs. For this reason, in cross-platform development, we need to make both builds separately. Android has an advantage, where we can create this certificate (and publishing key) ourselves on our local machine within minutes using keytool command. After this, we can create the build with command tns build android, which will create .apk file that can be installed on any Android device. As Apple has more strict policies around creating a build (in iOS development known as .ipa file), there is no command to create a local build which we could install directly on any device. We need to go through Apple’s development program, where we can only create a build that is stored on our Apple ID profile
55 7. Comparison and User Evaluation
outside of our reach. There is a possibility of building on a device, but only at a condition that the device is connected to our development computer and creating a build locally. To submit our build to Apple developers program, we can use tns publish ios which will upload our application to the Apple’s servers.
React Native Making a release build in React Native seems some- what tricky. In order to make such build, we need signing certificates for both iOS and Android platforms. With these, we can sign our created build and thus publish it into the platform stores. When we have the appropriate certificate we can build the release application with command npx react-native bundle and a switch –platform android/ios for what platform we want to make the bundle. In our case, when we wanted to produce such build, for yet unknown reason, we had to delete all the temporary resources files in order to satisfy the command. We still do not know why this behaviour is needed for the release build. There were no official statements from React Native team about this topic. As stated in NativeScript part for making a release build, in order to build for iOS devices, we still have the problem to create the release build locally. With this, we need Apple’s signing certificate to sign our application, and the build command will upload the build to the Apple’s servers where we can then access it and publish the application later.
Swift If we want to make a release build from Xcode, we will need to archive the project build first. This is done from the archive button which prompts the build window, where we can see our last made builds of the application. In order to do such build, we need a signing certificate to sign the application. To download such a certificate, we need to be part of the developer program issued by Apple. After obtaining this certificate or letting Xcode handle it automatically, we can sign the application and make the build, within the IDE, that will be uploaded to our developer profile and can then be distributed as an application.
Evaluation When it comes to making a release build, we can not say we have an approach that would be superior to the other ones. This
56 7. Comparison and User Evaluation
can be attributed to the fact that the cross-platform approaches still need to use the native platform tools to make such build and thus make it no different from the native approaches itself.
7.1.3 Lessons Learned
In this subsection, we will present strengths and weaknesses for every development approach from the point of the development process, that each of them presents. Many of the points made in this section are made from the observations when we were developing the Pocket skautIS application by using these approaches. Many of the strengths and weaknesses revolve around the fact that Swift has native integration for Xcode out of the box. Thus it naturally makes the development process more developer-friendly. As suppose the NativeScript and React Native are only a framework created by third-party organisations that do not have any native integration in any IDE.
Strengths NativeScript One of the biggest strengths of using NativeScript is probably the support of library installation through npm. This is es- pecially useful because Node.js has great open-source community support. If we are not satisfied with an implementation detail ina library, we can just make the change ourselves, or even help others. We also believe that NativeScript playground application is an excellent addition for any developer to use. This feature can be useful when there is a problem with a particular device that is not mentioned in the certificate used for application signing (a typical problem in iOSde- velopment). By installing the playground application, we can bypass this restriction and debug on the device that has a particular problem.
React Native We believe that the biggest strength of using React Native over other options is its code simplicity. Especially when the programmer has prior experience with JavaScript programming. If we are writing a simple application that does not use many screen designs and application states, React Native solution would be the most user-friendly solution. React Native also uses Node.js, so we
57 7. Comparison and User Evaluation
can also take the same advantage of community-based libraries as programming using NativeScript.
Swift Using Xcode and Swift has a significant advantage over other solutions, and that is that it uses a native code and is optimised for the best compilation from the same manufacturer that produces the devices which the application is running on. There is no additional abstraction level when using this approach. So if we are looking for the best possible application performance (e.g., older devices struggle with cross-platform approach), the only solution to this is to use the native approach. On top of this, it has many developer-friendly features, especially when debugging the application.
Weaknesses NativeScript Maybe the biggest weakness for NativeScript develop- ment is that sometimes things do not work on one platform as they do on the other. This leads into a development path that involves two specific implementations for the same functionality, one for Android and one for iOS. There also could be a problem in that every screen has separate TypeScript implementation, which handles the logic and HTML implementation, which handles the screen visuals. This in it- self is not bad, but the fact that there are no syntax checks and the error messages are in many cases vague makes finding the mistake challenging, especially if it only involves a typo in the function’s name.
React Native We believe that React Native also suffers from the same flaw as NativeScript, but it is more prominent for this approach. We had to find independent platform solutions more often, and most notably for the application alerts. We have come across a significant flaw in React Native while developing our application. This involved a process, which is only triggered if we are building a version with the intent of publishing this version. When we are developing and debug- ging locally, the names of the classes stay the same, but if we want to create a release version, the names of the classes get transformed. This in itself is not troublesome as in many cases we do not rely on a par- ticular class name (their names are just for code readability), but we
58 7. Comparison and User Evaluation parse server responses we want to match a given response into a class with a particular name in order to use this class then. Furthermore, when our name of the class gets compressed from UserDetail into just t (an example that happened while testing the release build), the parsing process does not work correctly and will throw an error. We did not found any way to turn off this process in the release build, so we opted for a workaround that every class must include its original name in a string parameter. Thus their name will get compressed, but the parameter will stay the same, and we can parse without an error.
Swift We did not find any weaknesses regarding development using the Swift programming language and Xcode as an IDE. The only minor issue was that Xcode turns off syntax highlighting for an unknown reason from time to time. Moreover, only its restart fixes the issue. We have only come across one significant barrier described in more detail in section 6.3. This problem revolved around parsing an XML response from the server, where Swift does not offer a developer-friendly option compared to the cross-platform approaches.
7.2 Empirical Comparison
This section discusses the empirical comparison of the three appli- cations, their source code, as well as statistics about generating such application builds. These statistics include building time, the clean start time for devices, the clean start time for simulator, memory and CPU usage.
Experiment Design For time measurements, we have used internal IDE (Xcode and Android Studio) solutions to measure clean build times. All of the testing measurements were done on an early 2013 Mac- Book Pro with these specifications:
• macOS Catalina Version 10.15.6,
• Processor 2,4 GHz Quad-Core i7,
• Memory 8 GB 1600 MHz DDR3,
59 7. Comparison and User Evaluation
• Graphics Intel HD Graphics 4000 1536 MB.
The measurements were taken while only the necessary programs were running on the computer during every test. For devices, we have chosen two Android devices and two iOS devices. Testing Android devices were Huawei Honor 8 2016 (Android version 7.0) and Sam- sung Galaxy J5 2016 (Android version 7.1.1). For iOS testing devices we used iPhone 6s (iOS 12.0) and iPhone 7 (iOS 14.2). All the time measurements were repeated ten times with the same conditions, and the results were averaged. Android Studio displays build time in the build section out of the box. This time is further di- vided into smaller parts such as load build time, configure build time, run tasks time and more. We have chosen to gather only the whole complete build time. Xcode does not offer this feature by default. We need to run defaults write com.apple.dt.Xcode ShowBuildOpera- tionDuration YES in the terminal. After which Xcode displays only the whole complete build time in the activity viewer section.
7.2.1 Project Size
For project size, we have been looking at the number of lines and also the number of files in the project. For this purposes we have useda program called cloc3. We can further benefit from this program as we can filter out unwanted files based on extensions or directory. As for the number of lines we have filtered out empty lines and lines that are commented (typically for documentation), as these only have an impact on code aesthetics and not its functionality. As for the file extensions, we have decided to spare them into two categories. The number of lines, including JSON files and the number of lines without JSON files. This decision was made because all of the projects useJSON files for configurations, and it is questionable whether they couldbe considered a source code file or a meta-data. We have further decided to split the measurements into two parts, as the Swift application did not include STS and Profile agendas. To compare cross-platform approaches and the native approach, we have decided to also exclude files that implement these two agendas from the projects.
3. https://github.com/AlDanial/cloc
60 7. Comparison and User Evaluation
We also excluded library files and unnecessary files such as platform- specific files for building the cross-platform applications andthe biggest folder in every Node.js project, node_modules.
without .json with .json without .json with .json Number of lines of code Number of lines of code (not including Profile and STS) 22000 18000
16500 13500
11000 9000 20092 16716 14177 14777 11658 5500 4500 8280
4203 3604 2810 3098 0 0 NativeScript React Native NativeScript React Native Swift Figure 7.1: Lines of code in the project, with and without JSON files. Profile and STS included (left), Profile and STS excluded (right).
We can see from the Figure 7.1 that the NativeScript application has the most number of lines. Native application programmed using Swift language had the least number of lines of all. Even when we took out the Profile and STS agendas from the cross-platform projects where only the React Native without JSON files came close and had only 800 lines more. This outcome could also be accounted for the fact that NativeScript application uses more files in order to define its behaviour. For exam- ple, in NativeScript we have to create an HTML file in order to define how the elements should be laid out, SASS file in order to define how the elements should look and TS file in order to define the behaviour of the elements. As for the Swift and React Native, this could every- thing be done in a single file. This information could be seen from Figure 7.2. Although Swift project used MVC pattern, which creates three files for every screen, it also had fewer files overall to React Native, where we used only one file per given screen.
7.2.2 Application Size
To make an application that could be run on a device, we have to convert our project into a build for the appropriate platform first. This
61 7. Comparison and User Evaluation
Number of files in the project Number of files in the project (not including Profile and STS) 500 400
375 300
250 200 442 326
125 100
86 91 63 0 0 NativeScript React Native NativeScript React Native Swift Figure 7.2: Number of files (filtered) in the project. Profile andSTS included (left), Profile and STS excluded (right)
is because Android and iOS platforms both use different formats for its builds in order to install such an application. Because of this, we have divided the chart in Figure 7.3 into two parts, one for Android (APK file) and iOS (IPA file). Furthermore, we can not compare the two platforms between each other. We can only compare the appropriate platforms within themselves.
Android iOS Application size release build 100
75
50 94,3 95,1 Megabites
25 35,3 28,4
0 5,5 0 NativeScript React Native Swift
Figure 7.3: Application size categorised for each platform.
62 7. Comparison and User Evaluation
We can see that as for Android applications, the NativeScript appli- cation is around 25% bigger in size than the React Native application. This could be attributed to the fact that the NativeScript application has more lines of code. Also, more static images were used within the application than in the React Native application. As for the sizes of iOS applications, it is a bit more strange. We can see that no doubt the native application programmed in Swift language is only about 6% of both NativeScript and React Native applications. There are two key points as to why this could be the case. Android and iOS both use different encryption of the code. This encryption is in place to ensure the user that he has the correct appli- cation from the given developer (the applications are encrypted with the developers private key). The second reason is that iOS bundles ver- sions of the same application to each bundle. This is done in order to ensure backwards compatibility for older devices which run different CPU architectures [34]. Because we have developed the Swift appli- cation only to support iOS 12.0 and further, but the cross-platform projects support iOS 9.0 and further. Plus they also have to bundle in the frameworks and libraries of each solution, which is not the case for the Swift application.
7.2.3 Clean Build Time
We have to make individual measurements for each platform sepa- rately as some development approaches can build for multiple plat- forms. We have used both native IDEs (Xcode and Android Studio) to generate each build and have tracked the build time ten times for each category. This tracking was done internally as both of the IDEs have native solutions to track the build time of the application. In the appropriate chart, we have also included a standard deviation (SD) in the form of error lines. Before every build, we have ensured to have a clean build folder. We would not clean the build folder if we were developing our application as usual. Not cleaning the build folder ensures faster build times as the compiler does not have to go through all of the unchanged files from the previous build, it just has to work out the changes made from the previous build. This reduces the build time drastically (sometimes as much as 90%). We have chosen to clean the build folder to reflect
63 7. Comparison and User Evaluation
on the individual development approaches and their optimisation of the build process.
Android iOS Average application release build time 420
315
210 401,56 seconds
105
31,431 18,97 43,59 0 15,48 0 NativeScript React Native Swift
Figure 7.4: Average clean build time for every application on every platform possible.
We have also chosen to build what is called a release build because, in many cases, the development build does not reflect the fully stan- dalone application installed on the device (because it is not encrypted and signed with a certificate). From the chart in Figure 7.4 we can see that the fastest out of all the approaches was the native Swift application. This was somewhat ex- pected as building for iOS devices, while only using a native approach is recommended by the developer. What we did not expect was, how long it took to build an iOS build using the React Native. On average, it took more than 400 seconds to complete the build fully. Many users on the internet forums have asked the same questions, but we were not able to find any satisfiable answer or a solution as to why theiOS build for React Native takes that long compared to other builds. As for the Android build, we can conclude that the NativeScript builds took on average 12 seconds less than the React Native builds. Which by itself is not a lot but if we convert it to percentage points, the NativeScript build was almost 28 % faster. The calculated results from the measurements were 31.42 (0.966) for NativeScript building on Android and 18.97 (0.938) for iOS. React Native had a time of 43.59
64 7. Comparison and User Evaluation
(2.997) on Android and 401.56 (7.003) on iOS. Lastly, Swift had a time of 15.48 (0.909) for an iOS build.
7.2.4 Clean Start Time
In order to measure the start time, we had used a standard technique, where we start a timer when the application receives a start call, and end this timer when the first screen finished its initialising process and is being displayed to the user. This measurement is done internally by implementing such a timer in code. We wanted to compare start times for the release versions of every application. As in many cases, older devices tend to struggle with opening an application and take considerably more time than newer devices, if the application is poorly optimised. We also wanted to compare the development approaches on one device, as this would ensure the same grounds for each application. This is a problem because no mobile device could run Android and iOS operating system simultaneously (removing iOS and installing Android on iOS devices is possible, but it is outside of the scope of this thesis). So we have decided to compare them on our MacBook Pro 2013 which we used for developing and testing. We will use emu- lators to simulate iOS and Android devices on our computer. As the emulator performance highly depends on its implementation on the given platform, these measurements are only informational.
iPhone 7 iPhone 6s Huawei Honor 8 Samsung Galaxy J5 Average start time for iOS devices Average start time for Android devices 4 9
3 6,75
4,5 2 seconds seconds 7,7 3,17 2,47 2,25 1 2,9 3,3 0,84 0,95 1,43 0,5 0,6 0 0 NativeScript React Native NativeScript React Native Swift Figure 7.5: Clean start times for Android and iOS applications on devices.
65 7. Comparison and User Evaluation
From the right chart in Figure 7.5 we can see that iOS devices were faster at starting up every application than Androids were. This was expected, as from our experience with programming for iOS devices, we have not noticed any slow start times even on older devices. This can not be said for older Android devices, as we can see the Samsung has struggled with opening up the current NativeScript application. It took the Samsung on average 7.7 (0.5) seconds to see the first screen, and the user could start interacting with the application. The Huawei device was on average more than 2.5 times faster, with an average start time of 2.9 (0.194) seconds. This trend can also be seen in the React Native application where the Samsung took on average 3.3 (0.235) seconds to start compared to the Huawei, which, on average, only took 1.43 (0.092) seconds to start, making it more than 2.3 times faster. For iOS devices, there are only slightly noticeable changes between the React Native application and the native application programming in Swift. As compared to the Android devices, we can not see any noticeable changes between the individual devices. Yes, on average, the iPhone 7 was faster, but only a slight improvement. We can observe that from the measurements both iOS devices did worse when starting the NativeScript application, where iPhone 6s had an average time of 3.17 (0.125) seconds, and iPhone 7 had an average time of 2.47 (0.019) seconds. Compared to NativeScript, the devices had better starting times when starting the React Native application. iPhone 7 had an average time of 0.84 (0.035), and iPhone 6s had an average of 0.95 (0.051), which is more than three times faster.
Average clean start time for Android emulator Average clean start time for iOS emulator 7 3
5,25 2,25
3,5 1,5
seconds seconds 2,67 5,35 5,12
1,75 0,75 1,24 0,74
0 0 NativeScript React Native NativeScript React Native Swift Figure 7.6: Clean start times for Android and iOS applications on emulators.
66 7. Comparison and User Evaluation
In Figure 7.6 we can see that the native iOS application had on average the fastest build time out of all of the measured applications. This was anticipated as we have tested this on a MacBook with a native, highly-optimised emulator. We can identify that when we tested different applications but still on the same iOS emulator, both the NativeScript and the React Native application performed worse than the native Swift application. NativeScript had an average time of 2.67 (0.076), React Native had an average of 1.24 (0.191), while Swift had an average of 0.74 (0.41). We can notice that the worse build times were measured on the Android emulator, where both of the applications had build times slightly above five seconds, 5.35 (0.882) for NativeScript and 5.12 (1.011) for React Native.
7.2.5 CPU and Memory Usage
We have used a native profiler features built into Android Studio and Xcode, in order to track the CPU and memory usage of each application. Profiler allowed us to track the usage of such resources throughout the given application run. It is a great tool that can be useful when debugging an application. It tracks CPU, memory and network usage at a particular time, so if there are some problems (e.g., slow application response), we can determine what causes them by using this tool. For an objective comparison, we have selected a predefined sce- nario that we go through on each device. This scenario involved log- ging in with a predefined account, searching for a person (Jan Mesl) and viewing his profile. After that, we look into our units detail andse- lect the registration statistics for the year 2010 and scroll to the bottom of the view.
67 7. Comparison and User Evaluation
Figure 7.7: Samsung’s (top) and Huawei’s (bottom) CPU and Memory profile for NativeScript application.
Figure 7.7 shows both Android testing devices going through the given scenario. There are no significant differences between the mem- ory charts, but CPU charts draws a different picture. We can observe that the CPU was continually running (continuous green line around 30%) on two occasions. When the user started the application and when he first logged in. We can determine this because the topmost timeline displays user interaction (red dot is for touch event and brown symbol is for typing). This proves our observation of clean start times where the older device struggled compared to the newer one, especially when running the NativeScript application. If we compare data from the different cross-platform development approaches on the Samsung device (NativeScript in Figure 7.7 and Re- act Native in Figure 7.8), we can observer that overall, the React Native application shows no signs of the continuous green line in the CPU chart. This indicates that the React Native application did not have a problem running on this device, while the NativeScript sometimes struggled. There were no noticeable differences when comparing the
68 7. Comparison and User Evaluation
Huawei device’s data, other than that the CPU usage was overall lower when running the NativeScript application.
Figure 7.8: Samsung’s (top) and Huawei’s (bottom) CPU and Memory profile for React Native application.
There were no significant differences between iOS devices andthe memory and CPU profiles. However, we have observed a substantial decline in CPU usage when running the native application developed in Swift. The charts in Figure 7.9 shows that the maximum CPU usage for NativeScript was 85%, for React Native 92% and for Swift 33% (these measurements were all taken from iPhone 6s). Despite the high values in the NativeScript and React Native runs, we did not feel that the device struggled while running these applications. Nevertheless, scrolling the tables in the user detail and registration detail were smoother in the Swift application. These results also maybe because the best-optimised programming method in performance on devices is native development because there are no additional frameworks or programs needed to be run by the device.
69 7. Comparison and User Evaluation
Figure 7.9: iPhone 6s CPU profile for NativeScript (top), React Native (middle) and Swift applications (bottom).
7.2.6 Lessons Learned
In this subsection, we will summarise the strengths and weaknesses of the given development approaches based on the empirical comparison, and measurements we have gathered when testing the applications. As we have tested these applications only on two devices per platform, the actual use case may slightly differ.
Strengths NativeScript Probably the biggest strength to NativeScript develop- ment is that the build times for every platform were almost identical
70 7. Comparison and User Evaluation
to their native counterparts. This is especially useful when develop- ing and debugging such an application. Even though this framework was last in almost every measured task (in terms of the measurement results), it was not that significant, and the end-user may not even acknowledge that it is not a purely native application. The numbers may not show it, but NativeScript is a useful framework for mobile- development.
React Native Even though React Native is a cross-platform mobile development approach, it does not have a significant overhead when it comes to file size and the number of lines compared to the native approach. We consider this a strength, especially when the file size and number of lines are compared to the NativeScript approach. It also has a better performance characteristic on emulators and devices, which could overall contribute to user satisfaction with the final application.
Swift Swift’s strengths relied on the fact that it has native support in Xcode and also on all of the Apple devices. This means that the build times were the fastest because Xcode is well optimised for this development. It also means that the application size is compressed at better rates and thus can be easily distributed. The data shows that even an older iPhone still has a good capability for running an application that was developed this year. The numbers show that the native approach is most useful when the developer is looking to develop an optimised and fast application even for older devices.
Weaknesses
NativeScript We think that there is only one notable weakness of the NativeScript was that it does not have a good support for older Android devices. Yes, the application can be run on such a device, but the application start takes much longer on these devices (compared to other approaches). This is probably the consequence of the CPU usage being too high and constant at such times. Meanwhile, for newer devices, it stands well and almost identical to React Native approach.
71 7. Comparison and User Evaluation
React Native We believe that the React Native’s biggest weakness is that the application build times on iOS devices were horrific. As NativeScript had almost identical times to native development, it is shocking that React Native took more than twenty times longer to build the final application. Although in the real world, where wecan use build folders, which reduces the overall build time for the next build, this measurement may not be that significant. Another weakness is that the final application size, especially for iOS devices, is vastly large. This may not appear as a disadvantage, mainly because many devices have lost of storage. However, if we consider the download time over a mobile connection, it could be unpleasant for the user.
Swift Overall we did not have any weakness for native development approach using Swift. It had the best results in every test, even though sometimes this difference was subtle or even negligible.
7.3 Survey
This section talks about the conducted survey of users. We wanted them to install two applications on their devices, the current Pocket skautIS application, and the React Native application developed for this thesis. After that, they were presented with several tasks that they had to complete in each application separately and then briefly write about their experiences. In this way, we can evaluate what application is better suitable towards the users and which lacks some user-friendly features. The whole survey questions are available in Appendix C. Visualisation in the form of charts to the data presented in this section can be found in Appendix D. The charts are arranged based on the questions presented in the survey and labelled accordingly.
7.3.1 Participants
As we knew that all of the participants would be either Czech or Slovak, we chose to construct the survey form in using the Slovak language as it would be easier for them to answer the questions and there would be no language barriers. The survey was created and distributed
72 7. Comparison and User Evaluation
through Google Forms and is still available at https://forms.gle/ kURUR4rGMraDdkMw7. Respondents were mainly tech-savvy people. Every participant selected that they had used the Android version of the application. Overall 71.4% of participants had no prior experi- ence with Pocket skautIS, and 28.6% had a significant experience.
7.3.2 Survey Structure
The survey was structured around tasks that the participant had to complete in both applications and then write about their user experi- ences. The participant also needed to specify which application he felt more comfortable with or if there were any setbacks when completing such a task. The answers were meant to be only brief (no excessive wording was needed). However, we had observed that when the user accoutered some bug or something that he did not feel is usual, he described this situation in great detail (sometimes even provided the method as to how to replicate this unwanted behaviour). We feel that this type of feedback is beneficiary. It shows what the user was shocked about and what should be considered for change in later iterations of the application. For each participant to have the most similar experience, we have provided them with sample accounts, and the applications were oper- ating only on the testing environment (https://test-is.skaut.cz/). If they follow our instructions in each of the tasks, they will replicate the same results each time. This ensures that every participant will be presented with the same data and could decide only based on his preference. After the tasks section there were brief questions about the overall user satisfiability with both of the applications. What application would they prefer using and an explanation why they choose the answer. There was also a question if they had accoutered some odd behavior when not completing the task and a question about visual differences between the two applications (for details see Appendix C). Note that we have chosen only to conduct this survey for people on Android devices. This decision was made because the APK file can be installed just by downloading it (from any source) on any device. As a contrast, this method is not replicable on iOS devices. We can only download and install apps on iOS devices through the App
73 7. Comparison and User Evaluation
Store, or TestFlight, which is not an easy process for an ordinary user. TestFlight is used primarily for beta testing new applications for users with developers accounts. On top of this set back from Apple, we would still need to be part of a developer program and go through an application review process for publishing (or even testing) an application. This process would set back our survey as newer applications tend to go through a more extensive review process than app updates. This is why 100% of our participants selected that they were using only Android devices.
7.3.3 Tested Tasks
For this survey, we have prepared several tasks to test the applications as well as user satisfaction with the given implementation. The par- ticipant than had to replicate each task in both applications, in order to evaluate each application and compare them. The comparing part consisted only from a brief text input about which application he was more comfortable using or which one had better handled the given task. We have prepared in a total of six tasks, each focusing on a different part of the application. These tasks were designed as what a standard user would want to know from the application in everyday use. These tasks included:
• deleting the last received message,
• changing the user role,
• searching for a given person’s address,
• finding the unit’s leader mobile number,
• finding the registration statistics for a given year,
• viewing users telephone statistics.
This subsection will further present data about which application was preferred when completing the given task. We will also discuss some of the more prominent answers about the user experience for the given task.
74 7. Comparison and User Evaluation
Delete Message In this task, the participant had to log in and delete the last received message. These messages are located in the Profile section of the ap- plication, and after clicking the button for all messages, the user is presented with all of his messages. After clicking on the last one, the participant is presented with a given message detail that can be deleted with a trashcan icon. This task’s results were that 57.1% of participants answered that both of the applications did an equally good job in completing the task. Moreover, about 42.9% answered that they prefer the current Pocket skautIS application. Almost all of the respondents pointed out that in the React Native application, the trash icon for deleting a message is offset beyond the screen bounds and thus is hard to click. We can confirm that this is the issue an in fact on some of the screen dimensions the icon is not clipping properly to the bounds of the screen. Some of the respondents also pointed out that the current Pocket skautIS application felt slower when using it for this task than the React Native one. This also probably influenced them to choose that both of the applications did the same job, as both of them had some setbacks when completing this task. We believe that the issue with offsetting the trash icon in the Re- act Native application can be solved with minimal effort. Thus, the participants could prefer this application when completing this task.
Change User’s role For this task, the participant had to change his role in the application. This can be achieved by clicking on the participant’s current role in the Profile section. After which he is presented with lists of roleshe can choose from, the final chosen role was left for the participant’s preference. This task’s results were that 42.9% of participants answered that both of the applications did an equally good job in completing the task. 42.9% thought that they had a better user experience in the React Native application, and the other 14.3% had a better user experience using the current Pocket skautIS application.
75 7. Comparison and User Evaluation
Some respondents pointed out that the React Native application had a faster response when completing this task compared to the current Pocket skautIS application. As this may be the case on newer devices, someone with an older device (did not specify) pointed out, that the React Native application did not have a loading indicator when he tapped the role. He was only after a brief moment prompted with the role changing alert, which is why he chose the current Pocket skautIS application. We can confirm that the Native Script application does not have a loading indicator for this task. However, we do not view this as a significant issue as the indicator could be easily added.
Find User’s Address
For this task, the participant had to find a specific predefined member’s address and write it in the form. For this, the participant had to select the Peoples section and write down the given name they wanted to search. They also needed to select where they want to search (the whole address book or just the unit), there was no right answer to which they had to search the person (in both cases the user profile would appear). After clicking on the user profile, the participant is presented with his details and can find his address in the top section. Every participant picked the correct answer, so we can say that there were no significant setbacks when finding this information in either application. This task’s results were that 28.6% of participants answered that both of the applications did an equally good job in com- pleting the task. About 42.9% answered that they prefer the current Pocket skautIS application. Finally, 28.6% of participants answered that they prefer the React Native application. The most prominent answer as to why did they prefer the current Pocket skautIS application more than the React Native one is that it had one of the search switches selected by default. As we acknowledge that this is true, the React Native application does not have any search switch selected by default. We do not consider this as a significant setback. In fact, we consider this to be a good thing that the participants only had a problem with something that can be fixed within seconds. Despite this, we can see answers pointing to the fact that the current Pocket SkatIS application felt slower and searching for the person took
76 7. Comparison and User Evaluation
longer. Which is probably the case that 28.6% of participants chose the React Native application as it was by their feelings faster.
Find Unit’s leader number
For this task, the participant had to find a phone number of the specific head of a unit. To see the specific unit, the participant had to select a particular role in the Profile section first. After which he could goto the Unit section and look for the person, which has the head of the unit title next to their name. After clicking on this person, the participant was presented with the units leader details and could find his phone number in the top section. Every participant has provided the correct telephone number. Thus we can conclude that everyone has completed the task correctly, and the participant could only focus on the application differences. This task’s results were that 85.7% of participants answered that both of the applications did an equally good job in completing the task. 14.3% thought that they had a better user experience in the React Native application. The responses to this task were probably the most consistent out of all of the tasks. Nearly every responder stated that he had the same user experience when completing this task in both of the applications and did not encounter any unwanted behaviour. A common answer from the 14.3% of participants who answered that they preferred the React Native application also wrote that they found it weird that the current Native Script application forced them to the new Person section with a new screen after tapping on the head of the unit. Some of them also stated in the bug section that they did not find this behaviour troubling, they simply did not expect it.
Find Unit’s registration statistics
For this task, we asked the participant to write down the unit’s age category, which had the most representation in the registration year 2010. This was achieved by selecting a particular role in the Profile section, after which the participant could tap on the registration button in the Unit section. This presented him with a list where he had to
77 7. Comparison and User Evaluation
select the year 2010 and navigate to the registration age category table section. Every participant has selected the correct age group. Thus we can conclude that everyone has completed the task correctly, and the participant can only focus on the application differences. 14.3% of participants though that neither of the applications did a good job an that they do none at all. 28.6% thought that the current Pocket skautIS application did a better job, and 57.1% of participants preferred the React Native application. Many answers pointed to the fact that they did not necessary found any solution to be particularly bad. The only difference for the respon- dents were that the React Native application had a graphic represen- tation for the data in the form of pie charts. We fully support this statement. However, we do not find adding a graphic representation for the data to the current Pocket skautIS application a challenging task.
Find Telephonic Spending
In this task, we asked the participants to write down the telephone number, which had the most spending throughout the last two months. To see the spending, the participant had to tap on the STS section in the bottom navigation bar and then click on the spending button. After that, he will be presented with a spending report screen from the last three months. Every participant has selected the correct telephone number. Thus we can conclude that everyone has completed the task correctly. 28.6% of participants though that both applications did the same job and they do not prefer any application over the other. 14.3% thought that the current Pocket skautIS application did a better job, and 57.1% of participants preferred the React Native application. Many responses stated that they preferred the React Native appli- cation because it showed a graphic representation of the spending report throughout the three most recent months. We can agree to this as the current Pocket skautIS did not show the spending chart. Some also stated that the chart legend did not fully reveal the phone numbers at the end. This also can be true, and similar problem as
78 7. Comparison and User Evaluation
for the trash icon could have occurred here. As on some displays, the phone numbers may not be fully visible. A common answer from the 14.3% of participants who answered that they preferred the current Pocket skautIS application also wrote that they found the chart confusing, which is why they chose the given answer. We believe that, with a minor change, the current Pocket skautIS could show the spending chart and thus please more users with a simple fix.
7.3.4 Overall Evaluation
The final part of the survey contained a set of questions regarding overall satisfaction with the applications. 71.4% of participants have chosen that they had a better user experience using the React Na- tive application over the current Pocket skautIS. 14.3% of participants answered that they had the same user experience in both of the appli- cations, and the other 14.3% stated that they did not have a good user experience in either of the applications. The answers here mainly point out to the lack of graphical rep- resentation in the current Pocket skautIS application and also slow response time compared to the React Native application. We have also included a question where the user should mention any graphical differences, that he noticed between the applications. Many replies here pointed out that the only difference is that the React Native application has charts on display that were not present in the current Pocket skautIS. One also pointed out that the current Pocket skautIS had one extra item in the bottom navigation bar that served only for logging out. We believe that these are only minor differences that could be ad- justed with a little bit of more work on the React Native side. This points us with the React Native application to a conclusion that there are not a lot of noticeable differences from the user interface stand- point. This was our goal when making this application. We wanted to replicate the current Pocket skautIS application as best as we could. Moreover, the responses from the given survey prove the accomplish- ment of this set goal.
79 7. Comparison and User Evaluation
7.3.5 Lessons Learned
We will further summarise the responses, which we had gathered from our participants with this survey. We will convert these responses into strengths and weaknesses in regards to the underlying application for each development approach.
Strengths NativeScript Main strong point as to why the participants chose the current Pocket skautIS application over the React Native was that it provided more feedback when a task was completed. Even though the respondents pointed out that the React Native application was faster, they still prefer to have the feedback shown to them rather than the fraction of time saved. Due to these responses, we belive that the current Pocket skautIS is built more robust and has better response handling and showcasing.
React Native Many participants pointed out that they prefer the React Native application simply because it felt better when running and quicker in responses. Even on the older devices, the users did not report any slow or long loading times when using the application. We view this as a big strong point of this approach, and even the testing supports this claim (although, the current Pocket skautIS did not rank that bad as the participants may point out). Other participants also suggested that they prefer this application because it has a graphic representation of the data in the form of charts. We do not find this as a significant strength, just because the charts could be easily added to the current PockatskautIS application as well.
Weaknesses NativeScript Based on the responses from the participants, the cur- rent Pocket skautIS application’s biggest weakness is that it runs slow compared to the React Native one. The measured data also support this claim. However, if we compare the average numbers, this applica- tion was not that much slower on most devices. Another weakness was that this application contained an extra item in the bottom navigation
80 7. Comparison and User Evaluation
bar that the participants did not find much use for. We did not find this as a significant weakness, as this item could be easily removed from the navigation bar as the application still has active ongoing development.
React Native As a weakness, we believe that the React Native ap- plication does not do a good job when it comes to a specific device problem. This may be attributed to the fact that the application was not developed with many devices, and thus this problem only occurred during testing. Most notably the problem with offset trash icon and phone number in the STS chart. This weakness could be resolved with more testing during the development phase or an overhaul after the application deployment.
81 8 Conclusion
This thesis aimed to compare two cross-platform mobile development approaches, namely NativeScript and React Native. We have further compared both approaches with the native approach, where we also develop a native iOS application using the Swift programming lan- guage. We have compared these three development approaches from three different viewpoints: development process, empirical compari- son and user experience. Instead of comparing artificial applications from tutorials, we de- cided to implement a real application. As a reference, we selected the Pocket skautIS application, implemented in using the NativeScript framework. This application was chosen because it has many features and an active user base. We have created a React Native implementa- tion of Pocket skautIS with the same features and Swift application with limited capabilities (namely due to the performance compari- son). The development process comparison is based on our experience gained throughout the project, such as ease of installing the given tools, necessary programming knowledge or the individual key steps throughout the development. The empirical comparison consists of descriptive statistics of the project codebase, application build size and several time measurements (e.g., application build time, application start time or profiling information). Last but not least, we conducted the user survey to compare the current NativeScript implementation with its React Native twin. The seven participants were given a set of tasks that they had to complete in both applications. Then they had to answer simple questions about their experience in both of the applications. There were six tasks in total, and there was one answer that was repeating in almost every user experience question. That was that the NativeScript application was less responsive than the React Native one. This can also be seen from the technical comparison where we have measured that the React Native application was twice as fast when starting the application on an older device. This problem was also observed when comparing the profiles of a predefined task in each application.
82 8. Conclusion
To sum up, we believe that the React Native framework is overall a better choice over the NativeScript framework. As it has better de- bugging features, and the code syntax is easier to understand. These features make it easier to learn for a novice developers. This fact is even more prominent when the developer has a prior experience with web development. On the other hand, NativeScript has better documenta- tion. However, the fundamental relationship among TypeScript, CSS and HTML could be hard to grasp for a new developer. React Native has longer build times (e.g., for iOS it took almost 22-times longer). Nevertheless, we do not really view this as a significant disadvantage, as it is not a reoccurring task and in many cases, we only need to build the final application once before publishing. Cross-platform application development is certainly a worthy alter- native to traditional native development endorsed by the platform’s creators. Because they are using native rendering capabilities and other native platform-specific APIs, their visual elements are almost identical, and their performance is similar to those native applications. So the choice of the development approach comes down to the de- veloper’s preference and prior experience with other programming languages. Developer with prior experience in front-end web devel- opment may prefer to use NativeScipt, while the back-end developer could prefer to use React Native. Nevertheless, these are only consid- erations, and a developer survey would be needed to confirm such claims.
83 Bibliography
1. Number of smartphone users worldwide from 2016 to 2021 [online]. Statista Online Services, 2020 [visited on 2020-10-18]. Available from: https://www.statista.com/statistics/330695/number- of-smartphone-users-worldwide/. 2. Mobile Operating System Market Share Worldwide [online]. Stat- counter Global Stats, 2020 [visited on 2020-10-20]. Available from: https://gs.statcounter.com/os- market- share/mobile/ worldwide. 3. WAGH, Dr. K; THOOL, Ravindra. A Comparative study of SOAP vs REST web services provisioning techniques for mobile host. Journal of Information Engineering and Applications. 2012, vol. 2, pp. 12–16. 4. About Swift, Features [online]. Apple Inc., 2020 [visited on 2020- 10-24]. Available from: https://swift.org/about/#features. 5. About Swift, Swift.org and Open Source [online]. Apple Inc., 2020 [visited on 2020-10-24]. Available from: https://swift.org/ about/#swiftorg-and-open-source. 6. Foundation [online]. Apple Inc., 2020 [visited on 2020-11-11]. Available from: https://developer.apple.com/documentation/ foundation. 7. UIKit [online]. Apple Inc., 2020 [visited on 2020-11-09]. Available from: https://developer.apple.com/documentation/uikit. 8. Android Studio release notes, Kotlin Support [online]. Google LLC, 2020 [visited on 2020-10-26]. Available from: https://developer. android.com/studio/releases#3-0-0. 9. Modern, concise and safe programming language [online]. Kotlin Foundation, 2020 [visited on 2020-10-26]. Available from: https: //kotlinlang.org/. 10. Kotlin Multiplatform Mobile [online]. Kotlin Foundation, 2020 [visited on 2020-10-26]. Available from: https://kotlinlang. org/lp/mobile/.
84 BIBLIOGRAPHY
11. What is NativeScript? – NativeScript [online]. Progress and com- munity, 2020 [visited on 2020-09-12]. Available from: https:// nativescript.org/faq/what-is-nativescript/. 12. How NativeScript Works [online]. Progress and community, 2020 [visited on 2020-09-12]. Available from: https://docs.nativescript. org/angular/core-concepts/technical-overview. 13. Data Binding [online]. Progress and community, 2020 [visited on 2020-09-14]. Available from: https://docs.nativescript.org/ angular/core-concepts/angular-data-binding.html. 14. React Fundamentals [online]. Facebook Inc., 2020 [visited on 2020- 09-18]. Available from: https://reactnative.dev/docs/intro- react. 15. Core Components and Native Components [online]. Facebook Inc., 2020 [visited on 2020-09-18]. Available from: https://reactnative. dev/docs/intro-react-native-components. 16. NGXS Introduction [online]. NGXS Community, 2020 [visited on 2020-11-13]. Available from: https://www.ngxs.io/. 17. JSX In Depth [online]. Facebook Inc., 2020 [visited on 2020-09- 20]. Available from: https : / / reactjs . org / docs / jsx - in - depth.html. 18. Ionicons v4 [online]. Drifty Co., 2020 [visited on 2020-12-15]. Available from: https://ionicons.com/v4/. 19. react-native-dialogs [online]. npm, Inc., 2020 [visited on 2020-11- 14]. Available from: https://www.npmjs.com/package/react- native-dialogs. 20. react-native-chart-kit [online]. npm, Inc., 2020 [visited on 2020-11- 16]. Available from: https://www.npmjs.com/package/react- native-chart-kit. 21. iOS and iPadOS Usage [online]. Apple Inc., 2020 [visited on 2020-12-26]. Available from: https://developer.apple.com/ support/app-store/. 22. WHAT IS COCOAPODS [online]. The CocoaPods Dev Team, 2020 [visited on 2020-09-22]. Available from: https://cocoapods. org/legal.
85 BIBLIOGRAPHY
23. Charts [online]. GitHub, Inc., 2020 [visited on 2020-11-20]. Avail- able from: https://github.com/danielgindi/Charts. 24. Material Design Icons [online]. Google LLC, 2020 [visited on 2020-11-18]. Available from: https://material.io/resources/ icons. 25. Command-Line Interface Setup [online]. Progress and community, 2020 [visited on 2020-11-22]. Available from: https : / / docs . nativescript.org/angular/start/quick-setup. 26. Setting up the development environment [online]. Facebook Inc., 2020 [visited on 2020-12-26]. Available from: https://reactnative. dev/docs/environment-setup. 27. Getting Started With NativeScript and Angular [online]. Progress and community, 2020 [visited on 2020-11-09]. Available from: https://docs.nativescript.org/angular/start/introduction. 28. Introduction to NativeScript-Vue [online]. Progress and commu- nity, 2020 [visited on 2020-11-09]. Available from: https : / / nativescript-vue.org/en/docs/introduction/. 29. Introduction to React Native [online]. Facebook Inc., 2020 [visited on 2020-11-09]. Available from: https : / / reactnative . dev / docs/getting-started. 30. Technologies [online]. Apple Inc., 2020 [visited on 2020-11-08]. Available from: https://developer.apple.com/documentation/ technologies. 31. About the Language Reference [online]. Apple Inc., 2020 [visited on 2020-11-08]. Available from: https://docs.swift.org/swift- book/ReferenceManual/AboutTheLanguageReference.html. 32. Debugging Applications [online]. Progress and community, 2020 [visited on 2020-09-24]. Available from: https://docs.nativescript. org/angular/start/cli-basics#debugging-applications. 33. Debugging [online]. Facebook Inc., 2020 [visited on 2020-09-24]. Available from: https://reactnative.dev/docs/debugging. 34. Required Device Capabilities [online]. Apple Inc., 2020 [visited on 2020-09-30]. Available from: https://developer.apple.com/ support/required-device-capabilities/.
86 A List of Electronic Attachments
• ReactNative.zip - Source code for the React Native application developed for iOS and Android platforms.
• Swift.zip - Source code for the native application developed using the Swift programming language.
• ReactNative.apk - File intended for installation on Android devices.
• Survey.csv - Generated output file from the conducted survey.
87 B Installation Manual for Developed Applica- tions
In order to run the developed React Native application, we need to follow these steps:
• Download the latest Node.js at https://nodejs.org/en/download/.
• Install Expo CLI using npm install -g expo-cli
• Install Expo Client on a device from the App Store or Play Store.
• Navigate to project in a terminal.
• Start the application with npm start.
• Scan the QR code on in the terminal with the Expo Client appli- cation.
In order to run the developed Swift application, we need to follow these steps (macOS is a prerequisite):
• Install Xcode from the App Store or the Apple developer portal (https://developer.apple.com/xcode/resources/).
• Open the project’s workspace (KapesniSkautIS.xcworkspace) with Xcode.
• Run the application with Run button or shortcut (Command + R).
88 C Conducted Survey
C.1 Pocket skautIS, comparrison of mobile applications
The goal of this survey is to compare user experience from the current Pocket skautIS application, available at platform stores with a newly developed application using React Native framework. Before you start completing this survey, be sure that you have both applications installed on your device or devices. Both applications work on a testing environment (https://test-is.skaut.cz), this is the reason you have to also install the provided Pocket skautIS application (if you have already installed this application from the store). Current testing application (icon with white background) is avail- able at this link: URL React Native application (icon with white background) is available at this link: URL Please read the instructions for each task in the heading of the section, use only the account mentioned in the current task. Account 1: account details Account 2: account details This survey is anonymous and will only be used for research pur- poses.
C.1.1 Introduction Questions
1. Which platform have you used for testing these applications? {Android; iOS}
2. What is your prior experience with Pocket skautIS application? {Advanced; Modest; None}
C.1.2 Delete Message
Task (testing Account 1): Sign in to the testing account and delete your last received message in the message section.
89 C. Conducted Survey
1. In which application did you have the best user experience while completing this task? {Current (white icon background); New (blue icon background); Same for both; Neither of them}
2. Briefly describe the reason behind the answer for the last ques- tion.
3. Briefly describe your user experience in the current application (white icon background) while completing this task.
4. Briefly describe your user experience in the new application (blue icon background) while completing this task.
5. Have you encountered any unwanted behaviour from the appli- cation side while completing this task (freezing, slowing down, bug, etc.)? If yes, briefly describe this behaviour.
C.1.3 Change User’s role
Task (testing Account 1): Change your role in the Profile section by taping on your current role. The choice of your next role is in your own decision. 1. In which application did you have the best user experience while completing this task? {Current (white icon background); New (blue icon background); Same for both; Neither of them}
2. Briefly describe the reason behind the answer for the last ques- tion.
3. Briefly describe your user experience in the current application (white icon background) while completing this task.
4. Briefly describe your user experience in the new application (blue icon background) while completing this task.
5. Have you encountered any unwanted behaviour from the appli- cation side while completing this task (freezing, slowing down, bug, etc.)? If yes, briefly describe this behaviour.
90 C. Conducted Survey C.1.4 Find User’s Address
Task (testing Account 1): Make sure that you have the role Stre- disko: vedouci/admin - 411.01 selected on your Profile page (if not, select this role). In the People section, search for person Novak Marin and find his resident address. 1. Enter the resident address of Novak Martin.
2. In which application did you have the best user experience while completing this task? {Current (white icon background); New (blue icon background); Same for both; Neither of them}
3. Briefly describe the reason behind the answer for the last ques- tion.
4. Briefly describe your user experience in the current application (white icon background) while completing this task.
5. Briefly describe your user experience in the new application (blue icon background) while completing this task.
6. Have you encountered any unwanted behaviour from the appli- cation side while completing this task (freezing, slowing down, bug, etc.)? If yes, briefly describe this behaviour.
C.1.5 Find Unit’s Leader Number
Task (testing Account 1): Make sure that you have the role Stre- disko: vedouci/admin - 411.01 selected on your Profile page (if not, select this role). In the Unit section, click on the head of the unit (Mesl Jan) and find out his telephone number. 1. Enter the telephone number (main) of the head of the Ko- privnice unit (Mesl Jan).
2. In which application did you have the best user experience while completing this task? {Current (white icon background); New (blue icon background); Same for both; Neither of them}
3. Briefly describe the reason behind the answer for the last ques- tion.
91 C. Conducted Survey
4. Briefly describe your user experience in the current application (white icon background) while completing this task. 5. Briefly describe your user experience in the new application (blue icon background) while completing this task. 6. Have you encountered any unwanted behaviour from the appli- cation side while completing this task (freezing, slowing down, bug, etc.)? If yes, briefly describe this behaviour.
C.1.6 Find Unit’s Registration Statistics
Task (testing Account 1): Make sure that you have the role Stre- disko: vedouci/admin - 411.01 selected on your Profile page (if not, select this role). In the Unit section, click on the Registration button and determine which age group had the biggest representation in the year 2010. 1. Which age group had the most representation in the year 2010? {to 6 years; to 15 years; to 18 years; to 26 years; above 26 years} 2. In which application did you have the best user experience while completing this task? {Current (white icon background); New (blue icon background); Same for both; Neither of them} 3. Briefly describe the reason behind the answer for the last ques- tion. 4. Briefly describe your user experience in the current application (white icon background) while completing this task. 5. Briefly describe your user experience in the new application (blue icon background) while completing this task. 6. Have you encountered any unwanted behaviour from the appli- cation side while completing this task (freezing, slowing down, bug, etc.)? If yes, briefly describe this behaviour.
C.1.7 Find Telephonic Spending
Task (testing Account 2): Log into the second account (if you are still logged in as Account 1). In the STS section click on the statistic button
92 C. Conducted Survey and determine which phone number spent the most resources (had the most call hours) 1. Which telephone number had the most telephonic spending in the last three months? {+420 732 970 083; +420 605132 000; blank}
2. In which application did you have the best user experience while completing this task? {Current (white icon background); New (blue icon background); Same for both; Neither of them}
3. Briefly describe the reason behind the answer for the last ques- tion.
4. Briefly describe your user experience in the current application (white icon background) while completing this task.
5. Briefly describe your user experience in the new application (blue icon background) while completing this task.
6. Have you encountered any unwanted behaviour from the appli- cation side while completing this task (freezing, slowing down, bug, etc.)? If yes, briefly describe this behaviour.
C.1.8 Overall Evaluation
1. In which application did you have the best user experience overall? {Current (white icon background); New (blue icon background); Same for both; Neither of them}
2. Briefly describe the reason behind the answer for the last ques- tion.
3. Have you encountered any unwanted behaviour from the appli- cation side overall (freezing, slowing down, bug, etc.)? If yes, briefly describe this behaviour.
4. Have you noticed any visual difference in the application el- ements or a piece of information which was present in one application but not the other? If yes, briefly describe this be- haviour.
93 D Charts From the Conducted Survey
This appendix contains visualized data from the conducted survey in the form of charts. Each chart has a caption which describes and references it to a given question from the survey.
Advanced Modest None
28,6%
71,4%
Figure D.1: Chart of the prior user experience with Pocket skatIS application, a question from section C.1.1.
NativeScript application React Native application Both applications Neither of them
42,9% 57,1%
Figure D.2: Chart of user application preference when completing the delete message task, a question from section C.1.2.
94 D. Charts From the Conducted Survey
NativeScript application React Native application Both applications Neither of them
14,3%
42,9%
42,9%
Figure D.3: Chart of user application preference when completing the change role, a question from section C.1.3.
NativeScript application React Native application Both applications Neither of them
28,6% 42,9%
28,6%
Figure D.4: Chart of user application preference when completing find user’s address task, a question from section C.1.4.
95 D. Charts From the Conducted Survey
NativeScript application React Native application Both applications Neither of them
14,3%
85,7%
Figure D.5: Chart of user application preference when completing the find unit’s leader phone number task, a question from section C.1.5.
NativeScript application React Native application Both applications Neither of them
14,3% 28,6%
57,1%
Figure D.6: Chart of user application preference when completing the find unit’s registration statistics task, a question from section C.1.6.
96 D. Charts From the Conducted Survey
NativeScript application React Native application Both applications Neither of them
14,3% 28,6%
57,1%
Figure D.7: Chart of user application preference when completing the find telephonic spending task, a question from section C.1.7.
NativeScript application React Native application Both applications Neither of them
14,3%
14,3%
71,4%
Figure D.8: Chart of overall user application preference, a question from section C.1.8.
97