Basics of MVVM architecture pattern in iOS swift for beginners in hindi
HTML-код
- Опубликовано: 6 мар 2020
- MVVM pattern was introduced way long back, this swift MVVM tutorial for beginners will help you to learn the basics of MVVM pattern. MVVM stands for model view ViewModel and recently MVVM in swift is catching the eye of many swift developers as an architecture pattern which can help them maintain separation of concern and write organized code.
In this MVVM architecture pattern video tutorial, I will try and explain how a swift iOS developer should select the right architecture pattern for an iOS project, not only that we are going to bust some common myths around the MVC pattern swift which has been going across the internet.
Mostly few developers these days are getting into the habit of criticizing the architectural pattern than really asking the question if they have implemented the pattern right, you will only run into issues if you have not implemented the architectural pattern in the right way and hence this MVVM basic introduction video will cover all those points and will explain in depth about
1. How you can choose the right architecture pattern for your project
2. Busting the myths across MVC architecture pattern
3. Role of a senior developer when they select an architecture pattern for their project
4. And many other questions that a beginner has when they start with MVVM pattern
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
✅ Subscribe to the channel and stay ahead of everyone by following the right way for writing clean code in swift. 🔥🔥🔥🔥🔥
Link: ruclips.net/user/codecat?sub...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🎶 Royalty free Music: www.bensound.com
----------------------------------------------------------------------------------------------------------------------------------------
📥 Download the ppt from the given link: drive.google.com/open?id=1P8y...
----------------------------------------------------------------------------------------------------------------------------------------
###########################################
Connect with me on social media
📧: codecat15@gmail.com
🐦: / codecat15
Facebook: / code.cat.792
Github: github.com/codecat15
###########################################
#mvvmSwift #swiftMVVMTutorial #swiftMVVMHindi
Very good session.
One question. If I chose which architecture should I use in our project according to the requirements and complexity. But if in future the complexity of app increases so what should I do in this case?
Because no projects stable at one time, client change the complexity as well as the requirements.
First of all, thank you for asking this question.
I will explain more on this in my coming video but let me answer parts of this. The complexity given by the client can be classified into two groups:
1. Either the client asks to make some complex changes in the existing module for which you have already written the code which is coined as a CR or change request
2. The client gives a completely new requirement which was not part of the original requirement like create a new feedback screen or create a new batman suite 😂😂😂
If you have seen this video till the end, you know that it's the separation of concern or single responsibility which matters a lot, we cannot predict what the client will give us but you can surely code better following separation of concerns like for module A all the code is isolated in the box A, for module B all the code is isolated in the box B and if changs come to module A then you know that only place where changes needs to happen is in box A and not in box B.
Let's say a new requirement comes so what we do is create a new box for that requirement and isolate the changes of that new requirement there, so this way box A and box B are not impacted at all.
In the MVC screenshot shown in the video that's how we isolated the changes so any complexity is thrown at the project, we see for which box it is and handle it there or if it's totally new then we create a new box for it.
I strongly believe it all boils down to how we are maintaining separation of concern and you can follow that with MVC pattern as well as shown in the screenshot, but we don't and when we see MVVM which follows the separation of concern by design we think that it's the pattern which makes our code better but it's not.
I wanted to show in this video ki it's not the pattern that makes your code clean and solid, it's you who makes it clean and solid by following good coding disciplines and hence code like a pro series was made as I was getting asked what are the principles that i follow as a developer.
@@CodeCat15 Thank you for the explanation. I will be more clear in your future video.
@@Puneet843 Kudos to that buddy, I will try to elaborate as much as I can in my next video, sometimes I feel that when the video is too long I am making a movie or something hahaha
@@CodeCat15 I feel your example is very straight to that point so that we can easily understand.
Also, we can watch any videos if we are interested on that topic.
Length is not the limit but interest.
@@Puneet843 Thanks a lot man really appreciate it
finally found an amazing video on MVVM. Not only the video, best RUclips channel for writing code properly, thx a lot man. waiting for two way binding with MVVM
One of the best sessions on MVC vs MVVM. I haven't understood the concept of choosing MVC over MVVM this clearly in the recent times looking at the other blogs and articles. Thank you.
Welcome to the channel Vinod and am glad the video was helpful. There’s also two videos I made on MVC do check them out as well to get more details on MVC
Mvc intro: ruclips.net/video/Vyy2_onhouQ/видео.html
Decomposition with mvc: ruclips.net/video/9qQrzjPAFvA/видео.html
Hope it helps and feel free to ask questions
@@CodeCat15 sure. Thanks
No doubt, you explain really well, especially when you give examples....
Hello Narendar, welcome to the channel and am glad these examples are helpful to you. If you have any questions then plz feel free to ask and i will be happy to answer them. Also please do share this channel with your iOS group on Facebook or WhatsApp
really a wonderful session it was. every thing explained properly with deep knowledge and understanding. ever best tutorial on RUclips on MVVM and MVC. it totally change my thinking process about design and architectural patterns. keep it up such session it help all junior and intermediate developer to learning great things who have no smart senior resources at work place.
One of the best teacher on RUclips.
Hi Ravi, It was awesome explanation with very good real time examples. Also it's really good as you also explaining the pros and cons. I didn't find the video for MVVM two way binding in this channel. Can you please share if its already available. Thanks a lot.
The way your videos explaining the concept is amazing really liked your explanation.. Just wanted to say thanks as ios developer I found few videos so much helpful.. 🙂
Welcome to the channel Abhishek and am glad these videos are proving to be resourceful, do feel free to ask questions and do share the channel among your iOS developers circle
Again excellent explanation, Ravi.......really loved your video
thank you brother for making this concept so clear
was waiting for this since long time..
Theres more to come on mvvm, this is just to cover some theory ground and bust some misconceptions around mvc pattern. This video will tell change your views on how you look at architecture pattern. Hope you like it. Do share this with your ios group and feel free to ask questions if you have any will be happy to help
Aree baba tu to DEV MANUS NIKLA RE, hats off brother, really appreciate your work from heart, thank you soo much for being a senior to us (dumb iOS developers)
I am just a learner like you who’s still trying to learn and do the right thing.
I like to ask & know the technical reason behind the implementation and that’s the process where you can identify and save yourself from going down a horrible path of code catastrophe.
Ye har dev ko karna chaiye but koi karta nahi,
senior se jitna ho sake utna question puchna varna aap implement to kar logaye cheezo ko lekin kyu implement kiya hai ye pata nahi hoga aapko
Agar senior creative dev hai to fir good practices ko bolo khatam bye bye good bye Tata gaya
Once again, thanks for your kind words and welcome to the channel 😊
Binge watch hoga abhi apke ke channel ka, and then start practicing one video(topic) at a time. And yes, I will pray that your channel will get infinite success.
bhai sahab , I like u r technical quality, First time I watch u r video, and I am fen of you
Thank you for the compliment bhai, ye topic pe koi questions ho to zaroor puchna, aur plz ye channel aapne ios group k saath share karna 🙏
Your sessions give great clarity 🙏 Thanks
Thank you Rohit I am glad they are helpful
Thanks a lot sir ❤️
The best explanation of every topic.
Do watch all the videos on this series as every video will show how your approach should be as a developer when we are coding, once am done with mvvm i will give my opinion on choosing the architecture pattern. Btw don’t forget to share this with your iOS group 😄
Finally got the correct platform to understand and learn the clean coding tricks
Hello Bushra, welcome to the channel I am glad these videos are helpful to you. Please do feel free to ask questions and do share this channel with your iOS group on what's app or Facebook :)
@@CodeCat15 could you please make some video for TDD (Test Driven Development).. It would be great help for me.
One of the best video about MVVM :-)
Thanks for your kind words Junaid, the best is yet to come this was just a trailer to clear all the misconception that is spread when someone says MVC has issues, I just cleared the air a little that you can choose MVC and still end up with
1. Less amount of code in viewController
2. Loose coupling,
3. Test cases for both your code and UI
so it's not the pattern that has issues it's the developer who is NOT implementing the pattern in the right way. The next series is all going to be about how you should implement the patterns in the right way. I think I will pause the API series for now.
BTW do ask questions if you have any on this, I know many of you wanted to see me actually implement the MVVM pattern but I think even before that the misconceptions need to be cleared out of the room.
Do share this video with your iOS group and feel free to share this on social media too 👍
Code Cat thank you 😍 keep it up 👍 excited for more videos
exactly thats what i am thinking... good explanation.
I even have more details on MVC video, mostly creative developers will not implement mvc pattern right and then blame the pattern itself for being clunky, apple has various flavors of mvc so one should look at them and then make a call based on their app if they want to move to mvvm or some other pattern based on the complexity of the project.
Mvc video link: ruclips.net/video/Vyy2_onhouQ/видео.html
great session .....
I am android developer. Learn deep coding knowledge from your video.
Thank you, am glad this is helpful.
I can see the lion's attitude throughout the explanations as there in the logo of the channel. Well explained, but as said in this video itself. I'm gonna cross check everything that said in this video.
Yup, mostly devs see something new and they treat it as a silver bullet specially creative developers, we saw this in the case of RxSwift, VIPER and MVVM. I am surprised as how developers don't follow decomposition and solid principles and were very much fixated on the architecture.
The architecture is just how we arrange the folders and know high level responsibility of one or two layers but then it's the low level design patterns and single responsibility which really adds value actually they both go hand in hand, you cannot select one and ignore the other and then blame the pattern.
it's like you buy a luxury car and just because you don't know how to drive you say that the car is useless and has issues.
In the case of MVVM there are many examples where we can see fat view models just like fat view controller so we really need to think it through before we write code as to why we are selecting a pattern or architecture and how the data flow is going to be and is the whole design going to hold the water.
Hey bro really nice tutorial and this would help a lot for clean coding.
I’m eagerly waiting for two way binding video on MVVM. 🙏🏻
two way binding is not really a feature of swift but yes it can be achieved it's not compulsory for you to implement it but then we all can see in SwiftUI how beneficial that feature can really be, I have slacked on the two way binding video a lot but I will roll it out soon after I finish a series.
Do support the channel by sharing it with your iOS group and feel free to ask more questions
The best explanation 😌
Thanks Ahsan, do share this with your iOS group on WhatsApp or Facebook and feel free to ask questions on this topic
Really good video.... can you make another video in which you can implement the mvvm in any project for better understanding?
Thank you for this video, I really need this.
Yes i was getting a lot of emails on this topic, the major thing about this video is that it’s not the architecture pattern which has issues its all about how we developers implement it. I have used mvc for a long time and never had issues and when i read stuff on the internet about lack of testability and everything that made me laugh. So wanted to show that as well, next week session on mvvm will be even better if you liked this one. Do share this with your iOS group
@@CodeCat15 sure and waiting for next video.
@@arvindpateldev You got it, am working on the video and it will open some doors to test cases that I always talk about so maybe the video will be a little lengthy :)
Nicely explained concepts of MVVM & other stuffs.
Glad they were helpful Jyoti, if you have any questions please do ask and do share the video with your iOS group
Bro such ma.. Dil kush ho gya I will subscribe your channel
Thank you, I am glad this was helpful
very good explanation. thanks a lot
Thank you :)
Awesome video ..you deserve much more subs
Thank you so much 😀 do share it with your iOS group and do ask them to subscribe if they like the content, and please always feel free to ask questions
Hello Ravi,
I must say, you provide a very good insight about MVC and MVVM. Many concept clear now. I have one question you mentioned that you need to choose architecture pattern depends on project requirements. But sometimes project have many versions and it is not declared by client at the time of initial version, as per initial requirements we choose architecture but then it becomes hard to maintain. (There is a one catch though sometimes we don't manage our code as required.) But how to choose a pattern when project requirements is not fully clear or disclose by client.
Good question indeed Subhadeep so in such cases I have few projects where I started with MVC but then the client after initial few releases kept on adding things and the project started growing and the complexities increased so then we took a call to not change the architecture but to see if we can introduce more decomposition coz changing the entire architecture would take time to do it right.
So if we had time we surely went for what best suited for the project be it MVVM or adding RXSWIFT but if not we would add more abstracted layers with single responsibility to handle it and that too worked fine for us.
Take it like this you cannot teach a baby to run directly it needs to learn to crawl first, stand and then walk before it starts running
Same with project arch most of the time I have seen clients are very through with what they want and the change requests are minimum but then there are certain odd cookies
Also if you choose a arc like MVVM for a 5-10 page app then it’s okay but my question is do you really need it? Do check out my apple MVC video to know about apple MVC coz am sure there you will find more of how apple mvc really works
Link: ruclips.net/video/Vyy2_onhouQ/видео.html
When I heard about MVVM then I think it is very complex and hard to understand for fresher But with this video I can understand that it is also a architecture design pattern and it waill also simple but with some conditions. I will watch series of MVVM. Thanks CodeCat
Great Mandeep, I am glad this video was helpful for you. I am yet to make another video on using two way binding for MVVM because if you are using MVVM you need to have two way binding, so far swift does not support two way binding out of the box but with SwiftUI i think this will be doable, but you can also use the observer pattern and build your own utility for two way binding.
Do share this video with your iOS group and do ask them to subscribe :)
@@CodeCat15 Thanks sir , I already share your channel with my friends . they also watch your tutorial video.
Thank you for this kind gesture
Good explanation on MVVM
Please create video on VIPER architecture
WOW, Ravi truly satisfied the way you have explained the things Why as a developer one should not select any design pattern based upon any personal preferences unless analyzing the complexity of the project, adding value addition to the project, knowing the project requirement .....it completely makes sense for every developer think before writing the piece of code.
I am glad this video was helpful, mostly devs choose architecture pattern because either it sounds cool or some other dev or blog is promoting that pattern but the main question is how is this pattern making your project code maintainable and solving the problem in hand. If you have question on this topic then please do feel free to ask and do share this video with your iOS group so that they too can ask the right questions while selecting an architecture pattern
@@CodeCat15 Already shared with many and they are thoroughly enjoying your videos vlogs will share it too with few juniors and with many freshers who have opted iOS as a career option thank you for your feedback keep sharing your coding skills and knowledge with us this really good way to be well aware of best coding practice .
@@techcapture8363 Awesome I am glad these videos are worth everyone's time and are helping everyone. Thank your for your support it means a lot.
Awesome!!! Can you please make tutorial regarding Refresh Token Implementation. This will be great!
As of now I am working on a 3 video series and after that this is in my list. Thank your for your patience I’ll try to release them asap.
Best tutorial bro .Good job i learned alot from your video.Keep this ggod work contiinue .
Welcome to the channel Deepak, I am glad this tutorial was helpful. There's also a playlist on MVC pattern do check that out to resolve any doubts on MVC as well
Playlist link: ruclips.net/p/PLb5R4QC2DtFsGyVTm1DB4WpgIJQn_g2cb
Please feel free to ask questions and do share the channel with your iOS group.
Hello, very well explained!
please make a video on MVC
Hello Hiren, welcome to the channel, soon there will be a session on MVC as well I just began with core data and once am done with that will do a session on MVC and threading too. If you have any questions then please feel free to ask and do share this video with your ios group on WhatsApp or Facebook
Hi,
Can you suggest why we use structure in mvvm and not class? This has been a favourite question in interview nowadays.
Well Explain!
Thanks a lot, do share this with your iOS group and feel free to ask questions on this topic
Hey..Please bring with one MVVM- coordinator pattern tutorial with example.
Part 1 of the coordinator video is now live, plz check the same and share your thoughts
Link: ruclips.net/video/Ji0bqURWv68/видео.html
Thank you. :)
Welcome buddy, just feel free to ask questions on this topic. Will be happy to answer those. And do subscribe and share this with your iOS group
Hi,
Please make a detailed video for two binding. I not getting any better resources for the same.
Thanks Sir
Glad it was helpful.
One more subscriber for you!!!
@CodeCat Great Video but One think i must say that yes i agree with the poor implementation of MVC but as your button action performs an api call and if you have three to 5 calls and at the end you are also creating a huge controller and if you have some pagination logic then more one. One thing i observe here is activity indicator code and success failure logic is also repeated here. In this case if we are properly implemented mvc we still breaking SRP rule as a controller has multiple responsibilities. Love your Videos. thanks 🙏
Hey @Mukul thanks for your comment buddy 🙏
let provide more insights on this as what was the idea behind the code clean up and please do feel free to provide your inputs as well
1. if you have three to 5 calls and at the end, you are also creating a huge controller: What I assume by this is in a screen I have 3-5 calls for different UI components (correct me if I got this wrong), but then shouldn't the API team create one service which can show this information?
Like orders, order entity has a lot of information from different parts like quantity, tax, price, address, user info, product info etc but in the end, it's just one service which shows all these information, I am always against the idea to have 3-5 API calls in one view be it web or mobile app because why do you want your client to do so much to display data?
We have servers with humongous processing power give me one consolidated service which deals with this Godzilla, imagine calling 5 services out of which one fails or two fails what then what? Poor user experience? OR you can just say to API team that hey give me one service, not 5 or 10.
I allow 2 API calls but if it's more than that I call for a meeting because that view is displaying way too much information and should have fewer API calls for good user experience, also 3-5 API call means the user MAY have to wait for a longer period of time again by doing this we are opening the window for bad user experience. Let me not get started with the network latency because I can keep on going why this is such a bad idea to have so many calls in a single screen 😇
If you are doing this Mukul in your apps, I request you cut down the numbers of API calls because I think now you have got an idea that doing this is a bad design and is bound to fail. So again it's the developer here who has to think about such use cases before implementing 3-5 API's in a single view because the possibility of failure here is high.
2. if you have some pagination logic then more one:
As I said in the video, MVC is a UI pattern and if you have paging logic then it's okay because your UI demands it, what is your definition of a huge view controller? Also paging logic just adds 3-5 lines of code and I had paging code in this app too and the viewController had 80 lines of code, now how you can get a huge viewController is also sometimes due to auto-layout code and I think we should try to push a lot of that inside the storyboard or Xib's as much as you can because that code has potential to grow huge.
3. One thing I observe here is activity indicator code and success-failure logic is also repeated here:
MVC is a UI pattern, it's ok to have UI code in the view controller. If it was MVVM then all this code would have been dumped inside the view. With MVC you don't get that extra layer of view and hence all the UI code lives inside the view controller. This is one of the reasons why I am so lenient with SRP in the viewControllers or should I say these are the trade-offs that come with MVC.
4. In this case, if we are properly implemented MVC we still breaking SRP rule as a controller has multiple responsibilities:
Since this is MVC pattern and MVC is a UI oriented pattern, the functions inside the view controller can and will have UI oriented calls like activity, alerts etc, the essence of SRP is inside the manager class where it interacts with different components sharing just one responsibility. (Will share more on this in my next video).
As long as my viewcontroller is not directly dealing with business logic or validations I think we are good because your view controllers job is to just display the data and it doesn't care where the data comes from. When I implemented this for the first time I had the exact same question but then slowly when I understood more MVC I think these are some of the things that come with MVC, but if you are handling this in a different way would like to hear it and improve my code as well :)
Even the same with MVVM yes, your viewModel should never have any reference to any class that inherits from UIView, view section (UIView or UIViewController) of it handles the UI oriented work, and since MVC stands for model-viewController where should the UI call reside? If you say model the answer is incorrect, viewController, unfortunately, yes these are trade-offs when you choose MVC.
In the end, I would like to say, that it all boils down to the architecture pattern you select for your project, for a project with moderate complexity if you select MVC then my friend the issue is lack of analysis where we just flipped a coin and went with MVC for a project which demanded MVVM. And MVVM has been there for way too long period and the iOS world has just started to pick this up because of how MVVM gives them loose coupling but I see even for simple project you are going to select MVVM then there is no value.
Example: Let's say you need a vechile to travel to work, so you buy an SUV, well you could have purchased a truck too, a truck is also a vehicle and technically speaking you can travel with it as well, but then the requirement did not match the need for a truck but an SUV.
So if we select MVVM for every project, I think we are purchasing a truck all the time every time and giving birth to unwanted complexities.
MVC yes I agree it can have cumbersome UI code but that's how MVC is, but really it's our job as a developer to isolate that side effect as much as we can by following coding principles and good design practice.
I hope I was able to answer your question, if not please do ask more and do share this channel with your iOS group too would really appreciate it.
@@CodeCat15 Thanks for a very descriptive answer, I learn a lot from this, i agree that we should not use a Sword(MVVM) when we can do with a Needle(MVC) but i must say that we cannot use MVC when it comes to scalability. UIView should not be responsible for dealing with the Network library, making decision to show loader or not, Firing GAEvents, Making calls to helper classes for validating things, it should be dump, it must take user action and delegate to its business layer which is ViewModel. It's not about if i add pagination logic it adds 80 line of code its about everything should have its place and taking about SRP ViewController is doing many things in general when we start a project and when we ends a project, as ViewController has all the animation logic, Validation logics, Navigation Logics and many more responsibility because of the way it designs.
And One thing i ll add is working with bigger team and using Stoyboard will led to merge conflicts and its really hard to resolve Storyboard conflicts and if you say we could use xib, then yes we can but it increase the resource utilisation of system and memory when it comes to an app that has lot of files. Take it on a Positive way bt the way Great Learning from the Video.
There was this case where I was assigned to a maintinence project and the db had 80k+ records and this db was growing so the app for simple select statement took 15 seconds.
If you look at it, this app had lot of data due to which it became slow over the period of time, so we fixed it by improving our db queries and deleting the records we don’t need basically horizontal scaling techniques were applied keeping the same architecture pattern which was mvc.
As said if project has complexities like facebook app then mvc is not the pattern to go with.
Validation is a big no for vc, i agree we have animations and everything lives inside vc when it comes to a large scale project and most of the animation is also driven by the question if you want the basic iOS animations which the framework provides OR is that a completely out of the box animation for which you either use pods or write your own.
I see you have felt the same pain as many devs, yes storyboards are a big time mess when we work with a huge team and it’s painful.
And it’s just not the merge conflicts, you cannot create custom init if you work with storyboard as well which makes it difficult to use concepts like constructor injection so you heavily rely on property injection which am not a fan of
And don’t get me started on the segue coupling and i am not sure if it’s just me when the screen grows in number then xcode takes a huge amount of time to load storyboard and work fluidly.
You know i love having such conversations, because it’s only when we share knowledge we grow and improve our skills and be better.
Looking forward for more such discussions, it was a good one buddy loved it cheers 🍻
Hi Ravi, I have watched many videos and All are helpful :)
Can you make video on SwiftUI & Combine, perhaps with small demo app?
Thank you
Hello Ajay, welcome to the channel and thank you for making the request.
I can surely make a small app using combine but then for everything i use in that demo i would have to give a short explanation which i think does more harm than good, coz if you don’t understand the core concept behind why a class is used and what purpose it serves then I believe its a lost cause and we are learning without understanding.
I surely will do a demo on an app but after covering few other wrappers which are heavily used coz then it will be easy to understand and we can ask more quality questions
I would also request you to please make a video on topic associated types and associated protocols and associated values with real-world examples. Thanks looking forward to your feedback.
I think i did show a small demo of associated types in one of the core data videos for code improvements i think its one to many video of core data but i have not done a standalone video on associated types. Have used them for just creating a base repository protocols with generics in my project for now
so good
Glad it was helpful, please feel free to ask questions and do share the channel with your iOS group.
Plain MVVM(Vannilla version) + Coordinators should be the standard version of a project. It will be easy to accommodate new changes and features in the future. VIPER is next level.
Hello Umang, welcome to the channel. I would say it depends on what the project demands and then adjust coz you may start with mvvm and have all those layers but it may not necessarily be needed for a project of small volume.
Viper is a different ball game altogether and i love this pattern a lot specially when you are working on a complex application that’s demanding.
Every project has a different size and requirements and based on that we decide the architecture pattern best fitting its demands. If we try to add anything extra just to future proof it then it just becomes gold platted.
Make video on VIPER Architecture as well
nice Video Bro
welcome to the channel and thanks for the comment, do share the video with your iOS group and do feel free to ask questions
picking a mvc pattern could be a batter approach .. because .. we may need to add any new enhancements in our future in that case.. mvc makes us easy to initiate that feature from wherever we want but for mvvm .. there could be a chance of tight coupling between viewmodel and view or viewmodel or controller when any new feature needs to add.. its just my observation !
it depends on how the team plans on doing the decomposition, adding tight coupling is easy but the real challenge is to keep them separate, I would use the view model to orchestrate the calls between the layers but the real deal is having those layers in the first place
Models are not only data properties/structure.
Wikipedia says:
Model
The central component of the pattern. It is the application's dynamic data structure, independent of the user interface.[10] It directly manages the data, logic and rules of the application.
Model is responsible for logic as well.
It’s debatable, a lot of folks add business logic in their model but then it just becomes a pain to manage,
having one layer that manages the business logic is much helpful and let me add my technical reason for that
what would one do when a single model has 7 different business rules?
what if the same business rules are applied to multiple models so will you copy paste those rules in all those different models?
Coz if we do then we are violating DRY principles or should I say we have code duplication in the project
and if the business logic changes we have to make the same change at all the places where we copied the rule and what if we missed?
It’s always better to keep the area of volatility in mind when we architect the project, having business rules in model to me is a big NO
I am a big fan of legos and the same principle I like applying in my project as well 😅
please make video on clean swift architecture as well.
Indeed Arslan that's a good suggestion
Hi Ravi, I am Vyankatesh Big fan of yours(Liked almost every single video of your tutorial😅)... Very great video I must say (as usual)... Just one doubt that Are there only 2 reasons behind selecting this particular MVVM architectural pattern? Or any other reasons are also there?
There are many reason why one would select a particular architecture pattern, but I see things in a different way.
What matters to me are things like
🎯 Avoiding functional decomposition.
🎯 Making sure that there's no violation of Single responsibility principle OR DRY.
🎯 Making sure we are not breaking abstraction.
🎯 Making sure that unwanted patterns are not implemented else they increase the code complexity for no reason.
Irrespective of what architecture you choose if these minor details are not followed then you can choose the worlds best architecture and still end up with a spaghetti codebase
@@CodeCat15 thank you very much for clarification Ravi👍
Hey Cat, most of the time we say we can't write many tests with MVC so we go for MVVM, In my opinion, no design patterns are perfect, we can write clean, scalable code with any of the design patterns.
Design patterns have many categories and each category is for specific purpose like structural, behavior, creational, concurrency and so on
Let me ask you something, If I want to cut a vegetable there are many tools I can use
I can use a kitchen knife
I can use a sword
I can use a saw
I can use a blade
I can use chain saw
I can use scissors
I can use a surgical blade
All the above can cut the vegetable, but the most suitable option we have is the kitchen knife
So when someone suggest we can implement any pattern and write code
I have multiple thoughts in my mind, I want to know what the pattern is and how it solves the problem in hand, also what are the drawbacks of using that pattern.
And MVC and MVVM are not design patterns its strange majority of devs call them design pattern when they are clearly architecture pattern
Happy iCoding :)
Happy iCoding Rishabh 😊
Hey Ravi, what is one-way binding? Is it updating UI should update the model, or vice versa?
In one way binding the flow of data is in one direction strictly i.e from UI to models a change in UI changes the model but a change in the model requires us to reload/refresh the view.
Example: UIKit framework
Two way binding this refresh is done by the system itself
Example: SwiftUI
Can we have a video on defining the project's complexity, please?
m beginer from where i should start to learn oops concepts
Can you recommend or create the API Client Example well defined, Which you think to implement on project, with couple of changes.
Hello @Saurabh welcome to the channel, I did create the API client as an open source project on GitHub which you can use as a Cocoapod in your project and the details on how to use it is mentioned in it's GitHub page. Does that answer your question? and if not then please feel free to ask more questions.
github.com/codecat15/HttpUtility
Code Cat Thanks i will look into it.
Cool, do ask questions on the utility as well if you have any, and watch the API playlist of mine where I make this utility and explain what the code does in details.
Do share this with your iOS group on WhatsApp or Facebook or with anyone who wants to learn swift would appreciate your kind gesture 🙏
Please create video for design architecture
I will, more to come in this series
Hi Ravi, In many articles its mentioned that as difference between MVC and MVVM is in case of MVC the data processing (performs logic over data) happens in view in MVC pattern and in case of MVVM the operations on data happens in View Model so is that correct? And if yes then under view we mostly have storyboard inly then where exactly data processing is happening?
This was my first video or so on YT, I didn't knew the code was this tiny, but I think over the next couple of videos you'll see it has improved a bit. Thank you for your feedback much appreciate it.
@@CodeCat15 No ravi, it was not feedback, I just asked that whether what is mentioned in above articles is true or not....And also answer my next doubt if possible...
Hi Ravi,
Thanks for the great explanation. But I have one question. Suppose In starting the project is very simple or let's say middle level which will take around 2-3 months but we know later it would be complex after some time especially in product-based companies. so should we choose MVC or later move to different architecture pattern? Or we should choose from starting the different architecture pattern?
Hello @Sahil, thank you for your question and welcome to the channel
Let me answer your question by asking a counter-question, what is going to be complex? Is it the project or a module in the project? If the project has started with one architecture pattern say MVC and you get 3 new complex requirements the time and cost it will take to convert the work done in the past to MVVM and re-test is going to increase and this will impact the project delivery. As a client, I would want those complex requirements in say 4 weeks but here your team is busy reinventing the wheel, re-doing all the hard work which they did in the past and coding for a new complex requirement with fewer developers is again going to impact delivery.
Choosing an architecture pattern for the project should be decided from day one and not in between, if you flip flop the pattern in between then that means the tech lead or senior or architect did not analyze the project requirement in a detailed manner, failing to analyze always leads to a big bad blunder in software projects.
My approach has been distributed responsibilities with solid principles this is one constant approach that I take in every project so if a change request or a new requirement comes in the project then I just separate out responsibilities each layer handles, the idea behind MVVM is the same, your responsibilities should be divided. you can do the same with MVC as well if a new project comes and has moderate complexities FROM DAY ONE then I will choose MVVM.
As I explained in the video, MVVM is no magic pill to make you a better developer, MVVM should be used based on your project complexities and the complexity of the project is known at day 1 not on day 400 so maybe we should take time in analyzing the project than directly jumping to code.
I hope I was able to answer your question, but if not feel free to ask more questions are always welcome here, do subscribe and share this channel with your iOS group would appreciate it.
@@CodeCat15 I Agree with your point that Choosing an architecture pattern for the project should be decided from day one and we must distribute the responsibilities with solid principles. But when in starting the project we have only limited requirements and after some months we have another requirement that we didn't expect and we know in the coming future there are a lot of new things that are going to come. how would you handle this? obviously, we can create a separate module that doesn't affect the existing one but the question again arise should we create the same architecture pattern or we can go with any pattern that suits the requirement?
@@sahilberi5759 Let me ask you this if you are already maintaining separation of concern with SOLID principles then how is changing the architecture pattern going to help if you are already maintaining good design principles in your project?
If you are following solid principles with separation of concern then I don't really think you need to do that because all the requirements are isolated in their own boxes and the new requirements can go in their own box without impacting anything else. Making the design as flexible as bendable as it can be is one key factor of project design, it should be like making an idol out of clay, and clay should bend to any direction (just me giving some crazy metaphors again hahaha)
As I said in my previous answer it's going to take efforts and time to revamp the project architecture which delays the project delivery but if time is not a problem and those requirements can be delivered in the next 8-10 months then I would say sure you can go ahead and make the change to MVVM or whatever pattern you choose based on the project but before you make those changes again the same question what will you gain? How will changing the pattern help you if your code is already set up to have distributed responsibility?
So to answer your question I have asked you few more questions, and this is how things should work, developers should share their thoughts and question the pros and cons of the approach they take before coding or making a big shift in the project.
@@CodeCat15 Yes, changing the architecture pattern doesn't help now. but if we know we have huge requirements ahead and team member's size also going to increase. Choosing different architecture for different modules won't help? And if we know we can make code more maintainable and testable by using a different architecture, toh shouldn't we go with that?
can't we have a mix of architectures in the same app?
Hi Ravi,
I have seen your MVC video also, where you are saying that there should be separate layer for business logic, data validation and api calls to avoid the complexity and huge number of lines of code in model. But here in MVVM, how are you suggesting to keep all the logic in ViewModel as these two are contradicting.
Actually I am preparing for an interview, and that's the reason I am bugging you like this.
Thank you in advance!!
Nope, the view model should be treated as an orchestrator to call these multiple layers, we should always maintain separate layers to maintain single responsibility.
All the best for interview, do share any complex questions that you get over instagram message or as comment here
@@CodeCat15 Thank you so much Ravi, for answering and sorry if you feel it was silly to ask. And surely, I will let you know about my interview and ask for answers.
Thanks,
I wish if i could code under your guidance
This truly means a lot, thank you for your kind words
Hello Ravi Bro,
Could you guide me from where i can learn swift from beginner to perfect level.
I know about Objective-C coding and basic coding in Swift.
Or any one can guide me?
github.com/codecat15/RUclips-tutorial/wiki/RUclips-channel-playlist
Above is the link of all the playlist in the channel covering basic to advance tutorials of swift programming.
Follow the list first, you may skip the beginner playlist if you like and jump to advance topics and design patterns.
Hope it helps, feel free to ask questions if you have doubts I will be happy to assist
bhae acha patteren likhny wli example b bna dyn fir takhe hm improve kr sky . if u need i can provide u authentication module which i have created storyboard vc's.
1- splash screen
2- register screen
3- login
4- forgot password
5- email verification
Well, next session mai login, table view controller, api parsing sab hai so I think I will cover most of it, if still you need something to github pe share karo karte hai coding
what is the right way of implementing in MVC?. i have searched and found mvc examples available on github created by different swift programmers. all have different approaches.
I think jab tak aap aapke code mai separation of concern, single responsibility jaise principles implement kar rahe ho along with design pattern based on use cases tab tak i think you are good. MVC ka bhi example aayega and trust me you will be surprised ki clean code principles follow karne ka advantage kitna hai aur usse developer ki life kitni easy ho jaati hai.
Har ek developer ka aapna version hai MVC ka jaise ka har ek company ka alag model hota hai car ka but basic principles same hote hai to hume bhi code k saath kuch aisa he karna chaiye.
Can we declier local veriable name and method perm name same
yes you can but then for the parameter I would just add underscore in front of it like _methodParameterName
what is the difference between Controller from MVC and Viewmodel from MVVM? very confused here!
Controller from MVC handles UI related task along with data display,
if some devs do not follow decomposition then everything from their API code to validation is just dumped inside the controller which is a bad practice
Controller should never ever handle any business logic, validation, API or database call.
ViewModel on the other hand WILL NOT HANDLE UI RELATED TASK
The controller and viewModel work together, the controller will request for data and the viewModel will get the requested data for the controller
Adding any kind of UIKit reference inside the viewModel is a violation of the MVVM core principle
Hope it helps and always feel free to ask more questions I will be happy to answer them
Thank you! i got that now.👍👍
Please add some example also if possible.
The MVVM playlist has 2 videos with code example and 1 video where am doing an event for code review with MVVM architecture. Hope that helps
ruclips.net/p/PLb5R4QC2DtFs8CsVZztGSJ0TM8J2URfg7
What about combine framework?can you please explain it.
After the threading series there will be combine framework series in details, there are few videos on swiftui just introduction part but more to come
@@CodeCat15 Any crash courses other than videos in RUclips?
@@pushpajuluri Not exactly, I will keep on sharing whatever new or old things I learn on RUclips only, the issue with crash course I feel is that one does not cover advanced topics as you see in this channel so I want this channel to be a one-stop for basic and advance tutorials
@@CodeCat15 I’m falling love with your videos,my only suggestion is to please avoid Hindi in middle as it is difficult for us to understand as a South Indian.
So it means selection of architecture is totally based on the complexity team size and duration of project only.
Its the only reason for mvvm to came existence.
Please reply.
One can select VIPER or MVVM pattern in the most basic app, there's no harm in that but that's over-engineering.
Think of it like this I am using a car to travel 300 meter where I can just walk and reach there but then there’s nothing stopping me to take my own car right it’s a matter of choice.
And if I take a car to travel 300 meters then that’s not a smart move I reach my destination but the cost to reach my destination and then come back to my home is expensive and that’s what most of the developers fail to calculate while analyzing the project.
Analyse the complexity of the app and think about what pattern would suit the need, many developers do say MVC is massive view controller agreed but we can surely follow decomposition and SOLID principles to create separate layers of abstraction. I have explained this in my MVC decomposition video.
If one dumps all the logic, API, business rules inside a view controller then such developers when they implement MVVM they are going to dump everything inside a…. you guessed it right a viewModel and then we have an issue of massive view models.
When a developer takes one pattern and potrays it like a silver bullet then that’s wrong there’s no one size fit all pattern it depends on the complexity of the project.
Hope I answered your question and if not then please feel free to ask more.
@@CodeCat15 Thanks
Bhai chava
What is meant by tight coupling?
tight coupling means when one class knows more about the other class, in general this is how tight coupling looks like
class ViewModel {
let apiClient: APIClient = APIClient() // initializing class APIClient
func foo() {
apiClient.performTask() // calling APIClient method
}
}
in this case the view model is dependent on the apiClient to make calls, and knows how to create the instance of the APIClient class
what if the requirement changes and you no longer need an API but a database, looking at the above code I would have to replace the apiClient with some databaseHandler, pretty simple change right.
but doing this breaks open close principle of SOLID because the viewModel is dependent on APIClient class to operate.
to solve this issue, we use dependency inversion principle and use a protocol instead of a concrete class and make the code loosely coupled.
Video on all these concepts are present in the playlist and as you go through those topics please feel free to ask questions and I'll be happy to answer them for you.
@@CodeCat15 Thanks Ravi for the explanation
After your question I thought of making a video on it, do check it out.
ruclips.net/video/szrrEruDoWQ/видео.html
i wish you told in english is their a chance of it thanks
I am not a fan of any celebrities or stars but I am a fan of your knowledge and your way of explaining, can we know how much experience do you have, how you achieved this expertise and your LinkedIn so we can follow you.
Thank you for the kind words
I have a total of 12 yrs experience and am a full stack developer, working in maintenance project kind of teaches you a lot on how not to code.
@@CodeCat15 why maintainace project are you in tcs 😂
Hahaha I wish