Xamarin.forms: Não é possível interceptar o botão Voltar do software

Tivemos uma discussão semelhante aqui. É isso que você está procurando? https://forums.xamarin.com/discussion/100287/allow-a-single-place-to-handle-back-button-requests-with-async-support

@samhouts Sim, esse é exatamente o nosso problema. O retorno de chamada mencionado acima precisa ser adicionado à base de código ou o método existente precisa ser aprimorado para incluir eventos do botão Voltar do software.

@samhouts esse bug

Eu concordo no ponto que OnBackButtonPressed deve lidar com BackButtons Hard e Software. No entanto, não é tão difícil interceptar os dois. Eu bloguei sobre esse tópico aqui: https://msicc.net/xamarin-forms-the-mvvmlight-toolkit-and-i-taking-control-over-the-back-buttons/

@MSiccDev Se continuarmos trabalhando em torno dos problemas apresentados pelo framework, então ele nunca será consertado e as pessoas terão que continuar fazendo isso por si mesmas repetidamente até o fim da tecnologia.

@AceCoderLaura true de um lado. Por outro lado, é preciso seguir em frente. A melhor coisa a fazer é contornar, mas relatar o problema.

Essas soluções alternativas quebram o menu de hambúrguer na página raiz ...
-.-

@AceCoderLaura Estou usando em um dos meus aplicativos com uma página MD sem problemas ...

@MSiccDev
Esta é minha solução alternativa para o 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 Seu OnOptionsItemSelected é acionado após clicar no botão nav-back oO No meu caso, nada aconteceu ... (Android)

Existe algum progresso para este problema? Eu tenho vários Navigationviews aninhados e seria ultra hacky corrigir isso em meu aplicativo. Eu concordo com @AceCoderLaura que isso deve ser corrigido por xamarin.

Mesmo problema. Eu acho que é bastante comum lidar com eventos em aplicativos corporativos. Deve ser consertado o mais rápido possível.

Corrija isso, ele foi relatado por quase um ano e é ridículo não tê-lo ainda.

@ddobrev Você está certo, este é um recurso muito útil, mas infelizmente ainda não foi definido claramente como ele deve funcionar. Alguém mencionou acima, mas não obteve resposta:

Sim, esse é exatamente o nosso problema. O retorno de chamada mencionado acima precisa ser adicionado à base de código ou o método existente precisa ser aprimorado para incluir eventos do botão Voltar do software.

Se isso tivesse sido claramente definido, eu teria tentado fazer um PR para implementá-lo.

Não sei por que, mas no meu caso (no Android) foi o suficiente para adicionar isso à minha MainActivity

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

            base.OnPostCreate(savedInstanceState);
        }

Com isso, OnBackButtonPressed é disparado mesmo se eu pressionar o botão Voltar do hardware e o botão Voltar do software na barra de navegação. Mas não entendo por quê.

No iOS, eu ainda precisava adicioná-lo com um renderizador de página personalizado.

Então, isso será corrigido no 3.6.0?

Acho que foi movido para Em andamento por engano.

@samhouts então ele precisa de especificações agora? O que não foi especificado sobre isso?

@ddobrev ainda precisamos especificar a melhor maneira de expor o que as pessoas desejam. Atualmente, OnBackButtonPressed mapeia mais especificamente para o botão Voltar do hardware, de modo que os recursos dele giram mais em torno dele. Muito do que as pessoas querem é mais um recurso OnNavigatingBack.

Apenas amarrar a seta de retorno do software a esse método agora ainda parece mais um hack do que fornecer a melhor solução

Por exemplo, apenas descontinuando OnBackButtonPressed e criando

OnHardwareBackButtonPressed e OnNavigatingBack

Bem, de qualquer maneira está bom. Apenas faça. Já faz tempo suficiente.

