Uma atividade e todos os outros fragmentos [fechados]

Estou pensando em implementar uma tela com Activitye todas as outras telas com Fragmentse managing all the fragments thru the activity.

É uma boa ideia? e minha resposta é NÃO, mas ainda quero saber mais claramente sobre esse pensamento.

Quais são os prós e os contras da ideia?

Nota:

Por favor, não me dê o link para fragmento e atividade.

EDITAR:

Aqui está algo sobre Fragmentos e atividade:

Prós:

1. Fragmentos devem ser usados ​​com atividades como uma sub atividade.
2. Fragmentos não substituem as atividades.
3. Fragmentos destinam-se à reutilização (é necessário saber de que maneira a reutilização pode ser alcançada.).
4. Fragmentos são a melhor maneira de escrever código para suportar tablets e telefones.

Contras:

1. Precisamos implementar a interface para obter os dados dos fragmentos.
2. Para o diálogo, precisamos percorrer um longo caminho para mostrá-lo.

Por que devemos usar fragmentos se não estamos considerando comprimidos? Qual é a diferença de horário de início entre atividade e fragmento?

Depende do aplicativo que você está criando. Criei vários aplicativos usando as duas abordagens e não posso dizer que uma maneira é sempre melhor que a outra. O aplicativo mais recente que criei, usei a Activityabordagem única e uma navegação no estilo do Facebook. Ao selecionar itens da lista de navegação, atualizo um único Fragmentcontêiner para exibir essa seção.

Dito isto, ter um single Activitytambém apresenta muitas complexidades. Digamos que você tenha um formulário de edição e, para alguns dos itens que o usuário precise selecionar ou criar, exija que eles acessem uma nova tela. Com as atividades, chamaríamos apenas a nova tela, startActivityForResultmas, como Fragmentsnão existe, você acaba armazenando o valor no Activitye fazendo com que o fragmento de edição principal verifique Activityse os dados foram selecionados e devem ser exibidos ao usuário.

O que Aravind diz sobre ficar preso a um único Activitytipo também é verdade, mas não é realmente esse limite. Sua atividade seria uma FragmentActivity e, desde que você não precise de um MapView, não haverá limitações reais. No entanto, se você deseja exibir mapas, isso pode ser feito, mas você precisará modificar a Biblioteca de Compatibilidade do Android para FragmentActivityestender MapActivityou usar o android-support-v4-googlemaps publicamente disponível .

Por fim, a maioria dos desenvolvedores que conheço que seguiram a única Activityrota retornaram a várias atividades para simplificar seu código. No que diz respeito à interface do usuário, em um tablet, algumas vezes você fica preso usando um único Activitypara alcançar a interação sempre louca que seus designers criam :)

- EDITAR -

O Google finalmente foi lançado MapFragmentna biblioteca de compatibilidade, para que você não precise mais usar o hack android-support-v4-googlemaps. Leia sobre a atualização aqui: API Android do Google Maps v2

- EDIÇÃO 2 -

Acabei de ler este ótimo post sobre o estado moderno (2017) dos fragmentos e lembrei-me dessa resposta antiga. Pensei em compartilhar: Fragmentos: a solução para todos os problemas do Android

Estou prestes a terminar um projeto (5 meses em desenvolvimento), com 1 atividade e 17 fragmentos, todos em tela cheia. Este é o meu segundo projeto baseado em fragmentos (o anterior era de 4 meses).

Prós

• A atividade principal é de 700 linhas de código, gerenciando bem a ordem da navegação dos fragmentos.
• Cada fragmento é bem separado em sua própria classe e é relativamente pequeno (~ algumas centenas de linhas de material da interface do usuário).
• A gerência pode dizer: "ei, que tal mudarmos a ordem dessas telas", e eu posso fazer isso com muita facilidade, pois esses fragmentos não dependem um do outro, todos se comunicam por meio da atividade. Não preciso vasculhar atividades individuais, para descobrir onde elas se chamam.
• meu aplicativo tem muitos gráficos pesados ​​e nunca funcionaria como uma atividade na tela 1. Todas essas sub-atividades na memória fariam o aplicativo ficar sem memória o tempo todo, então eu teria que fazer finish()todas as atividades não visíveis e criar a mesma lógica de controle para navegação, como faria com os fragmentos. Poderia fazê-lo com fragmentos apenas por causa disso.
• se fizermos um aplicativo para tablet, teremos mais facilidade em refazer as coisas, porque tudo já está bem separado.

