Dilema: quando usar Fragmentos x Atividades:

Eu sei que Activitiessão projetados para representar uma única tela do meu aplicativo, enquanto Fragmentssão projetados para serem layouts de UI reutilizáveis ​​com lógica incorporada dentro deles.

Até pouco tempo atrás, desenvolvi um aplicativo que dizia que eles deveriam ser desenvolvidos. Criei um Activitypara representar uma tela do meu aplicativo e usei Fragments para ViewPageror Google Maps. Eu raramente criei uma ListFragmentou outra interface do usuário que pode ser reutilizada várias vezes.

Recentemente me deparei com um projeto que contém apenas 2 Activitiesum é um SettingsActivitye outro é o MainActivity. O layout do MainActivityé preenchido com muitos fragmentos de interface do usuário ocultos em tela cheia e apenas um é mostrado. Na Activitylógica, existem muitos FragmentTransitionsentre 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 Activityalternância. Isso dá uma sensação mais fluente a essas transições de tela.

Acho que o que estou pedindo é compartilhar sua maneira atual de desenvolvimento com relação a esse tópico. Sei que pode parecer uma pergunta baseada em opinião à primeira vista, mas a considero uma questão de design e arquitetura do Android ... opinião baseada em um.

UPDATE (01.05.2014): Após esta apresentação de Eric Burke da Square , (que devo dizer que é uma ótima apresentação com muitas ferramentas úteis para desenvolvedores de Android. E não tenho nenhuma relação com Square)

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

De 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 apresentam todos esses fragmentos em um Activity. Então, basicamente, você terá o mesmo número de Activitiesem 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 na alteração de um fluxo que faz muito sentido. Como Eric Burke afirma e como eu também percebi, a filosofia de usar o mínimo Activitiespossível não é aplicável a todas as situações, porque cria uma confusão no que ele chama de atividade de "Deus".

Os especialistas dirão: "Quando visualizar a interface do usuário, saberei se devo usar um Activityou um Fragment". No começo, isso não fará sentido, mas, com o tempo, você será capaz de dizer se precisa Fragmentou não.

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

Ou seja, imagine uma caixa que representa uma tela. Você pode carregar outra tela nesta caixa? Se você usar uma nova caixa, precisará copiar vários itens da 1ª caixa? Se a resposta for Sim, você deve usá-lo Fragments, porque a raiz Activitypode conter todos os elementos duplicados para poupar tempo ao criá-los, e você pode simplesmente substituir partes da caixa.

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

Tome cuidado para não usar mal a caixa. Os especialistas em Android UX aconselham (você pode encontrá-los no YouTube) quando devemos carregar outro explicitamente Activity, em vez de usar um Fragment(como quando lidamos com a Gaveta de Navegação que possui categorias). Depois de se sentir confortável Fragments, você poderá assistir a todos os vídeos deles. Ainda mais, eles são materiais obrigatórios.

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

Minha filosofia é esta:

Crie uma atividade apenas se for absolutamente necessária. Com a pilha traseira disponibilizada para confirmar várias transações de fragmento, tento criar o mínimo possível de atividades no meu aplicativo. Além disso, a comunicação entre vários fragmentos é muito mais fácil do que o envio de dados entre as atividades.

As transições de atividades são caras, certo? Pelo menos eu acredito que sim - uma vez que a atividade antiga deve ser destruída / pausada / parada, empurrada para a pilha e, em seguida, a nova atividade deve ser criada / iniciada / retomada.

É apenas a minha filosofia desde que os fragmentos foram introduzidos.

Bem, de acordo com as palestras do Google (talvez aqui , não me lembro), você deve considerar o uso de fragmentos sempre que possível, pois isso facilita a manutenção e o controle do seu código.

No entanto, acho que, em alguns casos, pode ficar muito complexo, pois a atividade que hospeda os fragmentos precisa navegar / se comunicar entre eles.

