Um dos
problemas mais falados sobre a plataforma Android é sua fragmentação, que
envolve as diferenças entre hardwares, resolução e densidades de displays e,
versões do sistema operacional. Bem, tenho uma boa e uma má notícia para você
que está lendo este texto e é desenvolvedor Android:
Notícia ruim: realmente a fragmentação existe e não temos como
fugir dela;
Noticia boa: a plataforma Android é inteligente o suficiente
para fornecer diversos mecanismos para atacar e minimizar este problema. Temos
a especialização dos recursos, com isso, podemos fornecer menus, conteúdos
textuais e, principalmente, Views específicas
para cada aparelho, ou família de aparelhos. Quanto ao problema de diferenças
de hardware, a plataforma também
fornece APIs agnósticas, que só
impedem uma distribuição global de seu aplicativo se o código não for bom.
Porém,
neste pequeno artigo vamos focar na resolução do problema de fragmentação em relação à diferença de
versões do sistema operacional. No momento da escrita deste texto (Junho de
2013), o market share do Android 2.3.x supera as outras versões, tendo cerca de
44,1%. Porém, as versões acima da 4.0 também estão bem no mercado, com 28,6% e
16,5% para o Android 4.0.x e 4.1.x/4.2.x, respectivamente. O problema disso é
que temos APIs que só funcionam em algumas versões. Um dos casos mais famosos
são os Fragments, introduzidos na
versão 3.0. Como resolver este problema todo?
Existem
duas soluções principais e com um alto poder de auxílio para nós,
desenvolvedores Android:
Biblioteca de Compatibilidade: esta biblioteca permitiu que
recursos criados para versões mais recentes do Android possam ter retro
compatibilidade. Um exemplo bem conhecido são os Fragments.
Nas
versões mais novas do ADT, ao criar
um projeto no Eclipse já podemos perceber que dentro da pasta libs tem um jar com o nome iniciando em android-support-<versão>.
Com ela podemos utilizar Fragment,
GridLayout e outras classes criadas em versões mais recentes.
E o
melhor dessa história é o fato de, geralmente, utilizarmos as classes
exatamente da mesma forma como utilizaríamos em seu pacote normal. Veja o
trecho de código abaixo:
FragmentTransaction
transaction = getSupportFragmentManager().beginTransaction();
transaction.setCustomAnimations(R.anim.enter, R.anim.exit);
drugFragDetail = new DrugFragmentDetail();
drugFragDetail.setArguments(b);
transaction.add(R.id.detailFragment,
drugFragDetail);
O único
indício de uso da biblioteca de compatibilidade (sem olhar os imports) é o getSupportFragmentManager. Na API do Android 3.0 o método seria
o getFragmentManager. Por isso utilizei
a expressão “geralmente” há poucos parágrafos acima. Os imports das classes também alteram de android.app.* para android.support.v4.app.*.
Mas mesmo assim perceba que é um trabalho pequeno comparado aos benefícios
que temos como retorno.
Claro que
neste pequeno artigo não podemos mostrar todas as possibilidades desta
biblioteca de compatibilidade. Mas não se esqueça dela, em breve estará
utilizando-a massivamente em seus projetos.
Lint API Check: a outra fórmula milagrosa que podemos utilizar se
chama Lint API Check. Surgiu a partir
de mudanças feitas no ADT 17 e, permitiu que um código Android possa ser feito
com condicionais referentes a versão do sistema operacional. Mas claro que não vamos
fazer isso via código if-else por
exemplo, mas sim, utilizando Java
Annotations.
Para
exemplificar este conceito através de código vamos utilizar a PreferenceActivity. Esta era uma classe
filha de Activity especializada para
o uso de persistência de dados com SharedPreferences.
Acontece que depois da versão 3.0 do Android, o método que associa os campos
a serem persistidos mudou, ficando depreciado para versões pré 3.0. Podemos deixar
o código depreciado mesmo? Sim, mas não é o ideal. O Google tem boas razões para indicar isso e sempre que possível,
devemos remover este warning do
código.
Veja a
listagem abaixo:
import android.annotation.TargetApi;
import …
public class PreferenciaActivity extends
PreferenceActivity {
public static int prefs_xml= R.layout.preferencias;
@Override
protected void onCreate(final Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
try {
getClass().getMethod("getFragmentManager");
addResources11();
} catch (NoSuchMethodException e) {
addResourcesPre11 ();
}
}
@SuppressWarnings("deprecation")
protected void addResourcePre11()
{
}
@TargetApi(11)
protected void addResource11 ()
{
getFragmentManager().beginTransaction().replace(android.R.id.content, new PF()).commit();
}
@TargetApi(11)
public static class PF extends PreferenceFragment
{
@Override
public void onCreate(final Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
addPreferencesFromResource(PreferenciaActivity.prefs_xml);
}
}
}
No onCreate da PreferenceActivity estamos verificando se existe o método getFragmentManager. Caso afirmativo o bloco try irá trabalhar sem problemas e, isso nos diz que o aplicativo estará sendo executado em uma versão 3.0, ou superior, do Android. Caso negativo, versão 2.3 ou inferior.
Se
estivermos em 3.0 ou superior, chamamos o método addResources11, específico para estes API Level ´s. Mas sem a annotation
@TargetApi(11) e o import android.annotation.Target, o código irá
apresentar problemas ainda na compilação.
No método
addResources11 estamos fazendo uma
instância da classe PF, que também
está marcada com a anotação. A regra aqui é: a annotation sempre deve existir em método e classe que desejarmos
especificar em qual API Level ela
trabalha, logicamente com exclusividade.
Com isso
o código irá rodar perfeitamente em qualquer versão do Android, utilizando as
últimas técnicas e as classes indicas pela competente equipe que cria a
plataforma.
Apesar de
ser um artigo curto, espero ter indicado o caminho das pedras para dizimarmos o
fantasma da fragmentação de api level dentro
do Android. Use e abuse da biblioteca de compatibilidade e da Lint API
Check.
Att.
Ricardo
Ogliari
Comentários