Xamarin.forms: No se puede interceptar el botón Atrás del software

Tuvimos una discusión similar aquí. ¿Es esto lo que estás buscando? https://forums.xamarin.com/discussion/100287/allow-a-single-place-to-handle-back-button-requests-with-async-support

@samhouts Sí, ese es exactamente nuestro problema. La devolución de llamada antes mencionada debe agregarse al código base o el método existente debe mejorarse para incluir eventos del botón de retroceso del software.

@samhouts, ¿ya se ha aceptado este error? Es un gran problema. ¿Qué más información se necesita?

Estoy de acuerdo en que OnBackButtonPressed debe manejar tanto Hard- como Software-BackButtonss. No obstante, no es tan difícil intereceptarlos a ambos. Escribí en un blog sobre ese tema aquí: https://msicc.net/xamarin-forms-the-mvvmlight-toolkit-and-i-taking-control-over-the-back-buttons/

@MSiccDev Si seguimos trabajando en torno a los problemas que presenta el marco, nunca se solucionará y la gente tendrá que seguir haciéndolo una y otra vez hasta la muerte de la tecnología.

@AceCoderLaura verdadero en un lado. Por otro lado, hay que avanzar. Lo mejor es solucionarlo pero informar el problema.

Estas soluciones rompen el menú de hamburguesas en la página raíz ...
-.-

@AceCoderLaura Lo estoy usando en una de mis aplicaciones con MD-Page sin ningún problema ...

@MSiccDev
Aquí está mi solución hacky:

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 ¿Se activan sus OnOptionsItemSelected después de hacer clic en el botón de navegación hacia atrás oO En mi caso, no pasó nada ... (Android)

¿Hay algún progreso en este tema? Tengo varias vistas de navegación anidadas y sería muy complicado parchear esto en mi aplicación. Estoy de acuerdo con @AceCoderLaura en que esto debe ser parcheado por xamarin.

El mismo problema. Creo que es bastante común manejar un evento inverso en una aplicación empresarial. Debería arreglarse lo antes posible.

Solucione este problema, se informó desde hace casi un año y es ridículo no tenerlo todavía.

@ddobrev Tienes razón, esta es una característica muy útil, pero desafortunadamente ni siquiera se ha definido claramente cómo debe funcionar. Alguien lo mencionó anteriormente pero no obtuvo respuesta:

Sí, ese es exactamente nuestro problema. La devolución de llamada antes mencionada debe agregarse al código base o el método existente debe mejorarse para incluir eventos del botón de retroceso del software.

Si esto hubiera estado claramente definido, habría intentado hacer un PR para implementarlo.

No sé por qué, pero en mi caso (en Android) fue suficiente para agregar esto a mi MainActivity

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

            base.OnPostCreate(savedInstanceState);
        }

Con esto, el OnBackButtonPressed se activa incluso si presiono el botón de retroceso del hardware y el botón de retroceso del software en la barra de navegación. Pero no entiendo por qué.

En iOS, todavía tenía que agregarlo yo mismo con un renderizador de página personalizado.

Entonces, ¿se solucionará esto en 3.6.0?

Creo que se movió a In Progress por error.

@samhouts , ¿necesita especificaciones ahora? ¿Qué no se especifica al respecto?

@ddobrev todavía tenemos que especificar la mejor manera de exponer lo que la gente quiere. Actualmente, OnBackButtonPressed se asigna más específicamente al botón de retroceso del hardware, por lo que sus características giran más en torno a eso. Mucho de lo que la gente quiere es más una función OnNavigatingBack.

El simple hecho de vincular la flecha hacia atrás del software a ese método en este momento parece más un truco que proporcionar la mejor solución.

Por ejemplo, simplemente desaprobar OnBackButtonPressed y crear

OnHardwareBackButtonPresionado y encendidoNavigatingBack

Bueno, de cualquier manera está bien. Solo hazlo. Ha sido suficiente.

