Because I've read this in many comments now: Of course, putting this as state in the ViewModel works, too (and for filtering I'd honestly also do this myself). But, that doesn't change the fact that doing this is a mistake (I'm often doing code reviews and saw this one very often). Also, there are scenarios where you can't simply put this in the viewmodel, e.g. If you need the context when mapping something to string resources for example.
I would be very happy if your courses could be priced by Region.... In Brazil, 99 euros are equal to half a month of paid work... and been unemployed is tricky
I'd just have an unmutable list/map of boolean states in the ViewModel that can be accessed/modified via public methods. That way there's no filtering of any sort and only the item(s) that changed will recompose.
@@PhilippLackner You clearly prefer to keep the ViewModel clean and I prefer to keep the UI code simple and clean. As that's what you need for best performance. I wouldn't consider doing anything you demonstrated here in my UI code. I thoroughly enjoy watching your videos though and I learned many important things here that I value very much.
Thank you for sharing this information, it´s very helpful. I think you could take the opportunity to say that this kind of logic shouldn't be in your UI framework.
There's no general rule that this shouldn't be in the UI (considering that the VM is also part of the UI). Putting it in the VM solves this as well of course.
Can you pls create a video about libraries android provides and some history about different android version changes as it is difficult for a new developers to know what is new and what is not. Thank you
Yeah with the filter example I chose I'd also probably do that, but there are definitely cases where you can't/shouldn't do this in the ViewModel (imagine mapping something to string resources and you need the context)
Agree, because ViewModel acts as a state holder. And I also agree with Philipp, there are another scenarios that we'll be forced to handle the logic in the UI
Say I have a screen with 6 textboxes that the user can enter info into. Normally I'd see this represented as far as saving state by having 6 different state variables, one for each textbox (or really, two variables for each textbox, a private one in the ViewModel and a public one in the ViewModel, that the Composeable can access). Couldn't I also make a single class, like "MyState", that has 6 fields in it, and then manage my screen's state by just referring to that single state variable that my ViewModel now contains? So for example I'd just be referencing MyState.myVarOne, MyState.myVarTwo, ..., MyState.myVarSix rather than myVarOne, myVarTwo, ..., myVarSix. Hopefully that makes sense.
Would love to know your thoughts regarding this: I've been thinking for a while now, but still I'm not fully convinced that Jetpack Compose is actually an improvement compared to existing View system. When we separate the complexity into two ways, API complexity and implementation complexity, I divide them as follows: Android View System - High API Complexity & Medium Implementation Complexity Android View System + LayoutInflater - Low API Complexity & Medium Implementation Complexity Jetpack Compose - Low API Complexity & High Implementation Complexity API Complexity is the complexity of the interface that is exposed to app developers. Here, Compose definitely has got low API complexity, but under the hood, the complexity increases manyfold because one has to understand recompositions and also how the compiler is rewriting the Composables. Just the Android View System has high API complexity (I'd argue it is also medium complexity though) as laying out views in code is not that straight forward, XML actually reduces this to low with the use of LayoutInflater. You define layouts declaratively (one time at the layout, and most views don't simply change their positions anyway unless animated) so declarative UIs are actually achieved. This reminds me constantly that if in case some bug happens in Compose, say there are too many recompositions, or an edge case in animation which is causing another view to displace or change dimensions, people are gonna have to spend even more time trying to identify the cause of it. This, requires people to understand the implementation, which definitely has a high complexity. Would love to know your thoughts. If you think otherwise, I request you to please make a video about this.
Really enjoy your videos! I've been doing Android apps as a hobby for a year or so now and your videos have been a great help! Personally, i come from a web-development job so i'm by no means and Android expert. I'm wondering though, stuff like filtering the todos list and generally preparing data for the presentation layer, shouldn't that logic be done in the viewmodel or elsewhere? In my opinion and experience, the UI-layer shouldn't really do any other logic than implementing the UI, and the preparation of data shouldn't be the job of the UI-layer. Again, i'm by no means an app-developer so i'm sure i havent got the best understanding of good app architecture. Would appreciate your thougts on this!
I think UI must not do and filters, just show. First part no words, somebody do so? (facepalm) and I don't like "correction" with remaining logic in UI too.
Because I've read this in many comments now:
Of course, putting this as state in the ViewModel works, too (and for filtering I'd honestly also do this myself).
But, that doesn't change the fact that doing this is a mistake (I'm often doing code reviews and saw this one very often). Also, there are scenarios where you can't simply put this in the viewmodel, e.g. If you need the context when mapping something to string resources for example.
I prefer another approach in this case.
I prefer preparing those 2 lists in the VM and move logic to there
This one of the helpful things i need to do to optimize the apps I build, thanks!
Nice vid philipp, I hope you make some shorts about optimizing re-comipistions with "donut scoping", it revolves around the idea of inlining functions
Also we can call partition on our list and get both done and undone items list
It was really helpful, thanks for sharing
Hi Phillip, how can i set toolbar color like bootom bar and status bar color like toolbar color ?
I would be very happy if your courses could be priced by Region.... In Brazil, 99 euros are equal to half a month of paid work... and been unemployed is tricky
I'd just have an unmutable list/map of boolean states in the ViewModel that can be accessed/modified via public methods. That way there's no filtering of any sort and only the item(s) that changed will recompose.
That's super unflexible and unreadable though
@@PhilippLackner You clearly prefer to keep the ViewModel clean and I prefer to keep the UI code simple and clean. As that's what you need for best performance. I wouldn't consider doing anything you demonstrated here in my UI code. I thoroughly enjoy watching your videos though and I learned many important things here that I value very much.
Thank you so much. Wish I had known this early
I made every mistake you said don't do it 😂😂😂. Thanks Philipp
Thank you for sharing this information, it´s very helpful.
I think you could take the opportunity to say that this kind of logic shouldn't be in your UI framework.
There's no general rule that this shouldn't be in the UI (considering that the VM is also part of the UI). Putting it in the VM solves this as well of course.
this was exactly what I needed without this I had to recompose a lazy vertical grid in an if else block
Can you pls create a video about libraries android provides and some history about different android version changes as it is difficult for a new developers to know what is new and what is not. Thank you
Hey, Philipp.
Can you do a video for Rich text editor like most note application, please?
after applying this my UI loaded more smoothly, cool.
Your expressions in the thumbnail :)
Thanks
Amazing video :)
no logic other than a simple if in the ui. let vm drive the state.
Yeah with the filter example I chose I'd also probably do that, but there are definitely cases where you can't/shouldn't do this in the ViewModel (imagine mapping something to string resources and you need the context)
Agree, because ViewModel acts as a state holder. And I also agree with Philipp, there are another scenarios that we'll be forced to handle the logic in the UI
Please always give the source code link!
very cool
you are the best
Say I have a screen with 6 textboxes that the user can enter info into. Normally I'd see this represented as far as saving state by having 6 different state variables, one for each textbox (or really, two variables for each textbox, a private one in the ViewModel and a public one in the ViewModel, that the Composeable can access).
Couldn't I also make a single class, like "MyState", that has 6 fields in it, and then manage my screen's state by just referring to that single state variable that my ViewModel now contains?
So for example I'd just be referencing MyState.myVarOne, MyState.myVarTwo, ..., MyState.myVarSix rather than myVarOne, myVarTwo, ..., myVarSix. Hopefully that makes sense.
Would love to know your thoughts regarding this: I've been thinking for a while now, but still I'm not fully convinced that Jetpack Compose is actually an improvement compared to existing View system. When we separate the complexity into two ways, API complexity and implementation complexity, I divide them as follows:
Android View System - High API Complexity & Medium Implementation Complexity
Android View System + LayoutInflater - Low API Complexity & Medium Implementation Complexity
Jetpack Compose - Low API Complexity & High Implementation Complexity
API Complexity is the complexity of the interface that is exposed to app developers. Here, Compose definitely has got low API complexity, but under the hood, the complexity increases manyfold because one has to understand recompositions and also how the compiler is rewriting the Composables.
Just the Android View System has high API complexity (I'd argue it is also medium complexity though) as laying out views in code is not that straight forward, XML actually reduces this to low with the use of LayoutInflater. You define layouts declaratively (one time at the layout, and most views don't simply change their positions anyway unless animated) so declarative UIs are actually achieved.
This reminds me constantly that if in case some bug happens in Compose, say there are too many recompositions, or an edge case in animation which is causing another view to displace or change dimensions, people are gonna have to spend even more time trying to identify the cause of it. This, requires people to understand the implementation, which definitely has a high complexity.
Would love to know your thoughts. If you think otherwise, I request you to please make a video about this.
I think this type of logic should be in vm
And your vm avoid recompostion easily
Really enjoy your videos! I've been doing Android apps as a hobby for a year or so now and your videos have been a great help!
Personally, i come from a web-development job so i'm by no means and Android expert. I'm wondering though, stuff like filtering the todos list and generally preparing data for the presentation layer, shouldn't that logic be done in the viewmodel or elsewhere? In my opinion and experience, the UI-layer shouldn't really do any other logic than implementing the UI, and the preparation of data shouldn't be the job of the UI-layer. Again, i'm by no means an app-developer so i'm sure i havent got the best understanding of good app architecture. Would appreciate your thougts on this!
Agree. Filter in the viewmodel and then expose isDone and notDone in state and observe from the ui.
niceee !
The whole compose is a mistake!
continue the KMM on youTube please
did you met that Tinder girl?
What is tinder
I think UI must not do and filters, just show. First part no words, somebody do so? (facepalm) and I don't like "correction" with remaining logic in UI too.
Debatable :)
Roadmap >>>>>> android developer,,,, please?
Don't Make this English mistake of saying "do a mistake".
First
thanks