Mobile application development using the ReactiveX framework

Transcription

1 Masaryk University Faculty of Informatics Mobile application development using the ReactiveX framework Bachelor s Thesis Robin Křenecký Brno, Spring 2018

2

3 Masaryk University Faculty of Informatics Mobile application development using the ReactiveX framework Bachelor s Thesis Robin Křenecký Brno, Spring 2018

4

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

6

7 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. Robin Křenecký Advisor: RNDr. Jaroslav Škrabálek i

8

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

10 Abstract The objective of this bachelor s thesis is to introduce reactive programming and to examine ReactiveX library, examine its application in mobile application development and evaluate advantages and disadvantages of its usage on a real world example. iv

11 Keywords Reactive programming, ReactiveX, ios, Android, RxSwift, Swift,... v

12

13 Contents 1 Introduction Thesis structure Mobile application development Mobile development platforms Types of mobile applications Programming languages used in mobile application development Design patterns used in mobile application development Delegate pattern Observer pattern Iterator pattern Architectural patterns used in mobile application development Model-View-Controller Model-View-ViewModel Functional Reactive Programming Brief history and development of FRP Classical FRP Real-Time and Event-Driven FRP Arrowized FRP Reactive manifesto Advantages of FRP FRP in mobile application development ReactiveX framework an in-depth look Brief history of the ReactiveX framework Overview of the ReactiveX framework Foundation of ReactiveX Observable Scheduler Operators Single Subject ReactiveX in mobile application development Advantages vii

14 4.4.2 Disadvantages Major ios frameworks Major Android frameworks Major multiplatform frameworks Practical demonstration Application structure Dashboard screen Tasks screen Task detail screen Search screen Used technologies and architecture Programming language Tools Frameworks External services Architecture pattern Implementation Implementation without ReactiveX framework Implemetation with ReactiveX framework Evaluation criteria Objective criteria Subjective criteria Criteria evaluation Objective criteria evaluation Subjective criteria evaluation Summary of criteria evaluations Conclusion 47 Bibliography 49 A Code snippets 57 A.1 ViewController ViewModel communication A.1.1 ViewController ViewModel communication without ReactiveX A.1.2 ViewController ViewModel communication with ReactiveX viii

15 A.2 Address searching A.2.1 Address searching without ReactiveX A.2.2 Address searching with ReactiveX A.3 Timer creation A.3.1 Timer creation without ReactiveX A.3.2 Timer creation with ReactiveX A.4 Image downloading A.4.1 Image downloading without ReactiveX A.4.2 Image downloading with ReactiveX A.5 Tab Bar interaction A.5.1 Tab Bar interaction without ReactiveX A.5.2 Tab Bar interaction with ReactiveX ix

16

17 List of Tables 5.1 Performance tests results Code analysis tests results 42 xi

18

19 List of Figures 2.1 UML diagram of the delegate pattern UML diagram of the observer pattern UML diagram of the iterator pattern Model-View-Controller [24] Model-View-ViewModel [24] Reactive traits [32] Marble diagram for map operator [50] A use case diagram of the demonstrative application Screenshot of the dashboard screen Screenshot of the tasks screen Screenshots of task detail and address selection screens Screenshots of the search screen Model-View-ViewModel-Coordinator [83] Screenshot of the project folder structure 37 xiii

20

21 1 Introduction Mobile applications are continually gaining in complexity these days, and there are three main reasons behind it [1]. One reason is that it s not just smartphones anymore that are considered to be mobile devices. The mobile device catalog spans smartphones, tablets, phablets, convertible laptops, and wearables. Supporting all these devices is necessary in order to succeed in the mobile application industry. There is also a near-constant pace of upgrades of operating systems (OS) with little notice in advance. That was not a factor in the desktop environment where OS updates were expected every two to three years. Nowadays a major update takes place every six to twelve months. The final reason is the pressure for always-on availability and quick application responses. That means that there is a very little room for bugs and errors in mobile application development. The rising complexity means that developing a feature-rich mobile application has become a very demanding task. To create a responsive and robust app developers have to deal with a multitude of concurrent tasks like user input handling, playing audio, or making networking calls. That can cause a lot of trouble. The ReactiveX framework aims to help developers with these demanding tasks by solving the issues related to asynchronous programming. In a mobile application development, ReactiveX is one of the hottest topics today as a presentation about it is given at almost every international conference or even a local meetup [2]. The goal of this thesis is to introduce functional reactive programming and to examine ReactiveX framework, specifically focusing on its application in mobile application development, and comparing the development of a mobile app with and without the ReactiveX framework. 1

22 1. Introduction 1.1 Thesis structure The thesis is divided into four parts. The first part describes mobile application development from a technological point of view. It focuses on used technologies such as programming languages and design patterns. The second part describes Functional Reactive Programming, its history, advantages and its use in mobile application development. The third part provides an in-depth look into the ReactiveX framework, describes its history, elements of its interface and its use in mobile application development. Finally, in the fourth part, a comparative practical demonstration of the ReactiveX framework usage is presented and evaluated. 2