Como característica de la página, ¿tendría sentido algo como esto? Sería de gran ayuda si pudiéramos observar y cancelar la navegación inversa (de ahí la 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 segunda opción factible que puedo ver es implementar esto como parte de la interfaz INavigation .

EDITAR: modificó ligeramente la API

La solución @pikausp me parece la mejor

Además, creo que sería genial ampliar esto aún más e introducir algo parecido al "Estado de la página".

La página puede estar activa o inactiva.

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

Cuando se navega por la página, se invoca OnDeactivating . El valor de IsPermanent se basa en si la página se mantiene o no en la pila de navegación (verdadero para pops, falso para empujes).

Posiblemente introduzca OnActivated y OnDeactivated que se invocan una vez que se completa la navegación.

Esto le da al desarrollador un gran poder de flujo de navegación.

¿Cuáles son tus pensamientos?

¿Le importaría reportar algún progreso aquí, por favor?

¿Alguna forma de aumentar la prioridad?
He tenido soluciones durante años, que a veces ya no funcionaban, ...
Mi solución actual también es un truco realmente malo con desventajas, me encantaría eliminar los renderizadores de mi página de navegación personalizada para siempre y solucionar algunos problemas en el proceso.

Protuberancia

Cualquier actualización sobre la interceptación del botón de retroceso suave. Realmente estamos luchando con esto. Ninguna solución mencionada en esta publicación funciona para nosotros.

Esto es realmente necesario. Tener que piratear o implementar su propia barra de herramientas es un poco exagerado para una omisión tan obvia. Por favor ...

¿Alguna actualización aquí @samhouts ?
Parece que aquí se han sugerido varias soluciones de alto nivel, todas las cuales nos darían la funcionalidad que estamos buscando.

También me encantaría tener esta función.

Requerido para todos los casos de uso que deberían evitar la pérdida de datos. Yo también necesito esto, cada solución es demasiado complicada.

Bien, equipo, ahora nos inclinamos hacia la funcionalidad que se describe aquí: https://github.com/xamarin/Xamarin.Forms/issues/6971#issuecomment -574823028

¿Alguna objeción?

@samhouts Eché un vistazo rápido al problema vinculado y, como aún no he usado shell, esto es más una pregunta. BackButtonBehavior es solo una envoltura (con algunos extras) alrededor de un comando que se ejecuta cuando un usuario intenta navegar hacia atrás.

Básicamente, no se trata de interceptar la navegación inversa, sino de tomar el control de lo que sucede exactamente cuando un usuario intenta navegar hacia atrás a través de cualquier método disponible (deslizar, botón de la barra de navegación, botón de Android, ..). Puedo decidir llevar al usuario a una nueva página en lugar de navegar hacia atrás si así lo decido, ¿es correcto?

@samhouts Tengo una intercepción en funcionamiento en mi aplicación de producción para iOS uwp y Android. iOS y Android usando un renderizador de páginas personalizado. Cuando el usuario regresa a través del botón de retroceso del software o hardware, puedo mostrar la ventana emergente "¿Descartar cambios?". Cuando el usuario confirma el mensaje, se ejecuta la navegación hacia atrás y aparece la página, el otro usuario permanece en la página actual. Todavía no he considerado que deslizar el dedo también es posible para Regresar, eso falta en mi Implementación

@samhouts : no me queda claro cómo la propuesta permite la interceptación del botón Atrás para agregar un paso condicional.

¿Funciona así la propuesta?

• si no se asigna {Shell, NaviationPage} .BackButtonCommand, el botón de retroceso se comporta normalmente y la navegación hacia atrás se produce automáticamente.
• Si se asigna {Shell, NaviationPage} .BackButtonCommand, no se produce automáticamente una navegación hacia atrás. La instancia de ICommand asignada puede hacer explícitamente algo como esto, dependiendo de si está usando Shell o no.

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

Algo así debería funcionar para mí, pero parece engorroso. Quizás no estoy viendo bien la propuesta. Sería útil ver los casos de uso detallados con ejemplos.

PD Al igual que @nschoenberg , también tengo intercepciones con renders personalizados en mis aplicaciones (en NavigationPage, haciendo algo como el método MyProcessBackButton anterior. Es bueno que la propuesta no requiera Shell; permitirá una adopción más fácil para nuestras aplicaciones más antiguas).

• si no se asigna {Shell, NaviationPage} .BackButtonCommand, el botón de retroceso se comporta normalmente y la navegación hacia atrás se produce automáticamente.

Así es como me imagino que funciona, a menudo queremos la funcionalidad predeterminada, si no anulada. Esto se comportaría de la misma manera que anular el botón de retroceso del dispositivo en Android y devolver verdadero. ¿No tiene sentido replicar esa implementación de alguna manera?

Como característica de la página, ¿tendría sentido algo como esto? Sería de gran ayuda si pudiéramos observar y cancelar la navegación inversa (de ahí la tarea). Además, podría ser útil poder distinguir qué causó que la solicitud regresara.

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 segunda opción factible que puedo ver es implementar esto como parte de la interfaz INavigation .

EDITAR: modificó ligeramente la API

En el problema https://github.com/xamarin/Xamarin.Forms/issues/6971#issuecomment -574823028, no estoy seguro de dónde se expondrá exactamente el BackButtonCommand, ¿se proporciona solo en NavigationPage? ¿Existe una única implementación en una NavigationPage que contiene y todas las páginas insertadas en esa pila de navegación utilizan el mismo comportamiento? (No creo que este sea un caso de uso típico). ¿Cómo implementan las páginas individuales su propia anulación y aprovechan el comando?

Creo que la propuesta proporcionada anteriormente satisfaría las necesidades de los desarrolladores de anular por página, ya que la invocación de la navegación hacia atrás es algo irrelevante, a menudo el desarrollador simplemente quiere controlar lo que ocurre en la navegación hacia atrás, es decir, solicitar algún diálogo de usuario antes de enviarlos a otra página o simplemente dejarla como predeterminada.

No puedo hablar por todos, pero tenemos casos en proyectos en los que implementamos alguna función que se ejecuta si se presiona el botón del software, también anulamos el OnBackButtonPressed que llama a la misma función. Dos formas de navegación hacia atrás que ejecutan el mismo código.

Todas estas propiedades funcionan igual que cualquiera de las propiedades adjuntas en NavigationPage

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

Puede simplemente aplicarlos a la página activa y NavigationPage reacciona. Las propiedades adjuntas son agradables porque se pueden vincular, por lo que puede configurarlas en una página y vincularlas a la máquina virtual.

<ContentPage NavigationPage.BackButtonCommand={Bindiing BackCommand}

Una de las ventajas de tener el comando simplemente "deshabilitar" el comportamiento predeterminado es que habilita la navegación asíncrona. Porque ahora el botón solo se enruta al comando y el comando puede hacer lo que sea durante el tiempo que quiera y luego puede usar apis de navegación para completar la navegación si así lo desea.

Hacer que todo sea asincrónico es interesante principalmente debido a escenarios como deslizar hacia atrás o deslizar para descartar en un modal porque no son nativamente "asíncronos", así que lo que también podríamos hacer aquí es aprovechar esos gestos, enrutar al comando y cancelar el gesto.

También podríamos convertirlo en un evento en la clase de navegación que podría disparar todo el camino hasta el proxy jerárquico y luego con un evento podría usar un comportamiento EventToCommand.

También me pregunto si NavigatingBack tiene sentido. Si vamos a tener algo así, también podríamos crear un evento de navegación similar a shell.

Me doy cuenta de que esto es un poco divagante :-) pero solo quería responder algunas preguntas y obtener algunas ideas para discutir

