https://kotlinlang.org logo
#rx
Title
# rx
u

ursus

10/25/2018, 9:31 PM
and you need that keep track of that boolean to know if you are in pip mode state
g

gildor

10/26/2018, 2:49 AM
It really depends ho is source of those events.
if ViewModel switch pip mode, than activity should subscribe on VM property (LiveData, Observable) and update own state
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
u

ursus

10/26/2018, 5:36 AM
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.
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
But the you run into that restoration problem after configChange
g

gildor

10/26/2018, 5:51 AM
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
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.
u

ursus

10/26/2018, 6:32 AM
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)
Problem with that PipManager is that it has hard activity reference, so it cannot be passed to viewmodel, unless nulled out from activity.onDestroy
To your last message. How would you do reactive in viewmodel, if you can to let viewmodel die on config change?
g

gildor

10/26/2018, 6:36 AM
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
u

ursus

10/26/2018, 6:39 AM
So that you want viewmodel to emit Command objects to the activity to do those ui unrelated activity related stuff?
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
Do you mean PipManager to be detachable from VM?
3 Views