hello, Suleyman!

how can I help you today?

Hi Mark!

hope your day is going great :) I have a question about ViewModel Factories, I'll paste it in

I’m not sure when to use a ViewModelFactory. I thought it was for cases when you need to pass parameters to a ViewModel. But, for example I have a Repository class that has some query methods that take in some parameters and fetch data from DB. In my ViewModel constructor I initialise an instance of Repository and then in getters and setters of the ViewModel I can just use mRepository.get(parameters). So it can be done without the Factory, so what is it for then? :) To avoid leaks?

it is for the situation that you mentioned: when you need to pass parameters to a ViewModel

for example, you might want your ViewModel to also handle the saved instance state Bundle, so configuration is in one spot

if you do all of the initialization of the ViewModel in its constructor, you would need the Bundle in the constructor

and, for that, you need a custom factory

if you do not need to pass data into the ViewModel constructor (beyond the Application for an AndroidViewModel), you may not need a factory

though there may be scenarios where you wind up using one as part of some other framework (e.g., dependency injection)

Thanks for the explanation! So in my case, I believe I don't need it because I only need parameters for my queries.

I certainly would not create one just for giggles :-)

I wouldn't either :D thanks!

you're welcome!

So it's for more complex cases, for example when a repository handles whether to fetch data locally or from a network and therefore needs some parameters to work.

that's one possibility

or, you might use different factories for test scenarios, where you mock at the ViewModel level

oh yeah, that's true, didn't think of that scenario :)

it's a nice hook to have at your disposal, and may be more useful in more complex projects

can I ask you one more question?

go right ahead!

what onChange() method are you referring to?

I'm sorry, I meant onChanged method of the Observer

this is a LiveData Observer?

exactly

I don't see where that would necessarily create a leak

the actual Observer itself (anon inner class or lambda expression) might be a leak, depending on what it references directly

basically, don't reference views directly in the observer

though, even there, since the LiveData is lifecycle-aware, you're probably going to be OK

I'm not ruling out the possibility of a leak in your scenario, but I cannot picture what would be leaked... but I'm short on sleep today, so my brain is fuzzy

I understand, I have the same problem :) thanks for the explanation, it's very helpful :)

I won't torture you anymore, but I'll come back next time :D

trust me, this isn't torture

Then I have just one last question if you don't mind :D

go ahead!

note that if there are more people in the chat room, I would rotate between everyone, but you are the only one here, so the floor is yours

I fully understand that :)

I have a question that have been asked a million times maybe, but still bothers me. Providing different layouts for different screens, is it sufficient to provide the layouts based on smallest width (e.g. layout-sw600dp)?

that is difficult to answer in the abstract

I would say that typically -swNNNdp is sufficient

but you might also need -rtl, if the default RTL layout mirroring is not working to your satisfaction

if the same app supports unusual device types -- such as Android TV -- you might also need other resource set qualifiers to help distinguish them

so, for example, I am experimenting with the new Chrome OS emulator image right now

it's possible, though probably not ideal, that you would want different layouts for Chrome OS, to take into account keyboards and mice

in which case, I think -pc would be the qualifier

in contrast, having density qualifiers (e.g., -xhdpi) or language qualifiers (e.g., -kr) would be code smells IMHO

yeah, you are right, that what I was suspicious about, providing layouts based on density (hdpi, xhdpi, etc.)

density as a resource set qualifier behaves odds

er, behaves oddly

density is designed for drawable and mipmap, where Android can convert between densities automatically via downsampling and upsampling

but the resource system treats it as though *any* resource can be converted between densities, somehow

oh ok got it, so it's not very reliable for layouts

as a result, any lower-priority qualifier, like API level (-v21), gets ignored

right

usually, drawables/mipmaps are the only resource types to use densities

*maybe* values/, if for some strange reason you don't like the normal dimension unit calculations

anything else is unlikely to be what you want

ok perfect, the questions that were bugging for a while are now answered! Thanks a lot! And thanks for providing such a service, it's great to have someone as knowledgeable providing advice :)

I am happy to be useful!

Thanks again :) Have a great day and try to get some sleep! :D

thanks!

Bye!