Como a API Fragments auxilia na migração de aplicativos
de smartphone para tablets
Patrick de Carvalho T. Silva, Jony Melo
Instituto de Informática – Centro Universitário do Triângulo (UNITRI) Caixa Postal 309 – 38.411-106 – Uberlândia – MG – Brasil
patrickudia2@hotmail.com, jony.unitri@gmail.com
Resumo. O desenvolvimento de aplicativos para smartphones e tablets
cresceu muito nos últimos anos e o Android conseguiu uma posição de destaque neste mercado competitivo. Esse sistema operacional pode ser encontrado em inúmeros dispositivos com diferentes tamanhos de telas. Essa flexibilidade de tamanhos tornou-se um dos maiores desafios enfrentados pelos desenvolvedores. A API Fragments, lançada a partir do Android Honeycomb 3.0, busca resolver grande parte desses problemas. Assim, este artigo visa demonstrar, por meio de um estudo de caso, as vantagens no uso desta nova API, e se a mesma satisfaz as necessidades dos desenvolvedores. 1. Introdução
A popularização dos tablets contribuiu para o surgimento de um novo mercado para a produção de aplicativos móveis. Com características muito parecidas com as de um
smartphone, e com recursos básicos de um computador pessoal esse aparelho, em
formato de prancheta, despertou o interesse de muitos usuários e também das empresas por possuir tamanho compacto, leveza e muita praticidade em seu uso.
Mais leve, mais fino, e com um número considerável de aplicativos gratuitos, os
tablets, rapidamente, ganharam espaço entre os consumidores. O seu crescimento
ampliou o mercado para desenvolvimento de aplicações móveis e com ele novos desafios foram lançados para os desenvolvedores.
Entre os novos desafios a criação de aplicativos para smartphones e tablets que fossem compatíveis, e ao mesmo tempo diferentes tornou-se um problema para os programadores devido aos diversos tamanhos de tela entre os dispositivos.
Este artigo apresenta a API Fragments, uma classe poderosa que foi lançada a partir do sistema operacional Android Honeycomb 3.0 em 2011, e pretende auxiliar o desenvolvedor na solução desse problema.
Por meio de um estudo de caso, este artigo demonstrará o uso da API
Fragments, os conceitos mais importantes, os resultados e os benefícios obtidos durante
o processo de desenvolvimento de uma aplicação para tablets e para smartphones. No início, o artigo trará o surgimento do sistema operacional Android, depois abordará as classes mais importantes para se compreender o uso dos fragmentos, assim como o ciclo de vida de uma aplicação, trechos de código até o levantamento do estudo de caso e seus resultados. Ao final deste artigo, o leitor encontrará informações para baixar o aplicativo que foi criado diretamente na loja Play da Google.
2. Android
O sistema operacional Android foi lançado oficialmente para os usuários no ano de 2008, o sistema nasceu do acordo feito entre a OHA (Open Handset Alliance) e um consórcio liderado pelas gigantes da área da telefonia e tecnologia, entre eles: Samsung, Nokia, Morola, Sony Ericsson, HTC, Huawei, Asus, Acer, Dell, etc [Meier, 2012].
A Google promoveu seu novo sistema maciçamente entre os desenvolvedores e conseguiu estimular o mercado para que novos aplicativos fossem criados rapidamente antes do lançamento oficial do produto. Para isso, realizou diversos concursos e maratonas de programação, premiando os melhores aplicativos e seus criadores o que gerou mais expectativas ao redor do mundo pelo seu lançamento [Lecheta, 2012].
O novo sistema agradou os fabricantes e desenvolvedores, pois seu código aberto permitiu personalizações e alterações de código conforme a necessidade de cada fabricante. Após o lançamento, os dispositivos com Android popularizaram-se rapidamente pela grande quantidade de recursos, interface visual atrativa, GPS, além da enorme variedade de aplicativos disponíveis em uma loja de aplicativos própria denominada, inicialmente, de Android Market e que, atualmente (2013), passou a chamar-se Play Store.
As versões do Android são conhecidas como plataforma e cada uma delas é identificada por sua API Level, conforme o quadro da figura 1.
A participação do Android no mercado mundial chegou ao segundo trimestre de 2013 a 75% do total. A partir do terceiro trimestre do ano esse número aumentou para 81,3% e o iOS apresentou uma rápida queda, passando de 15,6% para 13,4%. Ainda assim, o sistema da Apple se mantém confortável na segunda posição conforme o gráfico da figura 1 [Strategy Analytics].
Figura 1. Quadro com as versões do Android e gráfico demonstrativo da participação global do Android em 2013. Adaptado dos sites [Android Developers] e [Strategy Analytics], respectivamente.
Desenvolvido sobre a plataforma do Linux, utilizando o kernel 2.6 que realiza todo controle e gerenciamento de memória, processos, threads entre outros. O Android possui uma máquina virtual própria, chamada Dalvik, onde todas as aplicações desenvolvidas são compiladas, convertidas para o formato .dex (Dalvik Executable) e compactadas em um arquivo com a extesão .apk (Android Package Executable) que nada mais é que a aplicação pronta para ser instalada [Lecheta, 2012].
A seguir será discutido aspectos da implementação de software para a plataforma Android.
2.1 A classe View
Para entender como a API Fragment funciona, é necessário conhecer um pouco sobre a classe View e Activity. A classe View é uma das mais importantes para o desenvolvimento de aplicativos para Android, pois todos os elementos gráficos são gerados por ela. Esta classe realiza também o gerenciamento de layout, desenhos na tela e criação de objetos. Possui ainda várias subclasses que são suas herdeiras, tais como:
buttons, textviews, imageview etc [Lecheta, 2013].
As telas para Android podem ser criadas diretamente por uma classe Java ou através de um arquivo XML (Extensible Markup Language) que deve estar obrigatoriamente vinculado a uma classe e esta classe, por sua vez, pode atribuir métodos e funcionalidades específicas para este layout.
Existem dois componentes que são herdeiros diretos da classe View. São eles os gerenciadores de layout e os widgets. Os gerenciadores de layout são basicamente componentes para agrupamento de elementos gráficos na tela e sua classe mãe é a
ViewGroup. Os widgets também são herdeiros diretos da classe View. A represetação da
classe pode ser observada na figura 2.
Figura 2. Representação da classe ViewGroup 2.2. A classe Activity
Esta classe trabalha em conjunto com a classe View sendo que todas as telas geradas pela aplicação devem possuir uma classe Activity atreladas a ela. Sua função basicamente é controlar todos os eventos ocorridos na tela e estabelecer uma View que representará a tela da aplicação.
Todas as classes que herdam da classe Activity devem ser declaradas no arquivo
AndroidManifest.xml que guarda todas as configurações da aplicação. Caso uma Activity não seja declarada neste arquivo, a aplicação não poderá ser executada
causando um erro fatal que fechará o aplicativo quando for aberto [Meier, 2009].
Figura 3. Ciclo de vida de uma Activity adaptado de [Lecheta, 2013]
A classe Activity possui um ciclo de vida que controla os possíveis estados de uma aplicação e também faz-se necessário conhecer este ciclo e seu funcionamento. Na figura 3 podemos visualizar todos os estados de uma aplicação. Supondo que uma aplicação poderá ser interrompida a qualquer momento, seja por uma chamada telefônica ou pelo próprio usuário, quando este resolve abrir outro aplicativo concomitantemente ao primeiro que foi executado, esta aplicação deverá estar preparada para estas possíveis mudanças de estados de tela e saber o momento certo para pausar, executar novamente ou ser destruída caso seja necessário [Lecheta, 2012].
3. API Fragments
Com o lançamento do Android Honeycomb 3.0, a Google melhorou e muito o desenvolvimento de aplicações para tablets. Esta nova API produzida especialmente para eles introduziu uma nova API chamada de Fragments.
Segundo, Lecheta (2012):
Um fragment permite desvincular a responsabilidade de gerenciar o conteúdo da activity, de forma que a activity principal pode ficar bem simples. Cada fragment representa uma view na tela, e na verdade ele é adicionado na tela da mesma forma que uma view comum.
Antes desta nova API, o desenvolvimento para tablets era muito complicado e trabalhoso, pois a activity principal ficava muito sobrecarregada com o excesso de código e atribuições delegadas a ela pelas diversas views. Para aproveitar o grande espaço das telas os desenvolvedores precisavam de muita criatividade e paciência, pois a metodologia antiga gerava muita duplicação de código, desorganização de classes e manutenção difícil e complicada. Como cada tela é gerenciada por uma Activity, a distribuição de várias janelas em uma mesma View poderia torna-se um desafio para o desenvolvedor [Lecheta, 2013].
Cada fragment controla seu layout de tela ou janela de forma simples e totalmente independente da view principal podendo até mesmo lançar uma thread própria para atualização de conteúdo sem que isso afete o desempenho da view principal. A figura 4 ilustra a tela de um tablet com vários destes fragmentos. A view principal fica por sua vez livre e sua activity menos sobrecarregada já que todo o trabalho pesado é transferido entre as fragments que componham a tela [Lecheta, 2013].
Figura 4. Layout de tela para tablet utilizando fragments
Apesar da API Fragments ter sido lançada a partir do Android Honeycomb 3.0, versão exclusiva para tablets, seus recursos podem ser utilizados em smartphones mais antigos como os que possuem a versão do Android 2.x. Para isso, é necessário estender a classe Fragment a partir de uma Activity utilizando uma biblioteca própria dentro da aplicação. Essa opção é muito útil quando o desenvolvedor precisa que sua aplicação com fragment também execute em smartphones. A fragment, ao contrário da activity, não precisa ser declarada no arquivo de configurações AndroidManifest.xml [Meier, 2012].
Assim como a classe Activity a API Fragments possui um ciclo de vida específico que possui muita semelhança ao ciclo de vida de uma Activity. Os eventos seguem a seguinte ordem: created, started, resumed, paused, stopped e destroyed. As ações sofridas em uma tela com vários fragments serão transmitidas a todos os elementos ao mesmo tempo. Portanto, se o usuário clicar no botão voltar do dispositivo será chamado o método pause ou destroyed da aplicação que executará uma ação em cascata para fechar todos os elementos da tela [Meier, 2012]. A figura 5 demonstra todos estes estados citados.
Figura 5. Ciclo de vida Fragment adaptado de [Meier, 2012] Os métodos mais importantes do ciclo de vida de um fragment são:
onAttach – esse método é chamado antes da inicialização da Fragment e está
referenciado a uma Activity.
onCreate – considerado o método mais importante, pois será associado a uma View que
retornará um objeto do tipo LayoutInflater como parâmetros para construção do
Fragment.
onActivityCreated – esse método é utilizado para disparar transações e buscar elementos
para compor a tela.
onDestroyView – método responsável por destruir a view criada pelo fragment.
onDetach - após a destruição da view pelo método onDestroyView, a mesma é
desassociada de sua respectiva activity por este método.
É importante ressaltar que todos esses métodos do ciclo de vida do fragment trabalham em conjunto com os métodos do ciclo da activity. Quando, por exemplo, o método onPause da activity é acionado o método onPause da fragment também é chamado na sequencia, um método está ligado ao outro.
Outro método que deve ter uma atenção especial é o onCreate que, em grande parte do tempo, estará associado a um arquivo XML através do objeto LayoutInflater. Este tipo de construção de tela é o ideal e o mais indicado pelos autores ao se usar
fragments [Meier, 2012].
Outra forma bastante útil para se criar fragments, sem utilizar o layout em XML, é chamando diretamente em tempo de execução a classe FragmentTransaction, que pode incluir, remover e substituir um ou vários fragments facilmente. Essa classe também suporta animações de tela entre outros recursos.
4. Estudo de Caso e Resultados
Neste estudo de caso foi desenvolvido um aplicativo para divulgar os produtos de uma empresa real no Google Play. A empresa possui como clientela, em sua grande maioria, gestantes das classes A e B, entre 25 e 40 anos de idade, com nível superior, modernas e detalhistas.
Foi observado que esses clientes, quando chegam à empresa, trazem consigo
tablets para mostrar o modelo do produto que procuram. Com base nessas informações,
a empresa resolveu desenvolver um aplicativo próprio para tablets e smartphones em que os clientes pudessem, a qualquer momento, acessar o catálogo de produtos de forma mais prática.
O aplicativo criado utiliza a plataforma Android e tem como base a API
Fragments. Com o uso desta API, foi possível criar em um único executável, uma
aplicação tanto para smartphones quanto para tablets com layouts diferenciados. Após esse estudo, o desenvolvedor poderá optar por usar ou não esta nova API conforme suas necessidades.
4.1 Ambiente
O ambiente utilizado para o desenvolvimento da aplicação é descrito abaixo:
Hardware: Processador Intel® Core™2 Quad CPU Q8200 @ 2.33GHz × 4, 4 GB de RAM – Random Acess Memory, 32-bit e disco de 320GB.
Sistema Operacional: Ubuntu 13.04, 32 bits e Windows 7 Professional Tecnologia: Java Android.
IDE: Integrated Development Environment (Ambiente Integrado de Desenvolvimento): Android Developer Tools
4.2 Metodologia
A solução foi criada para se comportar de forma diferente de acordo com o tipo do dispositivo, smartphone ou tablet, dependendo do aparelho o layout será adaptado e poderá contar com recursos diferenciados específicos.
Para que dispositivos com Android 2x possam usufruir da nova API Fragments, foi necessário adicionar uma biblioteca de compatibilidade chamada
android.support-v4.jar dentro da pasta libs do projeto. Esse é o primeiro passo que o desenvolvedor
deverá observar. A figura 6 ilustra as etapas do procedimento para incluir a biblioteca.
Neste projeto, a versão para smartphone foi desenvolvida primeiro e depois o código foi adaptado utilizando fragmentos para seu uso em tablets. Algumas diferenças entre os dispositivos como recursos e tecnologias, devem ser levadas em consideração neste momento. Uma das principais diferenças é o fato de que em grande parte dos
tablets, comercializados no mercado até o momento em que este artigo foi escrito, ainda
não possuíam a funcionalidade para efetuar chamadas telefônicas. Outros não contavam com GPS (Global Positioning System) e acesso a redes móveis 3G. Por isso, o desenvolvedor deverá ficar atento a estes detalhes.
O projeto criado possui em sua versão para smartphone, um botão para efetuar ligações e outro para enviar torpedos via SMS (Short Message Service), esses dois itens serão ocultados quando o usuário utilizar um tablet.
Figura 7. Tela com uma única view
Em uma aplicação simples que não utiliza a API Fragment, todo o código da tela de layout está ligado diretamente à uma Activity que, por sua vez, é responsável por todo gerenciamento de conteúdo, controle de threads e atualizações. Os especialistas recomendam que para cada View, figura 7, seja utilizada uma thread diferente, para que seu conteúdo seja atualizado ao mesmo tempo e independente das outras views [Lecheta, 2013].
O código dessa view é controlado pela classe MainActivity e utiliza o método
setContentView(R.layout.activity_main) para fazer a ligação entre o arquivo XML e
definir todas as funcionalidades para esta tela conforme os arquivos da tabela 1.
Tabela 1. Exemplo de arquivo XML ligado a uma classe.
Arquivo XML (Layout) Classe atrelada ao arquivo XML <RelativeLayout xmlns:android="http://schemas.android.com/apk/re s/android" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" android:paddingBottom="@dimen/activity_vertical_ margin" android:paddingLeft="@dimen/activity_horizontal_ margin"
public class MainActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState); setContentView(R.layout.activity_main);
} }
android:paddingRight="@dimen/activity_horizontal _margin" android:paddingTop="@dimen/activity_vertical_mar gin" tools:context=".MainActivity" > </RelativeLayout>
Supondo que o cenário seja um pouco diferente e que a aplicação deverá exibir um conteúdo mais amplo, diversificado, com uso de busca de dados externo e com atualização individual de cada elemento na tela, a partir deste ponto a questão começar a ficar um pouco mais complicada, pois a Activity terá um trabalho muito maior para gerenciar esta imensa quantidade de views ficando portanto, sobrecarregada. Como exemplo a figura 8 ilustra diversas views espalhadas pela tela de um tablet.
Figura 8. Tela com várias views distribuídas
Para esse caso, a classe Fragments pode ser bastante útil, pois ela divide cada parte da tela em pequenos pedaços e cada pedaço pode ser controlado individualmente, deixando livre a Activity principal, conforme o exemplo da figura 9. Cada View está relacionada a um arquivo de layout XML que, por sua vez, está relacionada a uma classe Java capaz de gerenciar de forma independente todo o conteúdo deste fragmento, sem sobrecarregar a tela principal.
Figura 9. Exemplo de uma aplicação com várias views utilizando fragments. 4.3 Resultado
No estudo de caso a tela do tablet foi dividida em duas partes seguindo o modelo proposto a seguir na figura 10:
Figura 10. Exemplo de como dois módulos de interface do usuário definidos por fragmentos podem ser combinados em uma activity para um projeto de tablet. Adaptado do site Google Developers.
No arquivo AndroidManifest.xml foi configurado a API Level mínima para 4, conforme a figura 11, correspondente à versão 1.6 do Android e a partir desta versão qualquer dispositivo Android que possua uma versão igual ou superior a esta poderá executar a aplicação com o uso da biblioteca de compatibilidade para Fragments.
Figura 11. Configuração do arquivo AndroidManifest.xml para executar também na versão mínima Android 1.6
Uma classe foi utilizada como base para todas as outras conforme ilustrado na figura 12. Ela tem a função de herdar diretamente da biblioteca de compatibilidades a API Fragments e todas as suas subclasses, a classe Fragment nativa foi descartada.
Figura 12. Classe base de todo o projeto que herda a biblioteca de compatibilidade Fragment
Até o momento não era possível colocar duas Activities em uma única tela. Mas, a partir de agora, todo o código da Activity pode ficar encapsulado dentro de um
Fragment. Os fragmentos podem estar em layouts sozinhos, com Views ou junto com
outros Fragments. Com isso, o problema de colocar duas activities em uma única tela é resolvido [Motorola Mobility, 2013].
No código que se segue na figura 13, um fragmento foi adicionado para representar todo o código de layout que está contido no arquivo
fragment_informacoes.xml.
Com esta alteração o projeto inicial, que tinha como foco apenas as pequenas telas dos smartphones, poderá utilizar mais de uma activity em um único local e abrir um novo caminho para a implantação de um layout mais refinado para tablets. O layout foi transferido para outro arquivo auxiliar como pode ser observado na figura 14.
Figura 14. Trecho do código do arquivo fragment_informacoes.xml.
Na figura 15, do arquivo o layout é inflado a partir do método inflate e o arquivo
fragment_informacoes é carregado como layout e os fragments são instanciados quando
a activity carrega o layout.
Figura 15. Código do arquivo FragmentInformacoes.java.
O uso da API Fragment ajuda muito a simplificar a lógica de negócio em cada
fragment. Ao utilizar fragments, o código é quebrado em pedaços menores e
reutilizáveis, podendo reutilizar esse componente em diversas telas posteriormente [Lecheta, 2013].
O resultado final é bastante significativo, pois através do refatoramento de algumas linhas do código obteve-se, em uma mesma aplicação, dois layouts diferentes
para smartphones e tablets de um modo muito mais produtivo e organizado conforme a figura 16.
Figura 16. Telas do aplicativo “Ateliê do Bebê by Mariza” disponível para sistema operacional Android versão 1.6 até 4.3 nas versões smartphone e tablet.
5. Conclusão
O estudo de caso demonstrou como é simples a utilização de fragmentos para a composição de telas diferenciadas para tablets que usam o sistema operacional Android. Algumas vantagens que foram destacadas por Lecheta e confirmadas no desenvolvimento deste projeto são:
O código da aplicação fica mais simples de manter; Organização do código;
Reutilização do fragment em outra activity sem duplicar o código;
Um fragment pode buscar seu conteúdo de forma totalmente independente de outro fragment;
Um fragment pode iniciar uma thread para buscar informações, se necessário; Um fragment é uma miniactivity capaz de fornecer conteúdo totalmente
independente de outros fragments.
Ao se fazer uso de uma View sem a API Fragments alguns problemas poderão ocorrer; como por exemplo, o código da activity principal poderá ficar sobrecarregado devido ao excesso de tarefas delegados a ela tornando o processamento da aplicação muito lento e consequentemente poderão ocorrer travamentos na aplicação. Este é um dos motivos principais nos quais recomenda-se o uso da API Fragments.
Durante o desenvolvimento do aplicativo alguns contratempos foram detectados, o principal deles foi a grande disparidade entre a velocidade dos emuladores no
Windows e no Ubuntu. O computador que foi utilizado possuía duas partições, uma com Windows 7 e a outra com o Ubuntu 13.04, o aplicativo foi testado nos dois sistemas operacionais, e o que percebeu-se é que no Windows para iniciar o emulador o tempo gasto era bem maior do que no Ubuntu, quase o dobro do tempo. Esse fraco desempenho do Windows dificultou os testes que foram, assim, transferidos para o Ubuntu.
Apesar do bom desempenho para iniciar o emulador o Ubuntu também apresentou alguns problemas, o mesmo não conseguia iniciar dois emuladores simultaneamente. Outro ponto negativo foi o não reconhecimento do tablet físico da marca AOC utilizado nos testes tanto no Ubuntu quanto no Windows, a ausência do
driver não permitiu que os testes fossem realizados no aparelho real.
Para instalar e testar o sistema no tablet AOC, a única alternativa encontrada foi exportar o projeto do Eclipse para um pendrive e transferir o arquivo executável diretamente para o aparelho. De fato, o teste em aparelhos reais é o mais recomendado entre os autores.
Espera-se que este trabalho contribua para a melhoria no desenvolvimento de aplicativos para Android e que o mesmo satisfaça as necessidades dos desenvolvedores em relação à criação ou migração de uma aplicação de smartphones para tablets, explorando os mais variados tamanhos de telas existentes de forma mais organizada e eficiente.
Uma sugestão para futuros artigos seria demonstrar o uso de um Webservice para alimentar a base de dados da aplicação. Além disso, um estudo mais aprofundado sobre a subclasse FragmentTransaction, uma outra maneira de adicionar um fragment na tela utilizando diretamente a API Java em tempo de execução, é recomendado para a continuidade deste artigo.
O aplicativo desenvolvido neste artigo encontra-se disponível na loja do Google Play sob o nome de “Ateliê do Bebê by Mariza” para download.
6. Referências
Android Developers. Fragments. Disponível em
http://developer.android.com/guide/components/fragments.html Acesso em: 09 de Setembro de 2013.
Lecheta, Ricardo R. (2013) “Google Android : aprenda a criar aplicações para dispositivos móveis com o Android SDK”, 3. Ed. , Novatec Editora, São Paulo. Lecheta, Ricardo R. (2012) “Google Android para tablets: aprenda a desenvolver
aplicações para o Android: de smartphones a tablets”, Novatec Editora, São Paulo. Lehtimäki, Juhani (2013) “Smashing Android UI: responsive Android UI and design
patterns for phones and tablets”, John Wiley & Sons Inc., United Kingdom.
Meier, Reto (2012) “Professional Android 4 Application Development”, John Wiley & Sons Inc., Indianapolis.
Meier, Reto (2009) “Professional Android Application Development”, Wiley Publishing Inc., Indianapolis.
Motorola Mobility. Introdução a fragmentos. Disponível em http://www.slideshare.net/motodev/introduo-a-fragmentos. Acesso em: 28 de Outubro de 2013.
Open Handset Alliance. Open Handset Alliance. Disponível em http://www.openhandsetalliance.com/. Acesso em: 16 de Setembro de 2013.
Strategy Analytics. Disponível em http://www.strategyanalytics.com/. Acesso em: 12 de Dezembro de 2013.
