Thank you so much. this is one of the best videos I have seen for the mvvm pattern in so less time. So what I learnt here is: model is the data source. View model contains the business logic and view contains only the UI manipulation part.
An interesting thing is that Google themselves dont consider the architecture they recommend to be MVVM! If you look at the jetpack architecture guide you will not find MVVM there and I have heard some of the Android team devs flat out reject that its MVVM, but the community seems to have decided it is, which goes to show some of the subjectivity involved in these type of things, so if you are confused don't stress it and do what allows you to get work done.
I am new to iOS Apps and have been reviewing a Quiz App on a Udemy tutorial done with MVVM and SwiftUI (not storyboards). I know the "Model" can just be the definition of the regular data struct. Next, the View defines the main view, child views, etc. The "View Model" on that course fills the data using the structs from the Model. Then it adds event handling code for the quiz for correct or incorrect selections. The View Model seems somewhat similar to the "controller" in the MVC model taught for old school Java Android apps or Java Servlets (circa 2013 - lol). But I understand there is controversy among MVVM on whether if it is valid for production. For the simple quiz on that Udemy tutorial, MVVM clearly works. But perhaps for more complicated production scenarios MVVM has its limits? If so, then what is a better solution of architecture? I am going to dive into the threads and articles soon to analyze that. This is just a thought on observations. I am still in the early learning stages on iOS App development. I have worked with Java and C# off-and-on for decades. I have used python heavily the past 8 years. It's fun to learn different development environments and code for iOS Apps.
The view model is similar to the controller from MVC; if I'm not mistaken, MVVM was invented as an improvement on MVC because the controller was too abstract and caused the code to be hard to read, as a single controller could tie together numerous views and models that are only superficially related. But a view model is more specifically targeted and works with a specific view and model, the downside being you could wind up writing several view models that do basically the same thing if you're not careful.
Do you have MVVM only playlist - mvvm crash course ?
Год назад+1
MVC with different terminology? This explanation matches my understanding of MVC. I read that a difference between MVC and MVVM is how the observer pattern is used by the view so that the view doesn't have knowledge of the controller. I would argue that the observer pattern is a controller, since if you've ever worked with UML MVC diagrams it's clear that you can have multiple controllers and are able to chain them. That would make the View a View-Controller-Model where "Model" here is the representation of the UI state, then the "ModelView" and Model a Model-Controller-Model pattern where the first occurrence of "Model" is again the UI state and the second occurrence of "Model" is the repository. Did I understand correctly or am I missing something? If I did understand this correctly, it seems odd that MVVM is described as an alternative to MVC rather than as a specific pattern built atop the constructs of MVC.
how is the flow if the user makes an input..like a search request.. does it go from the view to ... ? because the view doesn't now the viewmodel.. all in all it's centralisation right✌️
You described MVP, not MVVM. Your statement that Viewmodel contains business logic is incorrect. Viewmodel is kind of a caching proxy holding data for View on the client side. In the MVVM architecture, business logic belongs to the Model part, i.e. a server with repository. However, in the MVP architecture, Presenter (P) does contain business logic, while Model is a pure repository.
whats the difference between mvvm and mvc. I mean the viemodel does the same thing like a controller. controller handles the model and fires events if something changes. views can listen to them and update them
In MVC controller receive the requests and serve the view to the client (a generated html) through http. In ViewModel there is not http requests, it only binds DAO with UI in a more centralized way, specially in mobile apps.
MVC is outdated. The role of Controller is now fulfilled by a mouse driver and an operation system. You do not need a controller in a modern app. Yet, splitting your program into several decoupled parts is a nice idea. For that reason people come up with all those MV* stuff. Your short description reveals that you are likely using the MVP architecture and have named your Presenter part "controller". To answer your question, there's no difference because the author of the video errorously described the MVP architecture calling it MVVM.
I still can't wrap my head around, when exactly does the app become mvvm. I understand the different components that is in an Mvvm project, but i always fail to completely wrap my head around how all those components come together. Watched soo many videos regrading mvvm, but still can't draw a line in my head that seperates any other architecture project from mvvm architecture project.
Agree. Easy to understand my ass... i have this source code pointing to firebase and shjts... there is no way this is easy to understand by sparating shjts. No one ever called this particular codes easy to understand.. even the author himself LMAO
actually, up until now, i still not sure what does MVP and MVVM difference. I mean, layman term it is exactly the same. its just, MVVM uses livedata while MVP uses listeners
I HATE WHEN i found some tutorial make noobiest hard to understand what the heck is MVVM, I watched this tutorial without coding implementation but I understand what mvvm is.
This is incorrect. Business logic should be in the model, not the viewmodel. The viewmodel just adapts/validates the data between the view and model and notifies of changes between the two.
In the MVVM (Model-View-ViewModel) architecture pattern, business logic should be implemented in the ViewModel instead of the Model. The main reason for this choice is that the ViewModel is responsible for mediating the communication between the View and the Model and acts as an intermediary layer between them. In MVVM, the Model is responsible for data handling and presenting data without any business logic. In other words, the Model handles data modeling, database logic, and communication with the database, while the ViewModel implements business logic, complex calculations, input control, data validation, and any other business processing. Therefore, you should implement business logic, complex calculations, input control, data validation, and any type of business processing in the ViewModel. This approach helps you separate concerns and keep the View free from handling business logic, ensuring a clean separation of responsibilities in your Android app.
Which other concept do you want me to explain in 100 seconds?
Hilt, Work manager, coroutines, room
MVI
LiveData or StateFlow
Retrofit
Flow, Coroutines, RecyclerView, Work manager, Jetpack datastore
Damn this looks like a sh*t ton of work
Took 8-10h 🥵
@@PhilippLackner Thank you for all the hard work you put in! You simply are amazing :)
@@PhilippLackner amazing stuff....writing code is not simple but writing simple code is hard
Awsome, I have never seen a video or an article that defines this concept as goog as you. Thanks for all of your hard works.
Thanks!!
Finally someone made it clear with no unnecessary vocabulary. Thanks!
actually explanation sucks
Awesome man. Never seen such awesomoe content that too within 2 minutes. You are great
Hey !! I have started my android development journey by your kotlin playlist ...which is just awsm 💯 🤩 great work bro ..! 😁😁
I understand and somewhat seen the clean architecture relevance in just 100 seconds. Amazing! Thanks for this great content.
The graphic of video is so good!!!. Good explanation I could have used 2 years ago.
it is quick yet understood better than other videos. Thank you. For this video I subscribed you channel.
Love the quick explanations. It was all needed to learn the concept easy and quick! I prefer this over the other over complicated videos. ⭐️⭐️⭐️⭐️⭐️
Very simple,understandable and straight to the point🙌
Can you make a video on a generic MVVM design pattern and then tell us how it is sensible for Android. Lots of Love from India. ❤️🇮🇳
Thank you so much. this is one of the best videos I have seen for the mvvm pattern in so less time.
So what I learnt here is:
model is the data source.
View model contains the business logic
and view contains only the UI manipulation part.
The best 100 seconds of anything I've ever watched
Inspired by Fireship?😄
Great content bro! I love it🔥
Not by Fireship but by a German channel that does something similar on another topic :D Thanks!
Very simple sir. Thanks sir.
Good explanation I could have used 2 years ago
very straightforward, saving lots of time
Awesome!! Now I cant skip them.
The graphic of video is so good!!!
An interesting thing is that Google themselves dont consider the architecture they recommend to be MVVM! If you look at the jetpack architecture guide you will not find MVVM there and I have heard some of the Android team devs flat out reject that its MVVM, but the community seems to have decided it is, which goes to show some of the subjectivity involved in these type of things, so if you are confused don't stress it and do what allows you to get work done.
Yes, Model, View, and Controller. What else can it be?
THIS IS EXACTLY WHAT WE NEED - gold
¿How many viewmodels in a app? ¿Single or multiple for every module?
I am new to iOS Apps and have been reviewing a Quiz App on a Udemy tutorial done with MVVM and SwiftUI (not storyboards). I know the "Model" can just be the definition of the regular data struct. Next, the View defines the main view, child views, etc. The "View Model" on that course fills the data using the structs from the Model. Then it adds event handling code for the quiz for correct or incorrect selections. The View Model seems somewhat similar to the "controller" in the MVC model taught for old school Java Android apps or Java Servlets (circa 2013 - lol). But I understand there is controversy among MVVM on whether if it is valid for production. For the simple quiz on that Udemy tutorial, MVVM clearly works. But perhaps for more complicated production scenarios MVVM has its limits? If so, then what is a better solution of architecture? I am going to dive into the threads and articles soon to analyze that. This is just a thought on observations. I am still in the early learning stages on iOS App development. I have worked with Java and C# off-and-on for decades. I have used python heavily the past 8 years. It's fun to learn different development environments and code for iOS Apps.
The view model is similar to the controller from MVC; if I'm not mistaken, MVVM was invented as an improvement on MVC because the controller was too abstract and caused the code to be hard to read, as a single controller could tie together numerous views and models that are only superficially related. But a view model is more specifically targeted and works with a specific view and model, the downside being you could wind up writing several view models that do basically the same thing if you're not careful.
cool video man, straight to the point!!!
Do you have MVVM only playlist - mvvm crash course ?
MVC with different terminology? This explanation matches my understanding of MVC.
I read that a difference between MVC and MVVM is how the observer pattern is used by the view so that the view doesn't have knowledge of the controller. I would argue that the observer pattern is a controller, since if you've ever worked with UML MVC diagrams it's clear that you can have multiple controllers and are able to chain them. That would make the View a View-Controller-Model where "Model" here is the representation of the UI state, then the "ModelView" and Model a Model-Controller-Model pattern where the first occurrence of "Model" is again the UI state and the second occurrence of "Model" is the repository. Did I understand correctly or am I missing something?
If I did understand this correctly, it seems odd that MVVM is described as an alternative to MVC rather than as a specific pattern built atop the constructs of MVC.
Honestly I have yet to see a good description of MVVM that clearly differentiates it from MVC
Awesome..hope to see more like this🙌
Very nice explanation
Great video, thanks and keep it up!
We want a series of Mvvm from you
amazing ...so much info in so less time
glad you like it
how is the flow if the user makes an input..like a search request.. does it go from the view to ... ? because the view doesn't now the viewmodel.. all in all it's centralisation right✌️
You described MVP, not MVVM. Your statement that Viewmodel contains business logic is incorrect. Viewmodel is kind of a caching proxy holding data for View on the client side. In the MVVM architecture, business logic belongs to the Model part, i.e. a server with repository. However, in the MVP architecture, Presenter (P) does contain business logic, while Model is a pure repository.
What a great video! thxxx
Thanks a lot for this video.
Awesome video
Make more like this
Awsome explanation
Woah this is awesome🔥🔥
very clear
thank you
U r awesome 👨💻
Entendible, gracias Crack!!
Nice Explanation
Thank you so much!.
Love the animation
Life saver 🙌
does it have MVVM in web develop or just android ?
best explanation
You have a very nice channel.
Thank you very much!
is the xml like the view and the kt file for the model and logic?
whats the difference between mvvm and mvc. I mean the viemodel does the same thing like a controller. controller handles the model and fires events if something changes. views can listen to them and update them
In MVC controller receive the requests and serve the view to the client (a generated html) through http. In ViewModel there is not http requests, it only binds DAO with UI in a more centralized way, specially in mobile apps.
MVC is outdated. The role of Controller is now fulfilled by a mouse driver and an operation system. You do not need a controller in a modern app. Yet, splitting your program into several decoupled parts is a nice idea. For that reason people come up with all those MV* stuff. Your short description reveals that you are likely using the MVP architecture and have named your Presenter part "controller". To answer your question, there's no difference because the author of the video errorously described the MVP architecture calling it MVVM.
awesome video
THANK YOU
And the business logic where is it? in the viewModel? in the repository? Maybe in the Use case? or in the entities?
Did you watch the video?
@@PhilippLackner you're right, you mention in the viewmodel, good video by the way
wow those animations
Is there another video that explains how MVP or MVI would normally run on Android?
budget fireship.io hehe.
Loved it.
Job well done!
Why only budget 😐😂
so nice video tnx
I still can't wrap my head around, when exactly does the app become mvvm. I understand the different components that is in an Mvvm project, but i always fail to completely wrap my head around how all those components come together. Watched soo many videos regrading mvvm, but still can't draw a line in my head that seperates any other architecture project from mvvm architecture project.
To me not even the name makes sense. It should be model viewmodel view. MVMV
Agree. Easy to understand my ass... i have this source code pointing to firebase and shjts... there is no way this is easy to understand by sparating shjts. No one ever called this particular codes easy to understand.. even the author himself LMAO
please make a video about scope storage, there is almost no good videos on this topic tutorial
Sir any new project video
should provide source code of the mentioned example at the same time, to indicate which part is M, V, VM..
OK but this sounds exactly like MVC. You didn't explain how the ViewModel is any different than a normal Controller in the MVC pattern
actually, up until now, i still not sure what does MVP and MVVM difference. I mean, layman term it is exactly the same.
its just, MVVM uses livedata while MVP uses listeners
thankyouble :)
Epic!
Hello fireship :)
Awesome
Thank you so much♥️♥️
WOW 🔥🔥
nicee👌👌
next video on how to implement MVVM pleasee.
He already has two playlists about that on his channel. Check it out.
Belle Route
Evelyn Lodge
Laurine Plains
I HATE WHEN i found some tutorial make noobiest hard to understand what the heck is MVVM, I watched this tutorial without coding implementation but I understand what mvvm is.
Haley Plains
Howell Port
Ebert Springs
Schowalter Square
Jacquelyn Common
Daphney Viaduct
This is incorrect. Business logic should be in the model, not the viewmodel. The viewmodel just adapts/validates the data between the view and model and notifies of changes between the two.
In the MVVM (Model-View-ViewModel) architecture pattern, business logic should be implemented in the ViewModel instead of the Model. The main reason for this choice is that the ViewModel is responsible for mediating the communication between the View and the Model and acts as an intermediary layer between them.
In MVVM, the Model is responsible for data handling and presenting data without any business logic. In other words, the Model handles data modeling, database logic, and communication with the database, while the ViewModel implements business logic, complex calculations, input control, data validation, and any other business processing.
Therefore, you should implement business logic, complex calculations, input control, data validation, and any type of business processing in the ViewModel. This approach helps you separate concerns and keep the View free from handling business logic, ensuring a clean separation of responsibilities in your Android app.
I read more documents and I understand: business logics is for repository and UI logics is for View model
@@dmj8939 Correct. That way, business logic is kept at a separate layer to the UI. Only things directly related to the UI should be in the view model.
@@thefattysplace Repositories are not business logic
@@thebowshock7729 an odd comment as no one mentioned repositories. But they can be, if your business logic is in a repository!
Lubowitz Springs
Carolina Mill
Gleichner Ridges
Daugherty Highway
Melisa Forge
Regan Lodge
Lucius Springs
Schinner Cliff
Ferry Knolls
Grady Roads
Dorian Springs
Ritchie Extension
Brandyn Forks
Douglas Streets
Lindgren Cliffs
Terrance Extension
Florence Cape