Load possible attributes that can have preferences from the API and cache them

[stephanegigandet]

Smoothie currently shows preferences that are hardcoded (Vegan, Vegetarian, Gluten Free etc.).

They should be loaded from the API instead:

List of all attributes: https://world.openfoodfacts.org/api/v2/attribute_groups?lc=fr (lc indicates the language for the preferences names, descriptions, warnings etc.)

Possible values for each attribute, with translations: https://world.openfoodfacts.org/api/v2/preferences?lc=fr

In order to be able to set / change preferences even if there is no network, the app should cache the possible preferences.*

[monsieurtanuki]

Sounds interesting.

Some remarks:

1. we should start with at least a limited set of hardcoded preferences, to be expanded with what we retrieve from the website
2. what should trigger a refresh of the preference list from the website? In first approach, we could consider that we only refresh the list at app init time. And later think about the iterative refresh process.

[monsieurtanuki]

The main impact will be in user_preferences.dart.

Regarding the importance level, we just retrieve the translations, right, not the list? We would need the colors.

[monsieurtanuki]

• https://world.openfoodfacts.org/api/v2/attribute_groups?lc=en is a list - should we keep the same order?
• should "super-types" like nutritional_quality or ingredients_analysis be displayed, in different colors?

  //nutritional_quality: Nutritional quality
  nutriscore: Nutri-Score
  low_salt: Salt
  low_sugars: Sugars
  low_fat: Fat
  low_saturated_fat: Saturated fat
  //processing: Food processing
  nova: NOVA group
  additives: Additives
  //allergens: Allergens
  allergens_no_gluten: Gluten
  allergens_no_milk: Milk
  allergens_no_eggs: Eggs
  allergens_no_nuts: Nuts
  allergens_no_peanuts: Peanuts
  allergens_no_sesame_seeds: Sesame seeds
  allergens_no_soybeans: Soybeans
  allergens_no_celery: Celery
  allergens_no_mustard: Mustard
  allergens_no_lupin: Lupin
  allergens_no_fish: Fish
  allergens_no_crustaceans: Crustaceans
  allergens_no_molluscs: Molluscs
  allergens_no_sulphur_dioxide_and_sulphites: Sulphur dioxide and sulphites
  //ingredients_analysis:
  vegan: Vegan
  vegetarian: Vegetarian
  palm_oil_free: Palm oil free
  //labels: Labels
  labels_organic: Organic farming
  labels_fair_trade: Fair trade
  //environment: Environment
  ecoscore: Eco-Score

[stephanegigandet]

1. we should start with at least a limited set of hardcoded preferences, to be expanded with what we retrieve from the website

We could do that, for instance we could store the current JSON file. One issue is that it is language specific. I guess we could just display English until we load the language of the user.

2. what should trigger a refresh of the preference list from the website? In first approach, we could consider that we only refresh the list at app init time. And later think about the iterative refresh process.

We can try to refresh the list whenever the user tries to update the preferences.

Regarding the importance level, we just retrieve the translations, right, not the list? We would need the colors.

The server will not set colors, that's more a choice of the client. We could also retrieve the list of names, and not just the translations. That's how the Javascript interface does it on the web site.

https://world.openfoodfacts.org/api/v2/attribute_groups?lc=en is a list - should we keep the same order? should "super-types" like nutritional_quality or ingredients_analysis be displayed, in different colors?

Yes and yes, see #32 for how we should display it.

[stephanegigandet]

@monsieurtanuki : I started something here: https://github.com/openfoodfacts/smooth-app/pull/38 I'm starting Flutter so it may not be the best way to do things, I don't know. Feedback welcome!

[monsieurtanuki]

What I meant about "colors":

• there are different colors for "important", "mandatory"... - if we extract the ["not_important", ... , "mandatory"] and the translations from internet, we should extract their colors too
• there are 6 food preference group ("allergens", ...) and 27 food preferences ("allergens_no_gluten", ...) - it would make sense to visually group them, either in a common Container or with a distinctive color (or both)

[monsieurtanuki]

Regarding food preference group ("allergens", ...): the display is dealt with by #31.

[monsieurtanuki]

I should be able to create a PR tomorrow.

[monsieurtanuki]

The "let's find an up-to-date or a translated version on the server" part of this issue is now in #41.