Receiving updates question

[slaci]

Receiving updates question

[781flyingdutchman]

Hi, thanks for your feedback - this really does make the plugin better, so keep it coming!

I suggest adding a BroadcastStream, so in addition to updates there would be updatesBroadcast and we add the update to both streams if they have listeners. That way you can choose, and understand the risk of missing updates if you're not listening. Changing the type of the updates field would be a breaking change and for most users is unlikely to be an improvement. What do you think?

I'll add unregisterCallback.

[slaci]

Well broadcast streams don't buffer the events, so it would not degrade performance too much if its not used. In contrast the updates stream would buffer (if someone just uses the broadcast).

Make it possible to close the updates stream controller?

An easier solution would be to allow to close the updates stream controller. Currently destroy does this. That does other things too, I haven't checked what exactly, but it is possible its the right way for me currently (as I want to use the downloader on specific screens only). If those other cleanups don't make sense, then a dispose() method may be a good candidate which closes the streamcontroller and creates a new one). That may cleanup callbacks too. My usecase does not need a broadcast tbh.

If you would go with the broadcast:

Honestly I would deprecate the updates getter and replace it by an updates() method (or something), which can take params. The updates getter could call this method in a backward compatible way. The method could have an asBroadcast bool named parameter.

That would help with other things, that maybe also problematic (maybe not). When I was experimenting with resumeFromBackground() I couldn't find a good spot to call it when using the updates stream and bloc. Well, I'm still not sure what that method does exactly, but it dispatches updates, so you need to listen for those updates beforehand (as stated in the docs). Eg:

await resumeFromBackground();
await emit.forEach(updates, (update) {
  // too late (or maybe not because of buffering; but if you use broadcast, then too late for sure)
});
await resumeFromBackground();
// this won't run as `await emit.forEach` will hold the execution until the stream or bloc is closed 

For this the updates() method could take an onListen callback, or just something specific param which calls resumeFromBackground in the onListen method of the stream controller and it wouldn't depend on the buffering.

Just writing down my ideas, maybe they don't make sense, but these are the things I was struggling a little bit.