Semana passada aconteceu o Android Dev Conference, um evento realizado pelo iMasters, que concentrou mais de 1.200 desenvolvedores de alto nível em São Paulo.

Se você não pôde ir, não se preocupe, vamos trazer a cobertura das trilhas para vocês. Este artigo é referente a algumas talks da trilha Excellence.

Introdução ao Koltin

A primeira palestra desta trilha foi realizada pela Suelen Carvalho, agile coach, líder técnica e engenheira de software na Moip, além de mestranda em Ciências da Computação pela USP e com pós-graduação no ITA. Junto com ela tivemos o David Robert, CTO na Elo7, mestre em Ciência da Computação em inteligência artificial pela USP.

A palestra deles foi sobre o Kotlin, a nova linguagem de programação suportada pelo Android. Das principais características que eles trouxeram sobre a linguagem temos:

• Linguagem de programação estaticamente tipada;
• Funcional;
• Orientada a objeto;

 

O kotlin surgiu em 2011 e foi criada pela JetBrains. Em 2012 a linguagem se tornou open source e somente em 2016 saiu a sua primeira versão, a 1.0. Mas sua fama veio rápido graças ao Google. No Google I/O deste ano, a empresa anunciou o suporte oficial no desenvolvimento de Android.

Na sequência os palestrantes iniciaram um live code no qual mostravam claramente a diferença de verbosidade entre as linguagens. Kotlin realmente é escrito com muito menos código do que Java, o que, depois de você se acostumar um pouco com a linguagem, lhe ajuda a tornar-se um desenvolvedor mais performático.

Outro ponto interessante apresentado pelos palestrantes, é que este fato também ajuda na leitura do código por outros desenvolvedores.

Seguem alguns exemplos entre os códigos:

Kotlin:

package my.program
fun main(args: Array<String>) {
 println("Hello, world!")
}

Java:

public class HelloWorld {
 public static void main(String[] args) {
 System.out.println("Hello, World");
 }
}

Java:

class Book {
private String title;
private Author author;
 
 public String getTitle() {
return title;
}
public void setTitle(String title) {
this.title = title;
}
public Author getAuthor() {
return author;
}
public void setAuthor(Author author) {
this.author = author;
}
}

Kotlin:

data class Book(var title:String,var author:Author)

E aí, o que está mais fácil escrever?

Android Architecture Components

Na sequência tivemos Danillo Prado, desenvolvedor Android na Alterdata, falando sobre arquitetura de componentes.

Na sua palestra, Danilo fala que a arquitetura de componentes ajuda a reduzir o ciclo de vida complexo e a redução do Boilerplate code. Além disso, este tipo de arquitetura surgiu por conta da falta de uma recomendação do Google perante uma arquitetura.

Quando falamos que existe uma redução na complexidade do ciclo de vida, isso se dá porque o Lifecycle, simplifica o gerenciamento de ciclos de vida do app. Antes do component os componentes externos não conheciam os UI Controllers (Fragments/Activiteis). Sendo assim, os métodos OnStart() e onStop() poderiam ficar muito grandes.

Atualmente qualquer componente pode observar um ciclo de vida de um lifecycleOwner. E agora o listener conhece o ciclo de vida.

O boilerplate é mitigado pela presenção do Room, que evita o boilerplate por meio de um orm simples e eficiente. O ORM é uma lib de persistência e não tem nenhuma novidade, porém, agora é uma solução nativa da Google de persistência para Android. Sendo assim, atualmente é possível criar uma classe de database, anotar os modelos para que se tornem entidades e criar os dado para armazenar os dados.

O palestrante também abordou o LiveData, que observa os dados respeitando os ciclos de vida. Ele funciona da seguinte maneira; um objeto armazena um dado e permite que o dado seja observado. Antes, você trabalhava com chamadas manuais após mudanças no model e o gerenciamento de observers baseado no clico de vida era feito manualmente. Agora, o UI Controller será automaticamente notificado sobre as mudanças no Model. E o gerenciamento de Observers automático de acordo com o Lifecycle atual do Ui Controller.

Falando em ViewModel, ele é capaz de armazenar e gerenciar os dados da UI e garante que eles sobreviverão as mudanças de configuração.

O ViewModel é o “cara” que contém os dados apresentados na view e contém também a lógica de gerenciamento destes dados. Antigamente a lógica ficava nos Ui Controllers (God activities) e acontecia perda dos dados nas mudanças de orientação. Agora, é utilizado o MVVM (model view view model – a lógica é totalmente isolada, não se conhece a view). Quem avisa para view o que mudou é o DataLive e não o presenter. Conseguiu identificar o que aconteceu aqui? Temos um modelo de programação reativa, meus amigos.

Acessibilidade – o Novo Modo Deus no Android

Também acompanhamos a palestra do Gustavo Monteiro, desenvolvedor mobile na PSafe Tecnologia. O Gustavo falou sobre Acessibilidade, o novo Deus do Android.

