Por que usar fragmentos do Android?


15

Li a documentação e os tópicos de algumas outras perguntas sobre esse tópico e não me sinto realmente convencido; Não vejo claramente os limites de uso dessa técnica.

Fragmentos agora são vistos como uma melhor prática ; toda atividade deve ser basicamente um suporte para um ou mais fragmentos e não chamar um layout diretamente.

Fragmentos são criados para:

  1. permitir o Activityuso de muitos fragmentos, alterar entre eles, reutilizar essas unidades ... ==> Fragmenté totalmente dependente Contextda atividade, por isso, se eu precisar de algo genérico que possa reutilizar e manipular em muitas atividades, posso crie meus próprios layouts ou visualizações personalizados ... Não me importarei com essa camada adicional de desenvolvimento de complexidade que os fragmentos adicionariam.

  2. uma manipulação melhor para diferentes resoluções ==> OK para tablets / telefones em caso de processo longo, pois podemos mostrar dois (ou mais) fragmentos na mesma atividade em tablets e um por um em telefones. Mas por que eu usaria fragmentos sempre ?

  3. manipulando retornos de chamada para navegar entre os fragmentos (ou seja: se o usuário estiver conectado, mostro um fragmento; caso contrário, mostro outro fragmento). ===> Tente ver quantos bugs o Facebook SDK Log-in tem por causa disso, para entender que é realmente (?) ...

  4. considerando que um Aplicativo Android é baseado em Atividades ... A adição de outros ciclos de vida na Atividade seria melhor para projetar um Aplicativo ... Quero dizer, os módulos, os cenários, o gerenciamento de dados e a conectividade seriam melhor projetados, pois caminho. ===> Esta é uma resposta de alguém que costumava ver o Android SDK e o Android Framework com uma visão Fragments. Não acho que esteja errado, mas não tenho certeza se dará bons resultados ... E é realmente abstrato ...

====> Por que complicaria minha vida, codificando mais, usando-as sempre? caso contrário, por que é uma prática recomendada se é apenas uma ferramenta para alguns casos? quais são esses casos?


1
Não está claro o que você está perguntando, poderia resumir a pergunta, talvez abaixo da enumeração das supostas vantagens e da sua crítica a cada uma?
logc 12/06

Eu adicionei uma pergunta detalhada.
ahmed_khan_89

Estou perdido como @logc. Como você lidaria com esses casos sem fragmentos?
neontapir

Eu dei o que eu faria sem os fragmentos: (1) criar controles genéricos personalizados e reutilizá-los onde eu quiser (2) usando 2 atividades e navegar com startActivityForResult, ou simplesmente mudar entre visualizações (mostrando / ocultando, inflando / removendo ...) sem codificar muito ... (3) você pode usar um retorno de chamada mesmo em Atividades com visualizações (4) É uma resposta abstrata que sempre recebo quando discuto esse tópico ... que precisa de mais explicações ...
ahmed_khan_89

1
Hmm. Esta sessão de perguntas e respostas mostra a limitação do design da stackexchange onde o pôster original escolhe a "melhor" resposta. (Ao contrário de slant.co, onde todos votam.) Não é o ideal para uma pergunta ampla como essa. Aqui, uma pergunta vaga obtém uma resposta aceita que obviamente concorda com o que o solicitante queria ouvir. Se você não vê razão para usar fragmentos na sua situação, não use . Uma pergunta melhor seria pedir prós / contras do fragmento versus atividade . E há muitos tópicos nesse tópico exato.
Página

Respostas:


5

Fragmento é uma seção modular de uma Atividade que possui seu próprio ciclo de vida, recebe seus próprios eventos de entrada, que você pode adicionar ou remover enquanto a atividade está em execução (como uma "sub atividade" que você pode reutilizar em diferentes atividades)

Além da vantagem óbvia de usar fragmentos, a otimização da interface do usuário em diferentes telas, ele permite gerenciar o processamento em segundo plano da atividade sem um componente visível da interface do usuário.

Agora...

====> Por que complicaria minha vida, codificando mais ... ??

Embora recomendado, você não precisa, a menos que planeje controlar o ciclo de vida de elementos individuais e / ou reutilizar o estado da pilha ou o histórico das visualizações anteriores.


5

Se houver um caso de uso de "gateway" para céticos em fragmentos, provavelmente serão diálogos. Os métodos de longa obsoleto showDialog(...), onCreateDialog(...)etc., foram Nice, em que o quadro iria chamá-los para destruir e recriar seus diálogos quando a atividade hospedagem foi destruído e recriado automaticamente. Se você criar seus próprios diálogos diretamente, precisará gerenciar tudo isso sozinho. Mas se você usar a DialogFragment, poderá novamente permitir que a estrutura os gerencie para você. Nesse caso, os fragmentos podem simplificar bastante sua codificação.


1

Eu fiz essa pergunta mais de um ano atrás.

Eu estou usando fragmentos todos os dias e eu recomendaria.

Antes de mais, quero dizer que o uso de fragmentos é apenas uma opção e será um reflexo a considerar quando você começar a usá-los.

Vantagens:

1 / ajuda a modularizar o código no qual você pode ter um fluxo completo em uma Atividade, em fragmentos separados. Exemplo: + lista / grade e detalhes, + login e registro e esqueça a senha, + etc. Isso é incrível para obter um código reutilizável, que você sempre pode copiar e colar em diferentes projetos.

2 / você tem um novo ciclo de vida, cheio de aborrecimentos, mas também com vantagens. Exemplo: o fragmento de instância retida é impressionante porque resolve o problema da orientação.

3 / você pode gerenciar o fluxo de seus fragmentos por eventos e ouvintes da Atividade.

4 / uma pilha de seus fragmentos em sua Atividade.

5 / use a mesma barra de ação em muitas telas.

E muitos outros...

Às vezes, ainda estou usando a atividade como apenas contêiner, especialmente para o caso da câmera. Algumas APIs do Android e algumas bibliotecas de terceiros não são fáceis de implementar em fragmentos.

Bem, é como qualquer ferramenta, você deve considerar e julgar por si mesmo se é melhor usá-lo em um caso ou outro.

Espero que isso possa ajudar!!!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.