23 2 Mobile application development Mobile application development is the set of processes and procedures involved in writing software for small, wireless computing devices such as smartphones or tablets [3]. It has been gaining in popularity as mobile devices become more and more important 1. Today, over 20 % of all developers work as mobile application developers while in 2013 it was just above 7 % [5, 6]. This chapter introduces available mobile development platforms, discusses different approaches to mobile application development, and also deals with the use of programming languages and design and architectural patterns. 2.1 Mobile development platforms As of today, there are two leading platforms for which mobile apps can be developed: Android and ios. Together they cover over 99.5 % of total market share [7]. Android An open-source mobile operating system developed by Google and unveiled in 2007 [8]. It is based on a modified version of the Linux kernel and it is designed primarily for touchscreen mobile devices. Google has also developed versions of Android for televisions, cars and wrist watches. Nowadays it is the most commonly used operating system in mobile devices 2. ios A mobile operating system created and developed by Apple exclusively for its hardware. It was originally unveiled in As of today, it powers iphone, ipad and ipod Touch.[9] 1. For example, in % of web traffic came from mobile devices in US [4]. 2. With over 87 % of total market share [7] 3

24 2. Mobile application development 2.2 Types of mobile applications In general, there are three types of mobile applications: native, hybrid and web [10]. Native applications Native apps are developed for a single mobile operating system exclusively. They have to be developed using tools required by the specific platform, such as programming language or development environment. These apps are usually harder to build, but in return, they offer higher performance and better user experience as they use the native device user interface. Web applications Web apps consist of a web page that is optimized for a mobile device, and they use an internet browser to run. Their advantage is that they don t need to be downloaded and the development is easier and faster, but their usability is limited to the web browser. Hybrid applications Hybrid apps are a combination of native and web applications. They are developed using web technologies, and they are wrapped in a container that allows them to run natively on a mobile device. They are fast and relatively easy to build, but they lack in performance, speed, and overall optimization when compared to native apps. 2.3 Programming languages used in mobile application development Programming languages differ across the platforms and types of mobile applications [11]. The traditional languages in native application development are Java for Android and Objective-C for ios, both strongly typed, imperative and object-oriented languages. Lately, the popularity of these languages has been in decline as new languages appear, such as Swift for ios and Kotlin for Android, both very similar languages that are receiving a lot of attention in 4

25 2. Mobile application development mobile application development today [12, 13]. These languages have a lot in common as they both are general-purpose, multi-paradigm languages that focus on type safety and productivity. They also bring a lot of concepts and patterns from functional programming. In web and hybrid applications development JavaScript, a weakly typed, high-level object-oriented language, is most commonly used as it is the most popular language worldwide today [6]. Among other languages used in mobile application development is C#, used in the popular Xamarin [14] framework, or C++, a general purpose language used mostly in mobile game development. 2.4 Design patterns used in mobile application development During development, developers encounter many problems. It is likely that other developers had faced similar issues and had come up with various solutions. A design pattern is such solution that is commonly used for an occurring problem within a given context [15]. There are many design patterns used in mobile application development. Among the commonly used patterns are delegate, observer and iterator pattern [16, 17] Delegate pattern Delegate pattern is a software design pattern that enables an object, called delegator, to hold a reference to another object, called delegate. The delegator then delegates operations to the delegate. That allows object composition to achieve the same code reuse as inheritance [18]. 5

26 2. Mobile application development Figure 2.1: UML diagram of the delegate pattern Observer pattern Observer pattern is a software design pattern that enables an object, called observer, to register with and receive notifications from another object, called subject. Subject maintains a list of multiple observers, so the pattern is used when there is a one-to-many relationship between objects. Whenever a predefined event, condition or state change occurs, the subject automatically notifies all observers by calling one of their methods [19]. The typical implementation of observer pattern requires the observer to have a reference to the subject. This implementation is considered "tightly coupled" [20] because it forces both the observer and the subject to be aware of each other and to have access to each other s internal parts. That can lead to a couple of issues, for example with speed, scalability, maintenance or message recovery. This pattern can also lead to memory leaks, as the typical implementation requires both explicit registration and explicit deregistration. It is necessary to do so because the subject holds strong references [21] to its observers. These are not the only problems that the observer pattern encounters. For example, the order of events in which the observers are notified is unpredictable, and multithreading is almost impossible and usually avoided. Also, in a typical scenario, one would like to be notified of the initial value of the subject already on registration. In the standard observer pattern this is impossible and to receive the initial value, one has to ask for it right after the registration. 6

27 2. Mobile application development Figure 2.2: UML diagram of the observer pattern Iterator pattern Iterator pattern is a widespread pattern in object-oriented programming [22]. The iterator is an object that is used to traverse a container in sequential manner without any need to know its underlying representation. It is used to provide access to a container s elements. Figure 2.3: UML diagram of the iterator pattern. 7

