Android

21 jan, 2016

Android DevConference 2015: os dias de infância já passaram

Publicidade

A primeira versão do SDK para desenvolvimento de aplicações para Android remete ao distante ano de 2008. Nesses sete anos que se passaram, os desenvolvedores que trabalham com essa tecnologia tiveram a oportunidade de assistir a uma excitante evolução do Android como plataforma ubíqua para o desenvolvimento de aplicações móveis; não obstante, o método de trabalho e as ferramentas do dia a dia vêm evoluindo e se aprimorando continuamente, de maneira que a forma de pensar a construção de um aplicativo Android hoje é radicalmente diferente se comparada à de pouquíssimo tempo atrás – falar em um ano talvez não seja um exagero aqui.

A plataforma evoluiu e as ferramentas melhoram drasticamente. A API oficial está em sua versão 23. Vimos o ocaso da IDE Eclipse e do plugin ADT como solução oficial para desenvolvimento, bem como o surgimento e a disseminação da solução Android Studio combinada com Gradle Build System, o que definitivamente consolidou um ambiente de trabalho mais estável e melhor, em linhas gerais.

Vimos a evolução das bibliotecas de suporte, além do surgimento e da adoção em massa das APIs dos Google Mobile Services – distribuídas através do aplicativo do Google Play – como recursos para a promoção de comportamentos consistentes e unificados dentro das aplicações ao longo das várias versões da plataforma – e, definitivamente, fragmentação é hoje um problema muito menor do que a mídia “especializada” divulga para nós, desenvolvedores.

Dada toda essa evolução do ecossistema e do ferramental, o que será que os próximos dias reservam? No intuito de encontrar algumas dessas respostas, o Android DevConference aconteceu em agosto, trazendo à baila algumas reflexões e contando com a presença de mais de 600 participantes, de todos os lugares do Brasil.

É um ledo engano pensar que todos os problemas estão resolvidos dado o status quo atual das ferramentas e soluções para os desenvolvedores Android. A maturidade desse tipo de desenvolvimento vem tomando forma há cerca de três anos e, hoje, diversos caminhos se colocam adiante, no sentido de possibilitar aplicações que sejam cada vez mais complexas e ao mesmo tempo robustas, confiáveis, de fácil manutenção, impactantes e encantadoras para os usuários.

Alguns problemas remetem às próprias raízes da plataforma em si. A API do Android é primariamente acessível através da linguagem de programação Java, hoje com suporte oficial para a versão 7. Não obstante, essa API implementa apenas um subconjunto do CoreJDK, além das APIs específicas do Android em si e alguns (poucos) pacotes open source, que vagamente vão sendo depreciados…

Uma das consequências diretas do desenho da API do Android é a enorme verbosidade associada à linguagem Java em si. Contudo, sendo o toolchain do Android inspirado nas ferramentas para o Java tradicional, naturalmente linguagens que têm como alvo a JVM – como Scala e Groovy – passaram a buscar um lugar ao sol dentre os desenvolvedores, e a grande estrela do momento é Kotlin, linguagem desenvolvida e mantida pela JetBrains – empresa responsável pela IDE Android Studio – e que traz diversas características de linguagens de programação modernas com compatibilidade com o Java6, permitindo uma base de código muito mais concisa e expressiva para a aplicação. Trata-se de algo que facilita o trabalho dos desenvolvedores com prejuízo quase nulo de performance para a aplicação (e o usuário) final.

Por outro lado, uma aplicação que almeja ser robusta e encantadora precisa abusar do que melhor existe nas bibliotecas de compatibilidade, desenvolvidas e oferecidas pelo próprio Google. Não cabe aqui apenas referenciar os tradicionais backports de APIs, como Fragments, GridLayout, RecyclerView e outros: agora temos toda uma biblioteca que oferece padrões de interface e usabilidade consolidados na proposta do Material Design e que estão disponíveis para uso em implementações simples, diretas e – claro! – retrocompatíveis. Adicionalmente, hoje temos mais de 70% da base de aparelhos rodando versões do Android superiores ao KitKat, o que torna tudo o que pode ser criado com a API de Transitions capaz de reduzir em muito o trabalho para construções de animações complexas – acessível à grande maioria dos usuários das nossa aplicações.

É preciso destacar também que atualmente é quase impossível, do ponto de vista de produtividade, construir aplicações Android sem alguma biblioteca de código aberto, em especial aquelas consolidadas dentro da comunidade de desenvolvimento. Conhecer as principais opções, como consumo de REST, bibliotecas para ORM, Logging, consumo de imagens de forma assíncrona, Publisher/Subscriber e outras, medindo prós e contras, é básico para qualquer desenvolvedor moderno.

Ainda dentro do mundo open source, diversas soluções têm surgido para resolver antigos problemas ainda ligados ao desenho do framework do Android em si, como a ausência de um mecanismo padrão para implementar injeção de dependências na aplicação – objetivo hoje facilmente alcançável com a biblioteca Dagger2, também explorada a fundo no evento em uma apresentação dedicada ao tema.

Uma aplicação Android moderna é essencialmente construída de forma orientada a eventos, quase em sua totalidade assíncronos ou mesmo incontroláveis do ponto de vista do ciclo de vida de seus componentes. Nesse sentido, uma solução de fronteira, inicialmente criada pelos engenheiros do Netflix para problemas na Web e atualmente conduzida pela comunidade de código aberto, invadiu o dia a dia dos desenvolvedores Android, oferecendo um alento da programação funcional para a solução desse tipo de problema. RxJava é um dos assuntos mais quentes do momento para quem trabalha com o robozinho, e também teve uma palestra dedicada ao tema no evento. Definitivamente, é algo que um desenvolvedor moderno precisa entender e que uma aplicação moderna vai se beneficiar ao adotá-lo.

Por fim, não menos importante, foram-se os dias em que testes automatizados e a arquitetura da aplicação eram assuntos de segunda – ou terceira – ordem. Aplicações robustas precisam ser pensadas com um bom design de seus componentes em foco, tanto do ponto de vista de divisão de responsabilidades – e, aqui, falamos de padrões de arquitetura como MVP, MVVM e outros que ofereçam alguma saída para o código macarrônico induzido pelo framework do Android nas camadas de UI – quanto do ponto de vista de coesão e acoplamento de cada classe de domínio em si, no sentido de facilitar os testes automáticos, unitários e de interface, que atualmente têm um suporte oficial cada vez melhor com as novas ferramentas, como AndroidJUnitRunner, Espresso e Support Testing Library.

Dado tudo o que foi exposto até aqui – e que constitui apenas um breve resumo do que tivemos na edição deste ano -, o Android DevConference traz como a conclusão principal que os dias de infância do ecossistema de desenvolvimento para Android chegaram ao fim.

Aplicações que não se atentem para o que existe de mais moderno e mais atual e optem por seguir um caminho mais “tradicional”, usando a mentalidade de desenvolvimento de dois anos atrás, tendem a ficar muito distantes de concorrentes antenados do ponto de vista competitivo, podendo facilmente cair no ostracismo e irrelevância.

A velocidade de iteração e a adaptabilidade são alguns dos fatores mais críticos no sucesso de qualquer projeto ou negócio que envolve software, e as soluções que hoje viabilizam isso de forma mais elegante, produtiva e (por quê não?) divertida para Android já não são mais as mesmas de antigamente. O desenvolvimento para Android chegou enfim à sua fase adulta, e é melhor a sua empresa e o seu time estarem atentos para não abraçarem o novo quando já for tarde demais.