Xamarin.forms: Impossible d'intercepter le bouton de retour du logiciel

Nous avons eu une discussion similaire ici. C'est ça que tu cherches ? https://forums.xamarin.com/discussion/100287/allow-a-single-place-to-handle-back-button-requests-with-async-support

@samhouts Oui, c'est à peu près exactement notre problème. Le rappel susmentionné doit être ajouté à la base de code ou la méthode existante doit être améliorée pour inclure les événements du bouton de retour du logiciel.

@samhouts ce bug est-il encore accepté ? C'est un gros problème. Quelles informations supplémentaires sont nécessaires ?

Je suis d'accord sur le fait que OnBackButtonPressed devrait gérer à la fois les BackButtons matériels et logiciels. Néanmoins, il n'est pas si difficile de les intercepter tous les deux. J'ai blogué sur ce sujet ici : https://msicc.net/xamarin-forms-the-mvvmlight-toolkit-and-i-taking-control-over-the-back-buttons/

@MSiccDev Si nous continuons à contourner les problèmes présentés par le framework, alors cela ne sera jamais résolu et les gens devront continuer à le faire eux-mêmes encore et encore jusqu'à la mort de la technologie.

@AceCoderLaura vrai d'un côté. De l'autre côté, il faut avancer. La meilleure chose à faire est de contourner mais de signaler le problème.

Ces solutions de contournement cassent le menu hamburger sur la page racine...
-.-

@AceCoderLaura Je l'utilise dans l'une de mes applications avec une page MD sans aucun problème...

@MSiccDev
Voici ma solution de contournement :

public override bool OnOptionsItemSelected(IMenuItem item) 
{ 
            //If it's not the "home" button continue as usual 
            var androidHomeId = 16908332; 
            if (item.ItemId != Resource.Id.home && item.ItemId != androidHomeId) return base.OnOptionsItemSelected(item); 

            var navigation = App.MainMasterDetailPage.Detail.Navigation; 
            if (navigation.NavigationStack.Count > 1) 
            { 
                //We can go back, do the arrow functionality 
                this.OnBackPressed();
                return true;
            } 
            else 
            { 
                //We're at the root, do the hamburger functionality 
                return App.MainMasterDetailPage.IsPresented = true; 
            } 
}

@AceCoderLaura Votre OnOptionsItemSelected est-il déclenché après avoir cliqué sur le bouton de retour oO Dans mon cas, rien ne s'est passé... (Android)

Y a-t-il des progrès pour ce problème? J'ai plusieurs vues de navigation imbriquées et il serait très difficile de corriger cela dans mon application. Je conviens avec @AceCoderLaura que cela doit être corrigé par xamarin.

Même problème. Je pense qu'il est assez courant de gérer un événement de retour dans une application d'entreprise. Cela devrait être réparé au plus vite.

Veuillez corriger cela, cela fait près d'un an que cela est signalé et c'est ridicule de ne pas l'avoir encore.

@ddobrev Vous avez raison, c'est une fonctionnalité très utile, mais malheureusement, elle n'a même pas été clairement définie comment elle doit fonctionner. Quelqu'un l'a mentionné au-dessus, mais il n'a reçu aucune réponse :

Oui, c'est à peu près exactement notre problème. Le rappel susmentionné doit être ajouté à la base de code ou la méthode existante doit être améliorée pour inclure les événements du bouton de retour du logiciel.

Si cela avait été clairement défini, j'aurais essayé de faire un PR pour le mettre en œuvre.

Je ne sais pas pourquoi, mais dans mon cas (sur Android), il suffisait d'ajouter ceci à mon MainActivity

        protected override void OnPostCreate(Bundle savedInstanceState)
        {
            var toolBar = FindViewById<global::Android.Support.V7.Widget.Toolbar>(Resource.Id.toolbar);
            SetSupportActionBar(toolBar);

            base.OnPostCreate(savedInstanceState);
        }

