Xamarin.forms: Zurück-Taste der Software kann nicht abgefangen werden

Wir hatten hier eine ähnliche Diskussion. Ist das das, was Sie suchen? https://forums.xamarin.com/discussion/100287/allow-a-single-place-to-handle-back-button-requests-with-async-support

@samhouts Ja, das ist ziemlich genau unser Problem. Der oben erwähnte Rückruf muss der Codebasis hinzugefügt werden oder die vorhandene Methode muss erweitert werden, um Ereignisse von der Software-Zurück-Schaltfläche einzuschließen.

@samhouts wird dieser Fehler schon akzeptiert? Es ist ein großes Thema. Welche weiteren Informationen werden benötigt?

Ich stimme in dem Punkt zu, dass OnBackButtonPressed sowohl Hard- als auch Software-BackButtons behandeln sollte. Trotzdem ist es nicht so schwer, beide abzufangen. Ich habe zu diesem Thema hier gebloggt :

@MSiccDev Wenn wir die Probleme des Frameworks weiter

@AceCoderLaura stimmt auf der einen Seite. Auf der anderen Seite muss man vorwärts gehen. Am besten umgehen, aber das Problem melden.

Diese Problemumgehungen unterbrechen das Hamburger-Menü auf der Stammseite...
-.-

@AceCoderLaura Ich verwende es in einer meiner Apps mit einer MD-Seite ohne Probleme...

@MSiccDev
Hier ist mein hackiger Workaround:

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 Werden Ihre OnOptionsItemSelected ausgelöst, nachdem Sie auf die Nav-Zurück-Schaltfläche geklickt haben oO In meinem Fall ist nichts passiert ... (Android)

Gibt es Fortschritte zu diesem Thema? Ich habe mehrere verschachtelte Navigationsansichten und es wäre extrem hackig, dies in meiner Anwendung zu patchen. Ich stimme @AceCoderLaura zu, dass dies von xamarin gepatcht werden muss.

Gleiches Problem. Ich denke, es ist ziemlich üblich, Back-Events in Unternehmens-Apps zu verarbeiten. Es sollte so schnell wie möglich behoben werden.

Bitte behebt dies, es wird seit fast einem Jahr gemeldet und es ist lächerlich, es noch nicht zu haben.

@ddobrev Sie haben Recht, dies ist eine sehr nützliche Funktion, aber leider wurde nicht einmal klar definiert, wie sie funktionieren muss. Jemand hat es oben erwähnt, aber es hat keine Antwort erhalten:

Ja, das ist ziemlich genau unser Problem. Der oben erwähnte Rückruf muss der Codebasis hinzugefügt werden oder die vorhandene Methode muss erweitert werden, um Ereignisse von der Software-Zurück-Schaltfläche einzuschließen.

Wäre dies klar definiert worden, hätte ich versucht, eine PR zu machen, um es umzusetzen.

Ich weiß nicht warum, aber in meinem Fall (auf Android) reichte es, dies zu meiner MainActivity hinzuzufügen

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

            base.OnPostCreate(savedInstanceState);
        }

Damit wird OnBackButtonPressed sowohl ausgelöst, wenn ich den Hardware-Zurück-Button als auch den Software-Zurück-Button in der Navigationsleiste drücke. Aber ich verstehe nicht warum.

Unter iOS musste ich es noch selbst mit einem benutzerdefinierten Seitenrenderer hinzufügen.

Wird das in 3.6.0 behoben?

Ich glaube, es wurde versehentlich nach In Progress verschoben.

@samhouts, also braucht es jetzt eine Spezifikation? Was ist daran nicht angegeben?

@ddobrev wir müssen noch den besten Weg finden, um zu zeigen, was die Leute wollen. Derzeit wird OnBackButtonPressed genauer der Hardware-Zurück-Schaltfläche zugeordnet, sodass sich die Funktionen mehr darum drehen. Vieles, was die Leute wollen, ist eher eine OnNavigatingBack-Funktion.

Nur den Zurück-Pfeil der Software an diese Methode zu binden, scheint immer noch eher ein Hack zu sein, als die beste Lösung zu bieten

Zum Beispiel einfach OnBackButtonPressed verwerfen und erstellen

OnHardwareBackButtonGedrückt und OnNavigatingBack

Nun, so oder so ist in Ordnung. Mach es einfach. Es ist lange genug her.

Wäre so etwas als Page-Feature sinnvoll? Es wäre sehr hilfreich, wenn wir die Rückwärtsnavigation beobachten und abbrechen könnten (daher die Aufgabe\

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);
    }
}

