Closed paulleo closed 7 years ago
I'm sorry but I can't get your usecase. First of all, you don't need to call isDisposed()
on any async work, it needs to be called only inside one of the create(...)
methods (as you can see here). In addition, an Interactor just provides the streams for Presenter as the tools, it doesn't need to be aware of the entity that uses it or its lifecycle. That's Presenter work to handle such cases, and that's why it provides an addSubscription(...)
method.
I understand that the code you attached is just an example, but to avoid any potential problems in your production code - what do you want to achieve through wrapping a getAPIData()
call in Single.create(...)
? If I understand it correctly, it's redundant here.
If this comment doesn't answer your question, provide me more context and more specific usecase please.
Sorry the initial question was a little rushed. I've cleanup up the code to give a better example. You were right that the getAPIData() was redundant when not grooming the data for the Presenter. I just wanted to mention that in the case where the view and presenter is detached (and therefore the subscriber is disposed because of the addSubscription) while the interactor was doing async work to prepare the presenter data, it would crash without a check for disposed. So in this scenario, I was wondering whether it would be prudent to have a isPresenterAttached() function anyway?
I'm still not sure if I get you correctly, but the Interactor won't crash after the Presenter disposal. The Interactor in the Rx flavor of this lib shall not have reference to the Presenter, so Presenter actions shall not influence it.
Moreover, if the Observer gets disposed via the Disposable.dispose()
method the Observer won’t get any emission from the Observable and that's all. Observable can still emit its items and nothing dangerous will happen. As I have mentioned above, the only scenario where you should call isDisposed
is inside one of the create(...)
methods, but it's up to internal implementation of your components, and it does not depend on the Presenter-Interactor link and lifecycle.
Appreciate your response, thank you.
Hi, I think I can understand why a BaseRxInteractor needs no
isPresenterAttached()
logic as with BaseInteractor. However, in the case where one had a Presenter that had an addSubscription:We have found that we required similar checks for
subscriber.isDisposed()
on any async work.For example:
In light of this do you think the BaseRxInteractor should have some kind of
isPresenterAttached()
logic?