4 minutos de leitura
Autor(a)
Alex é instrutor e desenvolvedor e possui experiência em Java, Kotlin, Android. Atualmente cria conteúdo no canal https://www.youtube.com/@AlexFelipeDev.
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Se você é um desenvolvedor Android experiente, não é novidade que o SDK do Android não opera com as versões mais recentes do Java, em específico, atualmente temos 100% de compatibilidade com a versão 7 do Java.
Isso significa que as features legais que temos no Java 8 ou mais, por padrão, não estão disponíveis!
Como uma alternativa, a própria comunidade desenvolveu libs capazes de trazer um pouco da experiência do Java 8 no Android, como é o caso do Retrolamba que permite o uso de expressão lambda para interfaces funcionais (Single Abstraction Method).
Com base no interesse da comunidade, a própria equipe da Google disponibilizou o Jack (Java Android Compiler Kit), também conhecida como Jack toolchain, como uma alternativa experimental, para possibilitar algumas features do Java 8 'nativamente'.
Mesmo tendo uma proposta boa, a configuração via Jack toolchain não era das melhores, como também, haviam outros impactos que o depreciaram :(
Então, a partir da versão 3.0 do Android Studio, a Google otimizou essa solução adicionando uma etapa a mais na transformação de bytecode chamada desugar:
O desugar opera logo depois do código ser compilado pelo próprio compilador do Java, possibilitando o uso das features do Java 8 mesmo tendo a limitação de versão.
Para habilitar as features do Java 8 com o desugar, precisamos apenas adicionar o seguinte script no arquivo de build do módulo:
android { // demais configs
compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } }
Pronto, somos capazes de usar as features do Java 8 disponibilizadas.
"Legal, mas em quais situações posso usufruir das features do Java 8?"
A mais comum está relacionada às interfaces funcionais, como é o caso de listeners, por exemplo, um listener de clique com expressão lambda fica da seguinte maneira:
botao.setOnClickListener(v -> {
// implementação do clique
});
Comparando com a maneira 'tradicional':
botao.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
// implementação do clique
}
});
Bem mais simple, né?
Entretanto, nem todas as features estão acessíveis para qualquer versão de SDK do Android, mas não fique triste, abaixo estão as features disponíveis em quaisquer versões:
Da mesma forma, existem outras APIs, como é caso da classe Stream, que só são suportadas quando utilizamos a versão 24 como SDK mínimo. Outro caso são as classes do pacote java.time que exige a API 26.
De qualquer forma, é possível verificar os pacotes acessíveis diretamente pela documentação do Android. Agora vem a questão:
Caso o seu objetivo são features são suportadas por todas versões de SDK do seu projeto, faz muito sentido usufruir do Java 8.
Agora, se tiver que modificar o suporte mínimo, não é recomendável a mudança, afinal, você vai deixar de atender mais usuários por algo que não trás tanto valor para o produto final.
"Puts, eu queria muito ter acesso à API do
StreamouLocalDate, mas não posso aumentar o suporte mínimo do SDK, e agora?"
Existem algumas libs que podem ser adicionadas, como é o caso da Lightweight-Stream-API e a joda-time. É importante ressaltar que elas possuem uma interface similar às do Java, mas a implementação pode ter diferenças, como a ausência de processamento paralelo.
Muito provavelmente, você já ouviu falar sobre a linguagem Kotlin para desenvolver Apps Android.
A partir dela, temos suporte a expressão lambda, métodos padrões de interfaces entre outras features que não existem na própria linguagem Java, como é o caso de extensão de função, funções de alta ordem entre outras que vemos formação desenvolvimento mobile.
Avalie este artigo
