Imaginando que temos um aplicativo que agora esta crescendo. Novos desafios vão surgindo com o tamanho crescente e provável que algumas informações serão compartilhadas com as várias páginas, tais como usuário, algum código de identificação, temas… não faltarão dados a serem compartilhados de forma global. Binding vai ajudar nisto.
Com Binding você pode indicar todos os “controllers” que serão utilizado ao longo das páginas, alguns instanciados logo na entrada e outros quando o usuário fizer uma solicitação tardia (Lazy Load) do controle.
Para carga tardia de “Controller” Get possui um método Get.lazyPut(….) que põe o controle na pilha global e deixa lá para ser instanciado quando for chamado.
class <strong>Setup</strong> extends Bindings { @override void dependencies() { /// inicialização <strong>Get.lazyPut<Controller>(()</strong> => Controller(0)); Get.lazyPut<ControllerX>(() => ControllerX(0)); } }
Usando Get.lazyPut(..) o chamada ao “binding” vai associado as páginas que vão consumir os controles. A chamada a Setup.dependencias é feito ao abrir uma nova página que referencia a ela:
return <strong>GetMaterialApp</strong>( title: 'Flutter Demo', namedRoutes: { '/': GetRoute( page: MyHomePage(title: 'Flutter Demo Get'), <strong>binding: Setup(),</strong> ), }, initialRoute: '/', );
Aqui cabe algumas considerações. Usando Get.put( classe() ), a instancia é criado de imediato e não faz checagem se já foi instanciado em operação anterior, portanto seu uso deve levar em consideração se é desejável manter varias instancias do mesmo controle. Com Get.lazyPut(…) este problema é evitado. Além de por na pilho, ele também checa a sua existência fazendo funcione como um singleton reutilizando a mesma instancia – sendo adequado para controle global do dado. Mesmo nas situações de apontar para o memo binding mais de uma vez, a instância será única.
Ainda cabe um consideração sobre o comportamento “errático” do Get.lazyPut(…) que talvez poderia ser melhorado. Se a chamada do Get.lazyPut(…) for chamada fora de uma situação que se deseja uma instância de imediato – não tem este comportamento, chamou – cria a instância, quando o ideal seria instância somente quando executa o Get.find<>() ou quando fosse utilizar de fato.
Este comportamento compromete ter um único binding para várias situações, impondo a criação de “bindings” diferentes para a diversidade de controles desejados. Se uma página não consome um determinado controller irá exigir que tenha “binding” separado do principal, quando o ideal seria mantê-lo somente o seu tipo na pilha e não a sua instância, permitindo declará-lo mesmo quando ainda não se sabe o momento do uso.
Se gostou, deixa seu “like” na página e comentários para nos motivar a continuar escrevendo… Não gostou, não tem problema, gostaria de saber sua opinião mesmo assim.