Cached events. about otto

[JakeWharton]

Moving this responsibility to the developer was a design decision.

Event caching inside of a bus is a bad idea because it's a great way to
accidentally leak references. With the current system it's perfectly fine
to post events with references to Views, Contexts, Application instances,
etc. because they're distributed but not retained.

Furthermore, an advantage of a producer is that you can update the produced
value as frequently as you want without having to post an event. Or you can
use the fact that a producer is only called when something new is
registered to trigger other events or actions (such as checking freshness
of data and kicking off a background refresh of data).
On Oct 18, 2013 3:32 AM, "Anup Cowkur" [email protected] wrote:

Can we have an option to cache events? The last event can be cached and
the next time a subscriber registers itself, it will receive a copy of that
cached event. We have the concept of producers but the developer has to
maintain his own cache and provide it to the producer. It would be
fantastic if there were an option to automate this.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/97
.

[anupcowkur]

That makes a lot of sense. Maybe you guys can make it an advanced option like ThreadEnforcer.ANY for those who need it. Just a feature request. Thanks for taking the time to reply!

[imminent]

It already has Producer though, don't want to have 2 similar features in a library, makes things complicated for users of the library. Which do I use? What's the difference? Etc. It's not that events can't be cached already, it's that the event bus WON'T maintain said cache. So, unlike ThreadEnforcer.ANY (which removes the feature of checking the Thread that an event was posted on) Otto already handles both cases of cached events and non-cached events without any configuration.