greenrobot
Trigger ALL sticky events on registerSticky()
It would be great if registerSticky() method trigger ALL sticky events current class is subscribed to. My case: activity (sender), and fragment (built into layout) inside it (receiver). Activity sends bunch of events from onCreate, but, of course, they should be posted as sticky as there still no live fragment. When fragment is fully created it is registered to the EventBus, but now I have to check if there are sticky events for ALL event types this fragment is subscribed to. Very ugly. It would be much better if registerSticky() trigger delivery of all sticky events sent to current class.
registerSticky does deliver all sticky events. Is it a timing issue on your side?
If you think there's a bug, please try to isolate it.
According to the method description and to the (as far as I understand it) code, registerSticky delivers only one (last?) sticky event for current subscriber:
Like register(Object), but also triggers delivery of the most recent sticky event (not events) (posted with postSticky(Object)) to the given subscriber.
if (sticky) { Object stickyEvent; synchronized (stickyEvents) { stickyEvent = stickyEvents.get(eventType); } if (stickyEvent != null) { postToSubscription(newSubscription, stickyEvent, Looper.getMainLooper() == Looper.myLooper()); } }
But as far as I understand there can be more than one sticky events if they are of different types.
I agree too! If only the last sticky event delivered to the subscriber, it means sometimes maybe miss some useful event!
Meaning, keeping a queue of sticky event per event class. And then, we would need, methods for
- clearing this queue (per event class)
- get all events
- get last event
Does anyone knows of a fork based on version 3 that implemented this ?
Or maybe, just keep a counter of how many sticky events were fired, until a subscriber subscribed to this event class instance. So, saving only the last one, BUT knowing there were more, a user can decide to take some extra steps in, say, refreshing a view.
Sounds to me like you need proper persistence (a queue), like a log file or database. Or as said above, create an in-memory queue that you access if required. -ut
Yes, i started a few commits on my fork. After i create something that works, I will post it here, or create a pull request. So If it is in compliance with your code, other may benefit from it.