Quando devemos pensa e utilizar acessibilidade? Alguns insights foram alertados pelo autor:

• Automatização de tarefas;
• Acesso a ações bloqueadas por meio de código;
• Acesso a informações bloqueadas;

 

Os seguintes tópicos também foram abordados:

EventTypes

• Click;
• Window contente changed;
• Text scrollerd;
• Scrowlled;
• Window state changed.

 

Flags

• Include not important views;
• Report view ids.

 

FeedbackTypes

• Perform Actions

 

Precisamos falar sobre testes

Como não podia faltar, também tivemos uma palestra sobre testes, ministrada pelo Victor Oliveira Nascimento, consultor na Concrete Solutions, bacharel em Filosofia pela USP. Segundo a definição trazida pelo palestrante “Teste é uma das ferramentas para verificar a aderência de uma implementação de software a uma dada especificação.”

Uma pergunta que foi levantada na palestra foi: Você sabe qual o valor que seu teste gera? . Esta pergunta permeou boa parte do clima da talk. Vamos ver os principais tópicos abordados para poder entender ela de uma melhor maneira.

Primeiro, vamos a velha discussão, devemos fazer testes locais ou testes instrumentados?

• JVM vs Dalvik;
• Instrumentação: programadores implementam instrumentação na forma de instruções de código que monitoram componentes específicos em um sistema(…). Quando uma aplicação contém código de instrumentação ela pode ser gerenciada por uma ferramenta;
• Teste local não executa como será executado no usuário final, diferente da jvm;
• Recomendação do Google – 70% dos testes sejam locais e 30% sejam instrumentados;
• Recomendação do palestrante – 90% dos testes devem ser instrumentados e 10% sejam locais.

 

A principal questão que o Victor nos trouxe é, o valor que o teste gera. Ou seja, quão válido é um teste que funcione em um ambiente de testes que está longe do ambiente no qual o usuário irá executar o seu código?

Além disso, o teste instrumentado não simula, ou emula o sistema do usuário. Ele simplesmente imita o sistema. Por outro lado, o tempo de execução, as falhas aleatórias (flakiness) e a complexidade do setup da integração, são maiores. Afinal, nem tudo são flores.

Outros tipos de testes abordados pelo Victor foram os unitários vesus end to end.

Segundo o palestrante os testes unitários não testam necessariamente apenas um método (que comece a discussão). Já os testes end to end são escritos em linguagem natural, normalmente utilizando o gherking. Também são black-box, ou seja, não se importam com a implementação. Além disso, idealmente não possuem mocks/faker/stubs e a documentação é viva e executável.

Voltando a pergunta inicial, qual valor seu teste gera? Se você souber responder a essa pergunta, ficará muito mais fácil escolher qual modelo de teste irá utilizar em seus projetos. Lembrando, é claro, que nenhuma solução é ótima ou bala de prata.

Por que programação reativa?

Por fim, outra palestra que acompanhamos de perto foi a do Felipe Costa e do Bruno Kosawa que entraram no mérito da programação reativa.

Pela definição básica, programas são sistemas que recebem entradas, processam as informações e produzem saída. Porém, quando pensamos em programação mobile, devemos entender que aplicativos são organismos vivos, sendo assim, enquanto houverem entradas haverão saídas. Além disso, devemos entender que o estado é algo exponencialmente complexo.

Mas afinal, o que é programação reativa? Segundo a definição trazida pelos palestrantes é “programar com fluxo de dados assíncronos”. Porém, eles acreditam que nós já fazemos isso, sem pensar em programação reativa, então, trouxeram uma outra definição “paradigma de programação orientada a fluxo de dados e propagação de mudança”.

Eles também falaram sobre DataStreams, composables, backpressure, memory issues, logging e mainthread. Algumas vantagens, desvantagens e pontos que devemos ter cuidado ao optarmos pela programação reativa.

Criando dispositivos com Android Things e Google Assistante

Por último, tivemos a palestra do Luis Leão, course manager na Udacity. Leão falou sobre como utilizar o firebase para resolver alguns problemas do Andoid Things, deu algumas dicas sobre qual placa devemos trabalhar. Estas dicas foram baseadas em suporte, preço, curva de aprendizagem, etc.

Um problema encontrado neste desenvolvimento é que o desenvolvedor não tem controle total sobre o hardware, o baixo nível é controlado pelo Google. O que você consegue controlar são as Apps e o user drivers.

No que tange as permissões, elas devem ser declaradas no manifest.

Como projeto de exemplo, o palestrante trouxe uma máquina de drinks que atende pelo controle de voz.

Que venha o próximo

No final desta experiência, o Android Dev Conference deixou saudades. Os desenvolvedores saíram com muitos insights e com um excelente conteúdo, algo que com certeza eles poderão aproveitar para em sua vida profissional. Até ano que vem!