Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature/#551 - towards a refresh of stale data on the Product page #571

Closed

Conversation

monsieurtanuki
Copy link
Contributor

New files:

  • product_timestamp.dart: Abstract timestamp getter for Product.
  • product_timestamp_list.dart: List of ProductTimestamps.
  • product_database_timestamp.dart: Product timestamp taken from the local database upsert timestamp.
  • product_off_timestamp.dart: Product timestamp taken from the "last modified" OFF field.

Impacted file:

  • product_page.dart: added a check on the product timestamp, with the goal of stale data refresh

…oduct page

New files:
* `product_timestamp.dart`: Abstract timestamp getter for Product.
* `product_timestamp_list.dart`: List of ProductTimestamps.
* `product_database_timestamp.dart`: Product timestamp taken from the local database upsert timestamp.
* `product_off_timestamp.dart`: Product timestamp taken from the "last modified" OFF field.

Impacted file:
* `product_page.dart`: added a check on the product timestamp, with the goal of stale data refresh
@override
Widget build(BuildContext context) {
final LocalDatabase localDatabase = context.watch<LocalDatabase>();
final AppLocalizations appLocalizations = AppLocalizations.of(context)!;
if (_first) {
_first = false;
_product = widget.product;
_refreshIfNeeded(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be done inside a lifecycle method like didChangeDependencies().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know didChangeDependencies().
I'm not sure I understand the notion of "change dependencies"; in my mind I just want the code to be called once, for the first build, and that's it.

@@ -47,6 +51,7 @@ class ProductPage extends StatefulWidget {

class _ProductPageState extends State<ProductPage> {
late Product _product;
static const Duration _duration = Duration(minutes: 5);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sugg: _refreshInterval

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough.

@@ -73,13 +78,35 @@ class _ProductPageState extends State<ProductPage> {
_updateHistory(context);
}

Future<void> _refreshIfNeeded(final ProductTimestamp productTimestamp) async {
final int? millisecondsSinceEpoch =
await productTimestamp.getTimestamp(widget.product);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be simpler to just take the maximum of product.lastModified and DaoProduct(localDatabase).getLastUpdate(product.barcode) instead using all that abstraction? Or do you expect the ProductTimestamp hierarchy be useful anywhere else?

Copy link
Contributor Author

@monsieurtanuki monsieurtanuki Sep 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could probably manage to code that without abstraction, but it's not the way I code.
I do expect the ProductTimestamp to be used in a different use case: the timestamp for this product on the server. So far we deal with product "staleness" - and we could also deal with the product "freshness" on the server.

final int elapsedInMillis = nowInMillis - millisecondsSinceEpoch;
print('last modified was ${elapsedInMillis ~/ 1000} seconds ago');
if (_duration.inMilliseconds < elapsedInMillis) {
print('should refresh');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you intend to update this before merging?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely.
For the moment @stephanegigandet and I disagree about the way to refresh data: he would refresh automatically, and I would display a snackbar saying "This product data is 6 minutes old" / "Refresh action".
I'll probably implement the former or the latter, and if needed the code conversion from one version to the other shouldn't be problematic afterwards.

@M123-dev
Copy link
Member

I haven't read through the code yet, but I assume that when the product page is opened, the last modification time of the cached product is compared with the backend and updated if necessary. Am I correct with this assumption

@monsieurtanuki
Copy link
Contributor Author

I haven't read through the code yet, but I assume that when the product page is opened, the last modification time of the cached product is compared with the backend and updated if necessary. Am I correct with this assumption

No you're not.
Actually we don't call the backend at all for the moment.
For the moment we compare the database timestamp (local database upsert statement) and the OFF product last-modified field (I mean the product already in the local database). As I also suggested, we could have a look at the last modified field on the backend but it's not the case right now.
And given those timestamps, we can decide to refresh the local copy of the product from the backend data (instead of the current print statement that @slava-sh correctly flagged as "not to be merged"). Either because local data is stale, or because backend data is fresher.

@monsieurtanuki
Copy link
Contributor Author

This is the way it looks with the Snackbar of the latest commit:
Screenshot_2021-09-11-09-00-53

@M123-dev
Copy link
Member

Thanks for the explanation @monsieurtanuki, I understand your thought behind the PR but I don't think the current way makes that much sense. Just because the data is stale doesn't mean it's out of date. The idea to pay attention to the time is good in any case, I started #573 to discuss how and what we want to cache so that we hopefully come to a final concept.

@monsieurtanuki
Copy link
Contributor Author

Dismissed as in contradiction with #573.

@monsieurtanuki monsieurtanuki deleted the feature/#551 branch September 13, 2021 15:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants