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 😊
@waheedafolabi6929
2 жыл бұрын
Very helpful…thanks for the awesome content!
@ArifulIslam12365
2 жыл бұрын
Thank god I didn't need to ask gou to make video on this. ❤️❤️❤️❤️❤️
@CodeCat15
2 жыл бұрын
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.
@pratikgupta7373
2 жыл бұрын
thanks for awesome tutorial
@CodeCat15
2 жыл бұрын
I am glad this was helpful Pratik, please feel free to ask question and do share the video with your iOS group.
@pratikgupta7373
2 жыл бұрын
@@CodeCat15 sure
@NamitaMaheshwarinim
2 жыл бұрын
Really informative
@CodeCat15
2 жыл бұрын
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
@JunaidKhan-ny8tu
2 жыл бұрын
wow
@CodeCat15
2 жыл бұрын
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
@Jock3R87
2 жыл бұрын
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…
@CodeCat15
2 жыл бұрын
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 😅
@Jock3R87
2 жыл бұрын
@@CodeCat15 Well said the only satisfaction is having a branded car…
@puneetpal1466
2 жыл бұрын
nice n well explained👌
@CodeCat15
2 жыл бұрын
Thank you, am glad this was helpful. Do share the same with you iOS group and feel free to ask questions
@ajaychaudhary358
2 жыл бұрын
I will definitely try this pattern in my new project. Thanks for all your efforts.
@CodeCat15
2 жыл бұрын
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.
@marcoalonso6759
2 жыл бұрын
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.
@CodeCat15
2 жыл бұрын
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
@rebellious_703
10 ай бұрын
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?
@CodeCat15
10 ай бұрын
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.
@ernishant11
2 жыл бұрын
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 : 😂
@CodeCat15
2 жыл бұрын
Thank you Nishant, the main idea after all was to show how easy it is to write clean code and to think before code 😅
@ernishant11
2 жыл бұрын
@@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!!
@CodeCat15
2 жыл бұрын
That's great
@hamidkia5035
Жыл бұрын
Great work
@CodeCat15
Жыл бұрын
Glad this was helpful.
@d_e_e_p_a_k_000
Жыл бұрын
How to use navigator pattern in SwiftUI like Login - Singnup - Forgot Tabbar: Home - Notifications- setting where each tab will have own navigation
@rahulchaurasia5011
Жыл бұрын
Nice Video Very helpful, Thank you for making it . can we used Coordinator design pattern with switfui using NavigationView
@annapurnachandra3537
2 жыл бұрын
Well explained. Will use this pattern on the coming task.
@CodeCat15
2 жыл бұрын
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.
@annapurnachandra3537
2 жыл бұрын
@@CodeCat15 sure.
@abhishekdhiman9771
2 жыл бұрын
Awesome and great learning experience with you since last year.✌🏼
@CodeCat15
2 жыл бұрын
Many more to come ✌️
@muhammadusman-vc5re
2 жыл бұрын
Excellent way of teaching.
@viveksharma1402
Жыл бұрын
When we use Tabbar and side bar in that case delegate method is not working MainCoordinator function are not calling .
@mafarunnisap.k5151
2 жыл бұрын
Excellent Video
@subhadeepchakraborty4638
2 жыл бұрын
Please make a video on Clean Swift
@sreehaentertainment8126
2 жыл бұрын
Helpful topic bro ... love u from Telangana
@CodeCat15
2 жыл бұрын
Thank you, am glad this was helpful 😊
@RahulVerma-tv6gq
2 жыл бұрын
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
@CodeCat15
2 жыл бұрын
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.
@RahulVerma-tv6gq
2 жыл бұрын
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.
@prataprana2963
2 жыл бұрын
Great❤️❤️❤️
@CodeCat15
2 жыл бұрын
I am glad this was helpful
@AbdulRehman-mk1fz
2 жыл бұрын
Great work ❤ Please make a video using Coordinator design pattern with Clean architecture and MVVM.
@rahulfate435
2 жыл бұрын
Hi, can you please explain this pattern with tabbar after login and navinate from specific tab item
@CodeCat15
2 жыл бұрын
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?
@rahulfate435
2 жыл бұрын
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.
@CodeCat15
2 жыл бұрын
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.
@soumikmukherjee8752
2 жыл бұрын
superb and very nicely explained sir. Thanks you. When is the second part coming sir?
@CodeCat15
2 жыл бұрын
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.
@soumikmukherjee8752
2 жыл бұрын
@@CodeCat15 your videos are getting shared by default sir :)
@CodeCat15
2 жыл бұрын
Thank you so much 😊
@Real_Indian_bhartiya
2 жыл бұрын
Superb ..
@karanmehta6768
Жыл бұрын
In MainCoordinator.swift file there are several functions for push view controller can we reduce it to one function and make it generic?
@CodeCat15
Жыл бұрын
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.
@iostutorial518
2 жыл бұрын
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?,
@CodeCat15
2 жыл бұрын
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.
@theanonymousfoodie8906
2 жыл бұрын
Coordinator is same as Router in VIPER ? Is I’m correct
@vincentjoyhere
2 жыл бұрын
as always, excellent tutorial 👍
@hemantstha4144
Жыл бұрын
Thank you❤
@CodeCat15
Жыл бұрын
You're welcome 😊 Please feel free to ask questions on the same.
@amitavsingh593
2 жыл бұрын
Hi @Ravi, It will be great if you can make a video on Combine Framework?
@CodeCat15
2 жыл бұрын
That's the plan going forward, there will be more videos on the combine framework and some design patterns. Thank you for the suggestion.
@iosprogramming1122
2 жыл бұрын
e.g we have different storyboard (rather than Main) and want to pass multiple values to another controller.
@CodeCat15
2 жыл бұрын
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.
@iosprogramming1122
2 жыл бұрын
@@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?.
@CodeCat15
2 жыл бұрын
if you have more than 2 parameter then consider passing a model than function parameters.
@iosprogramming1122
2 жыл бұрын
@@CodeCat15 got it, thanks
@mobtech6738
2 жыл бұрын
Is the second part released?
@CodeCat15
2 жыл бұрын
Given below are the links to part 2 and 3 of this topic Coordinator pattern part 2: kzitem.info/news/bejne/sZmunJ9tmJiYlaQ Coordinator pattern part 3: kzitem.info/news/bejne/xa6l0naHi5F-fJw
@rohitp9371
Жыл бұрын
@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?
@CodeCat15
Жыл бұрын
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.
@rohitp9371
Жыл бұрын
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?
@CodeCat15
Жыл бұрын
@@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.
@CodeCat15
Жыл бұрын
@@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: kzitem.info/news/bejne/xa6l0naHi5F-fJw
@mshauket5679
2 жыл бұрын
not good to create instance of mainCoordinator inside loginvc better to pass in init of view controller.
@CodeCat15
2 жыл бұрын
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.
@kurbanalimasu4895
2 жыл бұрын
Thankyou so much sir
@CodeCat15
2 жыл бұрын
Most welcome
@hardipgajera2316
2 жыл бұрын
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.
@CodeCat15
2 жыл бұрын
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.
@NamitaMaheshwarinim
2 жыл бұрын
Wow ...
@CodeCat15
2 жыл бұрын
😊
@zulqarnainbutt9473
2 жыл бұрын
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.
@CodeCat15
2 жыл бұрын
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.
@zulqarnainbutt9473
2 жыл бұрын
@@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.
@CodeCat15
2 жыл бұрын
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.
@Shade_with_me_7
2 жыл бұрын
Will this pattern can apply , if my project has .xibs instead of storyboards?
@CodeCat15
2 жыл бұрын
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.
@roh9934
Жыл бұрын
So, it is advisable to use this pattern when one of my screen has navigations to a lot of screens right?
@CodeCat15
Жыл бұрын
In general no, how many screens are we talking about?
@roh9934
Жыл бұрын
@@CodeCat15 let's say in double digits. i have developed a screen which has that many navigations.
@CodeCat15
Жыл бұрын
Is it simple navigation or you need to pass any data to those screens from your current view controller?
@roh9934
Жыл бұрын
@@CodeCat15 in some cases, i have to pass data.. like variables, not complex models.
@AnkitSingh-wq2rk
2 жыл бұрын
Sir do freshers are expected to know the design patterns? or Its limited to SOLID principles ?
@CodeCat15
2 жыл бұрын
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: kzitem.info/door/PLb5R4QC2DtFuC7WzUd5bJP3tdVsUcI8E8
@AnkitSingh-wq2rk
2 жыл бұрын
@@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 ?
@CodeCat15
2 жыл бұрын
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
@AnkitSingh-wq2rk
2 жыл бұрын
@@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
@buba7456
2 жыл бұрын
Very helpful. Thank you
@CodeCat15
2 жыл бұрын
Glad it was helpful!, part 2 will be coming this week stay tuned and please feel free to ask questions on this pattern.
Пікірлер: 104