Unified back stack - #32
Conversation
…t, can be overlayed with a native screen
|
En l'état le rendu ne me semble pas acceptable. Quand je fais un retour arrière, je vois la page webview s'afficher une fraction de seconde avant la redirection. Si je suis sur la home, que je vais sur l'écran natif des settings puis que j'utilise le bouton back natif, je vois la page des settings webView s'afficher brievement avant de revenir sur la home. Visuellement ca casse l'expérience utilisateur puisque les deux pages sont visuellement différentes |
|
Pourquoi ne pas juste intercepter le bouton back natif sur les vues natives en faisant Comme ca on aurait le même comportement entre la fleche de la page et le bouton natif même si un jour on change sa cible |
4ce5b59 to
fe27d4b
Compare
C'est tout à fait exact, et c'est ce que j'espère qu'on pourra résoudre grâce à l'implémentation de numerique-gouv/ami-notifications-api#548, dans une future PR une fois que le côté web (numerique-gouv/ami-notifications-api#547) aura été implémenté. Cette PR règle le problème plus général du back qui est incohérent entre le back natif et le back webview, et une tentative d'avoir un comportement générique. J'aurais dû noter tous ces cas limite et les mettre dans l'issue : je viens de le faire avec deux exemples concrets. La solution proposée est d'avoir toujours la webview présente (pour garder par exemple l'état du scroll, les textes saisis dans des champs, etc...), et d'afficher une vue native par-dessus si il y en a une, et d'avoir une "stack" qui contient toutes les URLs et vues natives, dans leur ordre d'apparition, pour garantir un "back" cohérent et fiable.
Le Dans tous les cas, il me semble que cette solution est plus fiable et maintenable, est-ce que tu pourrais me faire une revue du code, et me dire ce que tu en penses ? Si tu penses qu'il y a une meilleure architecture ou une autre manière de le faire, je suis preneur, en attendant il me semble que cette modification va dans la bonne direction. |
|
Oui oui, je vais faire la review, je voulais juste comprendre les tenants et aboutissements de la PR pour pouvoir comprendre le code. ,Je n'avais pas saisi tout le périmètre de la PR, je n'avais fait le lien qu'avec les écrans natifs alors qu'effectivement le problème du back natif est plus large. J'ai reverifié cette histoire de superposition visuelle d'écran entre webview/natif et c'est vrai qu'il était présent (mais moins visible je trouve) mais plutot à l'apparition de la page alors que maintenant c'est à la sortie de la page. Ce n'est pas mieux ni moins bien, mais ca explique pourquoi le problème ne me choquait pas puisque je ne regardais que la réaction au back |
| }, | ||
| navigationIcon = { | ||
| IconButton(onClick = onBackButton) { | ||
| IconButton(onClick = onBackOnce) { |
There was a problem hiding this comment.
quelle est l'interet de la création de onBackOnce plutot que d'utiliser IconButton(onClick = {onBackButton(null)}) {} ? Je n'ai pas l'impression que ca améliore la lecture du code
| @SuppressLint("SetJavaScriptEnabled") | ||
| @Composable | ||
| fun HomeScreen(webViewViewModel: WebViewViewModel, goSettings: () -> Unit) { | ||
| fun HomeScreen(webViewViewModel: WebViewViewModel, navigationViewModel: NavigationViewModel, onGoBack: (url: String?) -> Unit = {}) { |
There was a problem hiding this comment.
Pourquoi initialiser onGoBack: (url: String?) -> Unit = {} par défaut puisque à priori on veut toujours avoir une action sur le "back" non ? Il me semble qu'il est préférable d'enlever le "={}" afin d'obliger le développeur à indiquer une action à faire (quitte à ce qu'il décide lui même de ne pas mettre d'action)
| webViewViewModel: WebViewViewModel, | ||
| goSettings: () -> Unit, | ||
| navigationViewModel: NavigationViewModel, | ||
| onGoBack: (url: String?) -> Unit = {}, |
There was a problem hiding this comment.
pareil, il me semble que le ={} est de trop
Conserver l'état de la webView ne devrait pas se faire en conservant la webView mais en gérant un State associé que l'on peut restaurer au besoin. Avant de proposer une solution, je pense qu'il faut prendre le temps d'analyser clairement les causes du problème des retours (natofs ou web) : qu'est-ce qui fait que dans l'état actuels, ils cohabitent mal. |
4 participants
Fixes #30