Die zweite mögliche Option, die ich sehen kann, ist die Implementierung als Teil der INavigation Schnittstelle.

EDIT: die API leicht modifiziert

Die @pikausp- Lösung sieht für mich am besten aus

Außerdem fände ich es toll, dies weiter auszubauen und so etwas wie "Seitenstatus" einzuführen.

Die Seite kann aktiv oder inaktiv sein.

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);
    }
}

Wenn Page von OnDeactivating weg navigiert wird, wird aufgerufen. Der Wert von IsPermanent basiert darauf, ob die Seite im Navigationsstack gehalten wird (true für Pops, false für Pushs).

Möglicherweise führen Sie OnActivated und OnDeactivated , die aufgerufen werden, sobald die Navigation abgeschlossen ist.

Dies gibt dem Entwickler eine große Macht beim Navigationsfluss.

Was sind deine Gedanken?

Würde es Ihnen etwas ausmachen, hier über Fortschritte zu berichten?

Gibt es eine Möglichkeit, die Priorität zu erhöhen?
Ich habe seit Jahren Workarounds, die manchmal nicht mehr funktionierten,...
Mein aktueller Workaround ist auch ein wirklich schlechter Hack mit Nachteilen, würde gerne meine benutzerdefinierten Navigationsseiten-Renderer endgültig entfernen und einige Probleme dabei beheben.

Stoßen

Jedes Update zum Abfangen der Softback-Taste. Damit tun wir uns wirklich schwer. Keine in diesem Beitrag erwähnte Lösung funktioniert für uns.

Das ist wirklich nötig. Ihre eigene Symbolleiste entweder hacken oder implementieren zu müssen, ist für eine so offensichtliche Unterlassung ein bisschen übertrieben. Bitte ...

Irgendwelche Updates hier @samhouts ?
Klingt, als wären hier mehrere High-Level-Lösungen vorgeschlagen worden, die uns alle die Funktionalität geben würden, nach der wir suchen.

Würde diese Funktion auch gerne haben.

Erforderlich für jeden Anwendungsfall, der Datenverlust verhindern soll. Ich brauche das auch, jeder Workaround ist einfach zu hackig.

Ok, Team, wir tendieren jetzt zu der hier beschriebenen Funktionalität: https://github.com/xamarin/Xamarin.Forms/issues/6971#issuecomment -574823028

Irgendwelche Einwände?

@samhouts Ich habe mir das verlinkte Problem kurz angesehen und da ich die Shell noch nicht verwendet habe, ist dies eher eine Frage. BackButtonBehavior ist nur ein Wrapper (mit einigen Extras) um einen Befehl, der ausgeführt wird, wenn ein Benutzer versucht, zurück zu navigieren?

Im Grunde geht es nicht darum, die Rückwärtsnavigation abzufangen, sondern stattdessen die Kontrolle darüber zu übernehmen, was genau passiert, wenn ein Benutzer versucht, mit einer beliebigen verfügbaren Methode (Swipe, Navbar-Taste, Android-Taste,..) zurück zu navigieren. Ich kann mich entscheiden, den Benutzer zu einer neuen Seite zu navigieren, anstatt zurück zu navigieren, wenn ich mich dafür entscheide, ist das richtig?

@samhouts Ich habe eine funktionierende Interception in meiner Produktions-App für iOS uwp und Android. iOS und Android mit benutzerdefiniertem Seitenrenderer. Wenn der Benutzer über die Software- oder Hardware-Zurück-Schaltfläche zurück navigiert, kann ich das Popup "Änderungen verwerfen?" anzeigen. Wenn der Benutzer die Eingabeaufforderung bestätigt, wird die Zurück-Navigation ausgeführt und die Seite wird eingeblendet, ansonsten bleibt der Benutzer auf der aktuellen Seite. Ich habe noch nicht bedacht, dass das Wischen auch möglich ist, um zurück zu gehen, das fehlt in meiner Implementierung

@samhouts -

Funktioniert der Vorschlag so?

• Wenn {Shell, NaviationPage}.BackButtonCommand nicht zugewiesen ist, verhält sich die Zurück-Schaltfläche normal und die Zurück-Navigation erfolgt automatisch.
• Wenn {Shell, NaviationPage}.BackButtonCommand zugewiesen ist, erfolgt keine automatische Rückwärtsnavigation. Die zugewiesene ICommand-Instanz kann dies explizit tun, je nachdem, ob Sie Shell verwenden oder nicht.

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(); }

