-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Lossless event delivery #109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Added support for lossless event delivery
Should not break, to avoid sending the event to just one of the subscribers.
|
A sticky event does not fulfill your use case? |
|
It's not exactly the same use case, it's for the cases where I do not know that there are no listeners (yet). The only way I could do it, is to always use sticky events, and remove them as soon as the first listener receives it. Although I understand your doubts in merging, as it can cause the list of events to grow indefinitely if some event doesn't get a listener which can create a very tricky bug. |
|
I recommend not merging this. This duplicates the sticky events functionality without adding anything new. Accomplishing what you are trying to do here would be to utilize sticky notifications, and your subscribers will still get the notifications after they initialize |
An event can now be: - Resubmitted and cancelled the equal running events - Resubmitted and ignored if that are equal running events - Cancelled when running
Conflicts: EventBus/src/de/greenrobot/event/EventBus.java
Added support for lossless event delivery
This way if the flag is set to true, the event is only delivered and deleted from the queue whenever a matching subscriber is registered.