 Good evening. My name is Soubh and I'm going to talk about navigation in an app of apps. This is an interesting title, but before that I need to make yourself familiar with what is an app of apps and what specifically we need to do our navigation in app of apps. A little bit of intro about me. I work as a principal software engineer at Spleason. Beside working for a few of the leading product companies in the past, I also contributed a lot to this community. And one way or the other, if you are attending this meetup, you are associated with this community. Either through iOS devs code or iOS on Bestie. So thank you for being a part of this community. So in the last couple of years, I have been part of three major refactors. So in Paypal, I was part of the team that refactored the PayPal app from Objective-C2. So then when I joined Spleason in 2016, the previous version of the SP app was building code of us in Chatterj. And I decided this is the first thing I need to change, so I and my team basically built a native strata. And last year we tried to build something different. So it's basically we did another refactor where we had made this app which is capable of having other apps inside the app. So some they call it super app, I didn't use that word. But the concept is not new. WeChat has been doing it for a few years. And similarly there are various other apps in the region like Gojek is doing it, PTM is doing it in India. And recently we started with SPR, primarily because we introduced other services, other utility services. EV is one of them. And we have other services which are basically many apps within the app. Now since we are in Grav, so you might be wondering is Grav falls into that category. Yes and no. That is primarily because Grav does it in a different way. They have multiple apps basically to tackle this scenario. So for example Grav 4, Grav Circle, so there are multiple apps to tackle this scenario. So when you build an app that has other apps inside it, there are primarily two main things you need to consider. One is networking and other one is navigation. There are obviously various other things that you need to take care of but these are the primary two things. And today I am going to talk about navigation. The concept of navigation and navigators are not new. And we have seen this guy. Anyone who doesn't know who this is? So specifically he is from the pirate of category. He is Captain Jack Sparrow and this is his team. So when they navigate the ship, who basically coordinates? Is it the crew coordinates or is it the captain coordinates? Obviously the captain does. So I will come to captain later but I am going to show you a basic, simple scenario and how we are going to introduce this concept here. So this is a food discovery app. You have this fantastic idea and you want to help tourists who are coming to Singapore to discover popular foods in Singapore. And you can have food details and you can find restaurants where they can find this food. Let's see how we will build such an app. Basically three simple screens. There is a full list page, there is a full details page and there is a restaurant list page. And this is the first iteration of this app. I have basically used Segway all the way through 3D control, 3 Segways. And you can do it either through Storyboard or you can use code. If you are someone like Veena who is sitting there who just introduced me and the others speakers earlier. She doesn't like Storyboard. So if you are somebody like Veena maybe you don't like Storyboard. But if you like Storyboard what do you use Segway? Basically there are two things you need to think about. Prepare for Segway and perform Segway. If you want to do it through code then basically you need to initialize the different order and then you need to push or present that different order. Pretty simple, right? Now let's imagine a different scenario. This is your initial scenario. Now you notice that your application is doing very well. And your product owner comes and say, hey, we are getting a lot of interest in the restaurants. So let's build this screen. Because it's basically just adding one more screen to the top. Which is like full list then from the first page you can go to the restaurant list page. Now irrespective of what you use with a Storyboard or code just imagine how you will solve this problem. Now let's say you have to deal with something else on top of that. Isn't when the complexity grows imagine how your code is going to look like and how your view controllers will behave. So there are some problems with the traditional conventional approach, right? You basically have your code snippets all over the place. Nobody owns the responsibility for navigation. Your view controllers know too much details about other view controllers. It's like if you're a bad view controller and you know too much details about the side view controller and so on and so on. And imagine you're initializing the same view controller multiple times and you have to change the signature. You have to change the method. You have to basically modify it everywhere. And quickly it can become unimaginable. So the solution is let the captain take care of it. So this is one approach. You might be using it in traditional in your network manager. Let's say your application might be having a network manager to take care of all network requests. So you basically have a navigation manager or navigation coordinator which will take care of all the navigation in your application. Now you might be wondering why this is important. Let me ask you a question. Let's say you want to go on a vacation with your partner to Paris. Will you do it yourself or will you go to an agent? Who is going to choose option A? So there are quite a few who will choose to do it yourself, right? Obviously because it's fun. It's going to give you more experience, right? Imagine you have to take 50 people with you because you're going to have a marriage in Paris and you are taking 50 friends with you. Are you still going to go ahead with option A? What if you need to still take more people, like 200 people, 300 people? Now you don't need to answer me. As in when the complexity increases your answer will take towards option B. Basically let somebody else take care of it because option A doing it yourself increases the complexity of it. So coming back to solution, basically we need somebody to coordinate the navigation for us. So there are two great talks and articles by this. Summer Panas, she came a talk in Rivescom 2017 I think and she talked about coordinate a pattern. And there is an article by Paul Herson. Both of them they introduce how you will create a coordinate a pattern yourself. For this particular talk, I'm going to talk about a library which helps you do that. So the library is URL navigator. Basically you need to do three things. Behind your URL pattern, map your view controllers to the URL handlers then you push present or open the URL. So in this case define your URL pattern. So thinking about the foot application, there is a foot list screen, foot detail screen and a restaurant list screen. So all the URLs are basically represented by an enum. Then you need to map them to a view controller. So you will have basically a saved navigator in your entire application. The entire application will have one navigator and then you need to map your view controllers to those routes that you just saw. And let's say you want to pass additional parameters then you can pass using something called context. I'll come to the context in a while. Then your own view controller will have a special method where it can return the view controller or a navigation view controller whatever you want. You can use storyboard for this. You can just initialize without using storyboard. Basically this is a unique method that will help you initialize the view controller. And when you need to just navigate to a view controller, push present or transition anyway, this is the only line you need to write. So in your view controllers, you do not need to know too much details about other view controllers. You are not initializing other view controllers yourself. The navigator is going to initialize for you. So there are a few other advantages that it has. Basically it hides unnecessary details that you don't need to know within the view controller. But because we are using URL schemes or URLs for initializing our view controller, it keeps us a lot more advantage than this. Let's see what it can help us to. So here is a representation how I can just visit an URL and go to specific view controller within my application. That is you can use this, that is you post on Facebook, post on Twitter, send somebody an SMS or simply pass somebody an URL. The person can not only come to your application but go to specific page in your application. This is one example. Second example, if you have used the force touch in iOS or 3D touch, you can basically go to specific page again just by using the URL. Third use case, if you have two day extensions or any other type of extensions, you can again go to specific page using just URL schemes. Now all of this is super easy and super convenient because you created a navigator functionality which uses URL schemes to navigate to specific view controllers. Now let me show you a quick demo. This is application. I am already using the URL navigator here. This is the navigator route where I have defined the URLs and this is the navigation map basically which is mapping each view controllers to the URL. And for this particular case for four details I am using something called context. The context is basically an additional parameter that you pass for individual view controllers. You need to have an init method something like this which is basically going to initialize that view controller and return it back to the navigation map. Now this I need to do whenever I want to go to a particular view controller. I just need to push or present and I need to pass additional context whichever is needed by that view controller. So this is the example where it is basically the form shortcut or three details example. Again I am using the same route here. If you see two options one is food list and another one is restaurant list. I am basically passing the same route here. Same with today view controller. I have basically two buttons and all I am doing is basically passing the same route. Now as you can see it is going to be going to make it super easy to manage your navigation using this method. That is the end of my presentation and if you have any questions you can ask me. That is the south question. So I saw you use enums for the URLs. So in that case why can't we just use just the enums without the URLs? Because you can just do a switch of the URLs of the enum cases and in terms of the context then we can just put parameters in those enum cases. So I am not seeing how the URL navigator would be more useful than not using it. I could just use the normal enum cases. So what the URL navigator does is basically it does three things. One is it takes care of the navigation part. The first part is you are defining the URLs. So if you are saying that you can define using basically instead of string you can just create your own URLs. And then the second part is mapping the view controller with the URLs. And the third part is presenting or posting. So if you do all three yourself you don't need to use the navigator. So I was just wondering why they decided to put URLs in the library in the first place. Why don't they just use the enum navigator? Because it seems to me that the URLs they don't do anything special. Aside from just making it maybe compatible with deep things that I can see. Deep linking is one of the main advantages. So it is meant to help you a lot when you need to let's say manage push notifications and you have to be able to implement specific pages. This is one use case I can think of and the other use cases that I sold. So if you don't use something like URL navigator and you need it to manage that in linking yourself. So if you are willing to do that yes you won't need to use this in the library. So yeah. Okay. Yeah, thanks a lot. I would suggest you to take a look at Samar Panath's video. See, recommend another way where you can create this all by yourself without using URL navigator. So that would be a good place to look at things here. Any other questions? So here like the navigator manage all the view controllers right. What happens if you do different injection? That means you are going to add more and more context. And like navigator has to keep the services, the view model, any kind of like objects to be able to inject it when you are going to build it. How do you manage that in injection with this library? Give me an example. Let's say you are a restaurant list. You need like a restaurant service, maybe like different kind of other different systems to make it work. And keep like the view thing you don't keep preferences with. So you are going to inject it when you are going to. So all the only thing the navigator is doing is just creating simple view controller. Your view controller still manages its own view model, its own preferences. Those are not being managed by the URL navigator. So you continue to do how you will be building your view controller as it is. The only thing you need to pass while initializing your view controller is just the navigator. You don't need to pass anything else. If you want to use a view model, if you want to use a delegate for whatever things that you are doing, you are free to do so. So yeah, so I think that's my question. How do you manage dependency injection with the navigator? So you want to pass a delegate or you want to pass a view model? So you can pass in the context if you want. So the signature of the context is basically you see any object. So you can pass a dictionary, you can pass a struct. You can literally pass any object you want as a context. Any other questions? If not, I just have one announcement to make on behalf of my friends at PayPal. They are looking for iOS engineers. Well, I don't work in PayPal anymore. But if you're interested, then you can either apply through LinkedIn or you can find me later and then I can make an intro. Thank you very much. Thanks.