Navigate to a promoted page (#548) - #50
Conversation
| val nativeRoutes: Map<String, Screen> = mapOf( | ||
| "/#/settings" to Screen.Settings, | ||
| "/#/notifications-welcome-page" to Screen.Onboarding | ||
| ) |
There was a problem hiding this comment.
Il serait peut être interessant que ce soit le back ou la webapp qui ai connaissance des urls et/ou du mapping afin de nous permettre de changer ces urls dans le front sans impacter l'application mobile et nous forcer à une nouvelle version.
There was a problem hiding this comment.
J'espère qu'il y aura moins de changement d'url dans le front que de pages promues côté Android et côté iOS.
Par ailleurs ma compréhension des discussions d'architecture en ce moment vont dans le sens d'un "contrôle" qui serait côté mobile natif, et non webapp. Il en découle que la décision de promouvoir une page, et le mapping qui y est associé (url -> écran natif), est de la responsabilité de l'application native, non de la webapp.
Si la responsabilité était côté webapp, il faudrait y stocker le mapping en double, pour chaque plateforme native, et trouver un moyen de sérialiser ce mapping, puis déserialiser côté natif : c'est un ajout de complexité pour résoudre un problème que j'espère rare (le changement d'url côté front).
Fixes numerique-gouv/ami-notifications-api#548
Avant, avec le flash (presque imperceptible) de l'affichage de la page web d'activation des notifications, avant d'afficher la page native :
screen-20260407-182725-1775579237746.mp4
Après, sans le flash :
screen-20260407-182625-1775579178022.mp4