O ano de 2017 marcou o lançamento da plataforma Android Things, que promete trazer todo o conhecimento, ferramentas, bibliotecas, arquitetura e ideologia do desenvolvimento Android usados em smartphones e similares para plataformas de sistemas embarcados, como o Intel Edison.
Neste artigo, não pretendo falar sobre as bibliotecas, sobre a codificação ou, ainda, entrar em detalhes de como podemos usar o Firebase no Intel Edison. A ideia neste texto é passar minha visão sobre o poder do Google/Android Things no contexto da Internet das Coisas, mostrar o poder que nós, desenvolvedores, temos em mãos, conhecendo o ecossistema do desenvolvimento para a plataforma Android.
O primeiro ponto diz respeito ao coração da aplicação Android. O AndroidManifest está presente no desenvolvimento do Android Things e com o mesmo papel de protagonista. A diferença sutil é a presença de um filtro específico para o IOT_LAUNCHER. Ou seja, o conceito de Intent e Intent Filter, herdado do Android “Normal”, segue presente também.
Apenas para elucidar o leitor, veja a pequena alteração no AndroidManifest.xml:
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="agora.humano.seja.com.helloworldthings" > <application ... > <uses-library android:name="com.google.android.things"/> <activity android:name=".MainActivity" > <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.IOT_LAUNCHER"/> <category android:name="android.intent.category.DEFAULT"/> </intent-filter> </activity> </application> </manifest>
A Intent define a intenção de uma ação disparada de/para o sistema operacional Android. Sendo assim, o Intent Filter é justamente um filtro dessa ação. A categoria LAUNCHER, já conhecida dos desenvolvedores, define que o ponto de partida da aplicação móvel é aquela activity. Logo, o IOT_LAUNCHER tem exatamente a mesma função. A plataforma embarcada, como o Intel Edison, sabe qual atividade vai iniciar os trabalhos no momento em que a aplicação Android for executada.
Olhando o manifesto, notamos a presença da já conhecida Activity. No desenvolvimento Android para smartphone, ela tem a função de representar uma tela e seu contexto. Aqui, temos a ideia de uma atividade. Mas o mais importante é que todo o ciclo de vida de uma Activity e toda a Activity Stack são reaproveitados no Android Things.
O SDK do Android Things ganhou o incremento de algumas bibliotecas e classes de suma importância para o contexto da plataforma, como a classe PeripheralManagerService, que permite requisitar todas as portas a que temos acessos naquele hardware. Ou, ainda, a classe GPIO, que pode fazer a ligação com um LED RGB, por exemplo, ou com um relê que ligaria a lâmpada da sua casa. Tudo isso de forma muito simples.
Abaixo, segue um exemplo muito simples de como um LED ligado na porta digital 6 do Edison Arduino pode ser ligada. Ou, ainda, esse simples LED poderia muito bem ser substituído por um relê que ligaria uma tomada da nossa residência.
public class MainActivity extends AppCompatActivity { private Gpio ledGpio; private static final String GPIO_PIN = "IO13"; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); PeripheralManagerService service = new PeripheralManagerService(); try { ledGpio = service.openGpio(GPIO_PIN); ledGpio.setValue(true); } catch (IOException e) { Log.e("GPIOS", "Error on PeripheralIO API", e); } } }
Para um desenvolvedor experiente da plataforma Android, é quase inacreditável saber que todo o conhecimento poderá ser replicado para o mundo IoT. O único ponto de dúvida talvez seja a variável GPIN_PIN valorizada com IO13, sendo que, na descrição do parágrafo anterior, citei a porta digital 6.
Um ponto de atenção no Android Things é justamente o nome das portas que estaremos trabalhando. Mas, na documentação oficial, é possível selecionar a plataforma alvo e saber os nomes de todas as portas que devem ser usadas. Por exemplo, para o Intel Edison Arduino I/O, a seguinte imagem é encontrada (https://developer.android.com/things/hardware/edison-arduino-io.html):
Aliado ao poder da simplicidade e reutilização do conhecimento, podemos citar as bibliotecas do SDK que estarão presentes nas plataformas alvos do Android Things. Até o momento da escrita deste artigo, são elas: Intel Edison, Intel Joule, NXP Pico i.MX6UL e Raspberry Pi 3.
E veja agora as APIs suportadas pelo Android Things até o momento da escrita deste texto:
- Cast
- Drive
- Firebase Analytics
- Firebase Cloud Messaging (FCM)
- Firebase Crash Reporting
- Firebase Realtime Database
- Firebase Remote Config
- Firebase Storage
- Fit
- Instance ID
- Location
- Nearby
- Places
- Mobile Vision
Ficou impressionado com as opções? Acredito fielmente que sim. Somente o set de opções do Firebase já seria muito valoroso. Agora, um desenvolvedor maker não precisa mais trabalhar com bibliotecas de comunicação serial ou Wi-Fi. Não precisa mais pensar no servidor de banco de dados NoSQL que receberá uma quantidade significativa de dados de sensores. O Firebase resolve isso da mesma forma simplista que resolve para smartphones.
E parece que os planos do Google para uma interligação de todas as coisas possíveis não param no Android Things. Um kit de desenvolvimento para o projeto Soli será lançado ainda este ano pela empresa. O Soli compreende um micro-radar de onda milimétrica que consegue interceptar e detectar gestos muito sutis como aqueles que fazemos com os dedos e as mãos. Para saber mais, navegue pela página do projeto aqui https://atap.google.com/soli/.
E ainda temos o Android Auto e o Android Wear. O primeiro chegou às terras brasileiras na primeira metade do ano passado. O Android Wear já é um velho conhecido. Mas o que importa é que o Android SDK e os principais pilares do desenvolvimento para smartphone são mantidos tanto para carros quando para vestíveis.
Ou seja, uma vez que o programador esteja apto a desenvolver para a plataforma Android, um mundo se abre aos seus dedos. E não estamos falando só de smartphones e tablet e seus bilhões de usuários, mas sim de plataformas embarcadas, sensores que detectam pequenos movimentos de mãos e dedos, automóveis e vestíveis.
E, para fechar o ciclo, é importante ressaltar que não é somente a filosofia de desenvolvimento que é compartilhada. O Google Play Services e o Firebase, que aceleram o desenvolvimento com APIs especializadas para features extremamente comuns, como mapas, banco de dados e push notifications, também são compartilhados. Difícil imaginar todas as possibilidades possíveis.