Closed avishail closed 1 year ago
In the end I managed to solve this like this:
I have a source of truth List A
when starting to refresh I'm turning on a boolean and when finish I'm turning it off.
in case I need to update the data as a result of my refresh, I'm calling the pagingController.refresh() and then making sure when _fetchPage is being called then I'm returning my source of truth.
On my _fetchPage method, I'm checking if the boolean is turned on and if so, I'm simply returning without adding any page to the pagingController.
Future<void> _fetchPage(int pageKey) async {
if (refreshIsRunning && pageKey != 0) {
return Future.value();
}
try {
final activities = pageKey == 0
? await _dataProvider.fetchInitialActivities() // this will return my source of truth list if it is not empty, or will trigger fetchMoreActivities if it is.
: await _dataProvider.fetchMoreActivities();
if (refreshIsRunning && pageKey != 0) {
return Future.value();
}
if (activities.length < 20) {
_pagingController.appendLastPage(activities);
} else {}
_pagingController.appendPage(activities, pageKey + 1);
} catch (error) {
_pagingController.error = error;
}
}
Same issue here, it would be nice to solve it without a hacky workaround
@avishail and @csondi10, this isn't in the package's scope. The problem here is how you're handling your concurrent requests – reason why you easily solved it on your end. There's no way for the package to cancel your ongoing request if it's not in control of that code, right? Depending on how you set up your state management and API calls, that bug doesn't happen.
@EdsonBueno , I do not expect the package to cancel the outgoing requests but I do expect it do disregard the content fetched.
I expect results started prior to reset to be dropped by the infra when they come back. I did it manually and I think you should do it in the package.
The way you add canceled and valid content is the same. How's the package supposed to know? The package does two things: display items and request them. You're in charge of the rest.
I do not 100% understand your question, but you can maintain a counter and each refreah will increase it. On every page fetch you attach the counter's value and disregard the reault in case it doesn't match the current counter.
@EdsonBueno This should be stated clearly in the documentation for refresh. Would be open for a PR that would document:
Resets [value] to its initial state. Page requests that are currently running won't be canceled by calling refresh.
The fact proves that the Android Paging library can solve this problem very well.
PageRequestListener should return a Future type and should operate on data within the library, not allowing the controller to set data.
Kotlin coroutines can be easily cancelled, but how can Dart's Future be cancelled? This is a problem.Developers should not have to deal with such tedious matters.
I'm facing a bug where when I'm pulling to refresh (_controller.reset()) while the next page N is being fetched, the final result is messy and composed of a mix of the the new page after the reset and the result of the fetched page N.