Can you explain purpose of RxJavaPlugins.onSubscribe method in subscribe method of Observable class? Inputs are Observable and Observer and result is Observer.
It allows wrapping the downstream Observer into a custom Observer, allows considering the upstream source's type for the wrapping and at the end, return the wrapper Observer to be subscribed to the upstream.
You can shim behavior after specific operators this way for diagnostic purposes.
Related
I have a function which receives a Publisher and creates a PassthroughSubject that is used to both:
subscribe to the source publisher
send values manually
E.g.:
class Adapter<T>{
let innerSubject=PassThroughSubject<T,Never>()
let scope = Scope() // custom type, Array<AnyCancellable>
func init(_ source:Publisher<T,Never>){
source.register(innerSubject).in(scope)
innerSubject.sink(receiveValue:{debugPrint($0)}).in(scope)
}
func adapt(_ T val){
innerSubject.send(val)
}
}
fn usage(){
let adapter=Adapter(Empty()) // change to Empty(completeImmediately:false) to fix
adapter.adapt(42) // should print 42,
}
The inner subject seems to be cancelled because Empty calls complete.
I would expect the inner subject's subscription to be cancelled, not the subject itself. In .Net at least that's the behaviour - am I missing something? Do I need to wrap this in a broadcasting subject? I thought that Publishers could receive multiple Receivers and multicast to each?
I would expect the inner subject's subscription to be cancelled, not the subject itself. In .Net at least that's the behaviour - am I missing something?
Just like with Observables, when a Publisher emits a completed event, it will not emit any more events. A Subject is a kind of Publisher. The behavior is exactly the same as in .Net so I can only assume you are missing something.
I thought that Publishers could receive multiple Receivers and multicast to each?
Yes they can. But they send the exact same values to each receiver, including the completion event. However, again just like with Observables and Rx Subjects, once it emits a completion event, it cannot emit anything else.
The documentation just says
protected abstract void subscribeActual(Observer<? super T> observer)
Operator implementations (both source and intermediate) should implement this method that performs the necessary business logic.
There is no need to call any of the plugin hooks on the current Observable instance or the Subscriber.
Observable.subscribe comes from the base interface definition in ObservableSource and is the main subscription method for Observables: internal and external components use it to run a flow in a standard way.
However, certain actions may be necessary for all kinds of Observables to be executed before the operator's business logic gains access to the incoming Observer, for example, applying plugin hooks and protecting against crashing subscribe implementations. So instead of requiring every operator to duplicate this preparation logic, they are in a single place and a new abstract method is present to deal with the customization of an Observable.
In my current application, I am using a 'selfmade' Observable class in order to implement the observer pattern. Observers (implementing an interface) can listen to certain events.
I am switching more and more of the project over to using an IoC container, but I fail to find a good place in the code to register the observers with the observable.
The ways to do this that I see are:
A) Inject the observable into the observer.
The constructor shouldn't do actual work, but even with method- or field injection this couples the observer with the observable. This is also the case if it's the other way around.
B) Create an observable factory and do it there.
In this case creating the observable depends on the implementations of several observers.
C) Create the observers by factory and do it there.
While this seems best to me concerning coupling, it turns out bad concerning DRY. In some cases the factory ends up being a copy of the fields and constructor of the observer, plus the observable and plus the one line of code for the registering.
Is there a way to handle this registering in a clean way? If not, are there compelling arguments to use a certain way over the others?
The solution was discovering the difference between Resolve() and Instantiate() methods.
I was always using Resolve(). With that, I would receive an Observer in the way it has been bound to the container.
However, Instantiate() does not care about how the class is bound to the container. It creates the class the standard way, but still injects the dependencies. So this can be used inside the factory for the observer.
I'm newbie to reactivex and rxscala, and can create an Observable like this:
val observable = Observable[String] { subscriber =>
subscriber.onNext("something")
}
I can put new strings to the subscriber inside the Observable.apply.
Is it possible to update the observable outside? I mean, is there any method like putNext:
observable.putNext("another string")
to make me put new things to the existing observable?
If you want to manually control an Observable, you need to use a Subject.
According to the ReactiveX documentation:
A Subject is a sort of bridge or proxy that is available in some implementations of ReactiveX that acts both as an observer and as an Observable. Because it is an observer, it can subscribe to one or more Observables, and because it is an Observable, it can pass through the items it observes by reemitting them, and it can also emit new items.
You can subscribe to a Subject, but you can also pass new elements to it, de facto controlling it manually, which is what you ask for.
Example:
val subject = PublishSubject[String]()
subject.onNext("one")
subject.onNext("two")
subject.onNext("three")
subject.onCompleted()
So I'm pretty new to both Scala and RX. The guy who knew the most, and who actually wrote this code, just left, and I'm not sure what's going on. This construct is all over his code and I'm not really clear what its doing:
def foo(List[Long]) : Observable[Unit] =
Observable {
subscriber => {
do some stuff
subscriber.onNext()
subscriber.onCompleted()
}
I mostly get do some stuff, and the calls to subscriber. What I don't get is, where does subscriber come from? Does subscriber => { instantiate the subscriber? What does Observable { subscriber => { ... } } do/mean?
If you take a look at the Observable companion object documentation, you will see an apply method that takes a function of type (Subscriber[T]) ⇒ Unit. So, when you call Observable{withSomeLambda}, then this is the same as calling Observable.apply{withSomeLambda}
And, if you go all the way to the source code you will see that this is really returning
toScalaObservable(rx.Observable.create(f))
where f is the lambda that you passed in.
So, subscriber is just the parameter of the lambda. It is passed in by the caller of that function.
This code is creating a new Observable as described here.
Basically when a downstream component subscribes to this stream, this callback is called. In the callback we determine when we, as a data source, will call onNext(v: T) which is how we pass each element we are generating to them, and when we will call onCompleted() which is how we tell the subscriber that we are done sending data.
Once you have created an Observable you can start calling Observable operators, which will either result in another, compound Observable, or will result in a terminating condition which will end the process, and generally result in a final result for the flow (often a collection or aggregate value).
You don't use the List in your question, but normally if you wanted to make a reactive stream out of a list you would call Observable.from().
PS: I think this is RxJava code.