Puede simplemente aplicarlos a la página activa y NavigationPage reacciona. Las propiedades adjuntas son agradables porque se pueden vincular, por lo que puede configurarlas en una página y vincularlas a la máquina virtual.

<ContentPage NavigationPage.BackButtonCommand={Bindiing BackCommand}

@PureWeen, lo siento, olvidé que el acceso a las propiedades era posible en una página de esa manera y, de todos modos, tiene sentido hacerlo de esa manera.

¿El NavigationPage.BackButtonCommand consumiría el botón de retroceso del dispositivo también o solo el botón de retroceso del software? Dado que hay otras formas de invocar la navegación hacia atrás.

Actualmente estoy pensando que NavigationPage.BackButtonCommand desaparece y tenemos algo más generalizado. Solo necesito pensarlo un poco más.

Algo relacionado con pop / push podría tener sentido y coincidir con las apis existentes

No estos exactamente, pero algo parecido

UserRequestedPoppingCommand
UserRequestedPushingCommand

O posiblemente PoppingCommand y PushingCommand y luego podemos tener algo similar a sus argumentos que den contexto.

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

También me gustaría que todo se pudiera enlazar, pero todavía no he hecho clic en una idea que me guste mucho.

¿Quizás algo en Navegación que indique el estado actual de la navegación?
Entonces, si se hace a través de un comando, puede preguntar a Navigation si es un gesto en progreso u otro

¿Algún avance en esto? Hemos estado esperando esto durante más de un año.

¿Algún avance en esto? Hemos estado esperando esto durante más de un año.

Relajarse. Un año no es nada. SplitView con MasterDetail en iPad se informó hace más de 4 años que no funciona y tiene errores. En este momento, Xamarin.Forms todavía usaba Bugzilla.

@SebastianKruseWago Ese es un escenario completamente diferente a la funcionalidad esperada que ya existe en un área diferente. También arreglaron un "error" que permitía una solución. Entonces, un año es mucho, para algo que debería haberse incluido desde el primer día.

@ akemper1 SplitView también debería funcionar desde el primer día. También es un error porque solo es un problema con el iPad MasterDetailRenderer. Ha funcionado antes de 2.4 o así con una fea solución. Entonces no creo que sea diferente.

Hola, ¿hay alguna novedad?

@scriptBoris Las posibles soluciones son las siguientes en estos enlaces, una solución podría encajar mejor que la otra dependiendo de la estructura de su proyecto.

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/

He obtenido ambas soluciones de los enlaces en proyectos separados.

Buenas tardes, me disculpo por molestarte, pero ¿hay alguna noticia para solucionar este problema? О.О

Estoy actualizando la pregunta :)

<ContentPage NavigationPage.HasBackButton="False">

¿Hay alguna actualización sobre esto? Las soluciones presentadas en este hilo son más que aceptables, han pasado años y la gente está esperando esto.

¿Alguien del equipo de Xamarin puede comentar sobre el estado de esto? Este es realmente un gran problema para muchas personas.

Sé que puede hacer esto en shell, pero para muchas aplicaciones más grandes que aprovechan Prism o MVVMCross shell no es totalmente compatible, por lo que esto es algo que realmente necesitamos.

Gracias

Disculpas @ akemper1 pero no hay actualizaciones específicas actualmente.

No nos hemos olvidado de este, pero estamos un poco retrasados ​​en una API oficial para conformarnos. Hay algunos RP de Shell pendientes que influyen en el botón Atrás que se propagarán a las API que se utilizan aquí.

Estoy de acuerdo con muchos que dicen que este es un gran problema para ellos.

Sin embargo, voy a probar algunas de las soluciones. Solo quiero poder evitar que un usuario regrese hasta que "confirme" que perderá los cambios en la página en la que se encuentra.

¿Alguna noticia sobre esto? ha pasado mucho tiempo :(