Get.back() with Get or Get.snackbar

[douglasss]

First I want to thank you for this amazing lib!

I want to know if there is a way to not dismiss the "GetBar" when we do a "Get.back()" or the user press the back button.

I'm struggling with this because I have a Firebase Messaging Service running on the background, e some times the user can receive a notification on the screen with a Snackbar. And i really want to use your implementation, my life would be much easier. But when the user presses the back button or i use "Get.back", the "GetBar" is dismissed.

Is there a way to prevent this behavior?

[jonataslaw]

First I want to thank you for this amazing lib!

I want to know if there is a way to not dismiss the "GetBar" when we do a "Get.back()" or the user press the back button.

I'm struggling with this because I have a Firebase Messaging Service running on the background, e some times the user can receive a notification on the screen with a Snackbar. And i really want to use your implementation, my life would be much easier. But when the user presses the back button or i use "Get.back", the "GetBar" is dismissed.

Is there a way to prevent this behavior?

Oi, obrigado por abrir essa issue, provavelmente irei fixá-la em um futuro próximo, pois acredito que outras pessoas irão aparecer com essa mesma dúvida.
Estou respondendo em português, porque vi que és brasileiro, e fica melhor de explicar.

O Flutter trabalha com empilhamento de rotas, isso significa que quando você sai da screen A para a screen B, a screen A continua aberta, mas é sobreposta pela screen B. Se você definir a próxima rota com um container e cor transparente, vai ver que ao navegar para outra screen, você verá inteiramente a outra que está abaixo.
Para exibir snackbars, o Flutter criou uma OverlayRoute, que é uma rota parcial, que cobre certa porcentagem da tela, e deixa todo o resto transparente, e com acesso ao gestureDetector, por isso você consegue clicar em algo, mesmo com uma snackbar aparecendo.
Para exibir uma snackbar/overlayroute, era necessario o contexto de um widget material (porque a overlayRoute usa elementos do material) e por esse motivo as snackbars padrão exigem o context do Scaffold. Na verdade qualquer context serviria, mas quebraria os elementos de texto e icones, bem como cores que dependem de um pai que seja um widget material.
Para funcionar sem o context do scaffold eu modifiquei do zero a overlayRoute, e o PageRoute para trabalhar com o currentContext do Get, que é herdado da navigatorKey. Foi necessário dizer tudo isso, para que você entenda que, se por exemplo, desejas que uma snackbar seja exibida sobre todas screens independente da rota, isso não será possível com o Flutter. Estou com um projeto de reescrever o MaterialApp do framework do zero para ter um contexto global, e um midleware descente de rotas (o que possibilitaria isso), mas isso ainda está em pré-alpha e por mais que gostaria de terminar, não tenho muito tempo disponível. Se sua issue foi sobre o comportamento de não fechar a screen, e sim a snackbar usando o botão voltar, esse comportamento foi planejado por razões de vazamento de memoria. O Get tem um ganho extraordinário de desempenho em apps com muitas screens justamente por centralizar toda navegação do aplicativo em uma única classe, ao contrário do framework que abre uma instância para cada navegação e sai dando rebuild no materialApp pra o coletor de lixo se virar para realocar memória e o app não entrar em colapso(vide: https://www.youtube.com/watch?v=yVBqT6hg4VA&t=7s). É um grande framework, o melhor que trabalhei para falar a verdade, no entanto, algumas coisas parecem que foram feitas às pressas, com muitas gambiarras que até hoje estão lá (a navegação é o maior exemplo disso, e por isso criei essa lib), mas posso inserir algo no futuro como "backOnPop" para ele fechar a snackbar juntamente com a current screen. No entanto, snackbar sobre todas screens com o framework atual não é possível (possível é com uma gambiarra chamada mapa de globalkeys, que vai te levar ao conjunto de piores práticas que podem se praticar no framework).
Se tiver qualquer dúvida à respeito disso, ou qualquer outro problema, não exite em abrir uma issue.

[douglasss]

Entendi, obrigado pela explicação. Vou encontrar uma outra forma de contornar meu problema. Essa parte de rotas no flutter realmente exige uma lib a parte para gerenciamento, não parece muito performática.

[rodrigorslima]

Entendi, obrigado pela explicação. Vou encontrar uma outra forma de contornar meu problema. Essa parte de rotas no flutter realmente exige uma lib a parte para gerenciamento, não parece muito performática.

quando você usa getBack() e logo em seguida faz mostrar uma snackBar, é melhor usar o getBack(closeOverlay: true) para não fazer o button de back deixar de funcionar enquanto a snackBar estiver aberta