Ao longo dos anos, tenho visto diferentes implementações do padrão de navegação Android. Alguns aplicativos usaram apenas atividades, enquanto outras atividades foram misturadas com snippets e / ou visualizações personalizadas ( Visualizações personalizadas )

Uma das minhas implementações de padrão de fragmento favoritas é baseada na filosofia “One-Activity-Multiple-Fragments” (“ One-Activity-Multiple-Fragments ”), Ou simplesmente o padrão de navegação de fragmento ( Padrão de navegação de fragmento ), em que cada tela no aplicativo é um fragmento de tela inteira e todos ou a maioria desses fragmentos estão dentro de uma atividade.

Essa abordagem não apenas simplifica como a navegação é implementada, mas também tem melhor desempenho e, portanto, oferece a você uma melhor experiência do usuário.

Neste artigo, exploraremos algumas implementações de padrões de navegação comuns no Android e, em seguida, apresentaremos o padrão de navegação baseado em snippet. Um aplicativo de amostra que implementa esse padrão pode ser encontrado em GitHub .

Um mundo de atividades

Um aplicativo Android típico que usa apenas atividades é organizado em uma estrutura do tipo Árvore (precisamente em um gráfico direcionado) onde a atividade principal é iniciada pelo lançador . Ao navegar no aplicativo, há um “ pilha de volta ”Da atividade que é mantida graças ao Sistema Operacional.

Um exemplo simples é mostrado no diagrama a seguir:

A atividade A1 é o ponto de entrada do nosso aplicativo (por exemplo, representa uma tela inicial ou um menu principal) e a partir desse ponto o usuário pode navegar para A2 ou A3. Quando você precisa se comunicar entre as atividades, você pode usar startActivityForResult () Ou você pode compartilhar um objeto lógico de negócios acessível globalmente entre as duas atividades.

Quando você precisar adicionar uma nova atividade, você deve seguir os seguintes passos:

• Defina a nova atividade
• Registre-se em AndroidManifest.xml
• Abra-o com um startActivity () de outra atividade

Embora este diagrama de navegação seja uma abordagem bastante simplificada; mas pode ficar muito complicado quando você precisa manipular de pilha de volta ou quando você tem que reutilizar a mesma atividade várias vezes, por exemplo, quando você deseja que o usuário navegue por telas de tutoriais diferentes, mas cada tela usa a mesma atividade como base.

Felizmente, temos ferramentas para esses casos chamadas tarefas e alguns guias para um navegação de pilha de volta apropriado .

como encontrar o número do cartão de crédito

Então, com a API de nível 11, os fragmentos chegaram ...

Um Mundo de Fragmentos

O Android introduz snippets no Android 3.0 (API de nível 11), principalmente para oferecer suporte a layouts de IU mais dinâmicos e flexíveis em telas grandes, como tablets. Como a tela de um tablet é muito maior do que a de um telefone, há mais espaço para misturar e combinar os componentes da IU. Os snippets suportam esses layouts sem a necessidade de você gerenciar alterações complexas na hierarquia de visualização. Ao quebrar o layout de uma atividade em pedaços, você pode modificar a aparência da atividade em tempo de execução e manter essas mudanças em uma pilha de atividades gerenciada pela atividade. - citação do Guia do Google API para fragmentos .

Este novo brinquedo permitiu que os desenvolvedores criassem uma interface de usuário com vários painéis e pudessem reutilizar os componentes em outras atividades. Alguns desenvolvedores adoram isso, enquanto outros não tanto . O uso ou não de snippets é um debate popular, mas acho que todos concordarão que os snippets trouxeram complexidade adicional e os desenvolvedores precisam entendê-los corretamente para usá-los.

O pesadelo do fragmento de tela inteira no Android

Comecei a ver mais e mais exemplos em que os fragmentos não apenas representavam uma parte da tela, mas a tela inteira era um fragmento dentro de uma atividade. Houve um tempo em que vi um layout em que cada atividade tinha exatamente um fragmento de tela inteira e nada mais, e a única razão pela qual essas atividades existiam era para armazenar os fragmentos. Além da falha de projeto, há outro problema com essa abordagem. Dê uma olhada no diagrama abaixo:

Como A1 pode se comunicar com F1? O que acontece é que A1 tem controle total sobre F1, porque criou F1. A1 pode passar um pacote, por exemplo, na criação de F1 ou pode invocar seus métodos públicos. Como F1 pode se comunicar com A1? Bem, isso é mais complicado, pode ser resolvido com um padrão de retorno de chamada / observador onde A1 assina F1 e F1 notifica A1.

Mas como A1 e A2 podem se comunicar? Conforme explicado acima, eles poderiam se comunicar via startActivityForResult () .

E agora a verdadeira questão: como F1 e F2 podem se comunicar? Mesmo neste caso, podemos ter um componente de lógica de negócios que é globalmente acessível e pode ser usado para transmitir dados. Mas esse componente nem sempre equivale a um design sofisticado. E se F2 precisar passar informações para F1 mais diretamente? Nesse caso, com um padrão ligue de volta F2 pode notificar A2, então A2 termina com um resultado e esse resultado pode ser armazenado por A1 que pode notificar F1.

Esta abordagem requer muito código chapa de ebulição e rapidamente se torna uma fonte de insetos , dor e raiva.

E se pudéssemos nos livrar de todas as atividades e ficar com apenas uma delas, que manterá o resto dos fragmentos?

elementos e princípios da lista de design

Padrão de navegação de fragmento

Com o tempo, comecei a usar o padrão 'One-Activity-Multiple-Fragments' na maioria dos meus aplicativos e ainda o uso. Existem muitas discussões por aí sobre esta abordagem ou filosofia, por exemplo Aqui Y Aqui . O que perdi foi um exemplo específico que posso ver e testar por mim mesmo.

Vejamos o seguinte diagrama por um momento:

Agora temos apenas uma atividade de contêiner e vários fragmentos que estão novamente em uma estrutura do tipo Árvore. A navegação entre eles é feita pelo FragmentManager , isso tem seu pilha de volta .

como fazer um vídeo em efeitos posteriores

Você vai perceber que agora não temos o startActivityForResult () mas podemos implementar o padrão retorno de chamada / observador . Agora, vamos ver alguns prós e contras dessa abordagem:

Prós:

1. Mais limpo e mais fácil de manter AndroidManifest.xml

Agora que temos apenas uma atividade, não precisamos mais atualizar o manifesto cada vez que adicionamos uma nova tela. Ao contrário das atividades, não temos que declarar os fragmentos.

Isso pode parecer uma coisa pequena, mas para aplicativos maiores com mais de 50 atividades, isso pode melhorar significativamente a legibilidade do AndroidManifest.xml Arquivo.

Observe o arquivo de manifesto do aplicativo de amostra, que possui várias telas. O arquivo de manifesto é super simples.

package='com.exarlabs.android.fragmentnavigationdemo.ui' >

2. Gerenciamento de navegação centralizado

No meu código de exemplo, você notará que eu uso NavigationManager que no meu caso, é injetado em cada um dos fragmentos. Este gerenciador pode ser usado como um local central para o exploração madeireira , gestão pilha de volta entre outros, para que os comportamentos de navegação sejam desacoplados do resto da lógica de negócios e não se espalhem por implementações de telas diferentes.

Vamos imaginar uma situação em que desejamos iniciar uma tela, onde o usuário pode selecionar alguns itens de uma lista de pessoas. Você também gostaria de passar alguns argumentos de filtragem, como idade, ocupação e sexo.

No caso de Atividades, você escreveria:

Intent intent = new Intent(); intent.putExtra('age', 40); intent.putExtra('occupation', 'developer'); intent.putExtra('gender', 'female'); startActivityForResult(intent, 100);

Então você deve definir onActivityResult em algum lugar para baixo e lidar com o resultado.

@Override protected void onActivityResult(int requestCode, int resultCode, Intent data) { super.onActivityResult(requestCode, resultCode, data); }