So etwas sollte für mich funktionieren, aber es scheint umständlich. Vielleicht sehe ich den Vorschlag nicht richtig an. Es wäre hilfreich, die Anwendungsfälle mit Beispielen zu beschreiben.

PS Wie @nschoenberg habe ich auch Abfangen mit benutzerdefinierten Renderings in meinen Apps (auf NavigationPage, indem ich so etwas wie die MyProcessBackButton-Methode oben mache. Es ist schön, dass der Vorschlag keine Shell erfordert - es wird eine einfachere Übernahme für unsere älteren Apps ermöglichen).

• Wenn {Shell, NaviationPage}.BackButtonCommand nicht zugewiesen ist, verhält sich die Zurück-Schaltfläche normal und die Zurück-Navigation erfolgt automatisch.

So würde ich es mir vorstellen, oft wollen wir die Standardfunktionalität, wenn sie nicht überschrieben wird. Dies würde sich genauso verhalten, als würde man die Zurück-Taste des Geräts auf Android überschreiben und true zurückgeben. Ist es nicht sinnvoll, diese Implementierung irgendwie zu replizieren?

Wäre so etwas als Page-Feature sinnvoll? Es wäre immens hilfreich, wenn wir die Rückwärtsnavigation beobachten und abbrechen könnten (daher die Aufgabe). Außerdem kann es nützlich sein, zu unterscheiden, was die Anforderung zum Zurücknavigieren verursacht hat.

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);
    }
}

Die zweite mögliche Option, die ich sehen kann, ist die Implementierung als Teil der INavigation Schnittstelle.

EDIT: die API leicht modifiziert

In der Ausgabe https://github.com/xamarin/Xamarin.Forms/issues/6971#issuecomment -574823028 bin ich mir nicht sicher, wo genau der BackButtonCommand angezeigt wird. Wird er nur auf NavigationPage bereitgestellt? Gibt es eine einzelne Implementierung auf einer enthaltenden NavigationPage und alle Seiten, die auf diesen Navigationsstapel verschoben werden, verwenden das gleiche Verhalten? (Ich glaube nicht, dass dies ein typischer Anwendungsfall wäre). Wie implementieren einzelne Seiten ihre eigene Überschreibung und nutzen den Befehl?

Ich denke, der oben bereitgestellte Vorschlag würde die Anforderungen der Entwickler erfüllen, die pro Seite überschrieben werden müssen, da der Aufruf der Rückwärtsnavigation etwas irrelevant ist eine andere Seite oder belassen Sie es einfach als Standard.

Ich kann nicht für alle sprechen, aber wir haben Fälle in Projekten, in denen wir eine Funktion implementiert haben, die ausgeführt wird, wenn die Softwaretaste gedrückt wird, wir überschreiben auch die OnBackButtonPressed , die dieselbe Funktion aufruft. Zwei Formen der Rückwärtsnavigation, die denselben Code ausführen.

Diese Eigenschaften funktionieren alle genauso wie alle angehängten Eigenschaften auf NavigationPage

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

Sie können sie einfach auf die aktive Seite anwenden und die NavigationPage reagiert. Die angehängten Eigenschaften sind schön, weil sie bindbar sind, sodass Sie sie einfach auf einer Seite einrichten und an die VM binden können.

<ContentPage NavigationPage.BackButtonCommand={Bindiing BackCommand}

Einer der Vorteile, wenn der Befehl nur das Standardverhalten "deaktiviert", besteht darin, dass er die asynchrone Navigation ermöglicht. Denn jetzt leitet die Schaltfläche nur zum Befehl und der Befehl kann so lange tun, wie er möchte, und dann kann er die Navigationsapis verwenden, um die Navigation abzuschließen, wenn er möchte.

Es ist vor allem interessant, alles asynchron zu machen, weil Szenarien wie das Zurückstreichen oder das Streichen zum Verwerfen auf einem Modal interessant sind, da diese nicht nativ "asynchron" sind Geste.

Wir könnten es auch zu einem Ereignis in der Klasse Navigation machen, das den hierarchischen Proxy ganz nach oben feuern könnte und dann mit einem Ereignis ein EventToCommand-Verhalten verwenden könnte.

Ich frage mich auch, ob NavigatingBack Sinn macht. Wenn wir so etwas haben, können wir auch einfach ein Navigationsereignis ähnlich der Shell erstellen.

Mir ist klar, dass das ein bisschen weitschweifig ist :-) aber ich wollte nur eine Frage beantworten und ein paar Ideen zur Diskussion stellen