28 2. Mobile application development 2.5 Architectural patterns used in mobile application development Architectural patterns are very similar to design patterns but they differ in their scope. Design patterns only affect a specific section of the code base; on the other hand, architectural patterns have a much broader impact [23]. Architectural pattern decides how the code is layered and how the requests are processed from the outer layers to the inner layers. There are, of course, lots of architectural patterns used in mobile application development. The most popular architectural pattern is the Model-View-Controller pattern. Nowadays, the Model-View-ViewModel pattern is gaining a lot of attention and many developers are starting to use that instead [24] Model-View-Controller In this architecture, the application is divided into three layers, where each of them has its own responsibilities. A Model represents the business logic of the app, a View represents the UI components of the application, and a Controller is an intermediary between the Model and the View that manages how the Model should be presented on the View. Figure 2.4: Model-View-Controller [24] 8

29 2. Mobile application development Model-View-ViewModel The difference from the MVC pattern is the presence of a ViewModel. ViewModel is a kind of middle layer between the Model and the Controller with the View. Its purpose is to take the presentation logic away from the View and the Controller, which results in thin and flexible View and Controller. That is important for testability, extensibility, reusability, and maintainability of the app. Figure 2.5: Model-View-ViewModel [24] 9

30

31 3 Functional Reactive Programming Functional Reactive Programming (FRP) is a programming paradigm for reactive programming that uses the building blocks of functional programming. Reactive programming is an asynchronous programming paradigm that revolves around data streams and propagation of change. In other words, programs which propagate all the changes that affected its data/data streams to all the interested parties (such as end users, components and sub-parts, and other programs that are in some way related) are called reactive programs [25]. Simply said, reactive programming is programming with asynchronous data streams. The fundamental idea behind FRP is to model things like user input and animations in a more direct, declarative way by making their behavior over time more explicit. The declarative approach makes a distinction between the what and the how of programming. A declarative language allows the programmer to say what without having to specify exactly how. In FRP many of the not so relevant details are left for the compiler to figure out. This declarative approach allows the programmer to think on a much higher level [26]. 3.1 Brief history and development of FRP Classical FRP Functional Reactive Programming was initially formulated by Paul Hudak and Conal Elliott in their 1997 paper Functional Reactive Animation [27]. Their implementation was called Fran, and it was written in Haskell functional programming language with the focus on animations. Two types of values were introduced: Events and Behaviors. Events represent a value at a particular time as a time-ordered sequence of event occurrences. They can model any discrete events. Originally they were intended for animations. Behaviors represent values that change continuously over time. Behaviors are time-varying, reactive values that always exist but 11

32 3. Functional Reactive Programming can be constantly changing. They are expressed as a function from a time to value. Fran had problems with space and time leaks. Memory usage could grow unexpectedly which resulted in surprisingly long computations. Programs that were relying on previous values could also cause different memory leaks in which the program was forced to remember all the previous values of a Behavior or Event. Memory usage could grow in proportion to the application running time Real-Time and Event-Driven FRP Real-time FRP was introduced by Paul Hudak and others at Yale in 2001 with the aim to resolve the inefficiencies of Classical FRP [28]. It overcame both space and time leaks at the cost of expressiveness. It introduced a Signal type - a type that can represent both Event and Behavior. Real-time FRP also ensured that Signals couldn t be used in ways that do not have an explicit, efficient implementation. It presented a two-tiered language: an unrestricted base language and a more limited reactive language for manipulating signals. In 2002 Hudak et al. proposed Event-Driven FRP [29] that introduced Discrete Signals - Signals that only changed on events. The programs were event-driven in that no changes needed to be propagated unless an event had occurred. Even though Real-Time and Event-Driven FRP solved many efficiency problems of Classical FRP, research focus had shifted away from this approach with the hope of recapturing the full expressiveness of Classical FRP Arrowized FRP Arrowized FRP was introduced by John Peterson, Antony Courtney, and Henrik Nillson at Yale in 2002 [30]. It aimed to resolve space and time leaks of Classical FRP and to maintain its full expressiveness. Instead of Events and Behaviors, it used Signal Functions, functions from Signal (the same Signal as in Real-Time FRP) to Signal. To avoid space and time leaks, programmers could only program with Signal Functions. Signals were not directly available. Signal Functions were conceptually equivalent to regular functions, but they made 12

33 3. Functional Reactive Programming it possible to avoid leaks in the implementation of the Arrowized FRP system because the evaluation of recursive functions could be carefully controlled. Unfortunately, Arrowized FRP inherited continuous signals from Classical FRP which was a foundational problem. The reason for it was the so called instant-update assumption: it had been proven that the continuous semantics could only be respected when the updates were instantaneous [31]. At least two problems made the instant-update assumption untrue on a real-machine: global delays and unnecessary updates. Global delays were caused by lengthy computations. Updates in these FRP systems were processed one at a time in the exact order of occurrence. And because updates do take time, and sometimes significant amount of time, the instant-update assumption couldn t be correct. One long-running computation would slow down the whole program. Unnecessary updates were caused by discrete inputs. Continuous signals assumed that signal values were always changing. Consequently, it was necessary to recompute the whole program as often as possible. There are many discrete inputs in every computer program (for example user input) therefore the program had to be recomputed even though the values might not have changed. This certainly wasted a lot of computing time. 3.2 Reactive manifesto The Reactive Manifesto [32] is a document defining the four reactive principles. It states that reactive systems are: 13