Avec cela, le OnBackButtonPressed est déclenché à la fois même si j'appuie sur le bouton de retour du matériel et le bouton de retour du logiciel sur la barre de navigation. Mais je ne comprends pas pourquoi.

Sur iOS, je devais encore l'ajouter moi-même avec un moteur de rendu de page personnalisé.

Alors, est-ce que cela va être corrigé dans la 3.6.0 ?

Je pense qu'il a été déplacé vers In Progress par erreur.

@samhouts a- t-il donc besoin d'une spécification maintenant ? Qu'est-ce qui n'est pas précisé à ce sujet ?

@ddobrev, nous devons encore définir la meilleure façon d'exposer ce que les gens veulent. Actuellement, OnBackButtonPressed correspond plus spécifiquement au bouton de retour du matériel, de sorte que ses fonctionnalités tournent davantage autour de cela. Une grande partie de ce que les gens veulent, c'est plus une fonctionnalité OnNavigatingBack.

Le simple fait de lier la flèche de retour du logiciel à cette méthode pour le moment ressemble toujours plus à un piratage qu'à fournir la meilleure solution

Par exemple, en désapprouvant simplement OnBackButtonPressed et en créant

OnHardwareBackButtonPressed and OnNavigatingBack

Eh bien, de toute façon, c'est bien. Fais-le. Cela fait assez longtemps.

