 Sit down and talk to your viewers. Hi, so my name is Harit. Today I'll be presenting on Coordinator. There's nothing too technical, so I just really hope you guys can see better, relax, and really just enjoy the presentation. OK, so I think before we really dive into Coordinator properly and try to understand what Coordinator is, it's very important that we try to understand what kind of problem we are trying to solve. And yes, it's our two familiar problems, the massive field controller problem. You see, field controller is a central part of iOS programming and it's such a convenient place for us to put almost any kind of responsibility into it, such as UI codes, networking codes, persistence, storage codes, and navigation codes on any other kind of codes you can name it, you can put into it. Such that sometimes, or rather, more often than not, our field controllers can balloon up to a size that becomes very recognizable later on. If such convenience is not handled properly. So let's say you have done a subproject and half a year later, you need to go back to that particular project and look at a particular field controller. And before you click that field controller file, your heart seems, you're like, I don't want to open that particular field control file. Most of the years, you have that MVC problem. Because deep down, you know that the codes there are messy. The responsibilities of the codes are so tangled up that in order for you to understand the things you have written again, you need to spend a substantial amount of time on it. And it's agonizing as best. So in order to solve this architectural problem that arises from MVC, which now stands for Model View Controller, a lot of people believe that a new architecture actually is needed. That's debatable, but that's not a topic of the day. So over the past years, I think since 2015, a lot of people have been coming up with architectures to try to solve the MVC problem. And some of the famous architectures are namely Viper, MVVM, and Redux. So despite the fact you have all those kinds of different architectures, they all have the same goal. And that is to actually dedicate the responsibilities away from view controllers to somewhere else. And in hope by doing so, try to elevate the clarity of your app. So if you think about MVVM, what it does is not really, what it does is that it tries to dedicate the responsibilities of model processing to another file. If you look at Redux, it's the same thing. It tries to dedicate the responsibilities of state preservation, state modification to another file. And our coordinator is doing the exact same. It's just that he's focusing on the transitioning parts of the app. And then the coordinator actually was introduced by this guy called the Soros Conlow. Hopefully I pronounced his name correctly in 2015. And the idea actually was taken from this book called the Patterns of Enterprise Advocation Architecture, if anybody's interested. So like I said, the idea of our coordinator is simple. It rigs a view controller or its responsibilities in dealing with transitioning codes. And move these transitioning codes to a parent class or a helper class. Now, that sounds actually pretty good. But I think that before we really adopt any solution to our current problem, it's very important that we think about is such a solution necessary. You see, changes don't come for free. Whenever a new architecture or any kind of solution is introduced, a lot of times we end up writing a lot more codes. We end up creating a lot more files. And we need to do a lot more logic thinking in order to just maintain the original functional relationships. And in order to evaluate this question of, is it necessary? I think, personally, I always look at two aspects. First, is the problem serious enough? Second, is the solution elegant enough? So for today, we're going to just, for today, we're going to look at the problem first. And so in order to demonstrate the problem, I have created an app called the Pokemon app. So this app is pretty simple. First, you have four view controllers, basically the first view controller, second view controller, Pokemon detail view controller, and second view controllers. So this is a flowchart. So whenever first view controller will be a main view controller, so whenever you go to the second view controller, if the user is not logging, you will actually go to login view controller. If the login is failed, you will go back to first view controller. If the login is successful, it goes back to second view controller. And if you tap a list of Pokemons on second view controllers, you will go to Pokemon detail view controllers. I know that sounds abstract, so I'm going to show you the example. And my computer is really slow, yeah. Okay, so this is like the first view controller. And if you go to second view controller because you haven't logged in, it will prompt you to log in view controller. I press cancel, it's failed, it goes back to first view controller, all right? But let's say you go to the second view controller, and you press login, then a list of Pokemons will be shown up. And then if you choose a Charizard, and you can sort of like, scroll, read the Charizard and stuff, and you can favorite it, things like that. And just to run this thing again. So that's basically the flow, but there's another feature of this app. So I just want to show you, so you can understand that the flow more clearly. I shouldn't have... So the same thing, you can be a Pokemon here, right? You can be an Eve, you can be a Pikachu, but let's say you are not logging, all right? You will just ask you not logging. But let's say now cancel, you will go back. But let's say now you log in, you will log in, and then automatically go to that, all right? So this is the, so-called the flow of it. So I just hope you guys are okay with it. So let's say we really sort of understand the flow of this app. And then we realize that second view controller actually is a central part of dealing with almost anything, right? So what do we need? What kind of, let's say we are trying to do a direct navigational or transitioning codes. What do we need? So there are three things we need, which are called the three UI view controller delegates, right? First, we need a first view control delegate to pass a selected Pokemon to the second view controller, correct? Second, we need a login view controller delegate to actually pass the login status back to the second view controller, right? And then we have the Pokemon details view control delegate to actually pass the favorite or unfavorite data back to the second view controller, right? So now let's look at the code for a little. So you see that, let's say we go to the view controller, so I define a delegate and then there's a lot of explanations, but we don't really need to go to the details and we have a delegate, all right, to actually sort of say that, all right, to send things over. With that, we go to login view controller. We will have this, whether the user has ever logged in or not, this particular protocol. I believe that people are familiar with UI view controller delegates, right? So we also have this Pokemon view controller to tell second view controller whether we have favorite or unfavorite anything. Now, if we go back to the second view controller, because like I said, second view controller is like the central thing of possessing all the data. So it needs to be the delegate of the three view controllers. Now, if you look at the code, right, right here, like I said, I sort of put the mark so that there's too much creation codes, right? So you need to do a lot of things to actually do the notifications, right? You need to create the view controller. You need to make sure that the delegate is passed. So this is it, I'm gonna go through the codes, but yeah. But if you look at it, right, for second view controller, this is almost more than half of what an entire view controller has, correct? It's a lot of codes, actually. So now we look at what, so now let's do an evaluation. So what are the pros of using UI view controller delegates to do such a work? First, they are very robust, right, they work. I mean, it's developed by Apple people, right? But now we look at the cons. One of the cons is that it's relatively massive, like I've shown you, you're almost occupied, like half of the view controller. Second, it can be a little bit hard to make sense of. Now, you will see that in order to maintain this relationship, for example, when we go to add delegate, we need to sort of set up the second view controller as a delegate of view controller. You will see that a lot of these codes are actually scattered around. So later on, you come back, you try to understand how this entire flow works. You need to go to multiple view controller in order to understand how everything works. But actually that is not such a big issue. Another one is that despite the fact that we don't really understand how these things work, but I'm just gonna tell you how it works. That there are certain responsibilities here that I actually tangled up. That if you try to evaluate it, there may be some difficulties, and you may spend some time on it, but it's not that difficult because this is a very simple app. Now, the last thing, which I think is the most important thing is that it's rigid. Why do I say that? So now imagine that in this particular app, you wanna add a third tab, let's call it third tab. Now, instead of Pokemons, I want you to choose the trainers. Now, how would you do it? Just in terms of transitioning. You will need to write for that particular view controller. You need to write another delegate function just for it because in the currently you are not, because now you no longer pass Pokemon data. You are passing a trainer data to the third tab. So we need to write almost everything here all over again on the third view controller. Now the second thing that I think is rigid and I want my biggest frustration is that what if somebody comes to law and tells you, hey, I schooled up, and I think that the flow is not right. I want to change the entire flow. Now what would you do? Now you need to go to almost every places to sort of delete all those codes and make sure that those codes don't interrupt the new codes. And you need to redefine all the delegates and do all these things all over again. Now that is a big hassle, right? So that's the reason why sort of I adopt coordinators. So what are coordinators? Let's say for every app, right? Actually in the system, in the system they all maintain a set of view controllers references. Now for example, let's say you do push pod dismiss. Actually you are talking to the sort of the invisible set of view controller references. But you cannot really fully manipulate because there are sort of hidden from you. So coordinators' idea is very simple. It's not maintain a set of view controller references ourselves. And then we manipulate the transition from this set of view controller references instead of the system set, right? So these allow us to actually the freedom and control over all how the transitions work, okay? Before I really move on to show you another demo app, I just want to say that the original implementation of coordinator by Soros kind of a little bit, it can be a little bit complicated. And there are some very tricky problems to solve along the way. And I have been using it so I know that it's kind of quite a lot of work. I'm going to just show you a demo app like this. So like I said, the original idea is that it to create a parent class. So you see that I have a main view controller, right? Okay? So now I need to create a one to one main coordinator. So it job actually does is that it coordinates the navigations along, right? But then you will have a lot of codes. Now you have to maintain this entire module yourself. But then the good thing is what? Let's say you go to main view controller. This is the only navigation codes you need to worry about. But still I think that something can be improved. So as I, before that, so if anybody is kind of interested in the original implementation, you can go to this, just search for coordinator medium. You will know this guy and then he has a farer tutorial on it. So if you guys are interested, you can go back to the original implementation and then sort of see what are the concept pros. Actually, I was quite tempted to show you guys as an example of this, but I think that evaluation of coordinators and then going through will take more than half an hour. So if you guys are interested in this program. So what I'm going to show you today actually is my own implementation of coordinators. Because like I said, I've been using coordinators and I feel that it's a hassle. So I thought I wonder if I write something for myself. So today I want to show you just, yeah, so I say that. So I'm going to show these. So first of all, we run the app. So just make sure that everything works, okay? Now, if I get the second view controller, pop star, I cancel, goes back, log in, favorite, come back. I'm not going to show much, but we all know that it works, right? So yeah, so now let's look at the codes. So actually, I really as a library, yeah. So if you guys are interested, you guys can actually take a look at this. The library that I've written, but so I'm going to go through about how those things are and how simpler you actually make my app works. So first of all, you need to define these things called the scenes, all right? So you need to sort of define all your view controllers. Now you're making an enum. Now you can have multiple on Storybot because I only have one Storybot command. So I just have a Storybot. And you need to return what's the Storybot's name and then just need to return the view controllers type. That's about it. Of course, you need to also name your view controller the same name as your view controller class in order for it to work. So just to show you, yeah. So the, okay, not this one. So you need to name it the same as the class and that's all. So now let's look at the codes. So now if you go to the app delegate, right? You'll realize that we don't need all these anymore, right? It's clean, we don't need those things. Now if you go to first view controller, you realize that we don't need those protocol delegates anymore, right? We don't need them. And then if you go down here, we don't need these things anymore. I will explain it a little more but just to delete something here. And you go to view controller, same thing. You don't need the delegate anymore so we can delete all these. And then you go to Pokemon, how about delete today? You don't need this anymore. So I have a habit of defining things. For example, now what you can do, basically this class called sync coordinator class, all right? So this is the only line of code you need to pass the data around and then sort of to perform certain functionality. And then for me personally, whenever I develop an app, I usually like to define the transitions as an enum in the view controller class. So and then you will have an execute function which is to call this particular line and then execute. So let's say now I wanna go to my second view controller. All I need is just one piece of one here, right? Just one single line and then it will perform that transition for me. I don't need to care about any other things. Sync here, now the transitions here because it's a pop to previous, right? Because we do a push and we pop to previous. So this sync coordinator because we need to know like which view controller we are popping to. So we need to put the main because in the main we have all defined the view controllers that we know, right? So you sort of like you can pop to the previous. Now second with a same with a login view controller. I just like to define this and then just call it. Now the thing comes here is about the second view controller, right? Now you see all those codes, right? That we initially have all these codes, right? We no longer need it, right? We don't want to need it. So we don't need this as well. No transitioning codes, just one line of it. And then that's almost as much as your view controller is about like 100 something lines. And then if you look at these, these are the two functions that I sort of defined. You see, so whenever you are trying to pass a data, now if the operation is push, present or tap, right? And you try to pass a data, this function will be called. This function is called will move to interface. That means that whenever somebody sort of instructs me to actually appear on the interface, this function will be, this particular function will be called and then you can process the data in it. Now another one is this, which is called a POT, POT Disney's functions. This one is called, whenever let's say you do a POT or Disney's function and you want to pass a data back and then you can just do this. Yeah. So basically reduce almost all the, you don't need all, you don't need view controller delegates anymore. You just do a very simple thing here. And then the logic is a lot cleaner. Yep. So yeah. Oh, just one thing. For anybody who is sort of like trying to look out for the, like the library or something. Because I've been rather busy, so I wrote it pretty short. So there are two problems. First is that it's the same as coordinator. The moment you use it, you have to stick with it, right? You cannot use your normal transitioning codes. Like I say, we maintain our own step of view controllers references. But this can be improved. I have some very dumb way of doing it, but I'm thinking of a more elegant solution. Second thing is that because I wrote it for my own, so my admin has type R view controller and then navigational controller. So currently this one only supports type R view controller and navigational controller. So when I free, I will add the speed view controller and then the page controller which has been introduced in 3 to 4.0. But the main idea for me is not to actually sell the things I wrote. But the main idea is to tell you guys an idea of doing things. So you guys can look at the codes and then develop your own. I think the only cause of using this service is that because it developed by me. So it's not that flexible. But if you guys understand the logic behind, you develop your own kind of coordinator and then everything would just be really, really short. Okay? So that's all if there's any questions? Yeah. Yeah, so thanks for presenting. You can go back to your source code. Yeah. Which one? So like we are most interested in this. Is it defined in the super class? No, actually it's a protocol. No, it's an extension. So it's defined. So because in the underlying coordinator, we call it ourselves. So you don't need to worry about it. You just know that whenever, let's say, let's say in this case where first few controller, every time you try to pass a data, this time you are trying to pass a Pokemon data. The moment you try to pass a Pokemon data because it's a tag select operation, you just come here, you know that because it's tag operation, we'll move to interface. I know the naming is a bit bad, but I'm bad with names. Where is the part where you call your move to interface? It's called automatically. You don't need to care about it. Okay, but it's called before 50 look. All right. It's there like the code which calls it. Oh, the code that calls it. The condition which calls is function in every controller. Okay, then we have to go to the parts. Yeah. So this is the place you call things. The logic, I make it such that it's called before 50 look. So if you guys are handling things that has to do with you, you need to create something, you need to create what do you call a local variable. Let me see, for example, this one local variable to sort of contain it so that whenever let's say, whenever few appears then you load it. But the cool things about this is that if you look at this, right, all of your controllers are isolated. They don't really talk to each other anymore. So you see all the property, let's say for this pre-selected Pokemon, right? Now, let's say you go to this example. No, not this one. Okay. Oh, that's the other code. Yeah, I think I change it. But anyway, the main point is that all of your controllers are actually isolated. So you can put almost all, because let's say you wanna pass this particular Pokemon to this guy, right? Let's say for another few controller, correct? You normally need to make it accessible. This is something that we don't want, because we don't want coupling between view controllers, correct? We want them to decouple. But you get this approach, you can sort of make it private, and then you still be able to attain it, data. These two view, these two methods is just like the under tunnel. So they pass the data under tunnel. Nobody can notice it. Any more questions? Yeah. You have multiple coordinators, right? Yes. No, you cannot have multiple coordinators. You only can have multiple scenes, because the coordinator, like I say, right? The original implementation is that every, like there's only, that there will be multiple coordinators coordinating something, correct? So I have like, I have a, let me assure this as an example, right? So I have a main view coordinator. So his job is simple. I only coordinate main view controller. If I may be able to go to, let's say currency lease coordinator, this is my job. I take care of it, correct? So there will be multiple view coordinators because you need to take care of every view controller. But in the sort of the method I wrote, what I do is that, I think that there is very trouble, so you need to maintain the entire thing. So what I do is that I have this central coordinator, just one guy. He does all the coordinating for you. Yes, but that's a more integrated, suppose there are two applications in the application, where they run in a different mode when dependent on the user. Okay, for example, let's say, give me an example that you will need a multiple coordinator. So I want to combine a finance app and a model of applications together. But I don't want to change, they are already coordinated designs. So for the design one application, we have one coordinator, and then another application one coordinator. Now I want to merge both of them into simple applications. Can I use those, do I need to create a single coordinator again? No. You don't need to, like for this one, the modified one set. Actually, have you finished? I'll show you, you may continue. Sorry for the time. It's the same reason. Two applications, we have two coordinators, each single one. Now I want to combine them together. Now, should I create a new coordinator from the beginning? Just for that, because I want to merge those two applications together, or should I just use two coordinators and then create one more, like any coordinator and then merge together? Okay, the idea is this, right? Now let's say you look at the code, so you will see that actually there's no coordinator creation. Do you get what I mean? So let's say, okay, we are not talking about the library, let's say we just talk about the underlying idea of creating a stack, correct? So now let's say you want to merge two apps, have two different coordinators, right? Now let's say you have sort of instructed the original coordinator, let's say first we control the coordinator, to be able to coordinate all kinds of data, and then the second guy has all the conforming data. Then yes, you only need one coordinator. Like I said, for example, this is the only thing, right? See, this is the only thing that you need to define. This is the only data required. Is it the only one application? Yes, then you need to, Oh, you just need to say that in another scene. That's it. If I understand your question correct, then you can define anything. Like I said, you see the story bundle here normally returns Neo, right? Because usually we just use our own story bundle in app. We don't use some, but you can define some other story bundle you want. The coordinator will still work. But of course, let's say you just implemented the idea yourself, and then they are somewhat different. Then you need to coordinate yourself, because you cannot put two incompatible data together. But then the idea is that, yes, if you want to merge them, right? One coordinator is enough. No matter how big you want to merge them. But like I said, there's nothing comfortable for you. You need to look at how you architect your app, and all other factors in order to decide how you want to reflect the things. Is that okay? Any more questions? Yeah. Does your coordinator know something about your IT or is something that is kind of certain for you? I guess it deals with view controllers. So yeah, it's actually, it's dependent on your IT. Do you think is it a problem of your solution or not? Actually, I was thinking about it. Maybe we can do it using the memory, the unsafe pointer to actually find the location of view controller and install it that way rather than using a view controller and stuff. But not really, because this app also helps creation of view controller. For example, let's say, let's say, let's say here, right? For example, let's say here, I say that's in coordinator, right? Now I want to coordinate it to some view controller in the main storyboard. And then I can present, let's say, I can present a native bar together with it. That means that you don't need to create a native bar. No, normally you need to create a native bar, put the guy as the root view controller, a native bar, then we present it, right? But in this case, you don't. And for the convenience of it, I created something like that. So yeah, it will be dependent on UIKit. Is it a problem? As long as UIKit doesn't screw up, I think that it isn't a problem. Yeah, any more questions? Yeah, how would you use this pattern to create, to use deep linking into the application? So for example, if you want to open a notebook, or in this case, a Pokemon P-June, and the name of the Pokemon, do you think it's usable for that? It's usable for that, but I don't want to give anything that is uncertain. I haven't really created a big app, or a medium-sized app in order for me to test out all the things. For example, when I create this Pokemon app, actually I found that there was some problem and I fixed along the way. So deep linking, I haven't really tried yet, but I think that it's usable. Because all you need to really care is about is this function in yourself, right? So if somebody sort of calls me, I just call someone else. So it is possible, but you will need more tests. Like for me, I usually like to create a bigger app in order for me to test the feasibility of the thing. So I can't really answer you for certain, but the possibility is there. Okay, so. If you're still interested, can you ask me later?