34 3. Functional Reactive Programming Responsive They respond promptly on time, and they focus on providing rapid and consistent response time to deliver consistent quality of service. This behavior then simplifies error handling, builds end user confidence and encourages further interaction. Resilient They stay responsive in case of any failure. Resilience is achieved through replication, containment, isolation and delegation. Failures are contained within each component. It isolates components from each other so that the failure that occurs in one component doesn t affect other parts of the system. Elastic They stay responsive under varying workload. The elasticity is achieved cost-effectively on commodity hardware and software platforms. Message driven They rely on asynchronous message passing. Non-blocking communication allows recipients to only consume resources while active, leading to less system overhead. Figure 3.1: Reactive traits [32] By implementing these four principles, systems become reliable and responsive, and that is what makes them reactive. 14

35 3. Functional Reactive Programming 3.3 Advantages of FRP The most important benefits of functional reactive programming are: No need to use callbacks Callback is an executable code that is called when a predefined event occurs. It is primarily used for asynchronous operations (asynchronous callback). Implementing a callback can be a tedious task that requires a lot of code, especially in some languages (for example in Java). Sometimes it is referred to as callback hell [33]. FRP offers different mechanisms for the tasks that generally require the use of callbacks. Threading and asynchronous operations made easy Working with threading is usually considered difficult in imperative languages [34]. FRP is built upon functional programming which makes threading easier by being stateless and by eliminating side-effects. This prevents both race conditions and lockouts. Threading and asynchronous operations are interrelated so as the threading gets more natural, so does asynchronous programming. Same API for every operation Reactive frameworks offer very intuitive and straightforward APIs that can be used for anything, be it computations, database accesses, animations, networking or user input handling. Standardized error handling Error handling is a significant concern when dealing with complex tasks, especially in networking. Reactive frameworks offer a standardized way to handle errors which can make error handling much less exhaustive. Declarative, readable code FRP models things in a declarative way which means that the code doesn t have to explain how the result is being achieved explicitly, but instead it only describes what the result should be. Therefore it is much easier to read the code and understand what its purpose is. 15

36 3. Functional Reactive Programming Testable and maintainable code A code that is declarative, readable and that uses the same API for every operation is much easier to test and maintain. It is possible to say that development and maintenance costs are reduced by using FRP. 3.4 FRP in mobile application development There are many frameworks used in mobile applications development that are built on FRP principles. It is important to note that these socalled reactive frameworks are not FRP implementations in its entirety. Reactive framework in mobile application development is a framework that is heavily inspired by FRP and uses some of its features. Their primary purpose is typically simplifying work with asynchronous events. The largest FRP inspired frameworks include: Sodium Sodium is a general purpose FRP system. It is part of a project to implement reactive libraries with similar interfaces across a range of programming languages [35]. It is probably the purest FRP framework. Sodium has a finished implementation in Kotlin and Java, so it can be used for developing mobile applications for Android platform. ReactiveX ReactiveX is a framework for composing asynchronous and event-based programs by using observable sequences [36]. It is the most commonly used reactive framework and will be discussed further in the following chapter. MobX MobX is a state management library for JavaScript frontend application [37]. It can be used in combination with React Native for hybrid mobile application development [38]. MobX seeks to derive the state of the app using Transparent Functional Reactive Programming [39]. 16

37 4 ReactiveX framework an in-depth look 4.1 Brief history of the ReactiveX framework Not long time ago object-oriented programming (OOP) was seen as the golden hammer to all developer s challenges. However, with increasing complexity of systems, it started to became clear in around 2008 that object-oriented programming cannot solve all problems [40]. In OOP, object and classes can become very chaotic when they need to interact with each other in increasingly complex and sometimes unplanned ways. Many decoupling design patterns help to solve these problems [41] but with them comes an unwanted side effect in the form of growing amounts of boilerplate code. Following these problems, functional programming started to get back in to play to complement OOP and help it to solve its problems. Functional reactive programming began to receive special attention and frameworks based on FRP emerged. One of the first reactive frameworks included Akka and Sodium 3.4. In 2009 at Microsoft, a computer scientist named Erik Meijer created a reactive programming framework for.net called Reactive Extensions (ReactiveX or Rx) [42]. In a few years time, ReactiveX was ported to many languages and platforms, including C++, Java, Python, JavaScript, Swift, etc. Nowadays ReactiveX is a cross-language standard in bringing reactive programming into the industry. 4.2 Overview of the ReactiveX framework ReactiveX (Rx) is a library for composing asynchronous and eventbased programs by using observable sequences. It extends the observer pattern to support sequences of data or events and adds operators that allow one to compose sequences together declaratively while abstracting away concerns about things like low-level threading, synchronization, thread-safety, concurrent data structures, and non-blocking I/O [36]. It is a combination of the best ideas from the observer pattern 2.4.2, the iterator pattern and FRP. One big difference from pure FRP is 17

