Movatterモバイル変換

public interfaceObserver<T>

Provides a mechanism for receiving push-based notifications.

When anObserver is subscribed to anObservableSource through theObservableSource.subscribe(Observer) method, theObservableSource callsonSubscribe(Disposable) with aDisposable that allows disposing the sequence at any time, then theObservableSource may call the Observer'sonNext(T) method any number of times to provide notifications. A well-behavedObservableSource will call anObserver'sonComplete() method exactly once or theObserver'sonError(java.lang.Throwable) method exactly once.

Calling theObserver's method must happen in a serialized fashion, that is, they must not be invoked concurrently by multiple threads in an overlapping fashion and the invocation pattern must adhere to the following protocol:

    onSubscribe onNext* (onError | onComplete)?

Subscribing anObserver to multipleObservableSources is not recommended. If such reuse happens, it is the duty of theObserver implementation to be ready to receive multiple calls to its methods and ensure proper concurrent behavior of its business logic.

CallingonSubscribe(Disposable),onNext(Object) oronError(Throwable) with anull argument is forbidden.

The implementations of theonXXX methods should avoid throwing runtime exceptions other than the following cases (seeRule 2.13 of the Reactive Streams specification):

• If the argument isnull, the methods can throw aNullPointerException. Note though that RxJava preventsnulls to enter into the flow and thus there is generally no need to check for nulls in flows assembled from standard sources and intermediate operators.
• If there is a fatal error (such asVirtualMachineError).

Violating Rule 2.13 results in undefined flow behavior. Generally, the following can happen:

• An upstream operator turns it into anonError(java.lang.Throwable) call.
• If the flow is synchronous, theObservableSource.subscribe(Observer) throws instead of returning normally.
• If the flow is asynchronous, the exception propagates up to the component (Scheduler orExecutor) providing the asynchronous boundary the code is running and either routes the exception to the globalRxJavaPlugins.onError(Throwable) handler or the current thread'sThread.UncaughtExceptionHandler.uncaughtException(Thread, Throwable) handler.

From theObservable's perspective, anObserver is the end consumer thus it is theObserver's responsibility to handle the error case and signal it "further down". This means unreliable code in theonXXX methods should be wrapped into `try-catch`es, specifically inonError(Throwable) oronComplete(), and handled there (for example, by logging it or presenting the user with an error dialog). However, if the error would be thrown fromonNext(Object),Rule 2.13 mandates the implementation callsDisposable.dispose() and signals the exception in a way that is adequate to the target context, for example, by callingonError(Throwable) on the sameObserver instance.

If, for some reason, theObserver won't follow Rule 2.13, theObservable.safeSubscribe(Observer) can wrap it with the necessary safeguards and route exceptions thrown fromonNext intoonError and route exceptions thrown fromonError andonComplete into the global error handler viaRxJavaPlugins.onError(Throwable).