Don't Do THIS Jetpack Compose Mistake
ฝัง
- เผยแพร่เมื่อ 3 ก.ย. 2022
- ⭐ Get certificates for your future job
⭐ Save countless hours of time
⭐ 100% money back guarantee for 30 days
⭐ Become a professional Android developer now:
pl-coding.com/premium-courses...
💻 Let me be your mentor and become an industry-ready Android developer in 10 weeks:
pl-coding.com/drop-table-ment...
Subscribe to my FREE newsletter for regular Android, Kotlin & Architecture advice!
pl-coding.com/newsletter
Join this channel to get access to perks:
/ @philipplackner
Join my Discord server:
/ discord
Regular programming advice on my Instagram page: / _philipplackner_
Checkout my GitHub: github.com/philipplackner
You like my free content? Here you can buy me a coffee:
www.buymeacoffee.com/philippl...
![4BANG - NOT LIKE US (REMIX) [Official Music Video]](http://i.ytimg.com/vi/HO22cYkha1s/mqdefault.jpg)
![Yoshi Rinrada - 'มาทำไม' [Official MV]](http://i.ytimg.com/vi/r41xbfRLkLs/mqdefault.jpg)
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
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.
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
This one of the helpful things i need to do to optimize the apps I build, thanks!
It was really helpful, thanks for sharing
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 :)
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.
Hi Phillip, how can i set toolbar color like bootom bar and status bar color like toolbar color ?
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.
after applying this my UI loaded more smoothly, cool.
thanks
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
Thanks
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?
Your expressions in the thumbnail :)
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
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 !
Please always give the source code link!
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?
What is tinder
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.
Debatable :)
Roadmap >>>>>> android developer,,,, please?
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.