Como um recurso de página, algo assim faria sentido? Seria extremamente útil se pudéssemos observar e cancelar a navegação reversa (daí a Tarefa \

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

A segunda opção viável que posso ver é implementar isso como parte da interface INavigation .

EDIT: modificou ligeiramente a API

A solução @pikausp parece a melhor para mim

Além disso, acho que seria ótimo expandir isso ainda mais e introduzir algo semelhante ao "Estado da página".

A página pode estar ativa ou inativa.

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

Quando a página é navegada para fora de OnDeactivating é invocado. O valor de IsPermanent é baseado em se a página é mantida ou não na pilha de navegação (verdadeiro para pops, falso para pushes).

Possivelmente introduzir OnActivated e OnDeactivated que são invocados assim que a navegação é completada.

Isso dá ao desenvolvedor um grande poder de fluxo de navegação.

Quais são seus pensamentos?

Você se importaria de relatar qualquer progresso aqui, por favor?

Alguma maneira de aumentar a prioridade?
Tive soluções alternativas durante anos, que às vezes não funcionavam mais, ...
Minha solução alternativa atual também é um hack muito ruim com desvantagens, adoraria remover meus renderizadores de página de navegação personalizados para sempre e corrigir alguns problemas no processo.

Ressalto

Qualquer atualização sobre a interceptação do botão soft back. Estamos realmente lutando nisso. Nenhuma solução mencionada neste post funciona para nós.

Isso é realmente necessário. Ter que hackear ou implementar sua própria barra de ferramentas é um exagero para uma omissão tão óbvia. Por favor ...

Alguma atualização aqui @samhouts ?
Parece que várias soluções de alto nível foram sugeridas aqui, todas elas nos dariam a funcionalidade que procuramos.

Também adoraria ter esse recurso.

Obrigatório para todos os casos de uso que devem evitar a perda de dados. Eu preciso disso também, toda solução alternativa é muito hacky.

Ok, equipe, agora estamos nos inclinando para a funcionalidade descrita aqui: https://github.com/xamarin/Xamarin.Forms/issues/6971#issuecomment -574823028

Alguma objeção?

@samhouts Dei uma olhada rápida no problema do BackButtonBehavior é apenas um invólucro (com alguns extras) em torno de um comando que é executado quando um usuário tenta navegar de volta?

Basicamente, não se trata de interceptar a navegação reversa, mas sim de controlar o que exatamente acontece quando um usuário tenta navegar de volta por meio de qualquer método disponível (deslizar, botão da barra de navegação, botão do Android, ..). Posso decidir navegar com o usuário para uma nova página em vez de navegar de volta se decidir isso, correto?

@samhouts Tenho uma interceptação funcional em meu aplicativo de produção para iOS uwp e Android. iOS e Android usando o renderizador de página personalizado. Quando o usuário navega de volta por meio do botão Voltar do software ou do hardware, posso mostrar o pop-up "Descartar alterações?". Quando o usuário confirma o prompt, a navegação de retorno é executada e a página é exibida, o outro usuário permanece na página atual. Ainda não considerei que deslizar também é possível voltar, isso está faltando na minha implementação

@samhouts - Não está claro para mim como a proposta permite a interceptação do botão Voltar para adicionar uma etapa condicional.

A proposta funciona assim?

• se {Shell, NaviationPage} .BackButtonCommand não for atribuído, o botão Voltar se comporta normalmente e a navegação volta ocorre automaticamente.
• Se {Shell, NaviationPage} .BackButtonCommand for atribuído, nenhuma navegação de volta ocorrerá automaticamente. A instância ICommand atribuída pode fazer algo assim explicitamente, dependendo se você está ou não usando o 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(); }

Algo assim deve funcionar para mim, mas parece complicado. Talvez eu não esteja vendo a proposta direito. Seria útil ver os casos de uso detalhados com exemplos.

PS Como @nschoenberg , também tenho interceptação com renderizações personalizadas em meus aplicativos (em NavigationPage, fazendo algo como o método MyProcessBackButton acima. É bom que a proposta não exija Shell - permitirá uma adoção mais fácil para nossos aplicativos mais antigos).

• se {Shell, NaviationPage} .BackButtonCommand não for atribuído, o botão Voltar se comporta normalmente e a navegação volta ocorre automaticamente.

É assim que eu imagino que funcione, muitas vezes queremos a funcionalidade padrão, senão substituída. Isso se comportaria da mesma forma que substituir o botão Voltar do dispositivo no Android e retornar verdadeiro. Não faz sentido replicar essa implementação de alguma forma?

Como um recurso de página, algo assim faria sentido? Seria extremamente útil se pudéssemos observar e cancelar a navegação reversa (daí a tarefa) Além disso, pode ser útil distinguir o que fez a solicitação navegar de volta.

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

A segunda opção viável que posso ver é implementar isso como parte da interface INavigation .

EDIT: modificou ligeiramente a API

No problema https://github.com/xamarin/Xamarin.Forms/issues/6971#issuecomment -574823028, não tenho certeza exatamente onde o BackButtonCommand será exposto, é fornecido apenas na NavigationPage? Existe uma única implementação em uma NavigationPage que contém e todas as páginas enviadas para essa pilha de navegação usam o mesmo comportamento? (Não acho que esse seja um caso de uso típico). Como as páginas individuais implementam sua própria substituição e tiram proveito do comando?

Acho que a proposta fornecida acima satisfaria as necessidades dos desenvolvedores para substituir por página, uma vez que a invocação da navegação traseira é algo irrelevante, muitas vezes o desenvolvedor deseja simplesmente controlar o que ocorre na navegação traseira, ou seja, solicitar algum diálogo do usuário antes de enviá-lo para outra página ou simplesmente deixe como padrão.

Não posso falar por todos, mas temos casos em projetos onde implementamos alguma função que é executada se o botão do software for pressionado, também substituímos o OnBackButtonPressed que chama a mesma função. Duas formas de navegação traseira executando o mesmo código.

Todas essas propriedades funcionam da mesma forma que qualquer uma das propriedades anexadas em NavigationPage

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

Você pode apenas aplicá-los à página ativa e a NavigationPage reage. As propriedades anexadas são boas porque são vinculáveis, então você pode simplesmente configurá-las em uma página e vinculá-las à VM.

