this is not allowed in case of canonical MVP also...
# rx
a
this is not allowed in case of canonical MVP also i’m use Moxy library for MVP (it’s awesome lib) and Moxy crashes on compile with view method returning non-void value
a
Moxy crashes on compile with view method returning non-void value
facepalm.jpg
a
why?
a
Why would MVP library even do that?
a
because of: 1. that is creator’s decision 2. this is rule of canonical MVP
a
Ah, so it basically prohibits you from reading state of View layer, it makes some sense then, but it makes RxBinding pretty useless for you in that case
a
some good guys do
presenter.setButtonObservable(RxView.clicks(button))
but I think this is ugly
a
yeah, feels like wrong indirection and I’m not sure how would you compose that with Presenter logic,
Observable<Observable>
?
a
nope, i decide to duplicate observable for view in presenter with RxRelay and transfer all data through presenter’s plain methods. Feels good, but a bit complicated. Also add to
Presenter#unsubscribeOnDetach(Disposable)
to give control on RxBinding’s subscriptions to presenter
a
So you have a pair of Disposable and Relay for each observable from View layer?
a
I have Relay for each view I need to react on different Rx thing. For example, button state depends on symbol count on multiple `EditText`s, so combining internal Relay is easy.
a
Mhm, I see, do you manage
.subscribe(presenter::onEditTextChanged)
Disposable?
a
Yep, previous line -
doOnSubscribe(presenter::unsubscribeOnDetach)
a
Ookay, that’s pretty non-obvious way to unsubscribe 😄 I mean I don’t think anybody would expect unsubscription management through separate side effect as
doOnSubscribe()
, it’ll work though
I still don’t see much benefit from such two way binding though, you need to manage disposables both on View and Presenter layer
a
yes, i agree, this solution is a little bit overcomplicated