38 4. ReactiveX framework an in-depth look that FRP operates on values that change continuously over time, while ReactiveX operates on discrete values that are emitted over time. ReactiveX basically deprecates the observer pattern and introduces an Observable type that solves almost all issues of the observer pattern [43]. The Observable is also an equivalent to iterator but with one big difference: the iterator pattern is a typical pull mechanism. In a pull mechanism, the consumer determines when it receives data from the producer. The producer itself is unaware of when the data will be delivered to the consumer. The data can only arrive synchronously because when the consumer pulls the data, the thread is blocked until those data arrive. An Observable is a push version of the iterator. In push mechanism, the producer pushes the data to the consumer whenever data are available. This approach is more flexible as the values can arrive both synchronously and asynchronously. An Observable type also has the ability to signal to the consumer that there are no more data available and it can also indicate to the consumer that an error has occurred. With these additions, it fully matches all semantics available on the iterator. The only difference is the direction in which the data flows. This means that any operation that can be performed on iterator can also be performed on an Observable. More details on the Observable will be provided in the next section. 4.3 Foundation of ReactiveX The three central concepts of ReactiveX are its Observable, Scheduler and operators. Other interesting blocks of ReactiveX include Subject and Single Observable An Observable [44] is an object to which another object, called observer, subscribes. The observer then reacts to whatever item or sequence of items (events) the Observable emits. In another context, an observer might be called a reactor, watcher or a subscriber. This model is usually referred to as the reactor design pattern [45]. 18

39 4. ReactiveX framework an in-depth look This pattern easily allows for concurrent operations because it doesn t block the thread while waiting for the Observable to emit events. Instead, it creates a watch in the form of an observer that is ready to react to the events at whatever future time they are emitted by the Observable. Subscribing to an Observable An observer is connected to an Observable through the Subscribe method. There are three subsets of this method that are called by an Observable under different circumstances:» onnext Every time the Observable emits new event it calls this method with the event as its argument.» onerror If the Observable fails to emit the expected event or encounters some other error, it calls this method with the error passed as the argument. If this method is called, the Observable stops emitting new events.» oncompleted This method is called by an Observable after it has called the onnext method for the final time, on the condition that onerror method was never called. 19

40 4. ReactiveX framework an in-depth look A subscribe call example written in pseudocode looks as follows: // create new Observable instance observable = someobservable(arguments) // create functions for subscription onnext = { event -> /* do something with the event */ } onerror = { error -> /* react to the occurred error */ } oncompleted = { /* perform a clean up when subscription ends */ } // subscribe to the Observable observable.subscribe(onnext, onerror, oncompleted) Unsubscribing from an Observable In some Rx implementations, the Subscribe methods has a return value of a Subscriber. A Subscriber is an interface that implements unsubscribe method. When this method gets called, it indicates that the Subscriber is no longer interested in the subscription. The subscription then ends and is released from memory. Finite and infinite Observables An Observable that emits a finite number of events and after the last emission calls its oncompleted method is a finite Observable. On the contrary, an Observable that never calls its oncompleted method and that may theoretically produce new events indefinitely is an infinite Observable. An example of an infinite Observable might be an Observable that produces new event when a user clicks on a particular key on the keyboard because it doesn t know when will be the last time the user is going to click on the key. "Cold" and "hot" Observables The time when an Observable begins to emit events depends on whether the Observable is "cold" or whether it is "hot". A "cold" Observable waits until an observer subscribes to it before it begins to emit events. Therefore the observer is guaranteed to receive all events that the Observable emits. A "hot" Observable begins to emit events as soon as it is created. 20

41 4. ReactiveX framework an in-depth look Any observer who later subscribes to that Observable will only receive events that the Observable emitted after the subscription Scheduler A Scheduler [46] is an abstraction over multithreading and concurrency. It can be thought of as a thread pool, from which Rx can pool a thread and execute its task on it. Rx offers a variety of different Schedulers that can be used. The variants of a Scheduler differ in every Rx framework, but common variants are for example a MainScheduler that operates on a main thread or a BackgroundScheduler that can be used for work on a background thread. By default, an Observable will notify observers on the same thread on which its Subscribe method is called. The SubscribeOn can be used to change this behavior by specifying a different Scheduler on which the Observable should operate. The ObserveOn operator determines a different Scheduler that the Observable will use to send notifications to its observers Operators Operators [47] are the horse-power behind Observables, providing an elegant, declarative solution to complex asynchronous tasks. They are the real strength of the Rx framework because functional programming allows us to significantly decouple dependencies and separate business logic, that operates within clearly defined boundaries of simple streams of a data object [48]. Each ReactiveX framework implements its own set of operators. Although there is much overlap between the implementations, there are also some operators that are only implemented in specific frameworks. Even the names of the operators differ across the frameworks. Operators usually operate on an Observable and they return an Observable. That allows for operator chaining. Each operator in the chain then modifies the Observable that was emitted from the previous operator. That is similar to the Builder design pattern [49] with one difference. In a classic Builder pattern the order in which the methods appear doesn t matter but with Observable operators order matters. 21

