Hide the search env switcher by default

[g123k]

Hi everyone!

For the next release of the app, we still want to keep some parts of the OxF integration (with the scanner for example), but we're not ready to promote it yet.

That's why we want to hide the OxF switcher from search:

However, hiding doesn't mean removing it all.
In the preferences, the idea is to add a switch to hide/show the swicher (default value: invisible).

[monsieurtanuki]

That goes beyond hiding those radio buttons: barcode search are performed on all OxF.

[g123k]

That goes beyond hiding those radio buttons: barcode search are performed on all OxF.

We will keep barcode search because @stephanegigandet will provide a unified API next week.
The idea is that we don't want to explicitly show that OxF is in the app, but if you scan something, it will be a surprise.

[monsieurtanuki]

The side-effect may be to consider all products as food, cf. dao_product.dart.
Which isn't the goal, I guess.

[g123k]

The side-effect may be to consider all products as food, cf. dao_product.dart. Which isn't the goal, I guess.

Mmmm, I've been thinking about your comment for 2 days.
The goal here is the same as selecting food in the current switcher.

What could go wrong?

[teolemon]

If we search for food by default, product_type will be food ?

[monsieurtanuki]

If we search for food by default, product_type will be food ?

Whatever we find on the food server will be considered food in Smoothie. Same for beauty, ...

I had the impression that @stephanegigandet's work ("unified search API") would make it possible to look for a barcode on the food server and to retrieve potentially a beauty product. If so it will be considered as food in Smoothie.
Maybe I misinterpreted.

Next steps would be anyway:

• for the server to provide the product type field in the Product json
• in the Smoothie code to be more flexible - if the Product already has a product type, not overwritting it with the server expected product type

[g123k]

If we search for food by default, product_type will be food ?

Whatever we find on the food server will be considered food in Smoothie. Same for beauty, ...

I had the impression that @stephanegigandet's work ("unified search API") would make it possible to look for a barcode on the food server and to retrieve potentially a beauty product. If so it will be considered as food in Smoothie. Maybe I misinterpreted.

Next steps would be anyway:

• for the server to provide the product type field in the Product json
• in the Smoothie code to be more flexible - if the Product already has a product type, not overwritting it with the server expected product type

Yes, a universal API for scanning (by barcode) will be available this week.
So the idea is to implement it in the app as soon as possible (it's blocking the release).
In other words, barcode scanning will support OxF (but we won't tell it explicitly in the app).

The same goes for product addition, where we can add a product on OxF.

However, here for the search env switcher, the idea is that we can only search for food (just like if "Food" was selected for all queries).

I know we can have some edge cases, where the full-text search wouldn't find a beauty product… But, once again, we already have the issue with the switcher.

[monsieurtanuki]

Then I did understand well and there are 2 issues to fix.

There's no ProductField called "product_type" - we don't retrieve that info from the server, which definitely forces Smoothie to consider all products from the food server to be food.
I'm currently working on the fix in off-dart, as the field seems to exist on the server.

In Smoothie, we must now retrieve that new product field, and not overwrite that field provided by the server with the "natural" product type related to the server (in our case, "food").

[g123k]

👌
We will notify you when the universal API will be available

[teolemon]

Ah ok, I thought we auto added product_type based on the pressed button, or the server base url as a stopgap measure.

[monsieurtanuki]

Ah ok, I thought we auto added product_type based on the pressed button, or the server base url as a stopgap measure.

For barcode search we loop on all 4 servers, stopping the first time we find something, and set the related server product type.
For text search we use only one server: the one of the selected product type.