En tant que fonctionnalité de la page, quelque chose comme ça aurait-il un sens ? Ce serait extrêmement utile si nous pouvions observer et annuler la navigation inversée (d'où la tâche Task\

enum ReverseNavigationSourceType {
    Unspecified,
    HwButton,
    Navbar,
    Gesture
}

class ReverseNavigationEventArgs {
    public ReverseNavigationSourceType SourceType { get; }
    public object Source { get; }
}

class Page {
    public virtual Task<bool> OnNavigatingBack(ReverseNavigationEventArgs args) {
        return Task.FromResult(true);
    }
}

La deuxième option réalisable que je peux voir consiste à l'implémenter dans le cadre de l'interface INavigation .

EDIT : légèrement modifié l'API

La solution @pikausp me semble la meilleure

De plus, je pense que ce serait formidable d'étendre cela davantage et d'introduire quelque chose qui ressemble à "l'état de la page".

La page peut être active ou inactive.

class PageActivationEventArgs { }
class PageDeactivationEventArgs {
    public bool IsPermanent { get; }
}
class Page {
    public virtual Task OnActivating(PageActivationEventArgs) {
        return Task.CompletedTask;
    }

    public virtual Task<bool> OnDeactivating(PageDeactivationEventArgs) {
        return Task.FromResult(true);
    }
}

Lorsque la page est éloignée de OnDeactivating est invoqué. La valeur de IsPermanent dépend du fait que la page est conservée ou non dans la pile de navigation (true pour les pops, false pour les push).

Introduisez éventuellement OnActivated et OnDeactivated qui sont invoqués une fois la navigation terminée.

Cela donne au développeur une grande puissance de navigation.

Quelles sont vos pensées?

Pourriez-vous signaler tout progrès ici, s'il vous plaît ?

Un moyen d'augmenter la priorité ?
J'ai des solutions de contournement depuis des années maintenant, qui parfois ne fonctionnaient plus,...
Ma solution de contournement actuelle est également un très mauvais hack avec des inconvénients, j'adorerais supprimer définitivement mes moteurs de rendu de page de navigation personnalisés et résoudre certains problèmes au cours du processus.

Cogner

Toute mise à jour sur l'interception du bouton de retour souple. Nous luttons vraiment là-dessus. Aucune solution mentionnée dans cet article ne fonctionne pour nous.

C'est vraiment nécessaire. Devoir pirater ou implémenter votre propre barre d'outils est un peu exagéré pour une omission aussi évidente. S'il te plaît ...

Des mises à jour ici @samhouts ?
On dirait que plusieurs solutions de haut niveau ont été suggérées ici, qui nous donneraient toutes la fonctionnalité que nous recherchons.

J'aimerais aussi avoir cette fonctionnalité.

Requis pour chaque cas d'utilisation qui devrait empêcher la perte de données. J'en ai besoin aussi, chaque solution de contournement est trop compliquée.

Ok, équipe, on se penche maintenant sur la fonctionnalité décrite ici : https://github.com/xamarin/Xamarin.Forms/issues/6971#issuecomment -574823028

Des objections?

@samhouts J'ai BackButtonBehavior n'est qu'un wrapper (avec quelques extras) autour d'une commande qui est exécutée lorsqu'un utilisateur tente de revenir en arrière ?

Fondamentalement, il ne s'agit pas d'intercepter la navigation inversée, mais plutôt de contrôler ce qui se passe exactement lorsqu'un utilisateur tente de revenir en arrière via n'importe quelle méthode disponible (balayage, bouton de barre de navigation, bouton Android, ..). Je peux décider de diriger l'utilisateur vers une nouvelle page au lieu de revenir en arrière si je le décide, est-ce correct ?

@samhouts J'ai une interception de travail dans mon application de production pour iOS uwp et Android. iOS et Android utilisant un moteur de rendu de page personnalisé. Lorsque l'utilisateur revient via le bouton de retour logiciel ou matériel, je peux afficher la fenêtre contextuelle « Annuler les modifications ? ». Lorsque l'utilisateur confirme l'invite, la navigation arrière est exécutée et la page apparaît, sinon l'utilisateur reste sur la page actuelle. Je n'ai pas encore considéré que le balayage est également possible pour revenir en arrière, c'est manquant dans ma mise en œuvre

@samhouts -

La proposition fonctionne-t-elle ainsi ?

• si {Shell, NaviationPage}.BackButtonCommand n'est pas affecté, le bouton Précédent se comporte normalement et la navigation arrière se produit automatiquement.
• Si {Shell, NaviationPage}.BackButtonCommand est affecté, aucune navigation arrière ne se produit automatiquement. L'instance ICommand attribuée peut explicitement faire quelque chose comme ceci, selon que vous utilisez ou non Shell.

c# async Task MyProcessBackButton(bool usingShell) { bool navigateBack = await DisplayAlert("Cancel?", "Undo changes", "Yes", "No"); var mainPage = usingShell ? (Page)Shell.Current : Application.Current.MainPage; if (mainPage is MasterDetailPage mdPage) mainPage = mdPage.Detail; if (navigateBack) await mainPage.Navigation.PopAsync(); }

Quelque chose comme ça devrait fonctionner pour moi, mais cela semble encombrant. Peut-être que je ne regarde pas correctement la proposition. Il serait utile de voir les cas d'utilisation énoncés avec des exemples.

PS Comme @nschoenberg , j'ai également une interception avec des rendus personnalisés dans mes applications (sur NavigationPage, en faisant quelque chose comme la méthode MyProcessBackButton ci-dessus. C'est bien que la proposition ne nécessite pas Shell - cela permettra une adoption plus facile pour nos anciennes applications).

• si {Shell, NaviationPage}.BackButtonCommand n'est pas affecté, le bouton Précédent se comporte normalement et la navigation arrière se produit automatiquement.

C'est ainsi que j'imagine que cela fonctionne, souvent nous voulons la fonctionnalité par défaut si elle n'est pas remplacée. Cela se comporterait de la même manière que de remplacer le bouton de retour de l'appareil sur Android et de retourner true. N'est-il pas logique de reproduire cette mise en œuvre d'une manière ou d'une autre ?

