Currently, using Observables in Android components that have access to Context (or are themselves) requires one to carefully think about detaching from these sequences as part of the component life-cycle, since otherwise a closure the sequence holds a (strong) reference to might leak the current context until the time the sequence finishes and releases all subscribers.

A good example are configuration changes, where Android first destroys, then recreates an Activity, but observables might still be holding on to a subscriber created within the scope of that Activity. Even with retained fragments that detach from their host activity, it's easy enough to leak the attached context indirectly by holding on to a view first created through that context (every view in Android has a strong reference to the Activity context it was first created in.)

This ticket aims to find solutions to improve this situation, potentially by leveraging newer Android API levels where available, and/or add first class support for newer Java language levels (Java 8/Retrolambda)

Some suggestions that have been made already follow.

Android 14+ APIs

One option would be to make use of Activity life cycle callbacks: http://developer.android.com/reference/android/app/Application.ActivityLifecycleCallbacks.html

This might allows us to unsubscribe once Android is about to destroy an activity.

Java 8 lambdas and Retrolambda

Part of the problem is that every "lambda" in Java 7 or below is an anonymous inner class that will hold a strong reference to the outer class, even if it's a pure function that does not access state outside the lambda. Java 8 + Retrolambda could help here, since pure functions will be materialized as static methods that hold no reference back to their owner.

http://cr.openjdk.java.net/~briangoetz/lambda/lambda-translation.html https://github.com/orfjackal/retrolambda

Weak subscribers

We've taken several stabs at this and always dismissed the solution. The idea was to use WeakReferences to bind subscribers and lambdas. The problem with his approach is that it doesn't work with lambdas, since the only incoming reference would be weak, and they are eligible for GC the instant they're created. There might still be other ways to achieve this, however, I'll leave it open for discussion.

This PR adds a DialogFragment returning an Observable.

This allows for composition of actions over UI interactions (asking a user for data, confirmation etc..)

This is the first PR in a series of backport from work we did. To help with comunication and my refactoring I'll issue the PR one by one as they get merged in or declined.

Problem: Espresso does not know about RxJava's async mechanisms, so it doesn't wait for subscriptions to finish before continuing on to the next testing step. Thereby, Espresso testing when using RxJava does not work out-of-the-box.

Solution: I've created a RxIdlingResource class that tracks subscriptions via a RxJavaObservableExecutionHook plugin and is registered with Espresso as an IdlingResource. This gives Espresso the knowledge it needs to wait or proceed with respect to RxJava background processes.

Also, since registering the plugin has to be done at a specific time in the startup process, I've created an RxAndroidJUnitRunner class that takes care of the setup.

Proposal Since this project seems to fill the gaps between RxJava and the standard Android api's, it seems reasonable to add RxIdlingResource to fill the gap between RxJava and the Espresso testing framework. If everyone agrees that this belongs in the RxAndroid project I can go ahead and create a PR.

Quick poll: anyone here who requires RxAndroid to support Java 6? It would be ideal if we could make a cut and drop Java 6 support. Any JARs built with language level 7 will NOT work with Android apps that are compiled against level 6, since Java 7 introduces new byte code instructions so is not backwards compatible.

The problem is that it's easy to miss that when juggling multiple SDKs and JVMs on your dev machine. I'm using jEnv right now to do that, but we already encountered an issue where a Nebula plugin was compiled and deployed under Java 7 and would fail the RxAndroid build.

Considering that Java 6 has reached end of life, should we support it or not? It's difficult to say, since it definitely took us a while to make the switch to Java 7 on Android.

This is a rough draft, produced from code, I have been using for a while already.

Note, that unlike most other operators in the library OnSubscribeAddAccount is left public to allow people to better adjust it for various needs - the code is already too sophisticated and does too much to try and stuff everything in bunch of static methods.

Before finishing this, I would like to know answers to following questions:

1. How do I test it? Robolectric 2.3 does not have proper shadow for AccountManager, so should I just write my own? By the way, are there plans to update to Robolectric 2.4, perhaps by employing SDK manager plugin to fetch dependencies? I am aware of #1369, but at current rate it is not going resolve itself.
2. What are project guidelines (ok, what should those be) regarding use of annotations? Complex AccountManager methods need @Nullable annotation rather badly, but which one to choose? Android ones? IntelliJ ones (used so far, because they are easiest to get). Perhaps, something more complex (Checker Framework)?

Hi,

I ran into a small issue when releasing into pro-guard.The method AndroidSchedulers.mainThread() makes the subscription to never be called:

This will not work (Hello will never show):

mRestService.login(email, password)
                .flatMap(user -> Observable.zip(
                        mRestService.checkUuid(user._token), 
                        Observable.just(user),
                        (v, u) -> (User) u // Pass user throught
                ))
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(user -> { Log.v(TAG, "Hello") }, throwable -> { });

This works as expected :

mRestService.login(email, password)
                .flatMap(user -> Observable.zip(
                        mRestService.checkUuid(user._token), 
                        Observable.just(user),
                        (v, u) -> (User) u // Pass user throught
                ))
                .subscribeOn(Schedulers.io())
                //  .observeOn(AndroidSchedulers.mainThread())
                .subscribe(user -> runOnUiThread(() -> { Log.v(TAG, "Hello") }), throwable -> { });

I'm using Jack and the latest AndroidStudio Gradle plugin (2.2.2) I've attached my proguard file in case you want to have a look: proguard-rules.txt

