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:
permitir o
Activity
uso de muitos fragmentos, alterar entre eles, reutilizar essas unidades ... ==>Fragment
é totalmente dependenteContext
da 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.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 ?
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 (?) ...
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?