Migration to Navigator 2.0

[g123k]

What

• As a requirement of Handle openfoodfacts.org links (Add deeplinking towards the product page) #920, we need to use the good old Navigator 1.0 with named routes or switch to Navigator 2.0.
• I suggest the second solution and use GoRouter, as it seems to be the best solution on the market.

Feel free to comment if you have better ideas.

Before starting, here are the required steps:

• Identify a library
• List all internal routes

Part of

• Distributing the app widely (tracker) #2515
• Handle openfoodfacts.org links (Add deeplinking towards the product page) #920

[monsieurtanuki]

Feel free to comment if you have better ideas.

I don't have better ideas but I feel free to comment all the same :)

As far as I understand the way GoRouter works, that means that all our pages should be similar to a URL, for instance /product/12345 for product page with barcode 12345. That's fine by me.
Be careful with the awkward home page with 3 tabs; that's probably not going to be the easiest part.
Good luck!

[M123-dev]

Yes I share the same opinion. It will certainly not be the easiest undertaking but is probably unavoidable for some things.
If you have any question about any design decisions feel free ask

[g123k]

@monsieurtanuki That's exactly what you've described. I think I will list all the possible routes before starting anything.

I know, this will take some time to develop, but when it will be done, the app will be fully compatible with web (even if that's not a priority) and able to handle deep links.

[teolemon]

It's also very important to acquire user at scale. We have 2 M monthly visitors on the mobile website, and web browsers can offer to install/open the app with associated URL schemes

[monsieurtanuki]

@teolemon Probably that means that the website URLs must match the app route URLs. Is that possible?...

[g123k]

I am not fully sure that it would be a nice idea to have the same routes, as the navigation within the app will be different.

Basically, it's the same as using the same models between an API and the UI. The day we have an external change, we shouldn't be impacted.

[monsieurtanuki]

@g123k I'm not saying it would be a nice idea: it's rather a fear that we will need that. Without that I don't know how you can expect a URL to be correct on the website and correct also on the app as deep link so that it will trigger the app download (if relevant) and the display on the app of the correct page. But I've never implemented deep link, I'm probably missing something :)

[teolemon]

@monsieurtanuki we just grabbed the barcode in the native versions.
we then had something like app://whatever:barcode
https://github.com/openfoodfacts/openfoodfacts-androidapp/pull/2862/files

[monsieurtanuki]

@teolemon Now with the code I remember more or less: the first thing is to catch the intent from a root URL (e.g. https://smoothie.org/) and then to extract the parameters from the full URL in order to know which page we should display. Therefore no need for the website URLs and the app route URLs to be identical, as long as you code the transformation from the former to the latter.

[monsieurtanuki]

@g123k Still working on it? I've just had a look at Sentry reports that all refer to the same spot, and I guess implementing a more refined navigation would be rather helpful.

[g123k]

Yes, I will (re)work on it ASAP.
This feature was judged non essential for the initial release, but now it is

[teolemon]

• Let's continue discussing in Handle openfoodfacts.org links (Add deeplinking towards the product page) #920, too many duplicate issues ;-)