Uma atividade e todos os outros fragmentos [fechados]

158

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?

Vineet Shukla
fonte
Você pode explicar por que você acha que a resposta é não? Por acaso eu discordo, mas é mais fácil abordar as preocupações que você possa ter sobre essa abordagem se soubermos quais são essas preocupações.
Alexander Lucas
1
@AlexanderLucas A resposta que eu não dei, porque isso torna seu código menos modular, aumenta a complexidade.
Vineet Shukla
@Ski Você está se concentrando mais em obter sua resposta aceita, por favor, concentre-se no que está sendo solicitado e qual deve ser a melhor resposta que você pode fornecer.
Vineet Shukla
3
Para quem acha isso, parei o refator porque as coisas ficaram muito complicadas muito rápido.
theblang
18
Esta é uma boa pergunta e não deveria ter sido fechada.
Jim No Texas

Respostas:

94

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

JustinMorris
fonte
6
Existe settargetfragmente você pode lidar com a atividade como startforresultprocedimento.
Lalith B
1
Na minha opinião, as atividades existem apenas porque é o sistema antigo. Fragmento não existia antes. Não há realmente nada que atividades e fragmentos possam, além de formalidades. Eu até poderia imaginar que em algum momento as atividades sejam removidas e tudo seja um fragmento.
Ixx 30/12/13
1
Resumindo os contras dos fragmentos - apenas você dá, não há realmente nenhum. startActivityForResult como Lalith B diz que tem uma contrapartida, e mapas também não é um problema. Além disso, tudo (estado de economia, etc.) pode ser tratado com os métodos de ciclo de vida do fragmento.
Ixx 30/12/13
85

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
Tamas
fonte
1
não tinha certeza de ter muitos fragmentos e só agora atividade ... qualquer problema na produção, e a culpa é sua !! :)
Shahar
1
@Dinash não deixe o SO reiniciar sua atividade. lidar com a orientação mudar a si mesmo. leia mais aqui: stackoverflow.com/questions/5913130/…
Tamas
1
@Tamas Você tinha telas com vários fragmentos (por exemplo, detalhes principais) e, em caso afirmativo, como lidou com isso?
theblang
7
@Tamas Essa abordagem é fortemente anti-android. Você acaba na classe GOD. O sistema Android foi projetado para trabalhar com atividades - por exemplo, você não tem uma boa maneira de lidar com as Barras de Ferramentas em vários fragmentos. Você não tem um fragmento inicial para obter resultados e muitos outros não possuem. Isso significa que você precisa reescrever toda a lógica que já existe. E os receptores de transmissão local, serviços e outros componentes do Android. Para iniciar um serviço, você deve fazer o seguinte: getActivity ()! = Null ... isso é realmente feio. Além disso, a comunicação entre os fragmentos é muito estranha, se você tem muito fr.
Teodor 31/03
9
700 linhas !!!! "agradável"???? As aulas são gratuitas.
beplaya
16

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?

beplaya
fonte
Humm ... a conexão entre instanciar uma exibição como uma prática ruim e o público findViewById () não é clara. Embora eu concorde com a instanciação de visualizações, também considero chamar findViewById de outra classe (por exemplo, a atividade que hospeda um fragmento o chama no fragmento) de uma má prática. Realmente não sei por que isso é público, pois, pelo menos nos casos em que posso pensar, isso resulta em código confuso e não em design modular.
Ixx 30/12/13
IMHO: Se você passar uma atividade para a sua exibição e apresentador (chamando os 2 combinados de "módulo"), você poderá reutilizar esse módulo em outras atividades. Se ajudar, pode ser melhor passar a atividade como um infográfico que expõe apenas as coisas necessárias. Se você odeia encontrar pontos de vista fora da atividade, pode injetar todos os pontos de vista, através dessa interface, na pres./view. O ponto principal é que eu acredito que a codificação do Android deve ser feita fora do conceito de Actvities and Frags, de modo que é fácil alternar entre os dois. código.
beplaya
3
Solte o MVP, você estará melhor sem o Android. Você pode gastar muito tempo tentando encaixar um determinado bloco de forma através de um orifício de uma forma diferente, com certeza é um desafio, mas provavelmente há requisitos funcionais nos quais você seria mais sábio ao passar o tempo.
straya
12

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.

Sahil Mahajan Mj
fonte
2

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.

CINZA
fonte
1

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.

Esqui
fonte
Para orientação, não é necessário usar diferentes layouts baseados em xml.
Vineet Shukla
@VineetShukla true, mas é uma opção, assim como usar diferentes layouts xml com base no tamanho da tela. Por exemplo, a tela inicial do meu telefone Android tem um layout diferente quando o vejo na orientação paisagem versus retrato.
Ski
0

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.

user1679130
fonte
"Acho que é uma má idéia para a implementação do telefone mudar para uma única atividade de pouso quando guias ou um menu deslizante são introduzidos, pois a navegação por guias ou menus resulta apenas em uma tela completamente nova". -> Não é compreensível o que exatamente você quer dizer, mas nem as guias nem o menu lateral são um problema em um aplicativo de atividade única (tablet / telefone).
Ixx 30/12/13
-1

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.

japino
fonte
4
Eu não acredito que isso seja verdade. Na documentação do ciclo de vida do fragmento ( developer.android.com/guide/components/fragments.html#Lifecycle ): "O ciclo de vida da atividade na qual o fragmento vive afeta diretamente o ciclo de vida do fragmento, de modo que cada retorno de chamada para a atividade resulta em um retorno de chamada semelhante para cada fragmento. Por exemplo, quando a atividade recebe onPause (), cada fragmento da atividade recebe onPause (). "
Ski