Eu acho que você deve decidir por si mesmo o que é melhor para você. Geralmente não é tão difícil converter uma atividade em um fragmento e vice-versa.

Eu criei um post sobre esse dillema aqui , se você quiser ler mais.

Por que prefiro Fragmento a Atividade em TODOS OS CASOS.

• Atividade é cara. No Fragmento, as visualizações e os estados de propriedade são separados - sempre que um fragmento estiver inserido backstack, suas visualizações serão destruídas. Assim, você pode empilhar muito mais fragmentos que atividade.

• Backstackmanipulação. Com FragmentManager, é fácil limpar todos os fragmentos, inserir mais do que em fragmentos e etcs. Mas para Activity, será um pesadelo manipular essas coisas.

• Um ciclo de vida muito previsível . Contanto que a Atividade do host não seja reciclada. os fragmentos no backstack não serão reciclados. Portanto, é possível usar FragmentManager::getFragments()para encontrar fragmentos específicos (não incentivados).

Desde o Jetpack , o aplicativo de atividade única é a arquitetura preferida. Útil especialmente com o componente de arquitetura de navegação .

fonte

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

1. com que frequência você reutilizará partes da interface do usuário (menus por exemplo),
2. o aplicativo também é para tablets?

O principal uso de fragmentos é criar atividades de vários painéis, o que o torna perfeito para aplicativos responsivos para Tablet / Telefone.

Não se esqueça que uma atividade é o 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ê tiver apenas uma tarefa em seu aplicativo, acho que precisará de apenas uma atividade e muitos fragmentos, se necessário. Claro que você pode reutilizar fragmentos em atividades futuras que resolvem outras tarefas. Essa abordagem será uma separação clara e lógica de 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.

Há mais 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 forma que o usuário clique em um botão para ir para uma página, inicie a atividade dessa página e destrua a atual. Isso causa muita sobrecarga. O melhor guia que posso dar é:

** Inicie uma nova atividade apenas 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á retornar ao navegador sem fechar o documento aberto e, em seguida, talvez abrir outro documento paralelamente ao primeiro.

O que eu 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 o fragmento 2 possui um título, menu diferente,
  será difícil lidar com isso. Ex: ao adicionar um novo fragmento, você pode alterar o título da barra de ação, mas, quando pop-lo, backstacknão há como restaurar o título antigo. Você pode precisar de uma barra de ferramentas em cada fragmento para este caso, mas, acredite, você gastará mais tempo.
• Quando precisamos 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 atividade para quebrar um fragmento dentro. Portanto, temos barra de ação, menu startActivityForResult, animação, ...

A grande vantagem de uma fragmentatividade excessiva é que, o código usado para fragmento pode ser usado para atividades diferentes. Assim, ele fornece reutilização de código no desenvolvimento de aplicativos.

usar uma actividade por aplicação para fornecer base para fragment utilização fragmentpara a tela, fragmentssão peso de lite , em comparação com activites fragmentos são reutilizáveis fragmentos são melhor adequados para a aplicação que suporta tanto telefone & pastilha

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

Pense em como os Fragments armazenam dados de lixo. Ao implementar o fragmento, você tem uma raiz de atividade para preencher com fragmento (s). Portanto, se você está tentando implementar muitas atividades com muitos fragmentos, deve considerar o desempenho em seu aplicativo, porque está manipulando (fala grosseiramente) o ciclo de vida de dois contextos, lembre-se da complexidade.

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

Saudações.

Eu uso fragmentos para melhor experiência do usuário. Por exemplo, se você possui um botão e deseja executar, digamos um serviço da web ao clicar nele, anexo 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 mudar para outra atividade.

Em segundo lugar, prefiro os fragmentos porque você pode lidar com eles facilmente durante a rotação.

Depende do que você deseja construir realmente. Por exemplo, o navigation drawerusa fragmentos. As guias também são usadas fragments. 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, eu uso fragmentse fragment dialogs, como é mais profissional. Além disso, eles são manuseados com mais facilidade na rotação.