Quantas atividades vs fragmentos?

Introdução:

O padrão básico do "Fragments Tutorial" é mais ou menos assim:

1. Em um tablet, tenha uma lista à esquerda e detalhes à direita.
2. Ambos são Fragmentse ambos residem no mesmo Activity.
3. Em um telefone, tenha uma lista Fragmentem um Activity.
4. Lançar um novo Activitycom os detalhes Fragment.

(por exemplo, API do Android 3.0 Fragments por Dianne Hackborn e o Guia da API do Fragments )

Nos dois dispositivos, a funcionalidade está no Fragments. (simples)

No tablet , o aplicativo inteiro é 1Activity ; no telefone , existem muitosActivities .

Questões:

• Existe um motivo para dividir o aplicativo de telefone em vários Activities?

Um problema com esse método é que você duplica muita lógica no Tablet principal Activitye no telefone separado Activities.

• Não seria mais fácil manter o modelo 1 Activity em ambos os casos, usando a mesma lógica de ativar Fragmentse desativar (apenas usando um layout diferente)?

Dessa maneira, a maior parte da lógica reside em Fragmentssi mesma e existe apenas uma Activityduplicação de código única e menor.

Também o que li sobre ActionBarSherlockisso é que parece funcionar melhor em Fragmentsvez de Activities(mas ainda não o trabalhei).

Os tutoriais estão simplificados demais ou perdi algo importante nessa abordagem?

Tentamos as duas abordagens com sucesso no escritório - mas estou prestes a iniciar um projeto maior e quero facilitar o máximo possível as coisas para mim.

Alguns links para perguntas relacionadas:

• Dilema: quando usar Fragmentos x Atividades:
• Padrões quando usar a transição de atividade vs fragmentos dinâmicos
• Android - preciso de alguns esclarecimentos sobre fragmentos x atividades e visualizações
• Atividades ou fragmentos no Android?
• Design de interação de vários fragmentos e atividades
• Então, quais são as vantagens exatas dos fragmentos no Android 3.0?

Atualizações

Recompensa iniciada em questão - ainda não estou convencido sobre o motivo pelo qual preciso duplicar minha lógica de aplicativo na atividade do tablet e em cada atividade do telefone.

Também encontrei um artigo interessante do pessoal da Square, que vale a pena ler:

• Defendendo contra fragmentos do Android

Concordo que os tutoriais são muito simplificados. Eles apenas apresentam, Fragmentsmas eu não concordo com o padrão sugerido.

Concordo também que não é uma boa ideia duplicar a lógica do seu aplicativo em várias atividades (consulte o princípio DRY na wikipedia ).

Prefiro o padrão usado pelo ActionBarSherlockaplicativo Fragments Demo (faça o download aqui e o código-fonte aqui ). A demonstração que mais se aproxima do tutorial mencionado na pergunta é a chamada "Layout" no aplicativo; ou FragmentLayoutSupportno código fonte.

Nesta demonstração, a lógica foi movida para fora do Activitye para o Fragment. Na TitlesFragmentverdade, contém a lógica para alterar fragmentos. Dessa forma, cada atividade é muito simples. Duplicar muitas Atividades muito simples, onde nenhuma lógica está dentro das Atividades, torna muito simples.

Colocando a lógica nos fragmentos, não há necessidade de escrever o código mais de uma vez ; está disponível independentemente da atividade em que o fragmento for inserido. Isso o torna um padrão mais poderoso do que o sugerido pelo tutorial básico.

    /**
    * Helper function to show the details of a selected item, either by
    * displaying a fragment in-place in the current UI, or starting a
    * whole new activity in which it is displayed.
    */
    void showDetails(int index)
    {
        mCurCheckPosition = index;

        if (mDualPane)
        {
            // We can display everything in-place with fragments, so update
            // the list to highlight the selected item and show the data.
            getListView().setItemChecked(index, true);

            // Check what fragment is currently shown, replace if needed.
            DetailsFragment details = (DetailsFragment) getFragmentManager()
                .findFragmentById(R.id.details);
            if (details == null || details.getShownIndex() != index)
            {
                // Make new fragment to show this selection.
                details = DetailsFragment.newInstance(index);

                // Execute a transaction, replacing any existing fragment
                // with this one inside the frame.
                FragmentTransaction ft = getFragmentManager()
                    .beginTransaction();
                ft.replace(R.id.details, details);
                ft.setTransition(FragmentTransaction.TRANSIT_FRAGMENT_FADE);
                ft.commit();
            }

        }
        else
        {
            // Otherwise we need to launch a new activity to display
            // the dialog fragment with selected text.
            Intent intent = new Intent();
            intent.setClass(getActivity(), DetailsActivity.class);
            intent.putExtra("index", index);
            startActivity(intent);
        }
    }

Outra vantagem do padrão ABS é que você não termina com uma Atividade do Tablet que contém muita lógica e isso significa que você economiza memória. O padrão do tutorial pode levar a uma atividade principal muito grande em um aplicativo mais complexo; pois ele precisa lidar com a lógica de todos os fragmentos que são colocados nele a qualquer momento.