<ContentPage NavigationPage.BackButtonCommand={Bindiing BackCommand}

Uma das vantagens de ter o comando apenas "desabilitado" o comportamento padrão é que ele habilita a navegação assíncrona. Porque agora o botão apenas direciona para o comando e o comando pode fazer o que quiser pelo tempo que quiser e então ele pode usar as apis de navegação para completar a navegação, se quiser.

Tornar tudo assíncrono é interessante principalmente por causa de cenários como deslizar para trás ou deslizar para dispensar em um modal, porque eles não são nativamente "assíncronos", então o que também podemos fazer aqui é tocar nesses gestos, encaminhar para o comando e cancelar o gesto.

Também poderíamos torná-lo um evento na classe Navigation que poderia disparar todo o caminho até o proxy hierárquico e, em seguida, com um evento, você poderia usar um comportamento EventToCommand.

Também me pergunto se NavigatingBack faz sentido. Se vamos ter algo assim, podemos simplesmente criar um evento de navegação semelhante ao shell.

Sei que isso é um pouco confuso :-) mas só queria responder a algumas perguntas e colocar algumas ideias para discussão

Você pode apenas aplicá-los à página ativa e a NavigationPage reage. As propriedades anexadas são boas porque são vinculáveis, então você pode simplesmente configurá-las em uma página e vinculá-las à VM.

<ContentPage NavigationPage.BackButtonCommand={Bindiing BackCommand}

@PureWeen sorry esqueci que o acesso às propriedades era possível em uma página dessa maneira e faz sentido fazê-lo dessa forma de qualquer maneira.

O NavigationPage.BackButtonCommand consumiria também o botão Voltar do dispositivo ou apenas o botão Voltar do software? Uma vez que existem outras maneiras de invocar a navegação de retorno.

Atualmente estou pensando que NavigationPage.BackButtonCommand vai embora e temos algo mais generalizado. Só preciso pensar um pouco mais.

Algo vinculado a pop / push pode fazer sentido e corresponder às apis existentes

Não exatamente, mas algo nesse sentido

UserRequestedPoppingCommand
UserRequestedPushingCommand

Ou possivelmente PoppingCommand e PushingCommand e então podemos ter algo semelhante aos seus argumentos que fornecem contexto.

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

Eu gostaria de tornar tudo vinculável também, mas ainda não entrei em uma ideia de que gosto muito ainda.

Talvez algo na Navegação que indique o estado atual da navegação?
Então, se for feito via comando, você pode perguntar à Navegação se é um gesto em andamento ou outro

alguma atualização disso? Estamos esperando por isso há mais de um ano.

alguma atualização disso? Estamos esperando por isso há mais de um ano.

Relaxar. Um ano não é nada. SplitView com MasterDetail no iPad foi relatado há mais de 4 anos que ele não funciona e está bugado. Nesse momento, o Xamarin.Forms ainda estava usando o Bugzilla.

@SebastianKruseWago Esse é um cenário completamente diferente da funcionalidade esperada que já existe em uma área diferente. Eles também consertaram um "bug" que permitia uma solução alternativa. Portanto, um ano é muito, para algo que deveria ser incluído desde o primeiro dia.

@ akemper1 SplitView também deve funcionar desde o primeiro dia. Também é um bug porque é apenas um problema com o iPad MasterDetailRenderer. Funcionou antes do 2.4 ou mais com uma solução alternativa feia. Então eu não acho que seja diferente.

Olá, alguma novidade?

@scriptBoris Possíveis soluções são as seguintes nesses links, uma solução pode se encaixar melhor do que a outra, dependendo da estrutura do projeto.

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/

Eu obtive ambas as soluções dos links em projetos separados.

Boa tarde, Peço desculpas por incomodá-lo, mas há alguma novidade para solucionar esse problema? О.О

Estou atualizando a pergunta :)

<ContentPage NavigationPage.HasBackButton="False">

Existe alguma atualização sobre isso? As soluções apresentadas neste segmento são mais do que aceitáveis, já faz anos e as pessoas estão esperando por isso.

Alguém da equipe Xamarin pode comentar sobre o status disso? Este é realmente um grande problema para muitas pessoas.

Eu sei que você pode fazer isso no shell, mas para muitos aplicativos maiores que tiram proveito do Prism ou MVVMCross, o shell não é totalmente compatível, então isso é algo de que realmente precisamos.

Obrigado

Apologies @ akemper1, mas nenhuma atualização específica atualmente.

Não nos esquecemos deste, mas estamos apenas um pouco atrasados ​​em uma API oficial para estabelecermos. Existem alguns Shell PRs pendentes que influenciam o Botão Voltar que se propagam para as APIs usadas aqui

Concordo com muitos que dizem que este é um grande problema para eles.

Vou tentar algumas das soluções alternativas. Só quero evitar que um usuário volte até "confirmar" que perderá as alterações na página em que está.

alguma notícia sobre isso? já faz muito tempo :(