Contras

• você tem que aprender como usar fragmentos

Primeiro, faça o que fizer, verifique se você possui um design modular usando modelo, visualização e apresentador que não seja altamente dependente de uma atividade ou de um fragmento.

O que as atividades e os fragmentos realmente oferecem?

1. Eventos do ciclo de vida e backstack
2. Contexto e recursos

Portanto, usá-los para que, SOMENTE . Eles têm responsabilidade suficiente, não os compliquem demais. Eu argumentaria que até mesmo intantar um TextView em uma atividade ou fragmento é uma prática ruim. Há uma razão pela qual métodos como Public View findViewById (int id) são PUBLIC .

Agora, a pergunta fica mais simples: preciso de vários eventos e bastidores independentes do ciclo de vida? Se você acha que sim, use fragmentos. Se você pensa que nunca, não use fragmentos.

No final, você pode fazer seu próprio backstack e ciclos de vida. Mas, por que recriar a roda?

EDIT: Por que votar isso? Classes de propósito único pessoas! Cada atividade ou fragmento deve ser capaz de instanciar um apresentador que instancia uma exibição. O apresentador e a visualização são um módulo que pode ser trocado. Por que uma atividade ou fragmento deve ter a responsabilidade de um apresentador?

Prós

Você pode controlar seus fragmentos a partir de uma única atividade, porque todos os fragmentos são independentes um do outro. Os fragmentos têm um ciclo de vida ( onPause, onCreate, onStart...) dos seus próprios. Por ter um ciclo de vida, os fragmentos podem responder independentemente aos eventos, salvar seu estado onSaveInstanceStatee ser recuperados (ou seja, ao retomar após uma chamada recebida ou quando o usuário clica no botão Voltar).

Contras

1. Crie complexidade no seu código de atividade.
2. Você precisa gerenciar a ordem dos fragmentos.

No entanto, é uma boa idéia, como se você precisasse criar um aplicativo, no qual deseja mostrar várias visualizações. Com essa ideia, você poderá visualizar vários fragmentos em uma única exibição.

Depende do layout do design do seu aplicativo. Suponha que, se você estiver usando Guias no ActionBar no layout de design, na Atividade Única do aplicativo for possível alterar fragmentos ao clicar no Tab. Portanto, agora você tem uma atividade e digamos que suponha três guias na ActionBar e a exibição das guias fornecidas pelos fragmentos, o que facilita o gerenciamento do plus também é viável. Portanto, tudo depende do esquema de design do seu aplicativo e de como você toma a decisão de criar para ele.

Prós:

• Pode ser usado para criar uma única interface utilizável por vários tamanhos de tela e orientações através de layouts xml.

Contras:

• Requer código mais complexo em sua atividade.

Acredito que é uma boa ideia, porque o uso de diferentes layouts xml com base no tamanho e na orientação atuais da tela pode tornar o aplicativo mais utilizável e reduzir a necessidade de lançar várias versões do aplicativo, se você planeja lançá-lo para telefones e tablets. Se seu aplicativo nunca será usado por tablets e telefones, provavelmente não vale a pena.

Sou um defensor do adiamento de toda a inflação de vista para fragmentos para fornecer melhor flexibilidade. Por exemplo, ter uma única atividade de aterrissagem para um tablet que agrega vários fragmentos e reutiliza os mesmos fragmentos em um telefone para mostrar uma tela por fragmento. No entanto, na implementação do telefone, eu teria uma atividade separada para cada tela. As atividades não teriam muito código, pois adiariam imediatamente para o fragmento correspondente para visualizar a inflação.

Acho que é uma má ideia que a implementação do telefone tenha que mudar para uma única atividade de aterrissagem quando guias ou um menu deslizante são introduzidos, pois a navegação por guias ou menus resulta apenas em uma tela completamente nova.

A razão mais importante que eu daria para não usar a abordagem de atividade única é para que o ciclo de vida da atividade possa ser aproveitado. As atividades contêm comportamento contextual de uma certa parte do aplicativo e fragmentos complementam esse comportamento. Ter a capacidade de tirar proveito das etapas substituíveis no ciclo de vida da atividade ajuda a separar o comportamento de uma atividade da outra por métodos como onPausee onResume. Esse ciclo de vida também permite retornar ao contexto anterior. Com a abordagem de atividade única, depois de deixar um fragmento, é necessário criar um mecanismo para retornar a ele.