I'm still confused a bit. The problems that you mentioned with ViewModel seem to be related to how people structure the ViewModel and not inherently the androidx ViewModel class itself. So I'm guessing you don't like the MVVM structure and not the android VM class itself? I personally use the androidx ViewModel class but my states and events resemble MVI with a bit of what you did. I do agree though, your example looks cleaner. Will try it out on some personal projects and see how it scales
Just use MVI much cleaner code abstract as much code from VM to utility classes. 1 state 1 event class MVVM is convoluted. Also, what's wrong with flows? Push all state to VM what's issue with that?
It started back in 2017 but people just didn't want to choose the simpler way of doing things (even when it was technically and behaviorally more correct). Then again, Android devs always seek out complexity for the sake of complexity, for who knows what reason.
I dont get the point because you basically did the same as the VM does but with a simplified version that does not cover what you are complaining. You will end having the same problems if your screen starts including big features, but instead of having a big VM class youll have 100 extension functions and 100 whens for every state (or a big state for the screen).
What is the harm in providing 2 parameters to a Composable - 1 state and 1 lambda for events? This will make things explicit rather than implicit CompositionLocal. Also, I feel the real purpose of VM is structured scoping and state caching. When you navigate to other screen and get back, how are you going to ensure not loading the last things again?
Yes, exactly, passing data via navigation is a bad idea due to serialization/desexualization, so we use view models to keep data/state we need in other viewmodels fragments (compose uis)
Also you are right about JetSnack's convoluted ViewModel . Its a nightmare . However there are several tutorials who show how to do a cleaner ViewModel . One such approach is MVI styled ViewModel .
Absolutely this is the worst thing about Compose. Their own frameworks, recommended to use together, do not even work together. It's grave sin to release these tools like this. At least with XML, we bypassed prop-drilling AND we had previews.
Hmmm, and still not just transforming business to ui. It's also lifecycle-aware. It gets out automatically when the activity is destroyed. Plus, you can't just create one just by calling it's constructor. At least in Android. Multiplatform is taking the path of viewmodels as well but I don't know the consequences about that yet. At least I'm OCD-ed by ViewModels. Even when I code in iOS or Flutter, I create a thing called ViewModel 😄
Before Android ViewModel we had Retained Fragments. It was just an object who's lifecycle survives configuration changes. Of all the Jetpack Libraries, it has the most confusing name.
Retained fragments were so much easier to use than ViewModel, but the Navigation people couldn't make Navigation work with it so they deprecated it. If we don't use Navigation multi-stack, then retained fragments still work...
Wow... It's great to see someone finally addressing the topic of VMs in composables. Using VMs everywhere never seemed ideal. Excellent point! Thanks for sharing about Evas!
There's some irony to the fact that React people just put the callbacks into a "context" which in Android world would be a CompositionLocal and then pass them down like that, instead of every single one as separate callback arguments. However, I think the callbacks belong in the state so that it is scoped to the state in which it is valid to be invoked, UI should know less not more.
State and event I thinks it's the best approach right now. Because it really makes sense, and you can adapt it to anything. Here what have I try. Change fragment bottom sheet that using viewmodel into Rxjava, it work perfectly. Using compose purely with mutableState and sideEffect without viewmodel. So my current approach right now state, event, any reactive library
ViewModels always felt a bit weird to me too. The problem i have is that don't scale easily as your screen becomes more complex. And the 1 VM per screen adage never made sense to me because you want components to be screen agnostic without the need to write a lot of glue code. I, like yourself prefer state hoisting + composition locals when applicable. Your video with the examples just reinforced this self discipline I have with the use of ViewModels (avoiding them i.e)
Imo, answer to all those questions is to get experience, then you will know when to create another subcomponent and its VM, when to choose which State approach etc. No one expects Android or any other professional level development to be clear after one year of shool projects.
Fair! I am pretty sure that there are teams that have very good intuition about ViewModels and really like them. I would like to re-emphasize: My point is more that we should be encouraged to use something different if we want to. I tried making it work for me since 2018 and I never really got warm with it. Sure, my profession is not to build Android Apps anymore, I am employed by JetBrains working on Kotlin, IntelliJ, ... I'll try to keep in touch though by having hobby projects. Nobody expects you to be great in one year, but honestly: My projects even in 2016, where I did strange freestyle MVC got quite far. I sense that we just accepted that things have to be hard whereas the iOS community often accepts pragmatic solutions.
The original idea that there is a problem with "State + Callbacks" is valid, state should contain the callbacks so that the operations are scoped to the state in which they are valid to invoke. Also, View should not know what function to invoke in VM to for example "set filtering to XYZ". EVAS is however a bit overengineered and seems not-multi-threading-safe, I do not think this is the right solution. Thrive for simplicity but you're fighting the framework to connect its bits.
> Also, View should not know what function to invoke in VM to for example "set filtering to XYZ" In defense of the ViewModels: When a Lambda is passed, I think they do not know directly. They have this one layer (lambda) in between them. Still agree here. > EVAS is however a bit overengineered and seems not-multi-threading-safe, I would be happy to learn at which points the library is not thread safe, because this would be my highest priority in fixing. It was designed with thread safety in mind, even trying to provide lock free thread safety where possible. Also, I hope that this gets across: My point is not that everybody should use what *I like*, but more: "See, I have fun with my own style, that I like, please feel encouraged to find what works for you and build this for *you*"
@@Zhuinden What vasily mentioned was quite different from sebastian's pain. That post from 2017 does not hold true after introduction of savedStateHandle.
![[[OFFICIAL MV]] เอิ้นขวัญให้อ้าย- อ๊ะอาย สกุณาพร | ค่ายเพลงเป็นหนึ่ง](http://i.ytimg.com/vi/83x6L3X3qh0/mqdefault.jpg)
I'm still confused a bit. The problems that you mentioned with ViewModel seem to be related to how people structure the ViewModel and not inherently the androidx ViewModel class itself. So I'm guessing you don't like the MVVM structure and not the android VM class itself?
I personally use the androidx ViewModel class but my states and events resemble MVI with a bit of what you did.
I do agree though, your example looks cleaner. Will try it out on some personal projects and see how it scales
I think I am done with Android 😂
@@androiddevo User name says no
Just use MVI much cleaner code abstract as much code from VM to utility classes. 1 state 1 event class MVVM is convoluted. Also, what's wrong with flows? Push all state to VM what's issue with that?
Great video! However, I still feel VMs got legs especially if you want to DI bunch of stuffs.
i was here when the revolution in android dev began
It started back in 2017 but people just didn't want to choose the simpler way of doing things (even when it was technically and behaviorally more correct). Then again, Android devs always seek out complexity for the sake of complexity, for who knows what reason.
What about Circuit/ Molecule
I dont get the point because you basically did the same as the VM does but with a simplified version that does not cover what you are complaining.
You will end having the same problems if your screen starts including big features, but instead of having a big VM class youll have 100 extension functions and 100 whens for every state (or a big state for the screen).
What is the harm in providing 2 parameters to a Composable - 1 state and 1 lambda for events? This will make things explicit rather than implicit CompositionLocal.
Also, I feel the real purpose of VM is structured scoping and state caching. When you navigate to other screen and get back, how are you going to ensure not loading the last things again?
Yes, exactly, passing data via navigation is a bad idea due to serialization/desexualization, so we use view models to keep data/state we need in other viewmodels fragments (compose uis)
Also you are right about JetSnack's convoluted ViewModel . Its a nightmare . However there are several tutorials who show how to do a cleaner ViewModel . One such approach is MVI styled ViewModel .
Ah... official example also passses view model to screen composable... breaking preview...
Absolutely this is the worst thing about Compose. Their own frameworks, recommended to use together, do not even work together. It's grave sin to release these tools like this. At least with XML, we bypassed prop-drilling AND we had previews.
Hmmm, and still not just transforming business to ui. It's also lifecycle-aware. It gets out automatically when the activity is destroyed. Plus, you can't just create one just by calling it's constructor. At least in Android. Multiplatform is taking the path of viewmodels as well but I don't know the consequences about that yet. At least I'm OCD-ed by ViewModels. Even when I code in iOS or Flutter, I create a thing called ViewModel 😄
Before Android ViewModel we had Retained Fragments. It was just an object who's lifecycle survives configuration changes. Of all the Jetpack Libraries, it has the most confusing name.
Retained fragments were so much easier to use than ViewModel, but the Navigation people couldn't make Navigation work with it so they deprecated it. If we don't use Navigation multi-stack, then retained fragments still work...
Wow... It's great to see someone finally addressing the topic of VMs in composables. Using VMs everywhere never seemed ideal. Excellent point! Thanks for sharing about Evas!
There's some irony to the fact that React people just put the callbacks into a "context" which in Android world would be a CompositionLocal and then pass them down like that, instead of every single one as separate callback arguments. However, I think the callbacks belong in the state so that it is scoped to the state in which it is valid to be invoked, UI should know less not more.
I liked the video, even though I do not agree with this pattern
@@arsildo thank you! Really happy for the positivity despite disagreement 😍
State and event I thinks it's the best approach right now.
Because it really makes sense, and you can adapt it to anything.
Here what have I try.
Change fragment bottom sheet that using viewmodel into Rxjava, it work perfectly.
Using compose purely with mutableState and sideEffect without viewmodel.
So my current approach right now state, event, any reactive library
ViewModels always felt a bit weird to me too. The problem i have is that don't scale easily as your screen becomes more complex. And the 1 VM per screen adage never made sense to me because you want components to be screen agnostic without the need to write a lot of glue code.
I, like yourself prefer state hoisting + composition locals when applicable.
Your video with the examples just reinforced this self discipline I have with the use of ViewModels (avoiding them i.e)
Imo, answer to all those questions is to get experience, then you will know when to create another subcomponent and its VM, when to choose which State approach etc. No one expects Android or any other professional level development to be clear after one year of shool projects.
Fair! I am pretty sure that there are teams that have very good intuition about ViewModels and really like them. I would like to re-emphasize: My point is more that we should be encouraged to use something different if we want to. I tried making it work for me since 2018 and I never really got warm with it. Sure, my profession is not to build Android Apps anymore, I am employed by JetBrains working on Kotlin, IntelliJ, ... I'll try to keep in touch though by having hobby projects.
Nobody expects you to be great in one year, but honestly: My projects even in 2016, where I did strange freestyle MVC got quite far. I sense that we just accepted that things have to be hard whereas the iOS community often accepts pragmatic solutions.
Great point
The original idea that there is a problem with "State + Callbacks" is valid, state should contain the callbacks so that the operations are scoped to the state in which they are valid to invoke. Also, View should not know what function to invoke in VM to for example "set filtering to XYZ". EVAS is however a bit overengineered and seems not-multi-threading-safe, I do not think this is the right solution. Thrive for simplicity but you're fighting the framework to connect its bits.
> Also, View should not know what function to invoke in VM to for example "set filtering to XYZ"
In defense of the ViewModels: When a Lambda is passed, I think they do not know directly. They have this one layer (lambda) in between them. Still agree here.
> EVAS is however a bit overengineered and seems not-multi-threading-safe,
I would be happy to learn at which points the library is not thread safe, because this would be my highest priority in fixing. It was designed with thread safety in mind, even trying to provide lock free thread safety where possible.
Also, I hope that this gets across: My point is not that everybody should use what *I like*, but more: "See, I have fun with my own style, that I like, please feel encouraged to find what works for you and build this for *you*"
I wonder if molecule can help here
@@IsuruKusumal yes!!
Finally someone speaks the truth about ViewModels
I remember when Vasiliy Zukanov said the same thing about ViewModels back in 2017
@@Zhuinden What vasily mentioned was quite different from sebastian's pain. That post from 2017 does not hold true after introduction of savedStateHandle.