42 4. ReactiveX framework an in-depth look Marble diagrams For better visualization of how the data are transformed through each operator, Rx documentation uses so-called Marble diagrams. It is just a timeline that is read from left to right, and that shows how the values are transformed in time. Usually, there are two of these timelines. The first one shows the events before the operator modified them and the following timeline shows the events after the modification. Figure 4.1: Marble diagram for map operator [50] Creating operators These operators are used for originating of new Observables: 22 Create Creates an Observable from scratch. This operator takes a function that accepts the observer as its argument. The function then calls observer s onnext, onerror and oncompleted methods as needed. Just Simply converts an item into an Observable that emits that item as an event. Interval Creates an Observable that emits an infinite sequence of ascending integers with a constant time interval between the emission that is specified on operator call.

43 Transforming operators 4. ReactiveX framework an in-depth look These operators transform events that are emitted by an Observable: Map Applies a function to each emitted event by an Observable and transforms it into a new event. FlatMap Quite similar to a Map operator, but instead of a transformation into a new event it transforms the source Observable into a new Observable that itself emits events. Scan Applies a function to the first event emitted by the source Observable and then emits the result of that function as its own first emission. This operator is sometimes called an accumulator in other contexts. Filtering operators These operators selectively emit items from a source Observable: Debounce Makes sure that event is only emitted from an Observable only if a particular timespan has passed without it emitting another event. Distinct Filters Observable events by only allowing those that have not already been emitted. Filter Emits only those items from an Observable that pass a predicate test. Skip Ignores first n events emitted by an Observable. The number of ignored events is specified on operator call. 23

44 4. ReactiveX framework an in-depth look Take Emits only the first n events emitted by an Observable and then completes while ignoring remaining events. The Number of emitting events is specified on operator call. Combining operators These operators work with multiple source Observables and create a single Observable: Merge Combines numerous Observables into one by merging events that they emit. Concat Concatenates the output of various Observables with all of the events emitted by the first Observable being emitted before any of the events emitted by the second Observable, and so forth if there are more than two Observables. Zip Combines the events emitted by multiple Observables by applying a specified function and emits a single event for every combination based on the result of this function. Other operators Only a few most often used operators were described in this section as describing every available operator is above the scope of this thesis. Other interesting operators may include error handling, utility, mathematical or conditional operators. A list of all standardly available operators can be found in Rx documentation [47] Single Single [51] is an Observable variant developed in some ReactiveX frameworks (for example in RxJava or RxSwift 4.4.3). In comparison to an Observable it always either emits only a single value or an error. For that reason, there are only two methods to subscribe to: 24

45 4. ReactiveX framework an in-depth look» onsuccess The sole item that the Single emits is passed to this method.» onerror The error that caused the Single to be unable to emit an item is passed to this method. A Single calls only one of these methods and it calls it just once. After the call, Single terminates, and the subscription to it ends. As Observables, Singles can also be manipulated through a variety of operators. Some operators can be used both on Observables and Singles Subject A Subject [52] acts both as an observer and as an Observable. It can subscribe to one or more Observables, and it can pass through the items it observes by reemitting them, and it can also emit new items. When Subject subscribes to an Observable, the Observable will begin emitting items. That can make an original "cold" Observable a "hot" Observable. Versions of Subject A Subject can come in different versions. Each of them is designed for a particular use case. Typically there are four versions of Subject: PublishSubject Emits those events to the observer that are emitted by the source Observable after the time of the subscription. BehaviorSubject Emits all the events that PublishSubject emits and it also emits the most recently emitted event when an observer subscribes to it. ReplaySubject Emits all of the events that were emitted by the source Observable regardless of when the observer subscribes. 25

46 4. ReactiveX framework an in-depth look AsyncSubject When the source Observable completes, AsyncSubject emits the last value emitted by the source Observable and then terminates. 4.4 ReactiveX in mobile application development Almost every mobile application involves asynchronous operations such as network requests, geolocations or database requests. Using these operations effectively is critical in creating great user experience. That can be a huge challenge for developers, and therefore a framework that largely simplifies working with asynchronous operations is a great deal. For this reason, ReactiveX is a big topic in mobile application development nowadays. For example, the Java version of ReactiveX, RxJava, is with over 32 thousand stars the most liked Java framework on GitHub [53] Advantages All of the advantages that were described as advantages of FRP 3.3 also apply to the ReactiveX framework. The most critical benefit in mobile application development is the possible lower development and maintenance cost that the usage of Rx can bring as the development should eventually become faster because a lot of possible bugs that can occur during development are eliminated Disadvantages The most considerable disadvantage of ReactiveX is that it comes with a steep learning curve especially for developers that have experience only with imperative programming languages. Rx requires a different mindset as it is a different programming paradigm. Another disadvantage is that it is a significant framework dependency. It would be a huge problem for developers if the community stopped developing the framework. Fortunately, the community 1. Especially bugs related to concurrency as the side-effects are limited and therefore there are fewer race-conditions [54]. 26

