2.0.0 forces rx/observables about nucleus HOT 7 CLOSED

Hi,

getView() looks like a workaround to me, its elimination was a matter of time.

Do you have a use case for it?

from nucleus.

My presenter calls methods on the associated view, but I'm not using Rx. Ususally just "getView().setFoo( true );" I'm sure I can do the same with the observable returned by RxPresenter.view(), but I'm not using that functionality, so it seems odd to need it. For now I've just defined my own view in my presenter class and am setting it during onTakeView.

from nucleus.

Sounds reasonable.

I was planning to completely drop non-rx part of the library.
Why are you avoiding rx?
For me the perfect presenter looks like a some kind of rx subject, that receives views+requests and emits data.

from nucleus.

I'm mostly avoiding it because:

1. It's ugly, and retrolambda (which cleans it up a bit) seems like such a hack that I'm hesitant to use it.
2. I'm still learning Java/Android, and Rx is like an entire meta-language on top of that.
3. It's confusing as all hell, even after reading a bunch of tutorials.

My understanding, regarding 1), is that this:

getView().setFoo( true );

... will become something like this:

        view().subscribe( new Action1<SomeActivity>() {
            @Override
            public void call( SomeActivity someActivity ) {
                someActivity.setFoo( true );
            }
        } );

That's just ugly, and non-necessary.

from nucleus.

Ok, I've got your point. I do not use retrolambda as well. :)

Do you know that calling getView() everywhere will sooner or later lead to NPE?

You don't need getView during onTakeView, but after onTakeView the view can be dropped at any moment, leaving you with NPE.

Rx guarantee that the callback is called only when getView() is not null. If you're not using rx you will need to make all that callbacks yourself and duplicate rx functionality on your own.

from nucleus.

Regarding NPE, I generally do null checks. If they get too cumbersome, I just wrap the whole thing in an update function that does an early out if getView() is null.

Btw, it looks like RxPresenter calls view.onNext(null); during onDropView. Doesn't that mean a null check within the observable will be necessary?

Regarding Rx in general; I find it difficult to wrap my head around how to handle everything. As an example, one case where I'm using it is: I have a RecyclerView with N objects in it. When you click one, it calls all the way back to the presenter, passing the ID of the clicked object. I needed to debounce those clicks before taking action, and after struggling a bit I ended up with an entire list of PublishSubjects, that mirrors the list of objects, to handle the clicks because I couldn't figure out how to get the debouce to work on a per-ID basis with just a single publish subject or observable.

from nucleus.

Yes, view() requires to make null checks. This observable was first designed to be used by deliverXXX methods internally. Nulls are needed to prevent memory leaks inside of combineLatest, but now I think that I need to split view() into takes() and drops() somehow.

I will keep getView(). I may probably subclass Presenter to make OldSchoolPresenterWithGetView or something. :D

Thanks for the feedback.

from nucleus.