I don't really see situations where you would need one viewmodel for many views, I much more see many viewmodels for one view... Does anyone has a practical example?
Hey mitch iam stucked with a problem and after i searched the day i have to ask you. When i connect my smartphone via usb its recognized from android studio, i can browse the filesystem. But when i press play button i get this error: Installation failed due to: 'device ' not found'. A few days ago everything works perfectly. Emulator works good as well. Do you have an idea? Thanks!
Actually I disagree with you cuz you're violating a very basic pillar rule in software architecture SINGLE RESPONSIBILITY. th-cam.com/video/tIPxSWx5qpk/w-d-xo.html at this stage you're talking about shared VM between fragments which is "according to my experience" not a very good way to go. It cuz the fragments are designed to be attached and detached from the activity and they can be created or destroyed when you navigate to another screen. It is not a good practice to have one single shared VM cuz by design this latter should follow the lifecycle of its owner hence, when you navigate to another fragment the VM will be always there and that could cuz many problems. My advise is to have a VM per fragment that should be responsible of every type of interaction specific to that fragment (Single Responsibility) also VM may hold instances of other things like repository or something that may hang that in your RAM for no reason. On the other hand you could use a shared VM if the processes that it's responsible for are Application scoped processes other wise you're just making your architecture vulnerable and badly designed. Would like to hear your feedback on my point of view and of course it's my own style of architecting apps and not the Rule :)
Interesting...In my scenario we are targeting a very small subset of screen sizes and don't need to persist on layout changes because well ...let's just say if you are using one of my apps and the orientation changes or it's in Portrait mode you have much bigger problems than whether your name is still in the name field;) (Android Automotive OS Apps specific to a vehicle...). For this reason I've considered not using View Models at all, I have ~23 screens( as Fragments) and 1 activity using the Navigation component. I'm curious so gonna watch, will let you know what I think... BTW i agree there is no correct or best model, only the right architecture for the job...sometimes some architectures fit, and there is always going to be a pretty good industry general go-to like this, Just like design patterns they give us a good place to start.
Orientation changes aren't the only reason for using a ViewModel. I highly recommend checking out the MVI course. I think it will blow your mind and change the way you manage events in your vehicle apps.
Google recommended architecture with repository pattern is shitty design. Repository pattern is basically useless in Android. Don't use it just because Google recommends it
@@codingwithmitch Repositories on Android are, in most cases, just one line delegate methods to something else. It's worst if that delegate is to the Retrofit API that is also one line. It's event worst if that repository call is in UseCase class which is also one line delegate. It's much better to separate some code flow JUST inside UseCase and leave it at that. It's much much cleaner. I can show you some examples if you are interested. And also job of the Repository is not to mitigate between API and Database calls.
@@codingwithmitch Also, you can implement invoke() operator function in your UseCase and call it like a function. ViewModel that uses UseCases can do it like so -> getArticles() to get the articles, no need to call repository.something(). Useful
Does MVI stand for Model-View-Idontcare?
are you a wizard?
@@amitparameshwar2704 HAHAHAHAHHAAHA
Damn. BARS, my guy. Coming hard.
Florian 😂😂😂😂😂
Wow we really enjoyed from the start! Keep up the good work!
Thanks.
i'm sad because i can't pay for this course.... i'm from Ethiopia no credit card nothing :(
Same here
paypal works
@@buzzminkyunghoon3856 not in my country
Bitcoin or SmartCash
I'm so excited to follow this course to the finish line, it seems exiting
Solid example. Excited to follow this course
Thank you so much for explaining how MVI is
Sad, I expected this video to explain the thing. But I guess as it's sold there is no free content in here but just advertisment.
I subscribed to your MVI course, man I was looking for this StateEvent and DataState stuff! The course is really good.
Hello,
I want to know the apps those are using MVI pattern please,
Juste 3 apps using the mvi
I don't really see situations where you would need one viewmodel for many views, I much more see many viewmodels for one view... Does anyone has a practical example?
AWESOME EXPERIENCE
Excellent. Another great video too
The best course ever!
Can you share your view on MVP? why do you prefer MVVM or MVI?
Hey mitch iam stucked with a problem and after i searched the day i have to ask you. When i connect my smartphone via usb its recognized from android studio, i can browse the filesystem. But when i press play button i get this error: Installation failed due to: 'device ' not found'. A few days ago everything works perfectly. Emulator works good as well. Do you have an idea? Thanks!
Try updating android studio
@@codingwithmitch thanks för response but i have the latest version i believe its an adb bug
Few developers saying MVI is similar to MVP and you said , its similar to MVVM. Which is correct ?
Mitch, can you show infinite list with mvi (sample is enough), thanks
Actually I disagree with you cuz you're violating a very basic pillar rule in software architecture SINGLE RESPONSIBILITY. th-cam.com/video/tIPxSWx5qpk/w-d-xo.html at this stage you're talking about shared VM between fragments which is "according to my experience" not a very good way to go. It cuz the fragments are designed to be attached and detached from the activity and they can be created or destroyed when you navigate to another screen. It is not a good practice to have one single shared VM cuz by design this latter should follow the lifecycle of its owner hence, when you navigate to another fragment the VM will be always there and that could cuz many problems. My advise is to have a VM per fragment that should be responsible of every type of interaction specific to that fragment (Single Responsibility) also VM may hold instances of other things like repository or something that may hang that in your RAM for no reason.
On the other hand you could use a shared VM if the processes that it's responsible for are Application scoped processes other wise you're just making your architecture vulnerable and badly designed.
Would like to hear your feedback on my point of view and of course it's my own style of architecting apps and not the Rule :)
Woow Im the first Viewer Bravoh. Hi Mitch
Does the camera course use fragmentactivity?
MVI , Android Architecture Components or LiveData with RxJava ?
Will you include PUT / POST in the MVI ? Its rather importent to see how it fits? (Your previous structure courses skipped that)
Ohh you have lot of white boards. I saw it today. I too have ordered one.
I like MVI too
You are awesome!
Interesting...In my scenario we are targeting a very small subset of screen sizes and don't need to persist on layout changes because well ...let's just say if you are using one of my apps and the orientation changes or it's in Portrait mode you have much bigger problems than whether your name is still in the name field;)
(Android Automotive OS Apps specific to a vehicle...).
For this reason I've considered not using View Models at all, I have ~23 screens( as Fragments) and 1 activity using the Navigation component.
I'm curious so gonna watch, will let you know what I think...
BTW i agree there is no correct or best model, only the right architecture for the job...sometimes some architectures fit, and there is always going to be a pretty good industry general go-to like this,
Just like design patterns they give us a good place to start.
Orientation changes aren't the only reason for using a ViewModel.
I highly recommend checking out the MVI course. I think it will blow your mind and change the way you manage events in your vehicle apps.
Any plans on teaching about security or encryption? I think that is extremely important
Not at this point. What kind of data are you worried about being encrypted?
How about MVVM with Kotlin Flows? ;)
Thank you for your work..!!!
@codingWithMitch plz also create some lectures on Android Animations :)
hay bro, since how many years u r doing adroid development?
ITs seems like u r advance android developer
Yes he is. He is being playing with Android since 3 years. And he is a pretty good developer.
Yeah about 3 years
Okay, at 9:13
"I am going to pause this video on podcast"
Can you link the podcast?
no, I'm going to upload this audio to the podcast
@@codingwithmitch yeah, so podcast would be on youtube only and not rss feed?
@@buzzminkyunghoon3856 codingwithmitch.com/podcast/
Super cool dude..can't wait for it..!!! But why is he shy at the end in the video?Lulz
Do I need to know Kotlin before taking the MVI course?
nope learn as you go
mitch, volume is very low, please help
It's not low. It's low on your end.
Turn the volume up on your phone lol
Brother don't put your gf pic in thumbnails. I feel jealous 😾
That is my wife
Oops, jealousy increased.
@@sksuraj1695 lol
model view intent
please mitch check you email ..
Google recommended architecture with repository pattern is shitty design. Repository pattern is basically useless in Android. Don't use it just because Google recommends it
settle down
@@codingwithmitch Repositories on Android are, in most cases, just one line delegate methods to something else. It's worst if that delegate is to the Retrofit API that is also one line. It's event worst if that repository call is in UseCase class which is also one line delegate. It's much better to separate some code flow JUST inside UseCase and leave it at that. It's much much cleaner. I can show you some examples if you are interested. And also job of the Repository is not to mitigate between API and Database calls.
@@markonovakovic3838 I'm good thanks
@@codingwithmitch Ok, how you like it
@@codingwithmitch Also, you can implement invoke() operator function in your UseCase and call it like a function. ViewModel that uses UseCases can do it like so -> getArticles() to get the articles, no need to call repository.something(). Useful