I guess the easiest way is having a

lateinit var

that's initialized when the viewmodel is injected in the Fragment... but that's a bit of a brittle way to do things?

Register and unregister the Broadcast receiver from the fragment and post received values to the view model ?

You mean providing a

MutableLiveData

from the

ViewModel

that the view can post to? It wouldn't have been a bad idea... but in my case, I need to combine that

Flow

with one I'm getting from a repository...

Maybe you could expose a broadcast receiver created in your VM that you would register/unregister in your fragment ? You might be able to get away without leaking your context 🤔. But I’d rather handle Broadcast receiver in the view part and treat it as if it was view inputs

I'm really trying to get rid of

Context

from my VM to make unit tests... having a Flow exposed instead of

BroadcastReceiver

code makes it easy to mock... I guess for now a

lateinit var

is the way to go... just wondering what everybody else does in this case. Your idea for

MutableLiveData

might also come in handy in other situations... thanks!

I wouldn’t use a

MutableLiveData

. I’m not sure it is a good practice to push from the view to the ViewModel using a MutableLiveData. Just expose a method in your view model 🤷

Yeah,

LiveData

is really to manage View lifecycles...

I would do it with wrapper class implementing some interface and injecting it in VM

Still with a

lateinit var

though... since I need to register that

BroadcastReceiver

...?

you can implement ViewModelFactory and pass that interface with constructor

Yeah but the actual

var

containing the

Flow

needs to be initialized in

onCreateView()

of the Fragment so that the viewmodel can listen to it...

Why you want to do it in

onCreateView

?

Because I need a

Context

to register that receiver with the lifecycle of the

Fragment

...

Your wrapper interface implementation can have context provided by constructor and you can use it to register broadcastreceiver

Yeah, I see what you mean now... I guess it could be cleaner in a sense, I just wonder if its worth the overhead unless there's more than one field... thanks!

if you want to not have platform specific code in

ViewModel

for testing purposes it worth 🙂

So for that I have a Flow... see the code I posted before (fromBroadcast) 😉

You can extend AndoroidViewModel instead of ViewModel and inject application for the context (it accepts application as a param) and then mock it, Androidx testing core library provides now support for mocking Andoroid components