Coordinator pattern in iOS Swift Part 1 | Hindi tutorial
Вставка
- Опубліковано 2 сер 2024
- Coordinator pattern in iOS is a delegate protocol pattern that helps in separating the navigation responsibility from the view controller. In this session we will explore how we can use the coordinator pattern in swift. In this session we will remove an existing storyboard implementation and replace it with coordiantor pattern.
The coordinator pattern uses the UINavigationController to push and pop the views, we can also leverage the uistoryboard to instantiate the view controllers before they are navigated
given are the chapters covered in today's video
0:00 introduction
0:18 responsibility of view controllers
2:04 default navigation process
4:09 issue with the default navigation
5:15 coordinator pattern overview
7:30 code demo
18:19 avoiding strong reference
18:39 end of part 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Given below are the links to part 2 and 3 of this topic
Coordinator pattern part 2 📽️: • Coordinator pattern wi...
Coordinator pattern part 3 📽️: • Clean coordinator patt...
-----------------------------------------------------------------------------------------------------------------------
✅ Subscribe to the channel and stay ahead of everyone by following the right way for writing clean code in swift. 🔥🔥🔥🔥🔥
🔗Click on the link to subscribe: ua-cam.com/users/codecat?sub...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------------------------------------------------------------------------------------------------------
📥 Download the source code from
GitHub: github.com/codecat15/UA-cam-...
Google drive: drive.google.com/file/d/1OcQc...
-----------------------------------------------------------------------------------------------------------------------
Video links mentioned
MVC video link: • Model view controller ...
MVVM video link: • Basics of MVVM archite...
Delegate protocol link: • Delegate in swift Prot...
-----------------------------------------------------------------------------------------------------------------------
############################################
Connect with me on social media
📧: codecat15@gmail.com
🐦: / codecat15
Facebook: / code.cat.792
Github: github.com/codecat15
###########################################
#coordinatorPatternSwift #uinavigationController #swiftHindiTutorials
Hey there, I hope this video was helpful to get you started with coordinator pattern, in the second part we will explore the pending topics of this pattern. Let me know if you have used this pattern your project via comments or any general feedback on the video is much appreciated. If you have not yet subscribed to the channel then please do support and subscribe, thank you for your time and have a nice day 😊
Very helpful…thanks for the awesome content!
Thank god I didn't need to ask gou to make video on this. ❤️❤️❤️❤️❤️
This pattern was in my backlog from a very long time, since I was hooked up with other topics I didn't get time to cover this one. I hope this was helpful and please feel free to ask questions on this topic and do share the video with your iOS group.
Very helpful. Thank you
Glad it was helpful!, part 2 will be coming this week stay tuned and please feel free to ask questions on this pattern.
as always, excellent tutorial 👍
Really informative
Glad you liked it, there's a second part of the video as well which I'll try to release by next week. Stay tuned
wow
Part 2 is going to be very interesting, I am looking forward to what folks have to say. I am glad this video was helpful Junaid
thanks for awesome tutorial
I am glad this was helpful Pratik, please feel free to ask question and do share the video with your iOS group.
@@CodeCat15 sure
Great work ❤ Please make a video using Coordinator design pattern with Clean architecture and MVVM.
I will definitely try this pattern in my new project. Thanks for all your efforts.
Are you using this pattern coz there’s an actual issue which you are trying to solve with the default navigation or just for the sake of using a pattern?
Patterns should be implemented to solve an existing issue that an app is facing and not for name sake
That’s over-engineering in my books and is not a good thing coz we are adding complexity for no reason
I would request you to wait till the second part becomes live which will be this Sunday and there I’ll explain child coordinator management along with my opinions which are pros and cons of this pattern.
Excellent Video
Please make a video on Clean Swift
nice n well explained👌
Thank you, am glad this was helpful. Do share the same with you iOS group and feel free to ask questions
Awesome and great learning experience with you since last year.✌🏼
Many more to come ✌️
Excellent way of teaching.
Great work
Glad this was helpful.
Superb ..
Nice Video Very helpful, Thank you for making it . can we used Coordinator design pattern with switfui using NavigationView
Thankyou so much sir
Most welcome
Great❤️❤️❤️
I am glad this was helpful
Well explained. Will use this pattern on the coming task.
If you have a valid technical reason to use this pattern only then use it, else I suggest avoid using a pattern that makes a simple task complicated than it needs to.
Check out the part 2 of this video as well where you’ll explore the complexity this pattern adds to our code
Before using this pattern compare the default navigation process with this pattern and see if this pattern really adds any value to your project or is making a simple task more complex.
@@CodeCat15 sure.
I enjoyed the video, Thanks for the efforts.
What is your thought on replacing protocols with closures?
Also, How do you see this pattern for SwiftUI?
There’s a use case of everything and if you’ve seen the part 3 of this video I have showcased the flaws of this pattern.
I wouldn’t recommend this pattern to be used by anymeans whatsoever unless you have a strong and proven use case for it.
If not then don’t implement complex and unfruitful pattern for something simple.
Wow ...
😊
Hi Ravi i like so much your video, i actually starting a new job like ios developer and ill learn a lot of your content, i need to kwon how pass data between 2 viewControllers using this pattern.
I think that's being covered in the second and third party of this video,
however this pattern is known for increasing the code complexity and many developers tend to move away from this pattern for the very same reason
navigation is the view controllers responsibility but with this pattern I have to create 2 protocols 3 classes and what not it's just too much for doing something simple
Thank you❤
You're welcome 😊 Please feel free to ask questions on the same.
Ravi as usual you nailed it mate!!! But again sometimes some people adamant to use this pattern nowadays even if not required for simple navigation…
Lack of analysis will always sabotage a project,
creative developers to look cool will implement a pattern even when it’s not needed
but to clean coders they actually look like fools who implemented something when it’s not needed or makes the code more complex than it needs to be.
these days many devs just hear the word pattern and they don’t do their analysis on it like if the pattern is good or not or even needed for their project
it’s like everyone just turns a blind eye on the analysis part.
Force using a pattern is like having a branded car with 10 issues,
the car owner will feel the pain of those issues while driving
but will just have one satisfaction which is having a branded car…
well imagine out of those 10 issues one is with engine and other is with breaks 😅
@@CodeCat15 Well said the only satisfaction is having a branded car…
Helpful topic bro ... love u from Telangana
Thank you, am glad this was helpful 😊
Coordinator is same as Router in VIPER ? Is I’m correct
When we use Tabbar and side bar in that case delegate method is not working MainCoordinator function are not calling .
i appriciate your work, but i had some quz for you, if we have more screens, do we like to use this maincordianator page to write many function for according to the screens?,
Thank you for the kind words, if we have more screens then in that case we create child coordinators which is explained in part 2.
If everything is added in the main coordinator then it will create something called as massive coordinators.
So to solve this, we will have to create one child coordinator per view controller.
In part 2 you will also find how this pattern raises the code complexity for achieving a small benefit
And in part 3 you’ll learn how just using coordinator pattern is not enough because there are problems with this pattern
My opinion is do not use this pattern, coz you’ll just be increasing the code complexity, the trade-off for using this pattern is high.
You fill your followers with full of confidence with detailed info on any topic you choose. I was wondering why Attrition rate increased since you started the channel LOL : 😂
Thank you Nishant, the main idea after all was to show how easy it is to write clean code and to think before code 😅
@@CodeCat15 Clean coding was only a word for me before I started following your channel. Now I am using it by myself and encouraging my team by sharing your videos!!
That's great
superb and very nicely explained sir. Thanks you. When is the second part coming sir?
I will try to roll it out by end of this week, I am glad the video was helpful, please feel free to ask questions and do share the video with your iOS group.
@@CodeCat15 your videos are getting shared by default sir :)
Thank you so much 😊
Hi @Ravi, It will be great if you can make a video on Combine Framework?
That's the plan going forward, there will be more videos on the combine framework and some design patterns. Thank you for the suggestion.
In MainCoordinator.swift file there are several functions for push view controller can we reduce it to one function and make it generic?
Yes you can surely do that but using a generic function may add a slight runtime overhead since the compiler needs to determine the appropriate view controller type to instantiate and push. Although the impact is generally minimal, it's worth considering in performance-critical scenarios.
When using a generic function for pushing view controllers, it's crucial to ensure type safety, maintainability, and performance while avoiding unnecessary complexity and code bloat.
can we Implement this on SwiftUI for navigation?? In swiftUI at some point navigations goes very down we have end up with tight coupling.
Please share any blog or something.
Yes we can implement this pattern in SwiftUI as well, I always suggest using the default navigation unless the default navigation becomes a big problem.
How to use navigator pattern in SwiftUI like
Login - Singnup - Forgot
Tabbar: Home - Notifications- setting where each tab will have own navigation
But for someone who is not using segueways for navigation and using one navigation controller for whole app by setting it in scene delegate is that's necessary for them to follow this pattern as we are creating an extension of view controller so we are already writing 2 lines of code for navigation one is in declaration of main coordinator and other is navigateToXYZ() and also when we have to pass some properties to next view controller we have to pass them in this function so can't we directly write two lines of code on each button's click?
Will it be bad because by doing this we are not rewriting the code again and again and we are done with only 2 lines of code and don't have to create seperate file for each view controller.
Please share your opinions
Thank you for writing a detailed comment,
my first question is does your project have a need to use this pattern, and if yes
what was the issue with the default navigation process and how does this pattern solve it? (don't give answers like loose coupling, or SRP) I am looking for an actual technical comparison with the default process.
I would refrain from using this pattern if it's not needed at all, yes there are one or two advantages but patterns should be used to solve an existing problem and not to make simple tasks more complex that's over-engineering.
Actually i don't know if there is any need of this pattern in my project, i was just asking you because I'm a big fan of your coding skills and knowledge so i just watch your each video and try to improve my knowledge and practical coding skills by implementing it in my projects, so i just want to confirm the reason of implementing this pattern actually I'm not that much capable at this stage that i can evaluate the pattern to be used on the bases of requirements.
Please also make a video on how to choose patterns according to requirements.
Will this pattern can apply , if my project has .xibs instead of storyboards?
It's going to be tricky to implement the coordinator board but I'll try to answer this question (via demo if possible) in the next video. The question here is does your project has a need for a pattern like this? if yes then what's the issue that your current project is facing due to default navigation process and how does this pattern tackle in solving those issues? Have a detailed comparison list of this first to talk it out with your senior before you implement this.
Is the second part released?
Given below are the links to part 2 and 3 of this topic
Coordinator pattern part 2: ua-cam.com/video/Pcx6k7_fgbo/v-deo.html
Coordinator pattern part 3: ua-cam.com/video/dxolBQR_MIg/v-deo.html
Hi, can you please explain this pattern with tabbar after login and navinate from specific tab item
I can but I guess when I release part 2 we all will rethink about using this pattern.
Plus if I may ask why would you implement this pattern? What’s the technical reason behind it?
I never faced any reason to implement this pattern except single responsibility principle for code separation part. I personally feel this pattern difficult to implement. And personally not suggest anyone to implement for only code separation part.
The pattern makes a simple task complex,
I wonder if anyone really gets any advantage of adding so much complexity to get a single benefit.
People using this pattern should really come forward and show how adding so much complexity to a simple task has helped them.
I too avoid using this pattern, if the framework is managing something for me I won’t add extra code to do the same thing.
I have a question. Is it okay to use presentation view Controller everywhere instead of navigation controller?
Or there is some scenarios for both.
Kindly guide.
that would depend on your app and client requirements if they are okay with such presentations then I guess its okay, if you ask me I would not like it because there may be some screens where full navigation is needed than just presenting a view controller.
@@CodeCat15 thank you so much for responding to me. You always come up with elite standard content in your videos. One thing is, presentation controllers can appear on full screen with modalPreentationStyle property set to full screen. I was worried if they take more memory space than a navigation controller.
Whatever class we use from the UIKit or Foundation they are already optimized and memory is managed in the right way by the iOS team.
It’s our code where we need to manage the memory and use the right patterns and make sure there are no strong references in the app.
As long as we write code with all the disciplines there are, we should be fine.
@codeCat15 In this architecture, Viewcontroller is holding an instance of Coordinator. If we have data models with ViewModel, in that case, I need to take the data from ViewModel and pass it to the coordinator. Instead, can ViewModel hold an instance of Coordinator? That way we do not need to get data from ViewModel in ViewController. Whats your opinion?
Short answer no, the ViewModel should not hold any kind of reference to the coordinator.
Below is a detailed explanation outlining my reasons:
🎯 Design intent: View models should be independent of the navigation and flow logic provided by the coordinator.
Keeping them decoupled helps in maintaining a clear separation of concerns and makes the codebase more modular and easier to understand.
🎯 Testing: ViewModels are often tested independently to ensure their logic works correctly.
When the ViewModel is aware of the coordinator, it introduces a dependency on the coordinator in the test environment, making unit testing more complex and less isolated.
🎯 Single Responsibility Principle (SRP): The viewModel's primary responsibility is to hold and manage the data that the view displays and to communicate with the low level classes.
By adding the responsibility of coordinating navigation, it violates the SRP, leading to less maintainable and harder-to-read code.
🎯 Memory leaks: If the viewModel retains a reference to the coordinator protocol, it may lead to retain cycles and memory leaks.
Coordinators are often retained by view controllers, and retaining them in the viewModel can lead to circular references.
Knowing the above if you still want to do it then you will be breaking many programming rules and disciplines and will introduce complexity to the code.
I consider this pattern complex enough in it's normal form, wait till you see part 3 of coordinator video where I am explaining how the coordinator itself is adding to the problem it was set to solve.
The other approaches I feel we can use is
1.keep the closure in viewModel and listen in the coordinator.
2.If we use reactive framework we can add a publisher in the viewModel. And we can listen to it in Coordinator.
Of course in both cases we will use protocols, that way there will be no tight coupling and viewModels can be tested independently.
What's your opinion about this approach?
@@rohitp9371 If the VM listens or responds to coordinator events then wouldn't that violate the the responsibility of the VM?
Question: Would it be okay If I use the Table view delegates in the ViewModel? UITableViewDelegate is a protocol so based on what you propose it would be okay to shift this code to the view model as well right?
In scenarios like push notifications or complex situations with multiple navigations or sheet presentations, including view presentation logic in the VM can lead to pollution of the ViewModel.
This can result in the ViewModel making decisions related to view appearance and dismissal, compromising the VM's intended purpose.
Furthermore, splitting the navigation logic into two files, ViewModel and Coordinator, would undermine the benefits of using the ViewModel and the Coordinator pattern.
Using closures or reactive frameworks for coordinator events in the ViewModel can make the code more complex and harder to read. Additionally, it can introduce testing complexities, making the overall codebase less maintainable.
Having worked with developers who experienced the drawbacks of the Coordinator pattern in mid to large projects, we should be cautious.
Maintenance overheads, tight coupling between coordinators, overuse of coordinators, and a lack of standardization can lead to unfavorable outcomes, it is crucial to be mindful of potential challenges that may arise as the project scope expands or involves complex navigations
Imagine if you want to move away from coordinator pattern tomorrow because apple introduced something better, then changing away from the Coordinator pattern in the future would result in high costs due to navigation logic spread throughout the codebase.
To maintain a clean and organized architecture, let the Coordinator pattern handle navigation and navigation logic between views. If data needs to pass from ViewModel,
it should be done through the View because the View would demand data from the ViewModel and what the view does with that data is not the concern of the ViewModel, this maintains separation of concerns.
@@rohitp9371 I invite you to review this video of coordinator where you can overcome some of the things but again, look at the code that I have to write for taking out just few lines of navigation. I hope this helps, please ask more questions I will be happy to answer them.
Clean Coordinator pattern implementation: ua-cam.com/video/dxolBQR_MIg/v-deo.html
So, it is advisable to use this pattern when one of my screen has navigations to a lot of screens right?
In general no, how many screens are we talking about?
@@CodeCat15 let's say in double digits. i have developed a screen which has that many navigations.
Is it simple navigation or you need to pass any data to those screens from your current view controller?
@@CodeCat15 in some cases, i have to pass data.. like variables, not complex models.
Sir do freshers are expected to know the design patterns? or Its limited to SOLID principles ?
I would expect a fresher to know at least Singleton pattern. There’s a playlist called code like a pro where SOLID principles are explained do check it out
Link: ua-cam.com/play/PLb5R4QC2DtFuC7WzUd5bJP3tdVsUcI8E8.html
@@CodeCat15 Thank you for quick reply sir !
I am familiar with that as I am developed few POCs with that pattern with SOLID principles and learnt from you only
Also I wanted to ask similar question on concurrency side up to how much extent fresher should be knowledgeable there ?
Does your playlist of operation queues and GCD is the required knowledge or it would be advance ?
Currently I am familiar with ARCs(redundancy cycles) and basics Dispatch Queue and dispatch groups
do they expect fresher to code up example of semaphores and deadlocks handling ?
From a fresher I would expect them to know the following
1. Constraints
2. API parsing without any third party
3. Database CRUD operations with core data or realm anything is fine
4. Basics of concurrency
But it does not matter what I expect, coz you see different companies have different expectations from a fresher and it totally depends on the org.
If I was working with a fresher, I would expect them to know the above 4 things rest other coding practices they’ll learn when they start working in team with me.
As senior it’s our responsibility to groom them the right way to explain what we are doing and why and hear them out too if they have some ideas on how things can be further improved
@@CodeCat15 Thank you sir ... yes i understand requirements may wary company to company i just want to get rough idea of bare minimum and where i stand right now
e.g we have different storyboard (rather than Main) and want to pass multiple values to another controller.
passing values should be no problem, once the view controller is instantiated, in the storyboard protocol you can use whatever storyboard you are using and once its instantiated, you may pass a parameter to a funciton like
// this is a sample code, will be covered in part 2 of the video
func navigateToSomeController(value: String){
let controller = SomeController.InstantiateFromStroryboard()
controller.someValue = value
self.navigationController.pushViewController(controller, animated:true) }
Hope it helps and if not, please feel free to ask more questions I will be happy to answer.
@@CodeCat15 yep, but i have a query. If we add need 4 to 5 value on other screen, so it is ok? to add 4 or 5 parameter inside function?.
if you have more than 2 parameter then consider passing a model than function parameters.
@@CodeCat15 got it, thanks
not good to create instance of mainCoordinator inside loginvc better to pass in init of view controller.
The mainCoordinator is passed as a delegate reference there’s no instance being created on the loginVC.
Coordinator pattern is after all a delegate protocol pattern and to avoid strong references we have used the weak keyword.
Let me know if that answers your question and feel free to ask more.