You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Channel.offer will submit a value, and crash if the channel is closed.
An experimental method, isClosedForSend, exists, but is not atomic when combined with an offer afterwards.
I previously used RxJava's PublishSubject to pass data. There, I would subscribe to the subject, dispose it when unneeded, and subscribe again if required. The subject can continue to take in events whether or not it has subscribers. In short, I'd like to produce the same idea with Channels. I'm using BroadcastChannel.openSubscription() or Channel() as a receiver channel, and then closing it when I no longer need events. However, I want the associated SendChannel to continue accepting (and disposing) events without crashing even if the receiver channel is closed.
As a specific use case, I'm using this as a replacement for Android's LiveData. LiveData allows you to submit data from any thread, and you can observe it on the main thread while adhering to an activity's lifecycle. Events sent outside the lifecycle are ignored, and the livedata itself operates like a conflated channel.
Look into using produce as a middle man, where the main SendChannel is never closed, and the producer will only pass values when the lifecycle allows it. I'm not sure if there's a problem with never closing a channel in this case, and this also depends on an obsolete api.
Potentially using a BroadCastChannel in all cases and only closing subscriptions. I have yet to verify this, but I'm also wondering if there's a better solution when I only have at most one subscriber.
The text was updated successfully, but these errors were encountered:
I'm not sure I fully understand your usecase. You mention BroadcastChannel, but it does not seem to have such a problem. If you openSubscription() and then close() this subscription, then the broadcast channel itself continues to work normally and you can still send() to just just like you did to PublishSubject. So what if your actual use-case? Can, you, please, clarify.
My use case more specifically refers to Channel itself, as that is where I get errors. After some more thought, I added the third solution which is to change everything into broadcast channels and use subscriptions. If that is the desired way to go about this use case, then this issue is resolved. Otherwise I was wondering if there's anything else that should be done with Channel.
Currently,
Channel.offer
will submit a value, and crash if the channel is closed.An experimental method,
isClosedForSend
, exists, but is not atomic when combined with an offer afterwards.I previously used RxJava's
PublishSubject
to pass data. There, I would subscribe to the subject, dispose it when unneeded, and subscribe again if required. The subject can continue to take in events whether or not it has subscribers. In short, I'd like to produce the same idea with Channels. I'm usingBroadcastChannel.openSubscription()
orChannel()
as a receiver channel, and then closing it when I no longer need events. However, I want the associatedSendChannel
to continue accepting (and disposing) events without crashing even if the receiver channel is closed.As a specific use case, I'm using this as a replacement for Android's LiveData. LiveData allows you to submit data from any thread, and you can observe it on the main thread while adhering to an activity's lifecycle. Events sent outside the lifecycle are ignored, and the livedata itself operates like a conflated channel.
My relevant stack overflow question is here
Currently, the two solutions I see are:
produce
as a middle man, where the mainSendChannel
is never closed, and the producer will only pass values when the lifecycle allows it. I'm not sure if there's a problem with never closing a channel in this case, and this also depends on an obsolete api.BroadCastChannel
in all cases and only closing subscriptions. I have yet to verify this, but I'm also wondering if there's a better solution when I only have at most one subscriber.The text was updated successfully, but these errors were encountered: