Meu dia no Android Dev Conference 2k17

No dia 25/08/2k17 estive presente no evento chamado Android Dev Conference em SP para conhecer as novidades do mundo Android e, por incrível que pareça o conteúdo foi muito rico! (Não é só brindes das empresas patrocionadoras! haha :P)

Android Dev Conference 2017 ❤

As palestras que presenciei estão listadas abaixo e posteriormente colocarei algumas percepções que eu tive sobre cada uma:

  • Introdução ao Kotlin — Suelen Carvalho & David Robert Camargo de Campo
  • Android Architecture Components — Danilo Prado
  • Arquitetura de um app Android — Thales Machado & Ygor Barboza
  • Coordinators pattern para Android: como isolar completamente as camadas de navegação e apresentação do seu app — Matheus Cassiano
  • Kotlin: 9 meses depois — André Luiz Cardoso & Thiago Porciúncula
  • NoSQL com Android — Como o novo paradigma de armazenamento de dados muda a forma de fazermos apps — Amelia Pessoa
  • Explorando GraphQL no Android com Apollo — Ubiratan Soares
  • Fragments — Por mais incrível que pareça — Rafael Toledo
  • Tudo o que você precisa saber sobre ConstraintLayout — Nelson Glauber

Então vamos lá para as minhas percepções :)

Introdução ao Kotlin

Kotlin ❤

A palestra teve uma breve explicação sobre a linguagem Kotlin, criada em 2011, pela JetBrains e adotada agora oficialmente pela Google. A maioria dos códigos apresentados nas palestras já estavam utilizando Kotlin e, aqueles que não estavam pediram desculpas, chega até a ser engraçado esse comportamento.

É uma linguagem estaticamente tipada, funcional e Orientada a Objetos o que faz dela uma ótima utilização para diversos cenários e também para tecnologias reativas!

Depois da breve explicação de como funciona bem por cima tivemos um Live Code bem interessante onde mostraram alguns pontos que indicarei a seguir:

  • Data classes: Para a utilização de Modelos na sua aplicação você pode utilizá-las para possuir os getters, setters, toString() e hashCode() com apenas poucas linhas. Tchau Boilerplate e matutenção nos métodos caso seja necessário adicionar mais uma propriedade.
  • Compatibilidade: Tem total compatibilidade com o Java, isso quer dizer que podemos escrever novas classes Kotlin e utilizarmos as classes Javas em qualquer parte do projetos. Para projetos em manutenção é uma boa ideia ir migrando a sua base de código gradativamente.
  • Comparativo: Não é mais necessário utilizar o comparativo equals em Objetos. Somente utilizar == que indica se os objetos são iguais, porém caso seja necessário verificar a instância em si do objeto é necessário colocar mais um = e pronto.
  • Dot notation: Bem parecido com o Objetive C e Swift não é mais nessário chamar os setters e getters, tudo é feito “automagicamente” para você. É bom para a leitura do código, você acaba lendo um pouco menos do que o necessário.
  • Interpolação de Strings: Modo fácil de interpolar as strings sem necessitar chamar o String.format. O mais legal dessa possibilidade é que você não perde performance ao utilizar, por detrás a IDE gera para você uma concatenação de Strings. Exemplo de uso:
println(“Name $name”)
  • Parâmetros com valores padrão: Achei bem interessante pois no nosso dia a dia criamos alguns métodos opcionais para valores que já poderiam ter como default algum valor. Com a utilização disso podemos diminuir um pouco mais o nosso código.
  • Ordem dos parâmetros: Não importa qual a ordem dos parâmetros dos métodos caso você os identifique na chamada da função, dessa maneira você não precisa ficar decorando a ordem e a IDE consegue lhe ajudar no autocomplete.
  • Função Inline: Para métodos mais simples você consegue utilizar métodos inline que auxiliam na performance.
inline fun inlined(getString: () -> String?) = println(getString())
  • Extensions Functions: Que nem no Swift você consegue adicionar métodos em classes do próprio framework ou nas suas. O exemplo que deram no live code foi com a classe BigDecimal criando uma método de cálculo da porcentagem. A utilização das extensions por padrão seria somente via package para os outros casos seria necessário importar no seu arquivo. Lembrando que por trás está sendo criada uma método estático, para utilizar é bem fácil:
NomeDaClasse.nomeDomeMétodo() { … } 
  • Notação Infix: Para os métodos que só tem um parâmetro há a possibilidade de criar métodos infix que pode auxiliar na leitura do seu código. É uma extension ou memberfunction. Para usufruir é necessário colocar o valor infix no ínicio do método:
infix fun Int.shl(x: Int): Int {…}
//Como fica
1 shl 2 
  • Override dos Operadores: Bem legal a possibilidade de realizar o override de alguns operadores mais usuais que encontramos como o ‘+’ e ‘-’. Exemplo:
operator fun plus(increment: Int) : Counter =  { Counter(dayIndex + increment) }

Bom esses foram os pontos que anotei no Live Code da apresentação. Na finalização mostraram também sobre as Coroutines. As coroutines tem como finalidade utilizar funções assíncronas sem a necessidade de utilizar Callbacks e também é bem performático.


Android Architecture Components

Architecture Components

O Android Architecture Components anunciado também no Google I/O deste ano ainda está em preview, por isso ainda não é recomendado criar sua aplicação com ela. É melhor esperar sair a versão oficial para começar a utilizar.

Bom, esta é a primeira arquitetura recomendada e oficial do Google e tem como objetivo ajustar o Ciclo de vida e eliminar boa parte de boilerplate que precisamos codificar em todas a Activities.

O Android Architectures Components é formado pelas seguintes bibliotecas:

Tem como objetivo remover todo o boilerplate dos componentes para as atividades do lifecycle da Activity. É necessário implementar a interface LifecycleObserver para a sua utilização. Um ponto positivo para a utilização disso é que você tem total controle via annotations e saber também em qual estado este componente está, com isso da para saber se a Activity/Fragment está adicionada no momento ou não e fazer todos os preparativos necessários para quando recuperar as informações.

Primeira ORM oficial do Google. Não é mais necessária a criação de todo aquele Boilerplate do SQLite. Para utilizar é somente necessário criar uma classe para inicialização do Database, Criar os seus modelos através de uma anotação e os DAOs onde terá as suas Queries. O bom desta ORM é que suporta bem migrations através de versionamento.

É necessário ficar atento na criação do banco de dados, é muito importante criar um singleton para a utilização do BD pois o .build() acaba sendo muito custoso.

Outra vantagem é que quando você está criando as queries em momento de compilação há a indicação de erros!

É a utilização de Observers de acordo com o Lifecycle. Quando você altera um objeto ele replica para todos os locais onde o objeto foi observado, respeitando sempre o lifecycle das Activites/Fragments.

Uma das mais imporantes bibliotecas tem como objetivo ser isolada da View o que facilita na hora dos testes. Um ponto positivo é que você consegue recuperar o ViewModel caso haja troca de configuração do celular não tendo de implementar diversos métodos para recuperação de instância/bundlers.

Caso seja necessário utilizar algo do Context será necessário herdar de AndroidViewModel.

Todo ViewModel tem de ser inicializado através da classe ViewModelProviders onde nele você pode observar o ViewModel e qualquer atualização resultará na troca de resultado.

Para os fragments é bom ter em mente que na hora de observar o ViewModel utilizar a instância da Activity para os casos em que outro fragment possa utilizar e o valor seja alterado em todos os locais.

Conclusão: O mais legal dessas libs é que você pode utilizar todas ou alguma específica para resolver os seus problemas.

Um exemplo de projeto está no próprio Github do Dan Prado: https://github.com/danprado/android-architecture-components-sample


Arquitetura de um app Android

Nubank + Arquitetura

Essa palestra foi apresentada por dois engenheiros Android do Nubank e teve como objetivo mostrar como está estruturada toda a arquitetura do aplicativo Android. Os problemas apresentados por eles sobre a arquitetura antiga era que o app possuía diversas telas com complexidades diferentes e os valores sempre tem de ser atualizados caso alguma mudança seja feita em alguma parte do aplicativo. Dessa maneira, desenvolveram uma arquitetura divida em Blocks e Controllers misturando as duas arquiteturas mais famosas no universo Android: MVP + MVVM.

O objetivo é respeitar o SOLID e realizar as atualizações dos valores instantaneamente através da componentização. A programação reativa é fundamental para isso pois são utilizados os observers.

A arquitetura possui os seguintes componentes:

ViewModel -> ViewBinder -> Controller -> Controller Holder -> Managers

Sendo que a dependência segue nessa ordem no que resulta consistência de dados e testes simples não sendo necessário em grande para dos momentos utilizar um framework de testes que utilizam contexto. Testes únitários já bastam (:

A utilização dessa arquitetura depende muito do que a sua aplicação deseja. Caso todas as telas tenham dados diferentes que não necessitam ser atualizadas não há porquê de utilizar tal arquitetura, porém para aplicativos grandes com diversos componentes utilizando valores mútuos pode ser uma bela de uma escolha.

Caso a comunidade ache válido eles estão vendo de tornar toda essa arquitetura como Open Source e liberar para a galera.


Coordinators pattern para Android

Coordianators Pattern ❤

Bom essa palestra tinha como indicar algumas libs para fazer todo o roteamento do aplicativo tentando fugir da complexidade dos fragments e o seu lifecycle enorme. Foram idicadas algumas libs mas a principal foi o Conductor (https://github.com/bluelinelabs/Conductor).

Como pró dessa lib é a criação de Single App Activity sem utilizar Fragments, animações entre as telas e persistir os dados de maneira fácil. O bom dessa lib é para a utilização de pushes e manter todo o histórico na hora de voltar ao estado inicial do aplicativo.

Dando uma olhada bem por cima deu para verificar que é gerado muito boilerplate e é necessário tomar cuidado para a desalocação dos coordinators dependendo do estado da Activity. Outro problema que encontrei também seria no caso da manutenção e simplesmente tomar cuidado também com a injeção de Views nesse conductor deixando a dependência somente para um fluxo específico, para a resolução disso seria necessário utilizar interfaces.


Kotlin: 9 meses depois

Kotlin de novo ❤

Essa palestra pareceu muito o complemento da primeira indicada nesse artigo. Começaram com uma introdução parecida porém adicionar algumas informações como :

  • Null Safety:

Todas as variáveis tem de estar preenchidas e só será possível ser nula através do marcador !!. Caso você use isso, provável que algo esteja errado haha.

  • Syntethic Properties:

Bem parecido com o sistema de Extensions por exemplo seria utilizar o components de uma view diretamente através do id do XML. Exemplo:

<TextView android:id=”@+id/hello” 
android:layout_width=”fill_parent” android:layout_height=”wrap_content”
android:text=”Hello World, MyActivity” />
//Usar assim (:
activity.hello.setText("Hi!")

Porém ele segue a regra do XML caso não esteja em camelCase terá de renomear através do import:

import kotlinx.android.synthetic.main.<layoutActivity>.* as helloTxt
  • Lambdas:

Vem de graça quando instala o Kotlin, dessa maneira não é necessário instalar Retrolambda!

  • Collections:

Você ganha a acesso a todos os métodos das Collections, meio que um fim do for()!

  • Sealed Classes:

Estado bem definido de escopo. Bem parecido com Enums você consegue fazer comparações de estados. (Aqui explica melhor: https://kotlinlang.org/docs/reference/sealed-classes.html)

  • Múltiplas classes por aquivo:

Acho que não muda muito do Java mas para Clean Architecture seria um ganho pois podemos colocar as interfaces do Presenter e View num arquivo só auxiliando um pouco a leitura.

Um fato interessante que percebi durante a apresentação foi que quando utilizado o operador when caso não cubra todos os casos é apresentado um erro de compilação no momento o que ajuda e muito o programador a se previnir.

Foram mostrados alguns problemas em relação ao Kotlin e são:

  • Build time
  • Multidex
  • Algumas features do próprio Android Studio ainda não funcionam porém com o apoio do Google pode ser que volte, um exemplo seria o Debug.

Algumas dicas que indicaram foi:

  • Para casos em que queira trocar o código Java pelo Kotlin só utilizar o conversor de arquivos
  • Pensar em Kotlin e não Java
  • Não utilizar as Java annotations caso queria colocar parâmetros default nos métodos acabará quebrando o build.
  • Adotar um code standard para os casos das syntethics properties. Principalmente caso você tenha uma mistura de arquivos em Java + Kotlin
  • Ficar preocupado com null nos arquivos Javas.

A conclusão que eu vejo depois dessas duas palestras seria: Use! Está valendo muito a pena e pode ter ganhos bem legais. Deixar o código mais limpo e seguro. Mesmo aumentando 1mb no seu apk você pode diminuir de outras maneiras e o build time também não afeta tanto, um teste para isso seria colocar um único arquivo Kotlin e ver quão demora o build pois posterior a inclusão dele não mudará caso coloque mais.


NoSQL com Android

NoSQL ❤

Essa palestra teve como objetivo mostrar para o público que há a possibilidade da utilização de NoSQL no Android. Diferente do paradigma habitual dos ORMs no Android, com base no SQLite o NoSQL nos traz uma performance bem mais elevada que as libs atuais através de diferentes maneiras como Docs, Chave-valor, etc.

Foi realizado benchmarks entre algumas libs que utilizam SQLite e NoSQL e a diferença de performance foi incrível. Com certeza utilizar bancos NoSQL acaba sendo mais rápido porém há alguns problemas, sendo um deles a consistência.

Para gerar consistência é necessário realizar validações dos dados antes mesmo da inserção/atualização/deleção dos dados. Normalmente através das ORMs padrões do Android temos algumas travas que validam os dados, porém no NoSQL isso não é possível.

Algumas libs apresentadas foram:

  • Firebase
  • CouchBase
  • iBoxDB
  • SnappyDB

O mais surpreendente para mim foi o Firebase, principalmente devido a sua popularidade e foi constado que a sua performance foi bem inferior em relação as outras. Principalmente devido a ser orientado a eventos e ser multithreads.

No final das contas para utilizar algum banco NoSQL é preciso dizer se a sua aplicação necessita de uma performance acima do normal e se o custo de validação dos dados consegue pagar a performance das ORMs atuais.


Explorando GraphQL no Android com Apollo

Apollo ❤

Na minha opinião uma das melhores palestras do evento e de uma importância muito grande. GraphQL vem para quebrar o paradigma de obtenção de dados.

A palestra foi iniciada explicando sobre REST e os motivos de sua criação há 20 anos atrás numa tese mestrado. E como todos nós sabemos a tecnologia evolui constantemente!

20 anos atrás mal tínhamos celular e a quantidade de informações que absorvemos diaramente através dele é muito grande, dessa forma no decorrer do tempo da para perceber alguns problemas presentes no REST como:

  • Não há definição de esquema de trabalho entre o server e client. Não há indicação de tipo dos campos e isso pode gerar inconsistência e falta de um “contrato”;
  • O versionamento acaba sendo algo natural e isso é problema pois é bem complicado depreciar uma chamada pois os usuários podem não atualizar o aplicativo.
  • Há casos em que é necessário realizar mais de uma chamada para juntar informações. Essa concatenação gera uma complexidade a mais.
  • E por último podemos verificar que há envio de dados a mais do que o necessário para as nossa aplicações.

Com o GraphQL você consegue matar tudo acima! 😱

  • Um único endpoint
  • Cliente e servidor conhecem o schema
  • Envia/Recebe somente os dados pedidos/necessários
  • Não necessita de mais de uma chamada
  • GraphQL gera a documentação “automágicamente”!

Para utilizar o GraphQL não é necessário utilizar a lib Apollo, até mesmo com o Retrofit é possível utilizar mas não recomendado.

O Apollo através de convenções pode lhe auxiliar a gerar os seus providers através do schema (que você usará em qualquer plataforma como iOS, Android e afins). Sendo assim você não precisa modelar N-A-D-A, tudo é gerado automaticamente para você.

Essa lib tem como vantagem toda uma camada de cache já pronta para utilização.

Para a utilização é necessário instalar um Plugin e para a convenção funcionar é necessário seguir a hierarquia de pacotes requerida.

Bom também que é suportado por Rx ou mesmo Callbacks!

Enfim, para ter mais informações acesse a lib: https://github.com/apollographql/apollo-android

Grandes empresas já começaram a implementar suas APIs utilizando o GraphQL, sempre bom se manter atualizado!


Fragments — Por mais incrível que pareça

Fragments ❤

Quando se escuta/lê a palavra fragment provavelmente lhe da arrepios, certo? E por alguns bons motivos: Lifecycle, IllegalStateException, etc.

Todos sabemos que é bem complicado de ver a famosa imagem abaixo:

Socorror! 😱

Mas querendo ou não o fragment tem as suas belas vantagens em manusear alguns cenários conforme mostrado na palestra:

  • Diferentes tamanhos: Principalmente hoje em dia que possuímos S8 x Moto C.
  • Layouts para diferentes configurações de telas (sim, algumas pessoas ainda utilizam!) : Portrait x Landscape.
  • Controle de Navegação : Botão superior da toolbar X Botão back do Hardware
  • Controle de Dialogs: Quando disparado um dialog você consegue manter o estado através da troca de configuração e também da destruição da Activity. Um exemplo foi um a criação de um dialog para envio do código recebido por SMS porém há chances da Activity morrer, dessa maneira quando volta o Dialog ainda está lá e o usuário consegue continuar a sua jornada.
  • Fragments também são bem interessantes para Componentização de UI: Lembrando que as dependências deve seguir esse caminho View <- Fragment <- Activity.
  • Fato interessante também é diferenciar quando é bom utilizar um fragment e quando seria bom utilizar CustomViews: Para casos em que lidamos com acesso a rede, hardware, intentes e houver uma complexidade sempre utilizar Fragments, já para casos que possua microinterações, carrosséis, vitrines, cards, etc utilizar as custom views.

Para casos em que precisamos lidar com mais de um fragment e atualizar os dados podemos utilizar listeners ou Android Architecture Components (WARNING! Recomendado ler sobre isso logo acima).

Entendendo como funciona os Fragments acabam sendo uma boa API para utilizar, sendo que atualmente está muito mais estabilizada do que antes.


Tudo o que você precisa saber sobre ConstraintLayout

Constraint Layouts ❤

Bom, esta foi a última palestra que participei e estava muito curioso sobre como lidar com essa nova maneira de criar layouts no Android Studio.

Houve algumas explicações sobre o que é e quais as vantagens:

  • Suporta todos os outros Layouts como Linear, Relative, Frame, etc exceto o FlexBoxLayout.
  • Melhora e muito a performance pois é Flat (sem mais XML no formato “Hadouken”)
  • Resumindo: É um mix de todos os outros Layouts
  • Funciona bem no Editor e também no XML (para os Old School! 😉)
  • Para utilizar as novas features só é necessário baixar no SDK do Android
  • Para os iOS Developers: Possui uma enorme familiaridade com o AutoLayout
  • Há indicadores de erros e Warnings.
  • Existe o conversor de LinearLayout para ConstraintLayout, porém não é muito eficaz.
  • Para imagens e Views que necessitam de Ratio não é necessário calcular pois existe um atributo para isso.

De resto não há muito mais o que falar pois teve muito Live Code. O mais interessante é que foi realizado um Layout com uma complexidade média em 5 mins!

Recomendo fazer esse Code lab pois o treino é a melhor ferramenta: https://codelabs.developers.google.com/codelabs/constraint-layout/index.html?index=..%2F..%2Findex#0


Para finalizar gostaria de agradecer e muito todos os palestrantes pelas ótimas apresentações e difusão de conhecimento. Agregou e muito para a minha vida pessoal e profissional. Peço desculpas se deixei passar algo ou tenha falado algo muito errado.

Espero que vocês tenham curtido e qualquer dúvida, comentário, xingamento, elogio, utilizem os comentários. Este foi o meu primeiro post da vida e achei super divertido realizar.

Muito obrigado! Peace ❤