 Sorry, let me do this. OK, hi. So today I'm presenting on reactive programming. So I developed my app YoMap with this reactive framework. And the idea is it allows you to bookmark places on your map, which I thought was a simple idea. And how it works is you could have thousands of places in your app, but the map would filter and display the places in the current map region as you zoom and pan around the map. So this is a rough diagram of how it works behind the scene. The view model on the left, it manages the data, which in this case are the map places. And those places are initially sorted into a quad 3. So it's more optimal to do a lot of filtering in real time. And when you change the map region or the filters, the view model would send the updated place annotations to the view controller. And within the view controller itself, the map card and the map view would sync up so that they highlight the same selected place. So that is to say there's a lot of moving parts. And before I used reactive programming, it got a little too complex at one point. So that's when I thought I would try to pick up this framework that I read about. To use a simpler example, let's think about how to implement online search. So we have a search box, and we want the search results to update as the user types in the search query. First of all, we can observe the search box value with a delegate function, like user update search query. And with each value that comes in, if the user type is very fast, you want to control the number of the rate of requests that you send to the network. So you implement some form of throttling. I'm just going to go through quickly this part. So we want to implement throttling. We want to check if the search query has changed from the previous query. And we want to create a new network request every time the query changes. So we have a delegate function to deep complete requests so that when the search request is completed and you receive the search response, this function will check that the data is from the current request. So we can ignore the previous searches. And then we can update the search results. But to implement this, all this functionality, we need to create at least three variables. So we have a last request time to keep track of the time window between each request so we can implement throttling. We have a previous query to check if the previous query is different from the current one. We have a current request to check if the data coming in is from the current search request. So we have to keep track of all this. But if we were to implement this the reactive way, let's see how we would do it. So if you use reactive cocoa, the text field would have a property called continuous text values. We can use this signal and we apply a number of operators to it. So the first one is ignore repeats so that we don't use this, if the value that comes in is a duplicate of the previous one, we don't use that. We just skip it. And we can apply a trotter with a window of 0.3 seconds and then we apply flat map. This is a bit complicated, but you'll see later how it works. Basically, it will only use the latest search requests. And finally, you attach an observer to the end of the chain to observe the latest value and update the search results. So when I was starting on reactive cocoa, it was difficult to wrap my head around this concept. And I find the best way to learn is with code examples, and that's what we're going to do. So if we have time at the end, we can create a simple app which would show you how the different parts of reactive cocoa come together. What is reactive cocoa? All right. Reactive cocoa started out as an Objective-C framework. And it has since migrated to Swift. And if you looked at the GitHub repo, there's two repositories. So one is reactive Swift. That's the call functionality. You don't need to create an iOS app with, I mean, you can create all sorts of apps with Swift nowadays. So that's what reactive Swift is for. But if you were to create an iOS app, you want the reactive cocoa library because it provides extensions to the different iOS and Mac classes. Let's look at the definition provided by the GitHub repo. The important words here are declarative and the concept of streams. So we have already seen in the example just now, the first example for implementing online search, that's a very imperative way of programming. Meaning you have to keep track of all the state changes. You have to create declare variables to keep track of this. You need to tell the program. You need to describe the program how things work. But reactive Swift is declarative. So instead of how things work, you describe what things are, what it is. We have another definition here from Wikipedia, what reactive programming is. So first of all, reactive programming is perfect for asynchronous operations and tasks. So anyway, we have the concept of data streams come up again. And as for inferred dependency, we'll see this in the demo later. Like when you chain operators together, you can see the flow of the cause and effect. And it makes it very easy to read the code and understand what it does. And finally, we have the reactive aspect of this programming. We also see how it is in the code later. OK, but before we go into how it works, let's think about how we pass data within iOS app. So there's key value observing, which we can use to observe changes in a variable. We there's delegation, which we can use to pass data between view controllers. And we can subscribe to notifications to be notified when an event occurs. OK, I didn't add this in, but we also have closures for callback functions when we want to implement asynchronous tasks. And I also want to talk a bit about promises, because reactive cocoa is like an advanced version of it. You can chain operators and pass values before they have been fulfilled, which is also used for asynchronous tasks. So when we talk about streams, this is a good visualization of it. And this actually comes from another programming language called Max. It's used by interactive artists, because they work a lot with audio streams and video streams. So a lot of times you can't control the discrete bits and bytes of the stream. So reactive programming is the way to go. So here you can see there's different streams being combined, the streams are being transformed, and then finally it reaches an observer that does something with the stream of data. OK, but with reactive cocoa, so this concept of streams is the base of reactive cocoa or reactive Swift. It's used to manipulate and pass data. So a stream represents a sequence of values over time. That's a bit abstract because it's extremely flexible. Instead of a variable, we can create a stream and then attach observers to receive and do something with the latest value from it. So the top part that represents a stream, which is different, not necessarily different values, but values over time. And that vertical line, it represents a completed, filled, or interrupted event. So the observer can not only receive any new values, it can also be notified when the stream has terminated. And then you can do something when that happens. OK, the way to create streams in reactive cocoa is by using these three classes, the signal, signal producer, and mutable property. And which one you choose depends on the situation. So let's just get into that. OK, first we need to create a playground. Let me just start up X code. I'm curious how many of you have heard of reactive cocoa or reactive programming? How many of you have tried it? Tried it? Use it in production? OK, how many of you are here because you're interested in how it works, right? Yes, I need to. It's actually there. Oh, actually, you can talk. Sorry. OK, so the best way to learn reactive cocoa is actually through a playground where you can experiment with the different classes. Is it connected? OK, something's wrong. Just to give you a quick idea of how to set it up, you can read about this on the repository itself. You need to put the playground in a workspace. And in the workspace, you need to add the reactive cocoa, reactive Swift, and the result libraries, the project files. And before you run your playground, you need to build this one by one. So you could select result, and then you built it command B. And then you built reactive Swift, followed by reactive cocoa. Once you've done that, your playground should be able to read the syntax. So you get the autocomplete, and if you run it, it should work. It'll work. All right, so let's begin with the signal class. The signal class allows you to, most of the time, you can think of the signal as a river. So it was there long before you go to the river. And when you fish in it, any fish that has swam downstream are no longer accessible. So the moment you attach an observer to the signal, from that point onwards, you receive the future values, but you can't access any past values. If you come from, say, RX, there's another library, RX Swift, and other RX libraries, signals are kind of the equivalent of hot observers. So that's to say, the signal often belongs to ongoing parts of your program, like views, or controls, or some kind of global shared object, like a store. So they don't produce side effects when they send values, and you typically observe them to be notified of events or change values. So I have a number of examples here to demonstrate what I just talked about. OK, so this works. If you look at the first example, observing a signal. So this is the basic of how I'm using a you have to attach an observer, and in this case, I'm using a closure. So I'm using a mutable property to manipulate the values of the signal. So here I've changed the value to 1, followed by 2, and then 3. And the observer would zoom in. Yes, I forgot about this. How's this? OK, so once the observer would get the value from the signal, as you can see, so it prints out 1, 2, 3. And in the next example, we're using MAP, which is operator to manipulate the signal. So this MAP function, which is just multiplying the value by 100, it's applied to every value that's sent by the stream. So here, again, I'm sending the same values, 1, 2, 3. But the values received by the observer is 100, 200, and 300. You can also use another operator called filter. And so you should be familiar with the filter function for sequences. So it's doing the same thing here, but with the stream. So here I'm sending the numbers 1 to 6. But when it pass through the filter, it will only accept those that are divisible by 2. So what I get in the observer, what the observer receives from the stream, is actually only 2 and 4 and 6. You can also combine signals with the operator, combine latest. So I have two different signals here, the left one and the right one. And this is what I set for the values. And in the observer, I've access to the left value and the right value. So I can do either one way. So here I'm just printing them out left and right. I think I know this a bit complicated, but I'll upload the playground and you can experiment with it. It will make more sense. But so what I said just now about signals, how do you use signals? When you import reactive cocoa, you'll notice that text fields, a lot of controls, they have a reactive property now. And for the text field, you have continuous text values. So this is providing any updated value in the form of a signal. I can't run this because this is all iOS code. But you can look at a code here and try to understand. So it's similar to using the delegate function of text field. Basically, whenever the text field changes, you have access to the new value. But as opposed to, say, the delegate function, you can do a lot more using operators. So I can actually do something like combine previous. And now I have access to the previous value as well as the current. So I can compare them and do something when they're similar or when they're the same or when they're not. OK, and then here's another scenario, which is notifications. You can, the notification center has a notification signal. All you need to do is specify the notification name. And then you'll receive the notification object in the observer. So again, you can do something really cool with this. What I'm doing here is I'm using the take operator. So it will take the first value, meaning when the app enters the background, it will just execute the code within disclosure once. And then the stream will end. The next example, we have user defaults. And we are using the KVO aspect of user defaults to turn it into a stream and do something with it. So if you have a settings screen in your app and when a user changes something, it changes the user defaults, you can immediately get the changes in this observer. And you can do something with it. And it's a lot less code to write. You also, OK, the last one is a replacement of delegate functions. So for the delegation pattern, usually you need to declare a protocol. And the child controller would use the delegate function. But in this case, we are just creating a signal manually using something called the pipe method of the signal class. So this is where we declare deep finish editing pipe. And when the done button is tapped, we want to send a value. And then in your root view controller, you can simply just use the edit view controller's deep finish editing signal to be notified whenever it sends a value. So probably not very obvious here, but just try out the playground. OK, the other class used to create streams is the signal producer. And this is one of the most confusing aspects of reactive programming because, OK, so going back to the other reactive library, sometimes they refer to observables as hot, sometimes as cold. And the cold aspect of observables is referring to this. You can contain side effects within a signal producer. But when you create the signal producer with the side effects in it, the code for the side effects are not executed. They're only executed the moment you use the start, any start function of the signal producer. So let's just look at the playground and see how it works. Signal producer. OK, so the first example we have is for asynchronous operations. I just want to tell you, you have five minutes left. OK, so I'll try to write this up. You have an asynchronous operation here. And OK, so this is one of the ways you initialize a signal producer. You use a closure, and in the closure you are provided the observer and the lifetime. So what you want to do is you want to put your code in here and your code should generate a value. And when it does, you use the observer to send this value from the asynchronous task. So what I'm doing here is I'm just using a timer so that I get a value two seconds later and then I'll send it. So when the timer starts, you will print starting timer, as you can see here. But by then it runs the other examples first. And two seconds later, you get timer ended, which is what we put in our observer. So again, like what I said just now, signal producers are cold because they don't execute the side effects. These are the side effects. They don't execute the side effects in the initializer until they are started. So if I run this again, you're not going to even see starting timer. And you'll realize that this is useful because you can create functions that return signal produces. And then you can see later, I think. So you can also delay a function call with the delay operator. You can convert a sequence into a stream and then make use of operators. And then collect to get back the sequence. And this is something you might use the most often because asynchronous operations, especially network requests, they're kind of a pain. So what I've done here is I'm using the iTunes API to search for these three keywords. I turned this array of queries. I converted it to a stream. So it will send the chain followed by nikes, followed by formation. And then it will run through the flat map operator but with a merge option. And within here, we are actually creating another signal producer. We're returning the signal producer, which contains the asynchronous task. So basically what this will do is it will run these three queries all at once, generate the three search queries. And when the response is completed, you do something with it, it will print out the results. So you can see here that it's generated the results. So we don't have a lot of time and there's one last class that generates a stream, which is the mutable property. You can think of it as a wrapper around the signal class. So it does a lot more because you can access the current value and you can produce a signal producer from it. So these are the different operators you use. The first line, it basically transforms the values in the stream. But the interesting parts are actually the operators that the second line and the third one, they can actually manipulate the stream. You can combine two different streams together. If an error has occurred, you can retry. Very easily. OK, since we don't have a lot of time, I'm just going to show you the demo. So let's see. So this is what we will do if we have time. But let's see. What it does is basically it's using the MapKit API to search for places. And every time you type something, it will generate the search. So if I search for, oh, sorry. So you can see the search request actually happens with each keyword we typed. And there's some form of throttling happens so we don't exceed the API rate limit. OK, I actually wanted to use this as an example of how you implement MVVM, the software architecture together with ReactiveCoco. But let's just look at it quickly. Because one of the hardest thing when I started learning ReactiveCoco was I didn't know how to use it together with view controllers. How to, like, where to use a signal, a signal producer, or mutable property. So even though we don't have much time, I'll upload this to a GitHub repository and you can look through it. But basically you have the view controller and you have a view model which manages the data and all the logic associated with the data. So it's really great for UI table view controllers. Here the view model is quite simple. It has a, let's see, it has a sections property. And this is basically the data for each table cell. When you initialize it, it set up the bindings. So there's search query property which gets the search bar value from the view controller. So here, view model.searchquery property, this is how we bind the search bar's continuous text values to the property so that the view model has access to it. And so whenever you type a character in the search bar, it will be emitted from the pass query signal. And here we are just doing the same thing like in the previous examples. We are throttling it. We are replacing the query value with an asynchronous task that returns a value. And then we are also catching any errors that result from the search query. And we are catching the error and skipping it all together. And then once you have the search query, you just display it in the, we're using the set, we are updating the sections property which the view controller has access to. So here, view model.sectionSignor, we attach an observer to reload the table. So very roughly, this is how it works if you use ReactiveCoco in an iOS app. OK, so do we have time for one question or two? I think you always have time for that. Sorry. OK. So I'm sorry, but you can answer them. OK, thank you, Benjamin. OK. Thanks for your talk, and thank you, sir. Thank you.