Sie können sie einfach auf die aktive Seite anwenden und die NavigationPage reagiert. Die angehängten Eigenschaften sind schön, weil sie bindbar sind, sodass Sie sie einfach auf einer Seite einrichten und an die VM binden können.

<ContentPage NavigationPage.BackButtonCommand={Bindiing BackCommand}

@PureWeen Entschuldigung, dass der Zugriff auf Eigenschaften auf einer Seite auf diese Weise möglich war und es trotzdem sinnvoll ist, dies zu tun.

Würde der NavigationPage.BackButtonCommand auch die Zurück-Taste des Geräts verbrauchen oder nur die Zurück-Taste der Software? Da es andere Möglichkeiten gibt, die Rückwärtsnavigation aufzurufen.

Momentan denke ich, dass NavigationPage.BackButtonCommand verschwindet und wir etwas allgemeineres haben. Muss nur noch ein bisschen darüber nachdenken.

Etwas, das mit Pop/Push verbunden ist, könnte Sinn machen und zu bestehenden APIs passen

Nicht genau diese aber etwas in die Richtung

UserRequestedPoppingCommand
UserRequestedPushingCommand

Oder möglicherweise PoppingCommand und PushingCommand, und dann können wir etwas Ähnliches wie Ihre Argumente haben, das den Kontext liefert.

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

Ich würde es gerne auch bindbar machen, aber ich habe noch nicht ganz in eine Idee geklickt, die mir super gefällt.

Vielleicht etwas in der Navigation, das den aktuellen Status der Navigation anzeigt?
Wenn es also über einen Befehl erfolgt, können Sie die Navigation fragen, ob es sich um eine laufende Geste oder eine andere handelt

Gibt es hierzu Neuigkeiten? Darauf haben wir über ein Jahr gewartet.

Gibt es hierzu Neuigkeiten? Darauf haben wir über ein Jahr gewartet.

Entspannen. Ein Jahr ist nichts. SplitView mit MasterDetail auf dem iPad wurde vor über 4 Jahren gemeldet, dass es nicht funktioniert und fehlerhaft ist. Zu diesem Zeitpunkt verwendete Xamarin.Forms noch Bugzilla.

@SebastianKruseWago Das ist ein völlig anderes Szenario als erwartete Funktionalität, die bereits in einem anderen Bereich vorhanden ist. Sie haben auch einen "Bug" behoben, der eine Umgehung ermöglichte. Ein Jahr ist also viel, für etwas, das vom ersten Tag an dabei sein sollte.

@akemper1 SplitView sollte auch vom ersten Tag an funktionieren. Es ist auch ein Bug, da es sich nur um ein Problem mit dem iPad MasterDetailRenderer handelt. Es hat vor 2.4 oder so mit einem hässlichen Workaround funktioniert. Also ich glaube nicht, dass es anders ist.

Hallo, gibt es Neuigkeiten?

@scriptBoris Mögliche

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/

Ich habe beide Lösungen aus den Links in separaten Projekten erhalten.

Guten Tag, ich entschuldige mich für die Störung, aber gibt es Neuigkeiten, um dieses Problem zu lösen? .О

Ich aktualisiere die Frage :)

<ContentPage NavigationPage.HasBackButton="False">

Gibt es dazu ein Update? Die in diesem Thread vorgestellten Lösungen sind mehr als akzeptabel, es sind Jahre her und die Leute warten darauf.

Kann jemand vom Xamarin-Team den Status dazu kommentieren? Das ist wirklich ein großes Thema für viele Leute.

Ich weiß, dass Sie dies in der Shell tun können, aber für viele größere Apps, die Prism oder MVVMCross nutzen, wird die Shell nicht vollständig unterstützt, daher ist dies etwas, das wir wirklich brauchen.

Vielen Dank

Entschuldigung @akemper1 aber derzeit keine spezifischen Updates.

Wir haben das nicht vergessen, aber wir sind nur ein bisschen verspätet, um eine offizielle API zu finden. Es gibt einige ausstehende Shell-PRs, die die Zurück-Schaltfläche beeinflussen, die an die hier verwendeten APIs weitergegeben werden

Ich stimme vielen zu, die sagen, dass dies ein großes Problem für sie ist.

Ich werde aber einige der Workarounds ausprobieren. Ich möchte nur verhindern können, dass ein Benutzer zurückkehrt, bis er "bestätigt", dass Änderungen auf der Seite, auf der er sich befindet, verloren gehen.

Irgendetwas Neues darüber? es ist echt lange her :(