-
-
Notifications
You must be signed in to change notification settings - Fork 279
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/#349 - history and scan lists now have displayed timestamps #401
feature/#349 - history and scan lists now have displayed timestamps #401
Conversation
… timestamps History and Scan lists now behave differently from the other lists. They use "extra data": a product is in the History (or the Scan) list if it has as an "extra data" the "last seen timestamp" (or the last scan timestamp). Bad news: as it's a new concept in the app, we'll start from scratch for both lists. Impacted files: * `continuous_scan_model.dart`: new way of adding a product to scanned products; refactoring * `continuous_scan_page.dart`: unrelated color fix * `dao_product.dart`: added "last seen" and "last scan" as extra data, with a direct access to products that have those extra data * `dao_product_list.dart`: history and scan lists are now handled as "different" lists, computed from the "last seen" and "last scan" extra data; refactored * `product_list.dart`: added extra `int` data; cleaner "same product list" test * `product_list_dialog_helper.dart`: cleaner "same product list" test * `product_list_page.dart`: added dates to the display * `product_page.dart`: simplified history management * `smooth_product_card_found.dart`: added an optional `refresh` parameter, after visiting the product page
Thanks for the pr @monsieurtanuki, I don't think have a proper understanding of the part of the code, so I can't follow exactly what is happening, but there is nothing that catches my eye. I'll trust you on that.
What exactly has changed now, if I remember correctly we had only the normal lists in a db the rest in shared preferences. Has something changed in the db or in the anyway temporary shared prefs code? |
Hi @M123-dev Regarding the database, we store single products in the In this PR, we don't use The idea here is to say: we don't maintain explicit product lists for history and scan, let's use the additional Doing so:
TL;DR |
@M123-dev Actually I'll probably update this PR today, preparing the refactoring that will later include shopping lists and pantries. |
@M123-dev @stephanegigandet @teolemon The main question that blocks me: does that make sense to see a product several times in the same list? |
Hey, catching up, sorry.
|
@monsieurtanuki I would say it depends on what kind of list. In pantries and normal lists not really, but in the history I would say it definitely makes sense. When we look at Google Maps as example, when I look at a place there is sometimes a field "Last visited: xx.xx.xxxx". But you can also go and and visit the whole history, there double entries make sense in any case. We have to choose what is our goal with the history. At least for me I am not that interested when I last saw a product in a store (and scanned it) but more what the name of the product I scanned last week was. |
@teolemon @M123-dev Thank you guys for your answers. Basically you say that it's needed to be able to store the same food several times in the same list - I'm lucky I asked because that was not my point of view at all. @teolemon By the way I'm not storing product data history at all, just one version of the product (the latest) for a given barcode. And pictures are not cached at all either. |
@monsieurtanuki : I think it would indeed make sense to use the same mechanisms (and the same code) for all types of lists, scan history, favorites, pantry, food intake tracking etc. Regarding the discussion between having multiple entries for one product, or only one: both use cases are interesting. And for pantry, it's even clearer that we need both: it's very interesting to see the current inventory of the items we have, and it's also very interesting to look at the history to see how many products we purchased in a month etc. An easy and generic solution is to have two tables:
It's like a bank account: we have the balance, and also the history of all transactions. |
Thank you @stephanegigandet for your comment. You're right, it's better if we find tables that fit many purposes. I'm not a big fan of a transaction table, as I cannot visualize currently clear use cases (except for food maniacs). My suggestions regarding tables:
With the custom json string, we can do whatever we want. What do you guys think of that? |
@monsieurtanuki I think the idea is quite good, especially that we then only have to write a list code. But I would recommend that we add a type parameter to product_list which specifies what type of list we are using. What do you think about also adding a string with json data to every product in the product table. In which then the scan timestamps and product page timestamps will be stored, because they are universal and not per list |
For the transactions, a very important use case is to be able to see one's consumpting over time, e.g. month to month. How many products I have eaten? How many packagings I have generated? Is the average Nutri-Score of food products I buy going down or up? Am I eating less and less meat? etc. Even when scanning products, it's very useful so that you can say things like "You last bought this item on June 20th 2020". And that's just obvious use cases, being able to look up history certainly opens many more use cases. Regarding performance issues: I'm not very worried. There won't be a lot of transactions, and even if someone has 100 000 transactions (that's 10 products added or removed every day for 3 years), that wouldn't be a big problem... |
@M123-dev My answers:
@stephanegigandet We do agree, the use cases for a transaction table is for food maniacs and have not even been remotely mentioned in issues so far. I don't reject the concept, but it's not a priority at all. And even the way you see things, we'll need both aggregate tables (like now) and transaction tables: whatever I'm coding for aggregate tables is not going in the wrong direction. Later we'll have to add transactions aside, in new tables. |
@monsieurtanuki makes sense, I wasn't thinking about the history list, but rather when a known product was last scanned/opened. But I completely lost sight of the history list there.
@stephanegigandet, we should also be able to get these data with the current proposal from @monsieurtanuki. If we add tracking functionality later, it would probably be better to create a list for products bought and a list for products eaten, rather than looking at when they were removed from a list. Especially the eaten list will also need a parameter for how much of a product has been eaten. |
Agreed. |
…y and scan timestamps In table `product_extra` we added an `int` column: * the primary keys are barcode and "extra key" (e.g. an id for each different list) * there is an `int` value and a `String` value * the `int` value is used for ordering data (timestamps or 1,2,3,...) * the `String` value is used for storing more complex data as json (e.g. the list of timestamps for history) The contents of table `product_extra` can be stored in flutter code with the new class `ProductExtra` (basically, `int` and `String`) For the moment the history and scan timestamps of each product are available via a lousy button at the end of the page. New file: * `product_extra.dart`: Extra data attached to a Product when it belongs to a ProductList Impacted files: * `dao_product.dart`: added an `int` column to the product extra table; now we use new class `ProductExtra`; refactored * `dao_product_list.dart`: now we use new class `ProductExtra`; refactored * `local_database.dart`: upgraded the db version because of a new column; added helper method `timestampToDateTime` * `product_list.dart`: now we use new class `ProductExtra`; refactored * `product_list_page.dart`: now we use new class `ProductExtra` * `product_page.dart`: added a sample button at the end of the page in order to display all history and scans related to the product
I suggest that we also store the "refresh from web" timestamp for each product, in a similar way as history and scans. If you're ok with that, I can add this feature (just the new historical data, not the refresh policy) and merge the code. |
@monsieurtanuki good idea, I don't see any point against the implementation of that. |
…refresh timestamps New files: * `abstract_dao.dart`: DAO abstraction * `dao_product_extra.dart`: DAO for Product Extra data Impacted files: * `barcode_product_query.dart`: automatically storing the product in the database * `continuous_scan_model.dart`: refactored * `dao_product.dart`: now extends new class `AbstractDao`; moved code to new class `DaoProductExtra`; refactored; optimized bulk actions * `dao_product_list.dart`: now extends new class `AbstractDao`; now using new class `DaoProductExtra`; removed a SQLite foreign key for performance reasons; not storing products anymore (it's done somewhere else) * `database_product_list_supplier.dart`: refactored because of `ProductListSupplier` * `local_database.dart`: new database version; added `DaoProductExtra` * `main.dart`: more verbose database crash message * `product_dialog_helper.dart`: minor refactoring * `product_list_supplier.dart`: refactored * `product_page.dart`: now we display the access, the scan and the refresh timestamps in the lousy temporary button * `product_query_model.dart`: removed the code regarding storing products in the database as it's now done in the `QueryProductListSupplier` * `product_query_page.dart`: minor refactoring * `product_query_page_helper.dart`: refactored because of `ProductListSupplier` * `query_product_list_supplier.dart`: automatically storing the products in the database; refactored because of `ProductListSupplier`
I've just added the "server refresh" timestamp history. I left the ugly "timestamps" button at the bottom of the product page, at least temporarily, in order to be able to check the different timestamp lists and to think about how to display those timestamps with more subtlety. Feel free guys to remove that button. I don't think there are many developers here ready to check my SQL code; if you don't mind I'll merge this PR without explicit approval by the end of the week. Then I'll go on with the database refactoring (#166), that will make the following things possible:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this (very huge) PR @monsieurtanuki this data is very nice to have.
I have not read any line in detail but the main picture looks good. Feel free to merge.
Such button should be no problem for development purposes, how and where we display the data has to be discussed anyways.
…refresh timestamps Impacted file: * `continuous_scan_model.dart`: minor private variable renaming
Thank you @M123-dev for your comments! |
History and Scan lists now behave differently from the other lists.
They use "extra data": a product is in the History (or the Scan) list
if it has as an "extra data" the "last seen timestamp" (or the last scan timestamp).
Bad news: as it's a new concept in the app, we'll start from scratch for both lists.
Impacted files:
continuous_scan_model.dart
: new way of adding a product to scanned products; refactoringcontinuous_scan_page.dart
: unrelated color fixdao_product.dart
: added "last seen" and "last scan" as extra data, with a direct access to products that have those extra datadao_product_list.dart
: history and scan lists are now handled as "different" lists, computed from the "last seen" and "last scan" extra data; refactoredproduct_list.dart
: added extraint
data; cleaner "same product list" testproduct_list_dialog_helper.dart
: cleaner "same product list" testproduct_list_page.dart
: added dates to the displayproduct_page.dart
: simplified history managementsmooth_product_card_found.dart
: added an optionalrefresh
parameter, after visiting the product page