Correct way to handle subscriptions

[larten]

What is the correct way to get callback about navigate back to a controller in the presenter.
If we have an attached presenter, we didn't set setRetainViewMode(RetainViewMode.RELEASE_DETACH), we don't get attachView() and detachView() in the presenter fur sure, because presenter stay in alive.
But for example I am subscribed to database change with an observer (Room) and it's very performance hungry. I would like to unsubscribe from changes during the controller isn't the current active controller, and resubscribe when we go back, but I don't want to rebuild the full UI.

I solved it with setRetainViewMode(RetainViewMode.RELEASE_DETACH) but in this case we start with a clean Controller, so we must to build the full UI again.

Do you have any idea or I just make in too complicated and this problem is easier :)

[sockeqwe]

Hm, so attach / detachView() should be called in that case regardless of RetainViewMode and you would subscribe / unsubscribe in Presenter.attachView() and Presenter.detachView(), right?

[larten]

I think it should use different callbacks to avoid misunderstandings.
But it could be a great feature, if the developer could subscribe/unsubscribe depends on Controller state. Currently on detach the subscriptions stay alive and it just doesn't forward the statechange to the render, but I believe there are cases when this causes too much unnecessary computation.

btw: It's an awesome project! I like this architecture and I used it in the last 3-4 public projects :) So big thanks for it!

[dimsuz]

I think that attaching and detaching view in presenter should follow the actual lifecycle of a view in the Conductor library. For example in my mvp-based app I rely on this fact and set RETAIN_DETACH in a few places to have exactly this effect - so that the view wouldn't be recreated and reattached.

But on the second thought when using MVI this shouldn't be a problem - view state will get restored. But for MVP it could be something which is not obvious. At least I think this must be carefully thought out before changing...

[larten]

You are right, I don't agree with attach / detachView() should be called in that case regardless of RetainViewMode.
I just say it would be great a different callback, which is regardless of RetainViewMode to manage subscriptions which are heavy.