Mar 20 | 3:55 PM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Mar 20 | 4:00 PM |
Eric | has entered the room |
Eric |
afternoon mark, nice to see you
|
Mark M. |
hello, Eric~!
|
Mark M. |
er, give or take a ~
|
Mark M. |
how can I help you today?
|
Eric |
when should I create a new viewmodel as opposed to using an existing one?
|
Mark M. |
do you mean a viewmodel *class* or a viemodel *instance*?
|
Mar 20 | 4:05 PM |
Eric |
good question. I meant class but I would be curious to know about instance as well
|
Mark M. |
well, the answer to "instance" is: you shouldn't be creating instances of your viewmodel, most likely :-)
|
Mark M. |
I am assuming that you are working with the Jetpack ViewModel system
|
Mark M. |
most of the time, the Jetpack or your dependency inversion framework (e.g., Hilt, Koin) will create your viewmodel instances for you
|
Mark M. |
in terms of when to create a new viewmodel class, my default tends to be "one per screen", with variations in cases where I might have some reuse that might work better with a reusable viewmodel
|
Eric |
if I have a master detail view, should I use one or two viewmodels?
|
Mark M. |
my gut instinct would be two, but I have not had to deal with master-detail in many years
|
Mark M. |
(though that sort of large-screen UI is something I hope to get back into later this year)
|
Eric |
I read that you want to use a shared viewmodel if you want fragment to fragment communication. So I opted to use a single viewmodel
|
Mark M. |
that can work
|
Mark M. |
it might also be that you wind up with 3 viewmodels: one for each of the fragments plus the shared activity-level one
|
Mar 20 | 4:10 PM |
Eric |
as I learn I'm trying to make sure I adopt best practice
|
Mark M. |
basically, while it's possible to have too much of a good thing, do not be afraid to create new viewmodel classes, particularly where the scope changes
|
Eric |
yes
|
Mark M. |
overall, though, I don't know that we have come to universal agreement on what the "best practices" are in this area
|
Eric |
cool I appreciate it
|
Mar 20 | 4:15 PM |
Mark M. |
if you have another question, go right ahead!
|
Mar 20 | 4:25 PM |
Eric |
Do you know if there's a kotlin or rxjava function for this? I have a list of StudentDetail and a dean's list. Both contain an id. I want a new list of StudentDetail but only if its id was on a dean's list. It's kind of like a filter but I uses lists instead
|
Mark M. |
students.filter { deansList.contains(it) } or something like that should give you what you want
|
Mark M. |
or students.filter { deansList.contains(it.id) }
|
Mark M. |
it depends a bit on what your classes all are structured like, but filter() is the right Kotlin function
|
Mark M. |
if you need to do this in an RxJava chain, that would be a map() operator that takes the list and returns the filtered list, using the Kotlin filter() function
|
Eric |
ok. You answered my questions. I appreciate it mark
|
Mark M. |
happy to help!
|
Eric |
enjoy your weekend, bye
|
Eric | has left the room |
Mar 20 | 4:55 PM |
Mark M. | turned off guest access |