and you need that keep track of that boolean to kn...

# rx

[ursus]

and you need that keep track of that boolean to know if you are in pip mode state

[gildor]

It really depends ho is source of those events.

[gildor]

if ViewModel switch pip mode, than activity should subscribe on VM property (LiveData, Observable) and update own state

[gildor]

if user interacts with UI directly and Activity is source of events, than activity should update this property in VM.
Or even both of them. Main idea that you should observe changes

[ursus]

Point is that I need activity context transitively. And id argue entering pip mode is a activity thing, not a dumb view thing. So id like to encapsulate activity reference inside my PipMamager abstraction and have fun enterPip() = activity.enterPip() on it. This allows me to read the return value of activity.enterPip(). PipManager would expose isInPipModeObservable to viewmodel, whicj then can map it to view state objects and emit them to ui. Key is that whole logic is in PipManager, which sits in viewmodel. And not im activity. If it were to sit in activity, then the whole thing doesnt make sense and might as well not proxy the button click to viewmodel but to PipManager sitting in the activity, directly.

[ursus]

And hence if I were to retain viewmodel, I can only do the latter, and that causes to have logic in view imo and circumvents viewmodel, so unit test is poorer. Its dumb. Best would be former case, and not retaining viewmodel so it can safely have the activity reference albeit transitively

[ursus]

But the you run into that restoration problem after configChange

[gildor]

Point is that I need activity context transitively

What do you mean? Activity apparently always has activity context, ViewModel doesn’t have any context

. And id argue entering pip mode is a activity thing, not a dumb view thing

Again, what do you mean? What is difference between activity and view in this context, it’s just some UI property

So id like to encapsulate activity reference inside my PipMamager abstraction and have fun enterPip() = activity.enterPip() on it.

I don’t see any problem with it, just this PipManager should depend on Activity and have Activity lifecycle

[gildor]

I do not want to advocate of usage ViewModel. if you fine with save/restore instance states on configuration, do this, but I still think that pure observable/reactive approach in this case a lot more flexible and can be used with or without keeping VM alive on configuration change.

[ursus]

Well, in my mind activity is not view. Activities views are view, or any UI. When you need activity.starActivity, or activity.requestPermission, thats not UI but it needs activity reference (I know you can most of times get away with application context for such things, but sometimes you can as in the permissions, or pip)

[ursus]

Problem with that PipManager is that it has hard activity reference, so it cannot be passed to viewmodel, unless nulled out from activity.onDestroy

[ursus]

To your last message. How would you do reactive in viewmodel, if you can to let viewmodel die on config change?

[gildor]

Yes, I understand and I'm talking that such cases can be architect using another approach, when VM emits events (such as start pip mode) and can be easily detachable, but I agree, it's very different from what you have now

[ursus]

So that you want viewmodel to emit Command objects to the activity to do those ui unrelated activity related stuff?

[ursus]

I used this before, as it was only thing that worked quickly with retained viewmodel, but it lacks where there is some more logic to it, or you want a return value of such call, unless you proxy it back to viewmodel, and create another relay to bring it back to original placs.. too ugly imo

[ursus]

Do you mean PipManager to be detachable from VM?