android use Dilema: quando usar Fragmentos vs Atividades:




use of fragment in android (12)

Eu sei que as Activities são projetadas para representar uma única tela do meu aplicativo, enquanto Fragments são projetados para serem layouts de interface do usuário reutilizáveis ​​com lógica incorporada dentro deles.

Até há pouco tempo, desenvolvi uma aplicação que dizia que deveriam ser desenvolvidas. Eu criei uma Activity para representar uma tela do meu aplicativo e usei Fragments para o ViewPager ou o Google Maps . Eu raramente criei um ListFragment ou outra interface do usuário que pode ser reutilizada várias vezes.

Recentemente tropecei em um projeto que contém apenas 2 Activities uma é uma SettingsActivity e outra é a MainActivity . O layout da MainActivity é preenchido com muitos fragmentos de UI de tela cheia ocultos e apenas um é mostrado. Na lógica do Acitivty , existem muitas FragmentTransitions entre as diferentes telas do aplicativo.

O que eu gostei dessa abordagem é que, como o aplicativo usa um ActionBar , ele permanece intacto e não se move com a animação de alternância de tela, que é o que acontece com a alternância de Activity . Isso dá uma sensação mais fluente a essas transições de tela.

Então eu acho que o que eu estou pedindo é compartilhar sua atual maneira de desenvolvimento com relação a este tópico, eu sei que pode parecer uma pergunta baseada em opinião no primeiro olhar, mas eu vejo isso como uma questão de arquitetura e design Android ... opinião baseada em um.

ATUALIZAÇÃO (01.05.2014): Após esta apresentação por Eric Burke da Square , (que eu tenho a dizer é uma ótima apresentação com um monte de ferramentas úteis para desenvolvedores do Android. E eu não estou relacionado de alguma forma a Square)

http://www.infoq.com/presentations/Android-Design/

Da minha experiência pessoal nos últimos meses, descobri que a melhor maneira de construir meus aplicativos é criar grupos de fragmentos que representam um fluxo no aplicativo e apresentar todos esses fragmentos em uma Activity . Então, basicamente, você terá o mesmo número de Activities em seu aplicativo que o número de fluxos. Dessa forma, a barra de ação permanece intacta em todas as telas do fluxo, mas está sendo recriada ao alterar um fluxo que faz muito sentido. Como Eric Burke afirma e como eu percebi também, a filosofia de usar o mínimo possível de Activities não é aplicável a todas as situações porque cria uma confusão no que ele chama de atividade "Deus".


Não se esqueça de que uma atividade é um bloco / componente do aplicativo que pode ser compartilhado e iniciado através do Intent! Portanto, cada atividade em seu aplicativo deve resolver apenas um tipo de tarefa. Se você tem apenas uma tarefa em sua aplicação, então eu acho que você precisa de apenas uma atividade e muitos fragmentos, se necessário. É claro que você pode reutilizar fragmentos em atividades futuras que resolvam outras tarefas. Esta abordagem será uma separação clara e lógica das tarefas. E você não precisa manter uma atividade com diferentes parâmetros de filtro de intenção para diferentes conjuntos de fragmentos. Você define tarefas no estágio de design do processo de desenvolvimento com base nos requisitos.


Você é livre para usar um desses.
Basicamente, você tem que avaliar qual é o melhor para seu aplicativo. Pense em como você gerenciará o fluxo de negócios e como armazenar / gerenciar as preferências de dados.

Pense em como os fragmentos armazenam dados de lixo. Quando você implementa o fragmento, você tem uma raiz de atividade para preencher com fragmento (s). Então, se você está tentando implementar muitas atividades com muitos fragmentos, você tem que considerar o desempenho em seu aplicativo, porque você está manipulando (grosseiramente fala) dois ciclos de vida de contexto, lembre-se da complexidade.

Lembre-se: devo usar fragmentos? Por que eu não deveria?

Saudações.


Eu uso fragmentos para melhor experiência do usuário. Por exemplo, se você tiver um botão e quiser executar, digamos, um serviço da Web ao clicar nele, eu anexei um fragmento à atividade pai.

if (id == R.id.forecast) {

    ForecastFragment forecastFragment = new ForecastFragment();
    FragmentManager fm = getSupportFragmentManager();
    FragmentTransaction ft = fm.beginTransaction();
    ft.replace(R.id.main_content, forecastFragment);
    ft.addToBackStack("backstack");
    forecastFragment.setArguments(b);
    ft.commit();
}

Dessa forma, o usuário não precisará se mover em outra atividade.

E em segundo lugar eu prefiro Fragmentos porque você pode lidar com eles facilmente durante a rotação.


usar uma atividade por aplicativo para fornecer base para fragment uso para a tela, fragments são peso leve em comparação com fragmentos de activites são fragmentos reutilizáveis são mais adequados para app que suportam tanto telefone e tablet


