Hello, I have a question about `replay` and `repl...
# coroutines
u
Hello, I have a question about
replay
and
replayCache
in
SharedFlow
. As far as I know, this parameter is designed for any new coming collector to be notified about some data emitted eariler. But I have no idea why it is designed as Int, is there any concrete use case that exactly 5 old emittions should be replayed to new collector, not all of the outdated data?
x
I'm gonna go with a classic here: "It depends". Different use cases may have different requirements. If what you want is to retrieve all the previous emitted elements, you can set
replay = Int.MAX_VALUE
u
Of course,
replay = Int.MAX_VALUE
meets my use case. But I want to know in which use case we need to set replay as a specific int value, not 0 nor Int.MAX_VALUE
w
the question you have to ask yourself is can you afford that much memory to keep an ever-growing buffer of previous data (including making those objects and everything they hold on to ineligible for garbage collection). And even if yes, then what would happen after you reach some max_value? Your assumptions about keeping all data would break anyway. So what I'm saying is... maybe you need to rethink what you're trying to achieve and use a better suited tool for it, such as a database or other form of persistence? or design for built-in resilience to lost data
u
Sorry for not making myself clear. There is 3 cases for replay parameter: 1. 0 for most cases, that nothing should be replayed. 2. Int.MAX_VALUE for some cases if someone needs to acheive data consistance, though it might not be a good choice. 3. A specific int value, that is what makes me confused, partial replaying outdated data can lead to data inconsistance, and if you dont need to rebuild latest state from them, why no making it 0? So i want some concrete use case of case 3 for better understanding of replay cache.
w
Oh ok, one idea I could come up with is imagine you're showing a UI of incoming data (news feed, sensor readings, whatever). If the user navigates away from that screen then comes back, it might be nice to populate the UI with a page of previous data (so .. 5-10 items for example?) immediately, while the feed resumes its operation and starts reading new items
u
Thanks, this makes sense to me.