Android: O que é melhor - várias atividades ou alternar visualizações manualmente?

Eu desenvolvi alguns aplicativos para Android, e essa pergunta fica sempre:

Como devo estruturar minha IU? Devo iniciar atividade após atividade e deixar o telefone para fazer o botão "Voltar", ou devo escolher uma maneira mais otimizada, mas mais complexa de implementar, com alternar manualmente as visualizações e, em seguida, fazer manualmente a funcionalidade do botão "Voltar"?

O que você acha (ou sabe) que é a melhor prática?

Eu diria que várias atividades quase sempre fazem mais sentido. Eu só não acho que o Android seja projetado para mudar constantemente seus próprios modos de exibição - você perde muito. Você mesmo precisa implementar o Back, não obtém nenhuma transição entre atividades, é necessário implementar muita lógica interna para retomar um aplicativo no estado correto. Se você não particionar seu aplicativo em Atividades, será muito mais difícil alterar o fluxo de seu aplicativo posteriormente. Isso também resulta em uma mega-atividade que pode ser muito mais difícil de manipular do que muitos pedaços menores de código.

Tenho dificuldade em imaginar que a velocidade é realmente um problema; se for, há algo errado com a maneira como você está inicializando cada Activity. Por exemplo, eu costumava tentar passar objetos serializáveis ​​entre atividades, e isso provou ser incrivelmente lento; quando mudei para um método mais rápido de passar objetos, a velocidade de lançamento de Activities aumentou imensamente.

Além disso, acho que é revelador que as diretrizes do Android para Activity e Task Design não mencionam a troca de views; é centrado em torno de um design Activity-as-View.

Gostaria de apontar alguns casos em que uma única atividade pode ser melhor projetada para um aplicativo Android que tem mais de uma visualização em tela inteira:

• Se as telas do aplicativo estiverem fortemente acopladas e compartilharem um objeto comum no qual todas estão operando. Nesse caso, a passagem do objeto pode exigir um pacote e pode estar sujeita a erros, pois haverá cópias dele. Um bom exemplo pode ser um assistente . Sim, você pode usar a estática para acessar o objeto comum, mas a estática pode ser perigosa no Android (pense em mudanças na configuração!)

• Se você quiser animações muito legais entre as telas. Talvez você queira que um pássaro decole em uma tela e pouse em outra. Tente fazer isso quando cada tela for uma atividade!

Por outro lado, se uma de suas telas for projetada para ser exibida por qualquer número de outros aplicativos, essa tela deve ser sua própria atividade.

ATUALIZAÇÃO de março de 2014:

Neste ponto, a questão agora deve incluir a escolha de fragmentos. Eu acho que Views são provavelmente a escolha menos provável dos 3: Activity, Fragment, View. Se você deseja implementar telas que usam o botão Voltar, então deve ser Activties ou Fragmentos, porque ambos lidam com o botão Voltar nativamente. Fragmentos precisarão ser adicionados à pilha traseira do FragmentManager para que o botão Voltar funcione. No entanto, gerenciar fragmentos, diálogos e back stack pode ser um pouco chato!

ATUALIZAÇÃO em setembro de 2018:

Alguns desenvolvedores do Google estão recomendando aplicativos de atividade única usando o novo componente de arquitetura de navegação .

Além disso, lembre-se de que implementar seu aplicativo com múltiplos Activitiesproporcionará ao usuário uma experiência mais coerente com a plataforma como um todo. Parte da experiência será moldada pelo uso dos aplicativos integrados do Google, de modo que os usuários provavelmente terão mais facilidade para usar seu aplicativo se ele se comportar de maneira semelhante aos que já estão instalados no telefone.

Diferente de outros, uso uma mistura de ambos, por exemplo,
1. Há um menu principal quando o aplicativo é iniciado
2. Você clica em pesquisar, leva você para a atividade de pesquisa
3. Em seguida, há um botão de filtro, que apenas muda a visualização e mostra você filtra as opções
4. Existem dois botões no final da visualização do filtro. Você clica em "Pesquisar" ou "Cancelar" e volta para a Visualização de pesquisa novamente (sem alternar a atividade)
5. Agora, se o usuário voltar ao telefone botão ele é levado de volta ao menu principal em vez das opções de filtro de pesquisa. Acho que é o comportamento correto.

Use-o da maneira que o usuário se sinta natural. E manter tudo em uma atividade tornará tudo complexo.

Tudo depende do aplicativo, o que você está tentando obter melhor desempenho, interface do usuário mais suave. IMHO Eu prefiro a segunda abordagem de controlar as Atividades manualmente, mesmo que seja mais complexa, como você afirmou. Esta é uma abordagem que usei no meu projeto de guias do Android, você também pode querer dar uma olhada em uma classe chamada ActivityGroup (não tenho certeza do pacote), ela permite que você tenha várias atividades entre as quais você pode alternar, uma boa coisa sobre esta classe é que suas atividades não são descarregadas quando você muda, mas uma coisa ruim é que leva mais tempo para carregar seu aplicativo principal.

Apenas minha opinião.

O problema com a troca de visualizações, que encontrei, também é causado pelo coletor de lixo. Parece que o GC é acionado quando você sai da atividade e não da visualização. Portanto, alterar guias com visualizações filhas bastante complexas, por exemplo, quase inevitavelmente levará a uma exceção de estouro de pilha.

Eu tive tantos problemas com o layout de múltiplas atividades que eu o desencorajo fortemente, a menos que haja um bom motivo para escolhê-lo.

Desvantagem de múltiplas atividades

Usando várias atividades, é muito difícil refatorar o código para retornar dados da atividade.

Se você chamar uma 'sub' atividade, a atividade principal pode ser eliminada. Mas você nunca experimenta isso durante a depuração em um dispositivo decente, portanto, você precisa sempre lidar com o estado de salvamento e o estado de recuperação correto. Isso é uma dor. Imagine chamar um método em uma biblioteca (ou seja, outra atividade) e você teria que garantir que, quando esse método retornar, seu aplicativo seja capaz de recriar seu estado completamente com todos os campos em todos os objetos na VM (ou seja, atividade. restoreIntance). É insano.

Além disso, ao contrário, quando você abre uma subatividade, a VM pode ter sido eliminada desde que a subatividade foi gerada pela primeira vez, como quando o aplicativo é minimizado enquanto a subatividade é exibida.

É muito mais limpo ter apenas um local para armazenar o estado do aplicativo relevante e, no meu caso, na maioria das vezes, se a VM for interrompida, quero retornar o usuário à tela principal e deixá-los fazer suas coisas novamente, porque não não gaste 30-50 horas codificando a funcionalidade de salvar / retomar que 0,1% dos usuários jamais experimentará.

Alternativo

Fragmentar ou apenas gerenciar você mesmo as visualizações de atividades. Gerenciar visualizações manualmente requer a codificação de alguma alternativa de troca de visualização para atividades / fragmentos com transições, se desejado.

E não, não significa uma megaatividade, como sugerido na resposta aceita, de qualquer outra forma que não seja um megaaplicativo. Exige apenas um pouco mais de design da base de código em peças adequadas, porque há um pouco mais de trabalho gerenciando visualizações, embora muito menos trabalho gerenciando estado de atividade e outras estranhezas.

Possivelmente relevante: Reddit: é oficial: o Google recomenda oficialmente a arquitetura de aplicativo de atividade única