En tant que fonctionnalité de la page, quelque chose comme ça aurait-il un sens ? Ce serait extrêmement utile si nous pouvions observer et annuler la navigation inversée (d'où la tâche). En outre, il peut être utile de pouvoir distinguer ce qui a provoqué le retour de la demande.

enum ReverseNavigationSourceType {
    Unspecified,
    HwButton,
    Navbar,
    Gesture
}

class ReverseNavigationEventArgs {
    public ReverseNavigationSourceType SourceType { get; }
    public object Source { get; }
}

class Page {
    public virtual Task<bool> OnNavigatingBack(ReverseNavigationEventArgs args) {
        return Task.FromResult(true);
    }
}

La deuxième option réalisable que je peux voir consiste à l'implémenter dans le cadre de l'interface INavigation .

EDIT : légèrement modifié l'API

Dans le problème https://github.com/xamarin/Xamarin.Forms/issues/6971#issuecomment -574823028, je ne sais pas exactement où le BackButtonCommand sera exposé, est fourni uniquement sur NavigationPage? Existe-t-il une seule implémentation sur une NavigationPage contenante et toutes les pages poussées sur cette pile de navigation utilisent-elles le même comportement ? (Je ne pense pas que ce serait un cas d'utilisation typique). Comment les pages individuelles implémentent-elles leur propre remplacement et tirent-elles parti de la commande ?

Je pense que la proposition fournie ci-dessus satisferait les besoins des développeurs à remplacer par page, car l'invocation de la navigation arrière n'est souvent pas pertinente, le développeur veut simplement contrôler ce qui se passe sur la navigation arrière, c'est-à-dire inviter l'utilisateur à dialoguer avant de les envoyer à une autre page ou simplement laisser par défaut.

Je ne peux pas parler pour tout le monde, mais nous avons des cas dans des projets où nous avons implémenté une fonction qui est exécutée si le bouton du logiciel est enfoncé, nous supplantons également le OnBackButtonPressed qui appelle la même fonction. Deux formes de navigation arrière exécutant le même code.

Ces propriétés fonctionnent toutes de la même manière que n'importe laquelle des propriétés jointes sur NavigationPage

https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Core/NavigationPage.cs#L19

Vous pouvez simplement les appliquer à la page active et la NavigationPage réagit. Les propriétés jointes sont intéressantes car elles peuvent être liées, vous pouvez donc simplement les configurer sur une page et les lier à la machine virtuelle.

<ContentPage NavigationPage.BackButtonCommand={Bindiing BackCommand}

L'un des avantages d'avoir la commande simplement "désactiver" le comportement par défaut est qu'elle permet la navigation asynchrone. Parce que maintenant, le bouton se contente d'acheminer vers la commande et la commande peut faire ce qu'elle veut aussi longtemps qu'elle le souhaite, puis elle peut utiliser les API de navigation pour terminer la navigation si elle le souhaite.

Rendre tout asynchrone est intéressant principalement en raison de scénarios tels que le balayage arrière ou le balayage pour rejeter sur un modal, car ceux-ci ne sont pas nativement "asynchrones". geste.

Nous pourrions également en faire un événement sur la classe Navigation qui pourrait déclencher tout le long du proxy hiérarchique, puis avec un événement, vous pourriez utiliser un comportement EventToCommand.

Je me demande également si NavigatingBack a du sens. Si nous voulons avoir quelque chose comme ça, nous pourrions aussi bien créer un événement de navigation similaire à shell.

Je me rends compte que c'est un peu décousu :-) mais je voulais juste répondre à une question et avoir quelques idées pour la discussion

Vous pouvez simplement les appliquer à la page active et la NavigationPage réagit. Les propriétés jointes sont intéressantes car elles peuvent être liées, vous pouvez donc simplement les configurer sur une page et les lier à la machine virtuelle.

<ContentPage NavigationPage.BackButtonCommand={Bindiing BackCommand}

@PureWeen désolé, j'ai oublié que l'accès aux propriétés était possible sur une page de cette façon et il est logique de le faire de toute façon.

La NavigationPage.BackButtonCommand consommerait-elle également le bouton de retour de l'appareil ou simplement le bouton de retour du logiciel ? Puisqu'il existe d'autres moyens d'invoquer la navigation arrière.

Actuellement, je pense que NavigationPage.BackButtonCommand disparaît et nous avons quelque chose de plus généralisé. Faut juste y réfléchir un peu plus.

Quelque chose de lié à pop/push peut avoir du sens et correspondre aux API existantes

Pas exactement, mais quelque chose dans ce sens

UserRequestedPoppingCommand
UtilisateurDemandéPushingCommand

Ou éventuellement PoppingCommand et PushingCommand, puis nous pouvons avoir quelque chose de similaire à vos arguments qui donnent un contexte.

C# enum NavigationSourceType { Unspecified, HwButton, Navbar, Gesture, FromCode }

J'aimerais également que tout soit lié, mais je n'ai pas encore tout à fait cliqué sur une idée que j'aime beaucoup.

Peut-être quelque chose sur Navigation qui indique l'état actuel de la navigation ?
Donc si c'est fait via commande vous pouvez demander à Navigation si c'est un geste en cours ou autre

Une mise à jour pour ceci? Nous attendons cela depuis plus d'un an.

Une mise à jour pour ceci? Nous attendons cela depuis plus d'un an.

Relaxer. Un an, ce n'est rien. SplitView avec MasterDetail sur iPad a été signalé il y a plus de 4 ans qu'il ne fonctionnait pas et était buggé. À cette époque, Xamarin.Forms utilisait toujours Bugzilla.

@SebastianKruseWago C'est un scénario complètement différent de la fonctionnalité attendue qui existe déjà dans une zone différente. Ils ont également corrigé un "bug" qui permettait de contourner le problème. Un an, c'est beaucoup, pour quelque chose qui aurait dû être inclus dès le premier jour.

@akemper1 SplitView devrait également fonctionner dès le premier jour. C'est aussi un bug car il ne s'agit que d'un problème avec l'iPad MasterDetailRenderer. Cela a fonctionné avant 2.4 ou plus avec une solution de contournement laide. Donc je ne pense pas que ce soit différent.

Bonjour, y a-t-il des nouvelles ?

@scriptBoris Les solutions de

https://forums.xamarin.com/discussion/67854/android-menu-and-back-button-not-working

https://theconfuzedsourcecode.wordpress.com/2017/03/12/lets-override-navigation-bar-back-button-click-in-xamarin-forms/

J'ai obtenu les deux solutions à partir des liens dans des projets séparés.

Bonjour, je m'excuse de vous déranger, mais y a-t-il des nouvelles pour résoudre ce problème ? .О

Je mets à jour la question :)

