Predictive back (SDK 37)#62
Open
Spriana wants to merge 9 commits into
Open
Conversation
Android 16 (targetSdk 36) impose le edge-to-edge et ignore l'opt-out windowOptOutEdgeToEdgeEnforcement, retiré ici. On gère donc les insets manuellement au lieu de compter sur fitsSystemWindows : padding du haut sur la toolbar (son fond colorPrimary peint la bande de barre d'état, icônes claires/sombres selon le thème), retrait de fitsSystemWindows des racines CoordinatorLayout et neutralisation de la gestion d'insets du DrawerLayout (sinon la toolbar ne peint pas la barre d'état et une marge grise apparaît en bas), padding du bas (barre de navigation + clavier) sur la barre d'envoi des topics, et padding du bas sur les listes pour garder le dernier élément au-dessus de la barre de navigation. Retrait aussi du scrim par défaut du ScrimInsetsFrameLayout du menu latéral. Vérifié sur Android 16. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ack=false Au targetSdk 36 le predictive back est activé par défaut et onBackPressed n'est plus appelé. On le désactive temporairement pour conserver les surcharges onBackPressed existantes (drawer, brouillons, retour WebView, double-retour) jusqu'à leur migration vers OnBackPressedDispatcher. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Le edge-to-edge (géré par le commit précédent) et le predictive back (neutralisé) sont prêts. Les autres changements du SDK 36 (orientation grand écran, pages 16 Ko, réseau local, intents) ne concernent pas cette app. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…a barre de navigation Avec beaucoup de topics favoris la liste du menu latéral défile, et son dernier élément passait sous la barre de navigation. Le ScrimInsetsFrameLayout consommant les insets, on applique le padding bas (inset de barre de navigation) sur le panneau du menu (parent de la liste) plutôt que sur la liste. Vérifié sur Android 16 avec 11 favoris, navigation à 3 boutons. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…menu latéral Au-dessus du menu latéral ouvert, la barre de navigation paraissait opaque (le fond plein du panneau remplissait la zone) alors qu'elle est transparente sur les autres écrans. On applique désormais clipToPadding + padding bas sur la liste du menu plutôt que sur le panneau (le ScrimInsetsFrameLayout consommant les insets, le listener reste posé sur le panneau) : le contenu défile sous la barre comme ailleurs et le dernier élément reste au-dessus d'elle. Vérifié sur Android 16, navigation à 3 boutons. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sur Android < 15 (pas d'edge-to-edge), la barre d'état des écrans à menu latéral était grise : le hack statusBarNeedToBeTransparent la rendait transparente, en s'appuyant sur le scrim du DrawerLayout désormais neutralisé. On retire ce hack et on passe statusBarColor de colorPrimaryDark à colorPrimary, pour que la barre d'état ait la même couleur que la barre du haut, comme le rendu edge-to-edge des versions 15+. Vérifié sur Android 7.1.1 (API 25). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Les surcharges de onBackPressed() (dépréciées) sont remplacées par des OnBackPressedCallback enregistrés sur le dispatcher, et android:enableOnBackInvokedCallback passe à true. C'est requis pour cibler le SDK 37. Les écrans dont le retour ne fait que finir l'activité (WebView, drawer) utilisent un callback activé selon l'état pour conserver l'animation de retour prédictif ; les écrans avec brouillon ou double-appui gardent un callback toujours actif qui relit l'état à chaque appui. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
En mode ALWAYS, le callback de retour reste désactivé pour laisser le système jouer l'animation de retour prédictif, et le toast « brouillon sauvegardé » est affiché dans onStop() au lieu du callback. Le callback ne s'active qu'en mode ASK_BEFORE avec un brouillon en cours, pour afficher la boîte de dialogue de confirmation ; le texte du brouillon est de toute façon sauvegardé dans onPause(). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
L'activation du predictive back faite dans les commits précédents en était le prérequis. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Merge #56 avant.
Le premier commit passe à OnBackPressedCallback partout où onBackPressed était utilisé.
Le second commit fait en sorte d’activer le predictive back quand on fait retour depuis un topic pour aller au forum, à condition de pas avoir activé l’option pour demander à chaque fois si on veut enregistrer le brouillon ou non. C’est une action très courante donc c’est sympa d’avoir le predictive back là. Faire retour depuis la création d’un topic souffre du même problème mais c’est une action bien moins courante donc je l’ai pas fait ; surtout que ce deuxième commit est très riche en commentaires parsemés par Claude et c’est peut-être too much.
Et puis on passe au SDK 37 !
Ci-dessous le plan de tests à faire, rédigé par Claude, que j’ai suivi à ~80 % (pas testé sondage ni brouillon dans nouveau topic ni connexion modérateur) :
Plan de test manuel
À faire de préférence sur un émulateur/appareil avec la navigation par gestes et le retour prédictif actifs (API 33+, activé par défaut sur 36/37), car c'est le comportement que la compilation ne peut pas vérifier.
Comportement du retour — inchangé, avec animation prédictive là où indiqué
Cible SDK 37