This PR resolves an issue related to the order of the bind operations that, in some cases, causes missing events due to the producer producing the events before the binding happens.
The idea is to accumulate the events until all the connections are bound and the subscriptions happen.
On the one hand, the MviCore library does not know about the Observable until we call the bind method. A new component called AccumulatorSubject helps to accumulate the events produced by an Observable until told to stop doing so and drains all the accumulated events. In this case, until all the Connections are bound. On the other hand, a UnicastSubject inside the Binding also collects the events once the Consumer subscribes to Observable.
The reason behind adding UnicastSubject in the middle is that there might exist bounded but not subscribed connections. So if all the bindings are bound, we can drain them but keep the not-consumed events in UnicastSubjects.
Because the UnicastSubject accepts only a single Observer, and the Binder class is reusable for the same Lifecycle object (we can call the start and stop operations multiple times), it creates a new instance for each binding every time we invoke the start method of the Lifecycle.
Also, due to the usage of multiple instances of Binder for subscribing to different Lifecycle events, we keep track of all the Binder instances. We may use the same Observables as the source in distinct Binder instances. So, once we bind all the connections from all the Binders, we can drain the AccumulatorSubjects.
This is not the final solution, just an ideation around a possible one
This PR resolves an issue related to the order of the bind operations that, in some cases, causes missing events due to the producer producing the events before the binding happens.
The idea is to accumulate the events until all the connections are bound and the subscriptions happen.
On the one hand, the
MviCore
library does not know about theObservable
until we call the bind method. A new component calledAccumulatorSubject
helps to accumulate the events produced by anObservable
until told to stop doing so anddrains
all the accumulated events. In this case, until all theConnections
are bound. On the other hand, a UnicastSubject inside theBinding
also collects the events once theConsumer
subscribes toObservable
.The reason behind adding
UnicastSubject
in the middle is that there might exist bounded but not subscribed connections. So if all the bindings are bound, we can drain them but keep the not-consumed events inUnicastSubjects
.Because the
UnicastSubject
accepts only a singleObserver
, and theBinder
class is reusable for the sameLifecycle
object (we can call thestart
andstop
operations multiple times), it creates a new instance for each binding every time we invoke thestart
method of theLifecycle
.Also, due to the usage of multiple instances of
Binder
for subscribing to differentLifecycle
events, we keep track of all theBinder
instances. We may use the sameObservables
as the source in distinctBinder
instances. So, once we bind all the connections from all theBinders
, we can drain theAccumulatorSubjects
.This is not the final solution, just an ideation around a possible one