Link the on-page add category button now that the dedicated section is working

[teolemon]

What

• Link the on-page add category button now that the dedicated section is working

[monsieurtanuki]

@teolemon Actually I'm a bit stuck here, as I'm a bit in conflict with @cli1005's #2201, the current SummaryPage and #1593. There are contradictory demands about behavior offline or with slow connectivity. And there seems to be a special case with picture upload.

Main question: should it be possible to edit data when offline?
My guess is that the answer is "no". When we edit a product, we save the modifications to the server and get the full refreshed product from the server. If the answer were "yes", it would cause confusion between a local version of the product and the server version, not only for the modified fields but for all the computed fields.

Related question: should we have a different behavior for image uploads?
My guess is that the answer is "yes". There are performances and therefore UX issues with large data like picture upload. And there are already related issues, like #2192 #1724 #1623 #1593 #1398 #917 #863 #513.

[teolemon]

@AshAman999 for the Offline Smoothie reflexion

[AshAman999]

Main question: should it be possible to edit data when offline? My guess is that the answer is "no". When we edit a product, we save the modifications to the server and get the full refreshed product from the server. If the answer were "yes", it would cause confusion between a local version of the product and the server version, not only for the modified fields but for all the computed fields.

For the GSoC 22, https://docs.google.com/document/d/1qRkbZwtkASM3_BNhZSkFEekkhrllddR4Tv69bCdquPs/edit?usp=sharing
It was proposed to enable the offline edit as well,
Somehow, we need to send the changes to the server later on if in case the edits were done in no network zone,

A possible solution that I am thinking of is to keep a queue of the edited tasks
Like keeping in a record probably a SQL-based DB the 1 barcode, the 2 type of edit made (Nutrition table, Nutrients,..etc and, the 3 edited values and sending the changes one at a time when the network connects and deleting from the front

For the case of refreshing the product, we can either update the local cache when we actually send the edits to the server and get the response or maybe precisely when the edit is done(assuming the server returns a successful status ).

That being said, here now comes again the question of the selection #1840 (comment) for no SQL or SQL based DB for offline dump, since a large volume of data is to be dumped, considering that hive might not be a good choice,
thus reducing the possible candidates to Sqflite or moor ( now known as drift)

@monsieurtanuki, @teolemon @g123k , @M123-dev
Should we now switch back to the good old SQL?

[monsieurtanuki]

@AshAman999 Thank you for your message.

What you unfortunately don't deal with are

1. server-computed fields like scores - could be a frustrating experience to change an ingredient in order to make it vegetarian, and not seeing the vegetarian flag set to green
2. the added complexity on the app in read mode - a product is not only the product already stored on the database, but with all the pending changes on top

Regarding the product refresh, we already send the changes and get the fresh product back.

I don't think we're talking about a large volume of data: we're only talking about atomic changes on products. So far I don't see a good reason in disqualifying hive, especially with its "lazy" mode (that we already use successfully for product data) - we could create a new lazy table with the barcode as primary key and the list of each change as field.

Besides, the pictures are dealt with in another issue - there we're talking about

• much bigger volumes (pics)
• much probable use case (pictures in a shop is more probable than changing a single data) (just my experience)

[AshAman999]

@monsieurtanuki Thanks for your reply

I don't think we're talking about a large volume of data: we're only talking about atomic changes on products. So far I don't see a good reason in disqualifying hive, especially with its "lazy" mode (that we already use successfully for product data) - we could create a new lazy table with the barcode as primary key and the list of each change as field.

Apart from not just storing the atomic changes on products, there has been proposed to keep a local DB for the top most used products in a country, that value I am guessing would be a bit large in number is to be done within this 3 months,

Analyzing and looking at your earlier comments left along many PRs I got the conclusion that hive will perform well till the DB is small, but since the local DB dump might be large here the startup time for the app can be big, so to reduce that SQFLite should be bought back.
It's not just for storing the atomic changes but to also make the work smooth even if the offline data dump DB contains more than 3k products for one country(maybe user can want to keep data for another country as well)

server-computed fields like scores - could be a frustrating experience to change an ingredient in order to make it vegetarian, and not seeing the vegetarian flag set to green

I believe we can just a snack bar that the data will be refreshed as soon as they connect to the network, and since we get a full product when we send the changes to the server that means we can then just update the local DB with the same updated details for that barcode/product

Besides, the pictures are dealt with in another issue - there we're talking about
much bigger volumes (pics)
much probable use case (pictures in a shop is more probable than changing a single data) (just my experience)

Had a look at the comments related to work manager there, I think we can upload the full resolution picture to the server till we need it and then have a miniature picture for the local cache or maybe discard the idea for the miniature images in local cache if the sizes become too large and yeah that's another issue for now

[monsieurtanuki]

Apart from not just storing the atomic changes on products, there has been proposed to keep a local DB for the top most used products in a country, that value I am guessing would be a bit large in number is to be done within this 3 months,

Then it's another topic, much more ambitious, that would deserve its own github issue, wouldn't it?

Analyzing and looking at your earlier comments left along many PRs I got the conclusion that hive will perform well till the DB is small, but since the local DB dump might be large here the startup time for the app can be big, so to reduce that SQFLite should be bought back.

That could be tested again regarding hive and the expected size of the database, but indeed with sqflite the startup is immediate, regardless of the size of the database.

It's not just for storing the atomic changes but to also make the work smooth even if the offline data dump DB contains more than 3k products for one country(maybe user can want to keep data for another country as well)

Therefore if it's just about storing atomic changes we can keep hive, if we consider only the size of the changed data.

I believe we can just a snack bar that the data will be refreshed as soon as they connect to the network, and since we get a full product when we send the changes to the server that means we can then just update the local DB with the same updated details for that barcode/product

OK for the warning snackbar.
You still don't address the computed fields like nutriscore until the network is available; you'd better display a very relevant message in your snackbar.

Regardless, my initial questions were just about an "add categories" button, and I don't think we should wait until all your 3K products / sqflite / offline code is merged.
If I sum up there are ambitious expected offline features, possibly merged in the next 3 months, and in the meanwhile we may assume that the network is always available.

[monsieurtanuki]

For the record I'm currently working on a more flutter-ish method, based on providers, in the spirit of https://docs.flutter.dev/development/data-and-backend/state-mgmt/simple