No geral, não pense nisso como sendo forçado a usar muitas atividades. Pense nisso como tendo a oportunidade de dividir seu código em muitos fragmentos e economizando memória ao usá-los.

Eu acho que você está no caminho certo. (E sim, os tutoriais são simplificados demais).

Em um layout de tablet, você pode usar uma única atividade e trocar e remover fragmentos (em vários 'painéis'). Enquanto estiver no layout do telefone, você pode usar uma nova atividade para cada fragmento.

Igual a:

Pode parecer muito trabalho extra, mas, ao usar várias atividades para telefones, você ativa o ciclo de vida básico da atividade e a transferência de intenção. Isso também permite que a estrutura lide com todas as animações e a pilha traseira.

Para ajudar a reduzir o código, você pode usar BaseActivityae estender a partir disso.

Portanto, se o usuário tiver um tablet, você usaria MyMultiPaneFragActivityou algo semelhante. Essa atividade é responsável pelo gerenciamento de retornos de chamada dos fragmentos e das intenções de roteamento para o fragmento correto (como uma intenção de pesquisa)

Se o usuário tiver um telefone, você poderá usar uma Atividade regular com muito pouco código e estendê-lo MyBaseSingleFragActivityou algo semelhante. Essas atividades podem ser muito simples, de 5 a 10 linhas de código (talvez até menos).

A parte complicada é rotear as intenções e outros enfeites. * (Editar: veja mais abaixo).

Eu acho que a razão pela qual essa é a maneira recomendada é economizar memória e reduzir a complexidade e o acoplamento. Se você estiver trocando Fragmentos, ele FragmentManagermantém uma referência a esse Fragmento para a pilha traseira. Ele também simplifica o que deve estar "em execução" para o usuário. Essa configuração também dissocia as visualizações, o layout e a lógica no fragmento do ciclo de vida da atividade. Dessa maneira, um Fragmento pode existir em uma única atividade, ao lado de outro fragmento (painel duplo) ou em Atividade de três painéis, etc.

* Um dos benefícios de ter um roteamento de intenção regular é que você pode iniciar uma Atividade explicitamente de qualquer lugar da pilha inversa. Um exemplo pode ser o caso dos resultados da pesquisa. (MySearchResults.class).

Leia aqui para mais informações:

http://android-developers.blogspot.com/2011/09/preparing-for-handsets.html

Pode ser um trabalho um pouco mais inicial, porque cada fragmento deve funcionar bem em atividades separadas, mas geralmente compensa. Isso significa que você pode usar arquivos de layout alternativos que definem diferentes combinações de fragmentos, mantêm o código de fragmento modular, simplificam o gerenciamento da barra de ação e permitem que o sistema lide com todo o trabalho da pilha traseira.

Aqui está a resposta de Reto Meier sobre o mesmo, tirada deste vídeo do curso Android Fundamentals da Udacity .

Há vários motivos pelos quais seria melhor dividir seu aplicativo em atividades diferentes.

• Ter uma única atividade monolítica aumenta a complexidade do seu código, dificultando a leitura, o teste e a manutenção.
• Torna a criação e o gerenciamento de filtros de intenção muito mais difíceis.
• Aumenta o risco de acoplar firmemente componentes independentes.
• Torna muito mais provável a introdução de riscos à segurança se a atividade única incluir informações confidenciais e informações seguras para compartilhar.

Uma boa regra geral é criar uma nova atividade sempre que o contexto mudar. Por exemplo, exibindo um tipo diferente de dados e alternando da exibição para a entrada de dados.

Um problema com esse método é que você duplica muita lógica na Atividade principal do Tablet e nas Atividades telefônicas separadas.

No padrão de detalhes mestre, há duas atividades. Um mostra os dois fragmentos em telas maiores e apenas o fragmento "principal" em telas menores. O outro mostra o fragmento "detalhe" em telas menores.

Sua lógica de detalhes deve estar vinculada ao fragmento de detalhes. Portanto, não há duplicação de código relacionada à lógica de detalhes entre as atividades - a atividade de detalhes apenas exibe o fragmento de detalhes, talvez passando dados de um Intentextra.

Também o que li sobre o ActionBarSherlock é que ele parece funcionar melhor com Fragmentos, em vez de Atividades (mas ainda não o trabalhei).

O ActionBarSherlock não tem mais nada a ver com fragmentos do que a barra de ação nativa, pois o ActionBarSherlock é puramente um backport da barra de ação nativa.

Referindo-se à 1ª pergunta de "Existe um motivo para dividir o aplicativo de telefone em muitas atividades?" - Sim. simplesmente se resume ao espaço disponível, um Tablet dá mais espaço aos desenvolvedores, permitindo que os desenvolvedores coloquem mais em uma tela. O Android nos diz que o Activities pode fornecer uma tela . Então, o que você pode fazer com uma tela grande em um tablet é algo que pode estar espalhado por várias telas em um telefone, porque não há espaço suficiente para todos os fragmentos.