47 4. ReactiveX framework an in-depth look around Rx is huge nowadays, and the framework is broadly used, even by some large companies 2, so this situation is highly unlikely. Especially in some languages, the debugging can become very difficult with Rx framework as the stack trace might grow huge, and the debugger might not be able to provide sufficient help. To make debugging little bit easier, Rx has a Debug operator that provides more information about the Observable on which it is used. Rx can also become memory intensive in some, yet rare, situations because it is based on streams of data that can become very large. Another problem might be an over usage of the framework. Rx is just not ideal for every situation, and it is easy to forget about it. This can lead to enforcing of using the framework even in cases where it doesn t make any sense Major ios frameworks RxSwift ReactiveX version written in Swift programming language [56]. It is the most commonly used reactive framework on ios platform. ReactiveSwift Apart from RxSwift, ReactiveSwift is not a direct implementation of ReactiveX APIs. It is an opinionated implementation of functional reactive programming that is heavily inspired by ReactiveX [57]. ReactiveSwift is mainly trying to simplify some Rx APIs and better match the Swift programming languages conventions. ReactiveObjC Legacy version of ReactiveSwift that is implemented in Objective- C programming language [58] Major Android frameworks RxJava One of the most used ReactiveX frameworks. It is written in Java programming language for Java Virtual Machine [53]. 2. For example Microsoft, Netflix or GitHub [55]. 27

48 4. ReactiveX framework an in-depth look RxKotlin RxJava can be directly used with Kotlin programming language. This lightweight library adds convenient extension functions to RxJava so that the usage in Kotlin is more natural and uses a full power of the language [59]. RxAndroid Module for RxJava that adds minimum classes that make writing reactive components in Android applications easy [60] Major multiplatform frameworks RxJS The biggest ReactiveX library for JavaScript programming language [61]. It can be used together with React Native multiplatform development framework [38]. 28

49 5 Practical demonstration In this chapter, a practical demonstration that displays ReactiveX framework in practice and shows how the common tasks are implemented will be presented. The demonstration should also reveal the actual advantages and disadvantages of the Rx framework usage. The practical demonstration consists of a native ios mobile app that is developed twice once with and once without the ReactiveX framework. That shows how things that are implemented in a traditional way are implemented with Rx and it also allows for direct comparison based on evaluation criteria that will be described later in the chapter. 5.1 Application structure The demonstrative app is a to-do list with some enhancements. It allows for adding tasks with a description, address, and start and end time. The task progress can be tracked. It also allows for tasks searching and receiving today s weather forecast. Figure 5.1: A use case diagram of the demonstrative application. 29

50 5. Practical demonstration The app is structured in a way that should cover typical common areas of mobile application development such as networking, data persistence and geolocation. It is split into four main screens a dashboard screen, tasks screen, task detail screen, and a search screen Dashboard screen The dashboard screen shows the tasks that are on plan for today. It also shows user s location and today s weather foreast for that location. The tasks are shown in a table view. If there is no task for today, a message informing about that is shown to the user. The task cell contains a task name, address, date, and its state. The task state can be one of planned, in progress, rejected or completed. If the task state is different than planned a time ticker is shown next to the task state name with current task progress. By clicking on the cell, the task detail screen is shown. In the top right of the screen, there is a button. By clicking on it, a table view with informations about used frameworks is shown to the user. Figure 5.2: Screenshot of the dashboard screen. 30

51 5. Practical demonstration Tasks screen The tasks screen shows all the user s tasks as an infinite table view that is initially scrolled on today s task. If there is no task for today an empty cell for today s date is shown. The task cell is the same as in dashboard screen and has the same interactions. In the top right of the screen, there is a button for adding a new task. By clicking on it, an empty task detail screen is shown, and the user can fill the task details. Figure 5.3: Screenshot of the tasks screen Task detail screen The task detail screen shows a detail of the task. In the top of the screen, it shows a task location on the map. Beneath it, there is a task state, and under the state there are buttons that allow for task state change. Under these buttons, there are fields with task name, description, address, start date and task duration. In the top right of the screen, there is an edit button. By clicking on it, the task detail screen becomes interactive, and the user can change 31

52 5. Practical demonstration the task s information. Also, a delete button appears at the bottom of the screen. By clicking on the delete button, a task is deleted. While in interactive mode, clicking on a task address shows a screen in which the user can search for an address. Figure 5.4: Screenshots of task detail and address selection screens Search screen The search screen allows for task searching. A task can be searched by all of its attributes. The found tasks are shown in a table view with the same task cell as in tasks and dashboard screens. By clicking on a task the task detail is shown, and the search is saved. The saved search is the found attribute of the task (for example a task name if the task name contains searched text). The search is also saved by clicking on search button. In that situation, the searched text is saved. When there are some saved searches, initial search screen shows them as the most recent or suggested searches. Suggested searches are the most often used searches without the recent ones. 32

