got to say, i was a bit confused by your implementation of selected items, but after i tried it (tweaked it a bit for my benefits) I can say it works really well. thank you!
Awesome man. I liked the way you manage states using and selection using lifecycle owner and LiveData. I would like to see videos on how you try to break your code. Please make a video on this topic as well.
I love this approach so much that, I decided to make my listinteraction a generic class so that I can pass any Model to it and also added selectAll() to it. I love you Mitch ❤️
If you observe selectedNotes in the bind method then it will be called several number of times each time you scroll. So the better practice would be to observe it in the constructor of the viewholder class. Then it will only be called when the onCreateViewHolder method is called.
Hi Mitch, congrats for all the stuff and effort sharing knowledge and ty very much. One question regarding passing lifeCycleOwner and the list to the adapter and view holder: I think that this violates the principle of single responsibility of RV's adapter (to create and binding data), but it's just a thought, what do you think about it? ... anyway it's a clever way to solve a problem
Hey Mitch, I like the style of this vlog series a lot. Following the process of someone figuring out stuff is nice :) I've got a comment on the recycler view stuff: Did you play around with ListAdapter yet? It comes with some convenience funcitons like updating the current data set and a DiffUtil, which checks for which rows are now abesnt, new or just have changed their content and only refreshes them. That in conjuction with not the raw data "note", but more like state objects as list items for the adapter containing properties for "selected" streamlined things up for me in the past. If using that you would provide a LiveData Object with a list of NoteItems, which hold the note and the state.
Sealed classes are wonderful! My only issue with them (enums suffer from this as well) are that they dramatically increase the apk size. I much prefer to use custom @IntDef or @StringDef if all you're trying to do is distinguish between states; the compiled code is MUCH smaller, while readability does not suffer.
Thanks, Mitch for this video... I didn't watch yet. I feel to say thanks to you before I watch it. I really like your presentation style. Whatever you said in your video, I understand very clearly.
Hey Mitch, great video! I was wondering whether it would be better to pass the viewmodel to the adapter as a constructor argument, because that way the adapter could directly call the viewmodel without going through the fragment with the interaction interface. It would also mean one less constructor argument for the adapter. The other thing I'm wondering is whether it would be better to observe the selectedNotes livedata separatly from the viewholder and somehow change the adapter items from there? In your implementation there is an observer for every single item and all of them get called on any selection change and all of them have to iterate through the entire list of selected items. If you have a recyclerview with for example 200 items and you have 100 of them selected and you select another, then the code would iterate through a 100 item list 200 times (= 20.000) which doesn't seem ideal. This might still be the cleanest solution, just a tought.
You can also replace when statement with a polymorphism and incapsulate your logic inside of the state to implement state pattern. In your app those sealed classes are just like enums.
I liked to use sealed class to pass firebase data state to activity. I used Google pattern with Resource class and Success, Loading and Failure sub classes, it worked well
Great video, Mitch! Keep them coming. I like your content far better than CodingInFlow 💪. Oh, also I think you can use "object" insted of "class" on the sub classes of your sealed class if they're not holding any state.
@@codinginflow Hahaha, I also watch and like your content, but don't tell Mitch 👀. Your last two building your app with Clean Architecture are really cool, keep them coming too.
I wasn't planning on pointing it out since it wasn't really the point of the video, but I second this comment about using an object declaration if the sealed class type doesn't take any unique data. It basically becomes an enum type at that point which makes referencing it slightly easier and overall more memory efficient I think (though that's quite minor)
Cool design! But is there really a reason to create sealed classes in this particular case? I mean you could've just used two int constants to keep track of the current state and change UI accordingly. Sealed classes are great when you need to delegate some functionality to the state classes with the same interface.
13:06 Hi. Grateful for videos and I'm curious about this observe-in-adapter approach. Is there a problem or I miss something. In short, each time when "selectedNotes.observe" is called new instance of Observer is created and will be destroyed only when lifecycleOwner is Destroyed. Plus, Observer (as an instance of anonymous class under the hood) keeps reference to the "note" and "itemView". This can cause tricky behavior in the future when the ViewHolders are being reused. ======= In Details. 1. Too many useless object are allocated (new Observer for each ViewHolder.bind) Let`s say user have 100 items. When user open the screen, only 10 are visible, so 10 ViewHolders are created and each observes LiveData with new Observer instance. Then user scrolls 10 elements more, so these 10 ViewHolders were reused and liveData gets new Observer instances. As a result the liveData has 20 observers, even though you have only 10 visible ViewHolders. Because old Observers will be removed only when livecycleOwner is Destroyed. 2. Each Observer instance keeps the "note" and "itemView" reference inside which can cause tricky behavior If point 1 is correct and there are much more Observer instances in memory than visible ViewHolders - then it can be the following case: ViewHolder1 instance were used to present Note1. After awhile user scroll down and eventually returns to the Note1 again. So another instance, lets say, ViewHolder 6 now presents Note1. Note: now we have in memory two Observers instances and both keep references to the same "note" but different "itemView". Note1 is selected so LiveData notifies its observers. Current ViewHolder Observer is invoked and make the itemView color to Grey - which is ok. And old Observer instance also gets notified, it has a reference to the Note1 so it change color of its current "itemView" to grey - which is now correct. Because this "itemView" is used now to present, for example, Note 3.
If you pass in the viewLifecycleOwner into your adapter, wouldn't it cause a memory leak ?? Because if you use a method in viewLifecycleOwner, and before that method returns the device is rotated and the activity is destroyed but not the viewLifecycleOwner so that method will still be able to return causing a memory leak. Please correct me if i'm wrong
@CodingWithMitch you should draw on your desktop while explaining code, it' more simple to follow. I mean something like a small overview what you're doing and where the glue is between those. I always try to comprehend with drawing after a video like this. I'm not a professional tuber but I use this too simple tool called "NittiTre WhiteBoard". Hopefully you will find a better one for windows. I'm a programmer and have learned to think with a whiteboard, when the problem and information overwhelmes me. Though I think the best skill to have a vision is to draw as less as possible to get an overview about relation, which is not taught in general.
Hey mitch, just recently found your channel and I'm loving how easily it is for me to understand your explanation. And especially loving all these vlog series!
I see in many videos a "when statement" being used inside the view, but I'm not sure if it's just normal or something that I should avoid (alongside ifs, fors, etc) because they should be on the ViewModel. Any thoughts on that?
is there any reason why you havent done it with diff util and the onBindViewHolder(ViewHolder, int, List) that caries the payload (List), so you do not have to rebind whole view holder just its small part, like a background color, like button etc.
Hi Mitch, Advice how to improve your adapter: selectedNotes.observe(... { notes -> val isNoteSelected = notes?.contains(note) == true itemView.changeClor( newColor = if (isNoteSelected) COLOR_GRAY else COLOR_PRIMARY ) } In my opinion it is much more readable Also I will explain why this approach is not good(i would even say bad approach): on each bind you create a new Observer, which will actively listen to the LiveData until the view will not be destroyed. Le's say you have 100 Notes in the list. If you scroll to the bottom of the list - you will have 100 Observerds, then if you scroll back to the top - you will have 200 Observers, and so on. And now on each item select\unselect the LiveData will trigger all this observers to work, and each of them will try to find a Note in the list of 100 Notes... and all this on the UI thread. Here your solution may start to lag
I thought that too. But like I said I inserted 1000. Scrolled up and down. Selected, unselected, basically did a bunch of interaction. And no lag. Worked perfectly 🤷♂️
@@codingwithmitch Yes, maybe it works. But it also may be that it will start to lag on some low-end devices. You should understand that you create hundreds or thousands of unneeded subscriptions so this approach is not good. And there is an easy way how to avoid it and improve performance
Hi can you give me a suggestion, a friend of mine asked me to create an e commerce app for android they dont have any setup.I am thinking of using firebase as backend and develop the app .what is your take on this. Open to all suggestions
Hello, cool videos there :) Have you tried setting view state in xml file via custom parameter with data binding? You keep state as a single livedata in your vm, lets u clean fragment class off a lot of code :)
@@pawemuniak634 I don't think the added complexity is worth what it does. View binding is great. But other than that having to make all these adapters and put logic in the XML is not my favorite thing.
Coding in flow is at Instagram too. U may consider opening an account there. Many people including me see his inst posts and forwarded to his channel. Of course ur vids deserves better and a bit advanced compared to his topics.
*Can anyone tell* can i just keep going with java for android, it took my too much time and effort to learn core java, collections, streams, functional programming in java, and other java stuff, and now there is new language called kotlin which people recommends for android development but if i go with it my java knowledge if i am not wrong will be wasted and i will be like *"why did i learn java? if i knew kotlin is better i would have never learn that much java stuff i would have started with kotlin only"* or maybe flutter, is kotlin rendering java useless for new android developers and in future is flutter going to render kotlin useless.
Your Java knowledge will actually help you. Kotlin fastens up development though. Learning more than one language is inevitable for a developer in the end anyways. And it will give you more thinking perspectives, which enhances your problem solving abilities. Go for it!
@@Forke13 thanks for your valueable answer, i was also worried about , the time by which i will get a grip of kotlin the flutter /reactnative etc will take over the development and then i will have to learn dart/Javascript
Hey Mitch, very informative tutorial. Keep it up with the videos. Just want to mention that the real advantage of sealed classes in your code would be when you add another view state and compiler automatically detects that there is type case missing in when statement. For that to happen you will need to use extension function in your when statement just like mentioned here, ua-cam.com/video/OyIRuxjBORY/v-deo.html. For your use case, you could have used enum class as well since there is no additional information you need in viewstate except the type.
Would love to see more more on Sealed Classes, keep up the good work!
More than a sealed class explanation, man I liked the way you used lifecycle owner in adapter viewholder...great work...keep it up🔥🔥🔥
got to say, i was a bit confused by your implementation of selected items, but after i tried it (tweaked it a bit for my benefits) I can say it works really well. thank you!
Man I am fan of Sealed classes. Using it for all kind of Result handling.
Same here. They're one of my favorite Kotlin features
Would love to see in-depth tutorial on Sealed Classes because nobody can do it better than you. Eagerly waiting!
Awesome man. I liked the way you manage states using and selection using lifecycle owner and LiveData. I would like to see videos on how you try to break your code. Please make a video on this topic as well.
I love this approach so much that, I decided to make my listinteraction a generic class so that I can pass any Model to it and also added selectAll() to it. I love you Mitch ❤️
If you observe selectedNotes in the bind method then it will be called several number of times each time you scroll. So the better practice would be to observe it in the constructor of the viewholder class. Then it will only be called when the onCreateViewHolder method is called.
mitch your videos/vlogs are becoming really really good, well done, keep em coming :D
This darn CodingInFlow guy can not keep getting away with this!
This is even better the second time
this is pure gem mitch!
Hi Mitch, congrats for all the stuff and effort sharing knowledge and ty very much. One question regarding passing lifeCycleOwner and the list to the adapter and view holder: I think that this violates the principle of single responsibility of RV's adapter (to create and binding data), but it's just a thought, what do you think about it? ... anyway it's a clever way to solve a problem
I don't see how it violates that principal
Would like to see some more videos and realtime examples on sealed classes
Great work buddy. Go ahead. It helped us a lot to learn all the Kotlin stuff.
Hey Mitch, I like the style of this vlog series a lot. Following the process of someone figuring out stuff is nice :)
I've got a comment on the recycler view stuff: Did you play around with ListAdapter yet? It comes with some convenience funcitons like updating the current data set and a DiffUtil, which checks for which rows are now abesnt, new or just have changed their content and only refreshes them.
That in conjuction with not the raw data "note", but more like state objects as list items for the adapter containing properties for "selected" streamlined things up for me in the past.
If using that you would provide a LiveData Object with a list of NoteItems, which hold the note and the state.
Yes I have. I prefer to setup diffutil myself like I have here. Listadapter does the same thing but I think it looks more complex
Sealed classes are wonderful! My only issue with them (enums suffer from this as well) are that they dramatically increase the apk size. I much prefer to use custom @IntDef or @StringDef if all you're trying to do is distinguish between states; the compiled code is MUCH smaller, while readability does not suffer.
i super liked your logic in the viewholder :D and im also a big fan of the livedata :)
Hey Mitch your explanations are awesome! I really like this channel. Thanks for your work
dude your content is really good, I learn so much from you
Thanks, Mitch for this video... I didn't watch yet. I feel to say thanks to you before I watch it. I really like your presentation style. Whatever you said in your video, I understand very clearly.
Hey Mitch, great video! I was wondering whether it would be better to pass the viewmodel to the adapter as a constructor argument, because that way the adapter could directly call the viewmodel without going through the fragment with the interaction interface. It would also mean one less constructor argument for the adapter. The other thing I'm wondering is whether it would be better to observe the selectedNotes livedata separatly from the viewholder and somehow change the adapter items from there? In your implementation there is an observer for every single item and all of them get called on any selection change and all of them have to iterate through the entire list of selected items. If you have a recyclerview with for example 200 items and you have 100 of them selected and you select another, then the code would iterate through a 100 item list 200 times (= 20.000) which doesn't seem ideal. This might still be the cleanest solution, just a tought.
This vlog was great. Easy to understand.
Did you really inserted 1000 items, is there a way to insert it in bulk?
Just made a loop that ran 1000 times. Then removed it
I actually discovered you from the Coding in Flow channel, so he also helps you :D
Florian is gonna be pissed
ahan I was thinking what I should write as you asked for comment... so Love you Mitch .. I have learned a lot from you bro
You can also replace when statement with a polymorphism and incapsulate your logic inside of the state to implement state pattern. In your app those sealed classes are just like enums.
Top channel for android
I liked to use sealed class to pass firebase data state to activity. I used Google pattern with Resource class and Success, Loading and Failure sub classes, it worked well
This kind of videos are very useful. Thanks for sharing knowledge
Great video, Mitch! Keep them coming. I like your content far better than CodingInFlow 💪. Oh, also I think you can use "object" insted of "class" on the sub classes of your sealed class if they're not holding any state.
wow
@@codinginflow Hahaha, I also watch and like your content, but don't tell Mitch 👀. Your last two building your app with Clean Architecture are really cool, keep them coming too.
I wasn't planning on pointing it out since it wasn't really the point of the video, but I second this comment about using an object declaration if the sealed class type doesn't take any unique data. It basically becomes an enum type at that point which makes referencing it slightly easier and overall more memory efficient I think (though that's quite minor)
Cool design! But is there really a reason to create sealed classes in this particular case? I mean you could've just used two int constants to keep track of the current state and change UI accordingly. Sealed classes are great when you need to delegate some functionality to the state classes with the same interface.
So yes Mitch, please talk us about sealed classes :0D
Don't worry sir!! You are the best!
13:06 Hi. Grateful for videos and I'm curious about this observe-in-adapter approach. Is there a problem or I miss something.
In short, each time when "selectedNotes.observe" is called new instance of Observer is created and will be destroyed only when lifecycleOwner is Destroyed. Plus, Observer (as an instance of anonymous class under the hood) keeps reference to the "note" and "itemView". This can cause tricky behavior in the future when the ViewHolders are being reused.
=======
In Details.
1. Too many useless object are allocated (new Observer for each ViewHolder.bind)
Let`s say user have 100 items. When user open the screen, only 10 are visible, so 10 ViewHolders are created and each observes LiveData with new Observer instance.
Then user scrolls 10 elements more, so these 10 ViewHolders were reused and liveData gets new Observer instances.
As a result the liveData has 20 observers, even though you have only 10 visible ViewHolders. Because old Observers will be removed only when livecycleOwner is Destroyed.
2. Each Observer instance keeps the "note" and "itemView" reference inside which can cause tricky behavior
If point 1 is correct and there are much more Observer instances in memory than visible ViewHolders - then it can be the following case:
ViewHolder1 instance were used to present Note1. After awhile user scroll down and eventually returns to the Note1 again. So another instance, lets say, ViewHolder 6 now presents Note1. Note: now we have in memory two Observers instances and both keep references to the same "note" but different "itemView". Note1 is selected so LiveData notifies its observers. Current ViewHolder Observer is invoked and make the itemView color to Grey - which is ok. And old Observer instance also gets notified, it has a reference to the Note1 so it change color of its current "itemView" to grey - which is now correct. Because this "itemView" is used now to present, for example, Note 3.
If you pass in the viewLifecycleOwner into your adapter, wouldn't it cause a memory leak ?? Because if you use a method in viewLifecycleOwner, and before that method returns the device is rotated and the activity is destroyed but not the viewLifecycleOwner so that method will still be able to return causing a memory leak. Please correct me if i'm wrong
No leaks
Hey Mitch. We would love to see a tutorial on Kotlin Sealed Classes. We'd be grateful.
@CodingWithMitch you should draw on your desktop while explaining code, it' more simple to follow. I mean something like a small overview what you're doing and where the glue is between those. I always try to comprehend with drawing after a video like this. I'm not a professional tuber but I use this too simple tool called "NittiTre WhiteBoard". Hopefully you will find a better one for windows. I'm a programmer and have learned to think with a whiteboard, when the problem and information overwhelmes me. Though I think the best skill to have a vision is to draw as less as possible to get an overview about relation, which is not taught in general.
Hey mitch, just recently found your channel and I'm loving how easily it is for me to understand your explanation. And especially loving all these vlog series!
Dude that's just amazing!
Thanks for such a great video 👍🏻👍🏻👍🏻
I see in many videos a "when statement" being used inside the view, but I'm not sure if it's just normal or something that I should avoid (alongside ifs, fors, etc) because they should be on the ViewModel. Any thoughts on that?
Hi. I have a question. Do you recommend using databinding with MVVM at all?
is there any reason why you havent done it with diff util and the onBindViewHolder(ViewHolder, int, List) that caries the payload (List), so you do not have to rebind whole view holder just its small part, like a background color, like button etc.
Any advantage of having that extra manager class and not having that logic in your ViewModel?
was nice , if u can create more about kotlin
Please make more videos about it
Please do make video on sealed class . How to manage state
Love to see examples on this
Loved your video ♥️
i would love to hear the sealed classes video from you sir
Please make a video on Sealed class and create a sample app
Awesome video!
why not coop with CodingInFlow? it's UA-cam, not console exclusives, you can enjoy both rather than fanboy one
Hi Mitch,
Advice how to improve your adapter:
selectedNotes.observe(... { notes ->
val isNoteSelected = notes?.contains(note) == true
itemView.changeClor(
newColor = if (isNoteSelected) COLOR_GRAY else COLOR_PRIMARY
)
}
In my opinion it is much more readable
Also I will explain why this approach is not good(i would even say bad approach):
on each bind you create a new Observer, which will actively listen to the LiveData until the view will not be destroyed. Le's say you have 100 Notes in the list. If you scroll to the bottom of the list - you will have 100 Observerds, then if you scroll back to the top - you will have 200 Observers, and so on. And now on each item select\unselect the LiveData will trigger all this observers to work, and each of them will try to find a Note in the list of 100 Notes... and all this on the UI thread. Here your solution may start to lag
I thought that too. But like I said I inserted 1000. Scrolled up and down. Selected, unselected, basically did a bunch of interaction. And no lag. Worked perfectly 🤷♂️
@@codingwithmitch Yes, maybe it works. But it also may be that it will start to lag on some low-end devices. You should understand that you create hundreds or thousands of unneeded subscriptions so this approach is not good. And there is an easy way how to avoid it and improve performance
Nice video, I would like to learn how to use sealed classes in my project.
Great work, thanks
thx for sharing, I like your video
Codinginflow crisis part 2😵😵😵😵😵
Hi can you give me a suggestion, a friend of mine asked me to create an e commerce app for android they dont have any setup.I am thinking of using firebase as backend and develop the app .what is your take on this. Open to all suggestions
Firebase is great if you don't have any web dev or server backend experience. But I always prefer a using a server that your actually own.
You are the real gee.
Hello, cool videos there :)
Have you tried setting view state in xml file via custom parameter with data binding? You keep state as a single livedata in your vm, lets u clean fragment class off a lot of code :)
Not a fan of data binding
@@codingwithmitch Why is that? Are there some big cons or you just didnt dive into it deep enough yet?
@@pawemuniak634 I don't think the added complexity is worth what it does. View binding is great. But other than that having to make all these adapters and put logic in the XML is not my favorite thing.
Hi Mitch ,
Will you create a course for this application in your website ?
Yep
Please, Give more samples for sealed
Is there a specific reason you chose to use a sealed class over an enum for your use case?
Could have used enum in this case. Would have been the same.
When statement haha
Awesome
sir please do course project kotlin mvvm hilt retrofit compleate token based authentication sir
florian is getting ready to show his face
Coding in flow is at Instagram too. U may consider opening an account there. Many people including me see his inst posts and forwarded to his channel. Of course ur vids deserves better and a bit advanced compared to his topics.
I gave that video a comment, youtube algorithm loves comments.
Mitch you're great, but CodingInFlow has that accent 😂
Maybe I will start pronouncing 'V' as 'W'
Shots fired
You are awesome!!
sir please about class delegation
Mitch when you type for search ..I saw wtf😁
super and thanks sir
*Can anyone tell* can i just keep going with java for android, it took my too much time and effort to learn core java, collections, streams, functional programming in java, and other java stuff, and now there is new language called kotlin which people recommends for android development but if i go with it my java knowledge if i am not wrong will be wasted and i will be like *"why did i learn java? if i knew kotlin is better i would have never learn that much java stuff i would have started with kotlin only"* or maybe flutter, is kotlin rendering java useless for new android developers and in future is flutter going to render kotlin useless.
Your Java knowledge will actually help you. Kotlin fastens up development though. Learning more than one language is inevitable for a developer in the end anyways. And it will give you more thinking perspectives, which enhances your problem solving abilities. Go for it!
@@Forke13 thanks for your valueable answer, i was also worried about , the time by which i will get a grip of kotlin the flutter /reactnative etc will take over the development and then i will have to learn dart/Javascript
Kotlin is basically the same as java. Your knowledge of Java is a good thing to have
@@codingwithmitch thanks for the answer mitch, will you please aslo reply for my comments above, one that was for Forke K
@@codingwithmitch Kotlin is Java in Mobile-optimized and with a bit of Steroids
😊 16:17 Yeah, I see W at the top (wtf)
So less code to do so much stuff 😬
oh wow
very nice
Better use data binding
Hey Mitch, very informative tutorial. Keep it up with the videos. Just want to mention that the real advantage of sealed classes in your code would be when you add another view state and compiler automatically detects that there is type case missing in when statement. For that to happen you will need to use extension function in your when statement just like mentioned here, ua-cam.com/video/OyIRuxjBORY/v-deo.html. For your use case, you could have used enum class as well since there is no additional information you need in viewstate except the type.
Coding in Flow be like: Hahahaha (Evil laugh) 😈👹
Sad to see his subscribers now reaching 2 lack 🤣🤣, well thanks not just for tutorials, but also for Coding in Flow 😂
We open-sourced our in-house MVI implementation. It plays really nicely with sealed classes. If interested, Google: WW Roxie
Googling
Engagement
Down voted. Title was “sealed classses” but didn’t get to it until 8 mins in. Then proceeds to read and show the kotlin documentation.
engagement
sealed class ..
real men wear pink.....and uses sealed classes
Mitch, quite disappointed with this video. You are focus on other staff other than the sealed class.
You want me to do other stuff you mean?
We need sealed classes demo video
Would love to see more more on Sealed Classes, keep up the good work!