Na minha opinião, isso não é relevante. O fator chave a considerar é

  1. quantas vezes você vai reutilizar partes da interface do usuário (menus por exemplo),
  2. é o aplicativo também para tablets?

O principal uso de fragmentos é criar atividades multipane, o que o torna perfeito para aplicativos responsivos do Tablet / Telefone.


Minha filosofia é esta:

Crie uma atividade somente se ela for absolutamente necessária. Com a pilha de backup disponibilizada para o envio de várias transações de fragmento, tento criar o menor número possível de atividades no meu aplicativo. Além disso, a comunicação entre vários fragmentos é muito mais fácil do que enviar dados entre atividades.

Transições de atividade são caras, certo? Pelo menos eu acredito que sim - já que a atividade antiga tem que ser destruída / pausada / parada, empurrada para a pilha, e então a nova atividade tem que ser criada / iniciada / retomada.

É apenas minha filosofia desde que os fragmentos foram introduzidos.


Coisa que fiz: Usando menos fragmento quando possível. Infelizmente, é possível em quase todos os casos. Então, acabo com muitos fragmentos e um pouco de atividades. Algumas desvantagens que eu percebi:

  • ActionBar & Menu: Quando 2 fragmentos tem título diferente, menu,
    será difícil de lidar. Ex: ao adicionar um novo fragmento, você pode alterar o título da barra de ação, mas quando pop de backstack não há como restaurar o título antigo. Você pode precisar de uma barra de ferramentas em todos os fragmentos para este caso, mas, acredite em mim, você terá mais tempo.
  • Quando precisamos de startForResult , a atividade tem mas o fragmento não.
  • Não tem animação de transição por padrão

Minha solução para isso é usar uma Activity para agrupar um fragmento. Então nós temos barra de ação separada, menu, startActivityForResult , animação, ...


A grande vantagem de um fragment sobre a atividade é que, o código que é usado para o fragmento pode ser usado para diferentes atividades. Portanto, ele fornece a reutilização do código no desenvolvimento de aplicativos.



Os especialistas lhe dirão: "Quando eu vir a interface do usuário, saberemos se devemos usar uma Activity ou um Fragment ". No começo, isso não terá nenhum sentido, mas com o tempo, você será capaz de dizer se precisa Fragment ou não.

Há uma boa prática que achei muito útil para mim. Ocorreu-me enquanto eu estava tentando explicar algo para minha filha.

Ou seja, imagine uma caixa que represente uma tela. Você pode carregar outra tela nesta caixa? Se você usar uma nova caixa, terá que copiar vários itens da primeira caixa? Se a resposta for Sim, você deve usar Fragments , porque a Activity raiz pode conter todos os elementos duplicados para poupar tempo na criação deles, e você pode simplesmente substituir partes da caixa.

Mas não se esqueça de que você sempre precisa de um contêiner de caixa ( Activity ) ou suas peças serão dispersas. Então uma caixa com partes internas.

Tome cuidado para não usar mal a caixa. Os especialistas em UX do Android aconselham (você pode encontrá-los no YouTube) quando deveríamos carregar explicitamente outra Activity , em vez de usar um Fragment (como quando lidamos com a gaveta de navegação que tem categorias). Assim que se sentir confortável com o Fragments , pode ver todos os seus vídeos. Ainda mais eles são materiais obrigatórios.

Você pode agora olhar para sua interface do usuário e descobrir se você precisa de uma Activity ou um Fragment ? Você conseguiu uma nova perspectiva? Eu acho que você fez.


Depende do que você quer realmente construir. Por exemplo, a navigation drawer usa fragmentos. Guias usam fragments também. Outra boa implementação é onde você tem um listview . Quando você gira o telefone e clica em uma linha, a atividade é mostrada na metade restante da tela. Pessoalmente, uso fragments e fragment dialogs , pois é mais profissional. Além disso, eles são manuseados mais facilmente em rotação.


Há mais nisso do que você imagina, é preciso lembrar que uma atividade lançada não destrói implicitamente a atividade de chamada. Claro, você pode configurá-lo de tal forma que seu usuário clica em um botão para ir a uma página, você inicia a atividade da página e destrói a atual. Isso causa muita sobrecarga. O melhor guia que posso dar é:

** Inicie uma nova atividade somente se fizer sentido ter a atividade principal e esta aberta ao mesmo tempo (pense em várias janelas).

Um ótimo exemplo de quando faz sentido ter várias atividades é o Google Drive. A atividade principal fornece um explorador de arquivos. Quando um arquivo é aberto, uma nova atividade é iniciada para visualizar esse arquivo. Você pode pressionar o botão de aplicativos recentes, que permitirá voltar ao navegador sem fechar o documento aberto, e talvez até mesmo abrir outro documento em paralelo ao primeiro.





architecture