53 5. Practical demonstration Figure 5.5: Screenshots of the search screen. 5.2 Used technologies and architecture Programming language The application is written in Swift 4.1 programming language [62]. Swift is a general-purpose, multi-paradigm, compiled programming language developed by Apple for ios, tvos, macos, watchos and Linux operation systems. It is designed to work with Apple s Cocoa and Cocoa Touch frameworks and the vast body of existing Objective- C code written for Apple products. The development of Swift started in 2010 by Chris Lattner. The first stable version was released in 2014, and in December 2015 it became open source [63] Tools Xcode Integrated development environment developed by Apple containing a suite of software development tools for developing 33

54 5. Practical demonstration software for macos, ios, watchos and tvos operation systems [64]. Git Most widely used modern version control system in the world. It is an actively maintained open source project initially developed in 2005 by Linus Torvalds [65]. CocoaPods Dependency manager for Swift and Objective-C Cocoa projects. It aims to improve the engagement and discoverability of thirdparty open-source Cocoa libraries [66] Frameworks Frameworks used in this app consist of standard Apple s Cocoa Touch frameworks and a few open source frameworks. Cocoa Touch is a set of UI frameworks for building software programs to run on ios, tvos or watchos operation systems. Cocoa Touch frameworks used in this project contain: 34 Foundation Foundation framework provides a base layer of functionality for apps and frameworks, including data storage and persistence, text processing, date and time calculations, sorting and filtering and networking [67]. UIKit UIKit gives the required infrastructure of ios applications. It provides the window and views architecture for implementing interfaces, the event handling infrastructure for delivering inputs into an app and the main run loop needed to manage interactions among the user, the system, and the app [68]. MapKit Framework that embeds map directly into app windows and views [69]. CoreLocation Framework that obtains geographic location and orientation of a device [70].

55 ReactiveX open source frameworks include: 5. Practical demonstration RxSwift ReactiveX implementation in Swift programming language. Introduced in the previous chapter RxCocoa RxSwift s extension with reactive bindings for Cocoa touch frameworks [71]. RxGesture Reactive wrapper for view tap gestures, swipe gestures, pan gestures etc [72]. RxDataSources UITableView and UICollectionView data sources for RxSwift. It helps especially with the implementation of sectioned UITable- View or UICollectionView [73]. RxAnimated Framework that embeds animated interface for RxCocoa bindings [74]. RxAlamofire Simple reactive wrapper around Alamofire library [75]. Other used open source frameworks include: Alamofire Swift-based HTTP networking library for ios. It provides an elegant interface on top of standard s ios interface. It is used to simplify common networking tasks [76]. AlamofireImage Simple image component library for Alamofire that makes image downloading easy [77]. Realm Mobile database built from the ground up to run directly inside phones. Realm uses very little resources, is easy to use and is faster than any current alternative [78]. 35

56 5. Practical demonstration SwiftLint Tool that enforces Swift coding style and conventions [79]. R.swift Code generator for resources like images, fonts and storyboards in Swift projects. It helps to get the code fully typed and limits the need of type casting [80]. AcknowList Simple library that helps to list all CocoaPods frameworks that are used in the project [81] External services The app uses OpenWeatherMap s API [82] for weather forecast fetching in the dashboard screen Architecture pattern The architecture used throughout this project is a Model-View-ViewModel- Coordinator (MVVM-C). It is a combination of largely used MVVM architecture and the Coordinator pattern [83]. The Coordinator pattern introduces a new object that encapsulates a lifecycle and takes all of the application s driving logic. It s task is to create, present and dismiss views while keeping them independent. Figure 5.6: Model-View-ViewModel-Coordinator [83] 36

57 5. Practical demonstration 5.3 Implementation The application is divided into three main parts - API, Model, and Screens. The purpose of the API is network communication. The Model manages the data in the application, and the Screens contain all necessary implementation that relates to everything that is visible on the screen - mainly all Coordinators, ViewModels and ViewControllers. Other parts of the app include Extensions, with various extensions [84], Helpers, with diverse helping classes and functions, and Supporting Files that contain necessary things such as assets or a launch screen. Figure 5.7: Screenshot of the project folder structure The model has one main Model class that encapsulates all needed services. This class is hidden behind protocols 1 to the outside world. There are also two types of entities - DatabaseEntity and Entity which basically mirror each other. DatabaseEntity is an object that is saved into the database. Entity is a struct that is used throughout the whole application and has a save(to database:) method that finds the corresponding DatabaseEntity of the Entity in the database and updates it, or creates a new one if the Entity was never saved before. The app initializes Model and AppCoordinator in AppDelegate s initializer and then shows the rootnavigationcontroller from AppCoordinator on the screen. The AppCoordinator is an object that initializes a MainContentCoordinator and creates a root UINavigationController of the application. The MainContentCoordinator is a coordinator that controls the main flow in the application and initializes all other Coordinators. 1. Declared in ModelProtocols.swift. 37