Don't Do THIS Jetpack Compose Mistake 

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.

Nice vid philipp, I hope you make some shorts about optimizing re-comipistions with "donut scoping", it revolves around the idea of inlining functions

This one of the helpful things i need to do to optimize the apps I build, thanks!

It was really helpful, thanks for sharing

I prefer another approach in this case. I prefer preparing those 2 lists in the VM and move logic to there

no logic other than a simple if in the ui. let vm drive the state.

Thank you so much. Wish I had known this early

Also we can call partition on our list and get both done and undone items list

Amazing video :)

Hi Phillip, how can i set toolbar color like bootom bar and status bar color like toolbar color ?

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.

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

thanks

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.

Hey, Philipp. Can you do a video for Rich text editor like most note application, please?

Thanks

Your expressions in the thumbnail :)

after applying this my UI loaded more smoothly, cool.

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

this was exactly what I needed without this I had to recompose a lazy vertical grid in an if else block

I made every mistake you said don't do it 😂😂😂. Thanks Philipp

very cool you are the best

niceee !

Please always give the source code link!

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 this type of logic should be in vm And your vm avoid recompostion easily

continue the KMM on youTube please

The whole compose is a mistake!

did you met that Tinder girl?

Roadmap >>>>>> android developer,,,, please?

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 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.

First

Don't Make this English mistake of saying "do a mistake".

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.