<ContentPage NavigationPage.HasBackButton="False">

Y a-t-il une mise à jour à ce sujet ? Les solutions présentées dans ce fil sont plus qu'acceptables, cela fait des années et les gens attendent cela.

Quelqu'un de l'équipe Xamarin peut-il commenter l'état de cela? C'est vraiment un gros problème pour beaucoup de gens.

Je sais que vous pouvez le faire en shell, mais pour de nombreuses applications plus volumineuses qui tirent parti de Prism ou de MVVMCross, le shell n'est pas entièrement pris en charge, c'est donc quelque chose dont nous avons vraiment besoin.

Merci

Excuses @akemper1 mais pas de mises à jour spécifiques actuellement.

Nous n'avons pas oublié celui-ci mais sommes juste un peu en retard sur une API officielle pour nous installer. Il y a quelques PR Shell en attente qui influencent le bouton de retour qui se propageront aux API utilisées ici

Je suis d'accord avec beaucoup qui disent que c'est un gros problème pour eux.

Je vais essayer quelques-unes des solutions de contournement cependant. Je veux juste pouvoir empêcher un utilisateur de revenir en arrière jusqu'à ce qu'il "confirme" qu'il perdra les modifications sur la page sur laquelle il se trouve.

Des nouvelles à ce propos? ça fait très longtemps :(