Recent changes to UI observables (particularly, 406bf6840fff2a98316faec8702311f9322047aa) added number of POJO event classes as well as some of associated infrastructure. Some of those were really useful, but few others: click, text change and toggle (aka "input") event classes look forced, as if those were added solely to match style of similar methods. Unfortunately, as explained below, they aren't very useful and accomplish nothing, except adding redundant entities and increasing range of possible issues.

Few possible uses for event classes, that come to mind are:

1. Encapsulating state, not stored in event source itself. This is the only sensible use for event classes in Android, which is why OnItemClickEven and OnListViewScrollEvent are legitimately useful and were added for good reason. Clearly not the case for click, text change and CompoundButton toggle events.
2. Storing associated data, for example for doing reduce on it. None of the event classes in question (except OnSubscribeTextViewInput) contain any useful state. Click and compound button switch are self-descriptive. CharSequence, returned by TextView.getText(), can be mutable, and as such, is dangerous to use, unless immediately converted to string (which means, that at least one map call have to be done anyway).
3. Turning emission of same object into emission of multiple distinct objects. RxJava already have timestamp operator for this.
4. Passing those events somewhere else, possibly after serializing them. Doing so with all 3 events in question is pointless and even potentially dangerous. All of them contain little besides strong reference to event source, which makes them potential source of memory leaks, and makes it harder to write Rx plugins, detecting those.

This merge request adds back Observables with tests and corresponding static methods, emitting plain View, TextView and Boolean objects. It also deprecates event-based methods. While we are at it, I have also renamed "input" to "toggle" as original naming choice was just plain bad.

Subclasses of the common Activity and Fragment classes, extended so you can easily get an Observable<LifecycleEvent>.

I wanted to get the ball rolling on this discussion (since it's the second part of #12, as I viewed it). I am fully aware this may be a controversial move. :P

I tried working up a version using ActivityLifecycleCallbacks, but it felt too weird to have one solution for Activity and another for Fragment. Also, watching #84 has caused me to realize there are multiple places where being able to hook into the Activity or Fragment directly will save a lot of boilerplate.

I purposefully chose to not rename the subclasses. That way, when you extend, say, Activity the package resolution dialog will show this version as well.

One conspicuously missing extension is ActionBarActivity, since it depends on #83.

There are possibly improvements that need to be made specific to Android related to CompositeException.

History of the discussion and work on this can be found at https://github.com/ReactiveX/RxJava/issues/1405

This PR changes the default main thread Handler to use asynchronous messaging. This allows us to avoid VSYNC locking that otherwise pushes every post to the next frame.

This works by relying on the new Handler.createAsync factory in API 28, and on pre-28 it will reflectively fall back to a private constructor of Handler (that's always existed) to enable this.

This should give us the original goal of #228 with the safety of still leaning on the main thread looper and not trying to directly run things ourselves and risking deadlocks/trampolining issues.

To use SDK 28, updated the AGP plugin and gradle along the way.

Prior discussion below

~This is a main thread scheduler that's optimized to directly execute given Runnables if it's already on the main thread, rather than always scheduling.~

~Prior art: #228~

~Kept as a standalone implementation right now for review and discussion, but ideally this implementation would replace the existing main thread scheduler implementation as the default.~

After migrating to RxJava2. observeOn doesn't accept AndroidSchedulers. Is there a alternate in Schedulers for AndroidSchedulers.mainThread() or how should i solve this issue ?

OLD versions RxAndroid - 1.2.1 RxJava - 1.1.6

Migrated Versions RxAndroid - 2.0.1 RxJava - 2.0.3

 rxHelper.manageSubscription(
                mDataManager.getProducts()
                .observeOn(AndroidSchedulers.mainThread())
                .subscribeOn(Schedulers.io())
                .subscribe(new SingleSubscriber<List<Items>>() {
                    @Override
                    public void onSuccess(List<Items> products) {
                        getView().hideProgress();
                        if (!products.isEmpty()) {
                            getView().showText(String.valueOf(products.get(0).getName()));
                            getView().showItems(products);
                        } else {
                            getView().showEmpty();
                        }
                    }

                    @Override
                    public void onError(Throwable error) {
                        Timber.e(error, "There was an error retrieving the products");
                        getView().hideProgress();
                        getView().showError();
                    }
                })
        );

OkHttp Dispatcher(48197)

java.lang.NoSuchMethodError

No static method disposed()Lio/reactivex/rxjava3/disposables/Disposable; in class Lio/reactivex/rxjava3/disposables/Disposable; or its super classes (declaration of 'io.reactivex.rxjava3.disposables.Disposable' appears in base.apk!classes3.dex)

1 io.reactivex.rxjava3.android.schedulers.HandlerScheduler$HandlerWorker.schedule(HandlerScheduler.java:91)

2 io.reactivex.rxjava3.core.Scheduler$Worker.schedule(Scheduler.java:402) 3 io.reactivex.rxjava3.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.schedule(ObservableObserveOn.java:161) 4 io.reactivex.rxjava3.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.onComplete(ObservableObserveOn.java:139) 5 io.reactivex.rxjava3.internal.operators.observable.ObservableSubscribeOn$SubscribeOnObserver.onComplete(ObservableSubscribeOn.java:68) 6 retrofit2.adapter.rxjava3.BodyObservable$BodyObserver.onComplete(BodyObservable.java:70) 7 retrofit2.adapter.rxjava3.CallEnqueueObservable$CallCallback.onResponse(CallEnqueueObservable.java:66) 8 retrofit2.OkHttpCall$1.onResponse(OkHttpCall.java:161) 9 okhttp3.RealCall$AsyncCall.run(RealCall.kt:138) 10 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) 11 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) 12 java.lang.Thread.run(Thread.java:929)

What is the problem and how to solve it ?