Meu problema pessoal com essa abordagem é que esses argumentos são 'extras' e não são obrigatórios, então tenho que ter certeza de que a atividade de recebimento trata dos diferentes casos, quando um extra está faltando. Posteriormente, quando uma refatoração for feita e quando o extra, por exemplo, 'idade' não for mais necessário, eu tenho que examinar todo o código onde esta atividade começou e ter certeza de que todos os extras estão corretos.

Além disso, não seria melhor se o resultado (lista de pessoas) chegasse como _Lista_ e não em uma forma serial que precisa ser desserializada?

No caso da navegação baseada em snippet, tudo é mais simples. Tudo que você precisa fazer é escrever um método no NavigationManager chamado startPersonSelectorFragment () com os argumentos necessários e com uma implementação ligue de volta .

mNavigationManager.startPersonSelectorFragment(40, 'developer', 'female', new PersonSelectorFragment.OnPersonSelectedListener() { @Override public boolean onPersonsSelected(List selection) { [do something] return false; } });

Ou com RetroLambda

mNavigationManager.startPersonSelectorFragment(40, 'developer', 'female', selection -> [do something]);

3. Melhores formas de comunicação entre as telas

Entre as atividades, só podemos compartilhar um Pacote que contém dados primitivos ou serializados. Agora, com fragmentos, podemos implementar um padrão ligue de volta onde, por exemplo, F1 pode ouvir F2 passando objetos arbitrários. Por favor, dê uma olhada nos exemplos de implementação anteriores de ligue de volta , que retorna uma _List_.

4. Criar fragmentos é menos caro do que criar atividades

Isso se torna óbvio quando você usa uma gaveta que tem, por exemplo, 5 itens de menu e em cada página a gaveta deve ser exibida novamente.

No caso de navegação pura atividade, cada página deve inflar e iniciar a gaveta, mas é claro que isso é caro.

No diagrama mostrado, você pode ver vários fragmentos de raiz ou fragmentos de raiz (FR *) que são os trechos de tela que podem ser acessados ​​diretamente da gaveta, e também a gaveta só é acessível quando esses trechos são exibidos. Tudo à direita da linha marcada no diagrama está lá como um exemplo de um esquema de navegação arbitrário.

Uma vez que a atividade contida contém a gaveta, temos apenas uma instância da gaveta, portanto, cada etapa de navegação onde a gaveta deve estar visível você não tem que começar de novo . Ainda não está convencido de como tudo funciona? Dê uma olhada em meu aplicativo de amostra, onde o uso de gavetas é demonstrado.

Contras

Meu grande medo sempre foi que, se eu usar o padrão de navegação de fragmento em um projeto, em algum momento eu encontrarei algum problema desconhecido que será difícil de resolver em torno da complexidade dos fragmentos, bibliotecas de terceiros e diferentes versões do System Operacional. E se eu tivesse que refratar tudo que fiz até agora?

uma das maneiras que os invasores podem acessar não criptografados

Na verdade, você teria que resolver os problemas com fragmentos aninhados , bibliotecas de terceiros que usam snippets como ShinobiControls , ViewPagers Y FragmentStatePagerAdapters .

Admito que obter experiência suficiente com fragmentos para resolver esses problemas foi um processo longo. Mas, em cada caso, o problema não era que a filosofia fosse ruim, mas que ele não entendia os fragmentos o suficiente. Mas se você entender os fragmentos melhor do que eu naquela época, não terá problemas.

Os únicos contras que posso citar agora é que podemos encontrar problemas que não são triviais de resolver, pois não existe uma biblioteca madura que mostre todos os cenários complexos de uma aplicação complexa com navegação baseada em fragmentos.

conclusão

Neste artigo, vimos uma alternativa para implementar a navegação em um aplicativo Android . O padrão foi comparado à filosofia de navegação tradicional que usa atividades e vimos algumas razões muito boas pelas quais é vantajoso usar fragmentos em vez da abordagem tradicional.

Caso você ainda não tenha revisado, verifique o aplicativo de demonstração na implantação GitHub . Não tenha medo de contribuir com bons exemplos que possam demonstrar melhor seu uso.

Relacionado: Os 10 erros mais comuns cometidos pelos desenvolvedores Android