DEV Community: Ricardo da Silva Ogliari

Um jogo de matemática no Arduino - A math game on Arduino

Ricardo da Silva Ogliari — Fri, 15 Apr 2022 14:56:49 +0000

> I'm still learning the English language, so please, if you find any English mistakes, let me know in the comments. Thank you very much.

Quando começamos a estudar uma nova linguagem ou plataforma é comum termos alguns problemas. No meu entendimento, isso pode ser amenizado quando criamos algo que nos empolgue. E, geralmente, desenvolvedores têm uma relação de muito amor com jogos. Logo, por mais simples que possa ser, um jogo modesto pode acelerar o processo de aprendizado.

When we start to study a new language or platform it is common to have some problems. In my understanding, this can be mitigated when we create something that excites us. And, generally, developers have a very loving relationship with games. So, as simple as it may be, a modest game can speed up the learning process.

Pensando nisso, propus a criação de um jogo matemático para aprimorarmos o conhecimento em IoT e, principalmente, no uso da plataforma de prototipagem Arduino. O objetivo é usar um display de 7 segmentos e a comunicação serial para mostrar dois operandos ao usuário, na sequência, o mesmo responde e receberá uma resposta de acerto ou erro. Sendo que esse processo se repete indefinidamente.

With that in mind, I proposed the creation of a mathematical game to improve knowledge in IoT and, mainly, in the use of the prototyping platform Arduino. The objective is to use a 7-segment display and serial communication to show two operands to the user, then, the user responds and will receive a hit or miss response. This process is repeated indefinitely.

Para que o leitor possa recriar o jogo, deixo a imagem do thinkercad abaixo com o circuito montado. Estamos usando um Arduino Uno, uma protoboard, um display de sete segmentos, um led RGB e resistores.

So that the reader can recreate the game, I leave the image of thinkercad below with the circuit assembled. We are using an Arduino Uno, a breadboard, seven-segment display, an RGB LED and resistors.

Os dois fios pretos estão ligando as portas terra do Arduino (GND) com as trilhas horizontais nas linhas indicadas com o símbolo “-”. Como boa prática, estamos usando a cor preta para indicar esses fios (em um circuito real seriam os jumpers).

The two black wires are connecting the Arduino ground ports (GND) with the horizontal tracks on the lines indicated with the symbol “-”. As a good practice, we are using the color black to indicate these wires (in a real circuit it would be the jumpers).

O display de segmentos possui dois pinos na sua parte central, que são ligadas a portas terras através de um resistor de 500 ohms. As outras 8 entradas são para seus segmentos. Lembrando que sete deles são para formar os segmentos individuais que foram o número e, o oitavo é para (des)ligar o ponto localizado no canto inferior direito. Estamos usando as portas digitais 13, 12, 11, 10, 9, 8, 7 e 6.

The segment display has two pins in its central part, which are connected to ground ports through a 500 ohm resistor. The other 8 entries are for its segments. Remembering that seven of them are for built the individual segments that were the number, and the eighth is for (un)connecting the point located in the lower right corner. We are using digital ports 13, 12, 11, 10, 9, 8, 7 and 6.

Por fim, usamos um LED RGB para indicar o acerto ou erro da resposta. Da esquerda para direita ligamos seus conectores as seguintes portas: digital 4, terra, digital 3 e digital 2.

Finally, we use an RGB LED to indicate the success or error of the answer. From left to right we connect its connectors to the following ports: digital 4, ground, digital 3 and digital 2.

Vamos explicar a codificação por partes. No inícios temos o conjunto de variáveis que indicam as portas onde o display e o LED estão ligados. Cada constante do tipo inteiro indica uma das portas digitais utilizadas. Na sequência teremos as variáveis do status atual e dos estados possíveis. Vamos utilizar a ideia de uma máquina de estados. Inicialmente, precisamos ler o primeiro operando, na sequência, ler o segundo operando e, finalmente, esperar a resposta do usuário.

Let's explain coding in parts. At the beginning we have the set of variables that indicate the ports where the display and the LED are connected. Each integer constant indicates one of the digital ports used. Next we will have the variables of the current status and the possible states. Let's use the idea of a state machine. Initially, we need to read the first operand, then read the second operand, and finally, wait for the user's response.

const int A = 13;
const int B = 12;
const int C = 11;
const int D = 10;
const int E = 9;
const int F = 8;
const int G = 7;
const int H = 6;

const int ledR = 4;
const int ledB = 3;
const int ledG = 2;

// máquina de estados
int STATE_READING_OP1 = 1;
int STATE_READING_OP2 = 2;
int STATE_WAITING_ANSWER = 3;
int status = STATE_READING_OP1;

int op1;
int op2;

Na função setup, que será chamada apenas uma vez, usamos a função pinMode para definir o modo de uso das portas digitais, sendo de saída. Nesta função, o primeiro parâmetro é a porta e o segundo justamente este modo. Além disso, usamos o Serial.begin para inicializar a comunicação serial, com uma taxa de 9600 bits por segundos. Por fim, usamos o randomSeed para criar números randômicos posteriormente.

In the setup function, which will be called only once, we use the pinMode function to define the mode of use of the digital ports, being output. In this function, the first parameter is the port and the second is just this mode. Also, we use Serial.begin to initialize serial communication, with a rate of 9600 bits per second. Finally, we use randomSeed to create random numbers later.

void setup(void)
{
  Serial.begin(9600);

  pinMode(A, OUTPUT);
  pinMode(B, OUTPUT);
  pinMode(C, OUTPUT);
  pinMode(D, OUTPUT);
  pinMode(E, OUTPUT);
  pinMode(F, OUTPUT);
  pinMode(G, OUTPUT);
  pinMode(H, OUTPUT);

  pinMode(ledR, OUTPUT);
  pinMode(ledG, OUTPUT);
  pinMode(ledB, OUTPUT);

  randomSeed(analogRead(0));
}

Na sequência teremos todos os métodos que formam os números possíveis, além da função clear, que limpa o display e não mostra nenhum número. A função digitalWrite foi usada. Ela recebe dois parâmetros, a porta e o que será escrito na mesma. Arduino tem duas constantes que representam o 1 e 0, respectivamente, sendo elas HIGH e LOW. Em uma visão mais baixo nível, enviar HIGH para um porta digital, faz com que a mesma emita 5V na sua saída, e, quando mandamos LOW, a mesma envia 0V. Por isso que um segmento será ligado ou desligado, por ter ou não, uma corrente elétrica.

In the sequence we will have all the methods that form the possible numbers, in addition to the clear function, which clears the display and does not show any numbers. The digitalWrite function was used. It takes two parameters, the port and what will be written to it. Arduino has two constants that represent 1 and 0, respectively, being HIGH and LOW. In a lower level view, sending HIGH to a digital port causes it to emit 5V at its output, and when we send LOW, it sends 0V. That's why a segment will be turned on or off, whether or not it has an electric current.

void clear(){
  digitalWrite(A, LOW);
  digitalWrite(B, LOW);
  digitalWrite(C, LOW);
  digitalWrite(D, LOW);
  digitalWrite(E, LOW);
  digitalWrite(F, LOW);
  digitalWrite(G, LOW);
  digitalWrite(H, LOW);
}

void zero(void) {
  digitalWrite(A, LOW);
  digitalWrite(B, HIGH);
  digitalWrite(C, HIGH);
  digitalWrite(D, HIGH);
  digitalWrite(E, HIGH);
  digitalWrite(F, HIGH);
  digitalWrite(G, HIGH);
  digitalWrite(H, HIGH);
}

void one(void) {
  digitalWrite(A, LOW);
  digitalWrite(B, LOW);
  digitalWrite(C, LOW);
  digitalWrite(D, HIGH);
  digitalWrite(E, LOW);
  digitalWrite(F, LOW);
  digitalWrite(G, HIGH);
  digitalWrite(H, LOW);
}

void two(void) {
  digitalWrite(A, HIGH);
  digitalWrite(B, LOW);
  digitalWrite(C, HIGH);
  digitalWrite(D, HIGH);
  digitalWrite(E, HIGH);
  digitalWrite(F, HIGH);
  digitalWrite(G, LOW);
  digitalWrite(H, LOW);
}

void three(void) {
  digitalWrite(A, HIGH);
  digitalWrite(B, LOW);
  digitalWrite(C, HIGH);
  digitalWrite(D, HIGH);
  digitalWrite(E, LOW);
  digitalWrite(F, HIGH);
  digitalWrite(G, HIGH);
  digitalWrite(H, LOW);
}

void four(void) {
  digitalWrite(A, HIGH);
  digitalWrite(B, HIGH);
  digitalWrite(C, LOW);
  digitalWrite(D, HIGH);
  digitalWrite(E, LOW);
  digitalWrite(F, LOW);
  digitalWrite(G, HIGH);
  digitalWrite(H, LOW);
}

void five(void) {
  digitalWrite(A, HIGH);
  digitalWrite(B, HIGH);
  digitalWrite(C, HIGH);
  digitalWrite(D, LOW);
  digitalWrite(E, LOW);
  digitalWrite(F, HIGH);
  digitalWrite(G, HIGH);
  digitalWrite(H, LOW);
}

void six(void) {
  digitalWrite(A, HIGH);
  digitalWrite(B, HIGH);
  digitalWrite(C, HIGH);
  digitalWrite(D, LOW);
  digitalWrite(E, HIGH);
  digitalWrite(F, HIGH);
  digitalWrite(G, HIGH);
  digitalWrite(H, LOW);
}

void seven(void) {
  digitalWrite(A, LOW);
  digitalWrite(B, LOW);
  digitalWrite(C, HIGH);
  digitalWrite(D, HIGH);
  digitalWrite(E, LOW);
  digitalWrite(F, LOW);
  digitalWrite(G, HIGH);
  digitalWrite(H, LOW);
}

void eight(void) {
  digitalWrite(A, HIGH);
  digitalWrite(B, HIGH);
  digitalWrite(C, HIGH);
  digitalWrite(D, HIGH);
  digitalWrite(E, HIGH);
  digitalWrite(F, HIGH);
  digitalWrite(G, HIGH);
  digitalWrite(H, LOW);
}

void nine(void) {
  digitalWrite(A, HIGH);
  digitalWrite(B, HIGH);
  digitalWrite(C, HIGH);
  digitalWrite(D, HIGH);
  digitalWrite(E, LOW);
  digitalWrite(F, HIGH);
  digitalWrite(G, HIGH);
  digitalWrite(H, LOW);
}

No código Arduino, a função loop será repetida indefinidamente enquanto a placa estiver recebendo energia. Logo no início temos um teste lógico, verificando se o estado corrente não é esperar a resposta do usuário. Nesse caso, precisamos gerar um número aleatório, que poderá ser o operando 1 ou o operando 2.

In Arduino code, the loop function will repeat indefinitely while the board is receiving power. At the beginning we have a logical test, verifying that the current state is not waiting for the user's response. In this case, we need to generate a random number, which can be operand 1 or operand 2.

A variável randNumber guarda o número aleatório gerado. O switch-case verificará o valor criado e chama a função correspondente para mostrar o número no display de sete segmentos.

The randNumber variable stores the generated random number. The switch-case will check the created value and call the corresponding function to show the number on the seven-segment display.

No último if-else precisamos saber se o estado corrente é ler o primeiro ou o segundo operando. Depois disso levando a máquina de estados para o passo seguinte, além de ter uma espera (função delay) de dois segundos (2000 milisegundos). Se o número lido for o primeiro operando, depois dessa pausa nos limpamos o display e temos uma nova espera de meio segundo. Dessa forma o usuário perceberá claramente que um novo número será apresentado. Já, se o número gerado foi o segundo operando, depois do intervalo de 2 segundos nós limpamos o display, porque, nesse caso, aguardaremos a resposta do jogador.

In the last if-else we need to know if the current state is reading the first or second operand. After that taking the state machine to the next step, besides having a wait (delay function) of two seconds (2000 milliseconds). If the number read is the first operand, after this pause we clear the display and have a new half-second wait. In this way the user will clearly perceive that a new number will be presented. On the other hand, if the number generated was the second operand, after the 2-second interval we clear the display, because in this case, we will wait for the player's response.

void loop(void)
{
  if (status != STATE_WAITING_ANSWER){
    int randNumber = random(0, 10);
    switch (randNumber) {
      case 0:
        zero();
        break;
      case 1:
        one();
        break;
      case 2:
        two();
        break;
      case 3:
        three();
        break;
      case 4:
        four();
        break;
      case 5:
        five();
        break;
      case 6:
        six();
        break;
      case 7:
        seven();
        break;
      case 8:
        eight();
        break;
      default:
        nine();
    }

    if (status == STATE_READING_OP1){
      op1 = randNumber;
      status = STATE_READING_OP2;
      delay(2000);
      clear();
      delay(500);
    } else {
      op2 = randNumber;
      status = STATE_WAITING_ANSWER;
      delay(2000);
      clear();
    }
  }
}

Finalmente, precisamos ouvir os dados que chegam via porta seral. Usaremos a função serialEvent, acionada quando dados estão disponíveis no buffer serial. Enquanto (while) dados seriais estiverem disponíveis (Serial.available()) nós leremos o próximo número inteiro. Na sequência verificamos se o status corrente já é de checagem da resposta. Caso afirmativo, verificamos se a multiplicação dos dois operandos é igual a resposta informada.

Finally, we need to listen for data arriving via the seral port. We will use the serialEvent function, triggered when data is available in the serial buffer. While (while) serial data is available (Serial.available()) we will read the next integer. Next, we check if the current status is already checking the response. If so, we check if the multiplication of the two operands is equal to the given answer.

Por fim, se a resposta estiver correta vamos mandar um valor de 255 somente para o pino digital que corresponde a esta cor, no LED RGB. Caso a resposta esteja errada a lógica é a mesma, mas com a cor vermelha. Depois do if-else temos uma nova pausa de dois segundos, na sequência, resetamos o LED para deixar sem cor e o ciclo reinicia.

Finally, if the answer is correct, we will send a value of 255 only to the digital pin that corresponds to this color, in the RGB LED. If the answer is wrong, the logic is the same, but with the color red. After the if-else we have a new two-second pause, then we reset the LED to no color and the cycle restarts.

void serialEvent() {
  while (Serial.available()) {
    int answer = Serial.parseInt();

    if (status == STATE_WAITING_ANSWER){
      if (answer == op1 * op2){
        digitalWrite(ledR, 0);
        digitalWrite(ledG, 255);
        digitalWrite(ledB, 0);
      } else {
        digitalWrite(ledR, 255);
        digitalWrite(ledG, 0);
        digitalWrite(ledB, 0);
      }

      delay(2000);
      digitalWrite(ledR, 0);
      digitalWrite(ledG, 0);
      digitalWrite(ledB, 0);
      status = STATE_READING_OP1;
    }
  }
}

Importante - Important: recebi ajuda e bons pitacos dos meus alunos. I received help and good tips from my students:

Alexandre Akira Enjiu
Ana Paula Soler Dos Santos
Anderson Fábio da Silva
Carlos Evandro Higa
Douglas Pereira Mateus
Erica Okamura
Gabriel Dargas
Gabriela Pinheiro da Silva
Giovana Rocha Santos
Guilherme Antonio de Souza Mauricio
Guilherme Cristiano da Silva Costa
Jackson dos Santos Roque da Silva
João Rafael Iasorli Rodrigues
Julia Assunção Silva
Lucas Goiana Malicia
Mariana Sayuri Kuchida
Michael dos Santos Silva
Vinicius Bezerra Lima

Flutter + PubNub + NodeRED + Arduino + Raspberry + IoT + Smart House (Parte 2 - Mobile)

Ricardo da Silva Ogliari — Sun, 04 Apr 2021 01:39:55 +0000

Aviso 1: Antes de ler este texto, indico a leitura da primeira parte.

Aviso 2: O código fonte da aplicação mobile está disponível aqui.

Notice 1: Before reading this text, I recommend reading the first part .

Notice 2: The source code of the mobile application is available here.

Aplicação Flutter. Flutter Application.
A aplicação mobile foi feita com o Flutter framework. A feature de controle de mídia for fortemente baseada no artigo A Comprehensive Guide to Playing Local mp3 Files (With Seek Functionality) in Flutter. The mobile application was made with the Flutter framework. The media control feature is heavily based on the article A Comprehensive Guide to Playing Local mp3 Files (With Seek Functionality) in Flutter.

Como a interface é bem simples, podemos usar uma classe StatelessWidget, com seu ciclo de vida mais simples e sem necessidade de controle de status. The interface is very simple, then, we can use a StatelessWidget class, with its simplest life cycle and without the need for status control.

A construção da interface acontece na sobrescrita do build, usando o par MaterialApp -> Scaffold, com um AppBar e um body. O corpo é construído no método _body. Temos apenas um Center -> Container -> Column, contendo dois botões (criados no método _btn). Além das funções normais da mídia, fazemos uma chamada ao publishToPubnub, enviando por parâmetro a ação necessário. 1 indica que a lâmpada deve ser ligada e 0 que deve ser desligada. The interface construction takes place in the build method, using the pair MaterialApp -> Scaffold, with an AppBar and a body. The body is built using the _body method. We have only one Center -> Container -> Column, containing two buttons (created in the _btn method). In addition to the normal functions of the media, we make a call to publishToPubnub, sending the required action by parameter. 1 indicates that the lamp should be turned on and 0 that it should be turned off.

Widget _body() => Center(
      child: Container(
        padding: EdgeInsets.all(16.0),
        child: Column(
          children: [
            _btn('Play', () {
              audioCache.play('one_horse_town.mp3');
              publishToPubNub(1);
            }),
            _btn('Stop', () {
              advancedPlayer.stop();
              publishToPubNub(0);
            }),
          ]
        ),
      ),
    );

  Widget _btn(String txt, VoidCallback onPressed) {
    return ButtonTheme(
        minWidth: 48.0,
        child: ElevatedButton(
            child: Text(txt),
            onPressed: onPressed
        )
    );
  }

  @override
  Widget build(BuildContext context) {
    initPlayer();
    pubnub = PubNub(defaultKeyset: myKeyset);
    myChannel = pubnub.channel('node-red');

    return Scaffold(
        appBar: AppBar(
          title: Text('Smart Party House'),
        ),
        body: _body()
      );
  }

O leitor deve ter visto que no build, criamos a instância de PubNub e Channel. O PubNub é um sistema de mensageria que segue o padrão Publisher-Subscriber. Sendo que, atuamos como publisher ou como subscriber em um dado canal. Neste caso, chamamos o mesmo de node-red. The reader must have seen that in build we created the instance of PubNub and Channel. PubNub is a messaging system that follows the Publisher-Subscriber pattern. Being that, we act as publisher or as subscriber in a given channel. In this case, we call it node-red.

Na instância de PubNub passamos uma instância de Keyset, que foi criada como uma constante da própria classe MainWidget. As chaves de publisher e subscriber são criadas no console do PubNub na aplicação criada neste mesmo local. IMPORTANTE: não confunda. Temos a aplicação Flutter e uma aplicação criada no console do PubNub, para termos acesso ao par de chaves pub-sub. In the instance of PubNub we pass an instance of Keyset, which was created as a constant of the MainWidget class itself. The publisher and subscriber keys are created in the PubNub console in the application created in that same location. IMPORTANT: do not confuse. We have the Flutter application and an application created on the PubNub console, to have access to the pub-sub key pair.

O método publishToPubNub é bem simples. Ele somente publica um dado no formato JSON para o canal criado previamente. The publishToPubNub method is quite simple. It only publishes data in JSON format for the previously created channel.

publishToPubNub(int action){
    myChannel.publish({ 'action': action });
}

Finalmente, faltou falar somente do método initPlayer. Neste local estamos apenas criando as instâncias de AudioPlayer e AudioCache. Também, criamos um listener para quando o áudio tocar completamente. Neste momento, apenas mandamos a ação de parar a música via PubNub. Finally, we only needed to talk about the initPlayer method. In this place we are just creating the instances of AudioPlayer and AudioCache. Also, we created a listener for when the audio plays completely. At this point, we just send the action to stop the music via PubNub.

void initPlayer(){
    advancedPlayer = AudioPlayer();
    audioCache = AudioCache(fixedPlayer: advancedPlayer);

    advancedPlayer.onPlayerCompletion.every((element) {
      publishToPubNub(0);
      return true;
    });
  }

Flutter + PubNub + NodeRED + Arduino + Raspberry + IoT + Smart House (Parte 1)

Ricardo da Silva Ogliari — Fri, 26 Mar 2021 19:30:35 +0000

Olá pessoal. Hey guys.

Nesta série de artigos vou explicar detalhadamente um estudo de caso que implementei para mostrar aos meus alunos da graduação e MBA na IMED e FIAP, respectivamente. In this series of articles I will explain in detail a case study that I implemented to show to my students in IMED and FIAP.

A Idéia. The Idea.
Uma aplicação mobile com uma opção de tocar e parar uma música específica. Essa ação de início e paralisação do som causará uma ação de ligar e desligar uma lâmpada física na "casa inteligente". A mobile application with an option to play and stop a specific song. This action of starting and stopping the sound will cause an action to turn on or turn off a physical lamp in the "smart home".

O que usei no mobile?. What did I use in the mobile?
A aplicação no mobile foi criada com o Flutter. Além dos pacotes padrões que já vem com o SDK da plataforma, usei também um pacote específico para interagir com o PubNub (link aqui). he mobile application was created with Flutter. In addition to the standard packages that come with the platform SDK, I also used a specific package to interact with PubNub.

Além disso, a parte de integração com a mídia e as ações de tocar e parar o arquivo mp3, foi fortemente baseada no artigo A Comprehensive Guide to Playing Local mp3 Files (With Seek Functionality) in Flutter. The part of integration with the media and the actions of playing and stopping the mp3 file, was strongly based on the article [A complete guide to playing local mp3 files (with search functionality) on Flutter.

O que usei no Cloud? What did I use in the Cloud?
Foi necessário um ponto central para integrar o aplicativo mobile com o Node-RED rodando no Raspberry Pi. A solução encontrada foi usar o PubNub. O PubNub é um serviço de mensageria com suporte para mais de 70 SDK´s. Incluindo suporte para DART e nodes para o Node-RED. Ou seja, perfeito para meu objetivo. A central point was needed to integrate the mobile application with Node-RED running on the Raspberry Pi. The solution was found using PubNub. PubNub is a messaging service with support for more than 70 SDKs. Including support for DART and nodes for Node-RED. That is, perfect for my goal.

Você falou Node-RED? Did you say Node-RED?
Sim, correto! Usei o Node-RED para uma prototipagem rápida e upload do serviço no Raspberry Pi. Yes correct! I used Node-RED for quick prototyping and uploading the service to the Raspberry Pi.

E no Hardware, o que foi usado? And no hardware, what was used?
Foi usado um Raspberry Pi 3 Model B conectado via porta serial a um Arduino Uno. No Uno, por sua vez, liguei um relê de apenas um canal que liga ou desliga a lâmpada. A Raspberry Pi 3 Model B connected via serial port on an Arduino Uno was used. In Uno, I connected a relay that turn on or turn off the lamp.

E agora? And Now?
Nos próximos artigos desta série vamos reconstruir passo a passo o desenvolvimento do caso de uso. In the next articles in this series we will reconstruct the use case development step by step.

Aguardem.... :)

Uma Idéia para Arquitetura de Aplicativos Flutter

Ricardo da Silva Ogliari — Wed, 17 Feb 2021 02:22:28 +0000

Como este texto tem como ponto central uma idéia de arquitetura para aplicações Flutter, deixe-me explicar o que uma imagem de uma espécie de casa está fazendo aqui. Ela é uma das igrejas de madeiras encontradas na Noruega. Para ser mais específico, na foto estamos vendo a Borgund Stave church. Para saber mais sobre estas igrejas impressionantes visite esta página. Devido a sua arquitetura ímpar, ela estampou a capa deste texto :).

Arquitetura base

Estudando possíveis arquiteturas já existentes para desenvolvimento Flutter, encontrei o artigo "A importância da Clean Architecture no Flutter", escrito por Fabio Maia e disponível aqui. O principal motivo por esta arquitetura chamar a minha atenção foi a semelhança com o JetPack Architecture Componentes, sendo assim, seria de fácil entendimento pelos desenvolvedores oriundos do nativo, principalmente do Android nativo. Abaixo, a imagem encontrada no artigo do Maia:

E abaixo você encontra um resumo alto nível das pastas que criei no projeto Flutter seguindo a estrutura proposta por Maia. Porém, não utilizei exatamente o mesmo fluxo de dados. Usei um pacote gerenciador de estados para não precisar ter o fluxo partindo dos dados até os Widgets.

Para ficar mais claro, veja como fica a estrutura de pastas do projeto base:

Aplicativo Base

O aplicativo aqui proposto é algo bem simples. Uma tela de login que leva para uma lista dos filmes preferidos, lendo os dados de um serviço web.

i18n no projeto

Começamos explicando o padrão usado para internacionalização. Seguimos a documentação entitulado como "Internationalizing Flutter apps", disponível no site de desenvolvedores Flutter. Link aqui.

Devido ao uso deste guia, temos uma pasta no diretório lib chamada l10n. Dentro desta, podemos encontrar 3 arquivos extensão .arb, definindo o conteúdo dos textos internacionalizados na aplicação. Sendo eles: app_en.arb, app_es.arb e app_pt.arb:

Abaixo, veja o conteúdo do app_en.arb:

{
  "login": "Log in",
  "@login": {},

  "user": "User",
  "@user": {},
  "enterUser": "Enter your user",
  "@enterUser": {},
  "pleaseEnterUser": "Please, enter your user",
  "@pleaseEnterUser": {},

  "password": "Password",
  "@password": {},
  "enterPassword": "Enter your password",
  "@enterPassword": {},
  "pleaseEnterPassword": "Please, enter your password",
  "@pleaseEnterPassword": {}
}

O uso do arroba no nome do recurso de texto serve para adição de uma possível descrição do que é este recurso de texto. Aqui não foi usado, porém, é perfeitamente possível sua utilização. Outro ponto. Estas descrições só são exigidas no template do arquivo de internacionalização (vamos falar sobre isso na sequência). Ou seja, o conteúdo do arquivo app_es.arb não contém os recursos precedidos pelo arroba:

{
  "login": "Iniciar Sessión",

  "user": "Usuario",
  "enterUser": "Ingrese su  usuario",
  "pleaseEnterUser": "Por favor, ingrese su usuario!",

  "password": "Contraseña",
  "enterPassword": "Ingressa tu contraseña",
  "pleaseEnterPassword": "Por favor, introduzca su contraseña!"
}

Na pasta raiz do projeto, também temos um arquivo l10n.yaml, crucial para a internacionalização. Seu conteúdo clarifica algumas coisas que mostramos anteriormente:

arb-dir: lib/l10n
template-arb-file: app_en.arb
output-localization-file: app_localizations.dart

Falta pouco. Outra alteração é necessária no pubspec.yaml. Na sub-seção de dependencies adicionamos o flutter_localizations. Na sub-seção flutter, colocamos a propriedade generate com valor true.

...

dependencies:
  flutter_localizations: # Add this line
    sdk: flutter

...

# The following section is specific to Flutter.
flutter:
  generate: true

E para completar a configuração de i18n é necessário a configuração de alguns delegates na MaterialApp. Os três pontos indicam parte do código que será visto na sequência e não importância neste momento.

...

class MyApp extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    return GetMaterialApp(
      localizationsDelegates: AppLocalizations.localizationsDelegates,
      supportedLocales: AppLocalizations.supportedLocales,
      ...
    );
  }

}

Configurações Globais

Neste projeto também tomei o cuidado de encontrar um pacote que facilitasse a criação de configurações globais, como definição de url´s, pensando da divisão do projeto em flavors, ou ainda, alguma chave de api usada na aplicação, como Google Maps ou alguma chave de web service, por exemplo.

O primeiro passo é criar uma pasta assets->cgf com um arquivo app_settings.json.

O conteúdo deste arquivo pode ser visto aqui:

{
  "api_key": "ae5319efd54af97f99f70e5******"
}

No momento só temos a chave de api para consumir um serviço web, que veremos na sequência. Porém, qualquer outra configuração global pode ser inserida aqui respeitando a estrutura do arquivo json.

Algumas alterações também são necessárias no pubspec.yaml. Na parte de dependências, adicione o pacote global_configuration seguido pela sua última versão. Na sub-seção flutter -> assets adicione o caminho do arquivo de configurações json.

dependencies:
  ...
  global_configuration: ^1.6.0

flutter:
  ...
  assets:
    - assets/cfg/

Por fim, precisamos apenas carregar essas configurações em algum momento na nossa árvore de widgets. Eu preferi fazer isso logo na inicialização da aplicação:

void main() async{
  WidgetsFlutterBinding.ensureInitialized();
  await GlobalConfiguration().loadFromAsset("app_settings");
  runApp(MyApp());
}

class MyApp extends StatelessWidget {

  ...

}

Link para o pacote global_configuration aqui.

Posteriormente, vamos usar os valores destas configurações na aplicação.

Menção honrosa: Get

Usamos diversos pacotes nesse modelo de arquitetura, porém, um deles merece destaque, porque foi usado em diversos momentos da aplicação. Estamos falando do Get. Sua documentação pode ser encontrada aqui. Usamos este pacote para gerenciamento de estados, controle de rotas e controle de dependências.

Rotas e Injeção de Dependência com Get

No arquivo main.dart, veremos o uso do Widget GetMaterialApp, um pouco incomum, visto que, o “normal” seria o MaterialApp. Isso foi necessário para a configuração de rotas com o Get. Perceba as propriedades initialRoute e getPages. Este último, por sua vez, recebeu o valor routes, que está definido no arquivo routesDefinitions, na pasta lib -> core.

class MyApp extends StatelessWidget {

 @override
 Widget build(BuildContext context) {

   return GetMaterialApp(
     ...
     initialRoute: loginPageName,
     getPages: routes,
   );
 }

}

O routesDefinitions.dart possui a definição de rotas, que no pacote Get é chamado de page. Perceba dois pontos importantes aqui. Um deles é a definição de constantes para o nome das páginas. No momento temos apenas duas. O segundo ponto é a propriedade binding na primeira página. Desta forma, criamos uma vinculação e uma dependência automática entre esta página e uma instância de CoreBinding.

const String loginPageName = "/login";
const String listPageName = "/list";

final routes = [
 GetPage(
     name: loginPageName,
     page: () => LoginScreen(),
     binding: CoreBinding()
 ),
 GetPage(
   name: listPageName,
   page: () => ListScreen.initialize(),
 )
];

Finalmente, o CoreBinding tem um código um pouco mais simples. Mas, perceba a herança com Bindings. E também, a sobrescrita do dependencies. Desta forma, vinculamos este método como dependência neste binding. Dentro do método estamos usando o lazyPut do Get, para que, quando necessário, uma instância de RestClient seja fornecida, já usando o design pattern Singleton. Assim, na primeira tela da aplicação já teremos criado uma instância da classe que é o ponto de conexão da aplicação com o mundo do webservice.

class CoreBinding extends Bindings{

 @override
 void dependencies() {
   Get.lazyPut<RestClient>(() => RestClient(Dio()));
 }

}

Camada de Dados

Agora que falamos sobre alguns tópicos mais gerais, podemos entrar nas camadas que fazem parte da espinha dorsal da arquitetura, e, que foi mostrada nas figuras iniciais deste texto. Na pasta lib temos uma pasta filha, chamada dataSources. Dentro desta, por sua vez, temos uma pasta database para dados locais, salvos no banco de dados NoSQL com um ORM. E, uma pasta webServices para acesso a dados de um serviço REST.

No webServices, usei o pacote retrofit, documentação aqui. A principal razão foi pela similaridade com uma biblioteca homônima, disponível para desenvolvimento nativo Android.

Veja o conteúdo do arquivo restClient.dart, que está na pasta lib -> dataSources -> webServices.

part 'restClient.g.dart';

@RestApi(baseUrl: "https://api.themoviedb.org/3")
abstract class RestClient {
 factory RestClient(Dio dio, {String baseUrl}) = _RestClient;

 @GET("/movie/top_rated")
 Future<ResultGroup> getTopRated();

}

O pacote retrofit usa o build_runner para geração de código automático. No restClient.g.dart tem um detalhe muito importante. Estou colocando a apikey do webservice themoviedb, lendo esta informação do pacote de configurações globais. Veja o trecho do qual estou me referindo.

@override
Future<ResultGroup> getTopRated() async {
 const _extra = <String, dynamic>{};
 final queryParameters = <String, dynamic>{};
 final _data = <String, dynamic>{};
 final _result = await _dio.request<Map<String, dynamic>>(
     '/movie/top_rated?api_key=${GlobalConfiguration().getValue("api_key")}',
     queryParameters: queryParameters,
     options: RequestOptions(
         method: 'GET',
         headers: <String, dynamic>{},
         extra: _extra,
         baseUrl: baseUrl),
     data: _data);
 final value = ResultGroup.fromJson(_result.data);
 return value;
}

Já na camada de dados local, estamos usando o Floor. Sendo assim, precisamos criar uma entidade, o objeto de acesso aos dados (DAO) e o banco de dados propriamente dito.

A entidade está na pasta useCases -> models, no arquivo topRatedResponse.dart, na classe Result. Veja o uso da anotação @entity. Também, a anotação @JsonSerializable, porque estamos usando o pacote json_serializable documentação está disponível aqui.

part 'topRatedResponse.g.dart';

@entity
@JsonSerializable()
class Result {
 bool adult;
 String backdrop_path;

 @primaryKey
 int id;

 String original_language;
 String original_title;
 String overview;
 double popularity;
 String poster_path;
 String release_date;
 String title;
 bool video;
 double vote_average;
 int vote_count;

 Result({
   this.adult,
   this.backdrop_path,
   this.id,
   this.original_language,
   this.original_title,
   this.overview,
   this.popularity,
   this.poster_path,
   this.release_date,
   this.title,
   this.video,
   this.vote_average,
   this.vote_count
 });

 factory Result.fromJson(Map<String, dynamic> json) => _$ResultFromJson(json);
 Map<String, dynamic> toJson() => _$ResultToJson(this);
}

@JsonSerializable()
class ResultGroup {
 int page;
 int total_pages;
 int total_results;
 List<Result> results;

 ResultGroup({this.page, this.total_pages, this.total_results, this.results});

 factory ResultGroup.fromJson(Map<String, dynamic> json) =>
     _$ResultGroupFromJson(json);
 Map<String, dynamic> toJson() => _$ResultGroupToJson(this);
}

O DAO (Data Access Object) está na pasta lib -> dataSources, no arquivo topRatedDAO.dart. No Floor usamos exaustivamente as anotações, prova disso é o uso do @dao, @Query e @insert. Além disso, todas são auto-expicativas.

@dao
abstract class TopRatedDao {
 @Query('SELECT * FROM Result')
 Future<List<Result>> findAllResults();

 @insert
 Future<List<int>> insertResults(List<Result> results);
}

Por fim, na mesma pasta referida anteriormente, encontramos o appDatabase.dart.

part 'appDatabase.g.dart'; 

@Database(version: 1, entities: [Result])
abstract class AppDatabase extends FloorDatabase {
 TopRatedDao get topRatedDAO;
}

Repositórios

Acima da camada de dados, temos os repositórios. Como nosso aplicativo ainda é muito simples, temos apenas o arquivo moviesRepository.dart, na pasta repositories. Nesta classes temos dois métodos, uma para chamadas remotas, ou seja, para o web service, nominado como getRemoteTopRated. E, um método que busca as informações salvas no banco local, no método nomeado como getLocalTopRated.

class MoviesRepository {

 void getRemoteTopRated() {
   Get.find<RestClient>().getTopRated().then((response) {
     ListScreenController controller = Get.find();
     Get.find<AppDatabase>().topRatedDAO.insertResults(response.results);
     controller.setResultGroup(response.results);
   });
 }

 void getLocalTopRated() {
   Get.find<AppDatabase>().topRatedDAO.findAllResults().then((response) {
       ListScreenController controller = Get.find();
       controller.setResultGroup(response);
     }
   );
 }

}

Aqui usamos o pacote Get para injeção de dependências. Sendo assim, apenas usamos o método estático find da classe Get para requisitar as instâncias das classes desejadas. Em ambos os casos teremos um mesmo retorno de dados, que é passado para o controller da aplicação, que veremos logo na sequência.

Mas e aonde essas dependências são configuradas? Já vimos isso parcialmente, mas é um conceito importante que vale a pena ser revisto. Quanto ao RestClient, isso foi feito no CoreBinding.

class CoreBinding extends Bindings{

 @override
 void dependencies() {
   Get.lazyPut<RestClient>(() => RestClient(Dio()));
 }

}

Quem assumir a dependência de binding com esta classe recebe o método dependencies por herança. Sendo assim, quando a página ligada ao CoreBinding for chamada, teremos o lazyPut do Get chamado. E isso podemos ver no routesDefinitions:

final routes = [
 GetPage(
     name: loginPageName,
     page: () => LoginScreen(),
     binding: CoreBinding()
 ),
 GetPage(
   name: listPageName,
   page: () => ListScreen.initialize(),
 )
];

Em relação ao AppDatabase, sua instância foi criada no main.dart:

...

class MyApp extends StatelessWidget {

 @override
 Widget build(BuildContext context) {
   $FloorAppDatabase.databaseBuilder('app_database.db').build().then((appDb) => Get.lazyPut<AppDatabase>(() => appDb));

   ...
 }


}

Casos de Uso

Neste aplicativo de exemplo, temos apenas um caso de uso. Ele está no arquivo moviesUseCase.dart, dentro da pasta useCases. Devido ao projeto ainda ser simples, o use cases também está simples. Ele é apenas uma camada de ligação para o repositório e a chamada ao método local ou remoto de busca de dados.

class MoviesUseCase {

 final MoviesRepository repository = MoviesRepository();

 void getRemoteTopRated() {
   return repository.getRemoteTopRated();
 }

 void getLocalTopRated() {
   return repository.getLocalTopRated();
 }

}

Camada LogicHolders

Acima da camada de casos de uso, temos a logicHolders. Dentro dela temos os bindings, já discutidos anteriormente e, os controllers. Dentro do mundo Flutter, os controllers geralmente tem uma relação forte com pacotes de gerenciamento de estados, como Provider, BLoC ou MobX, por exemplo. Aqui, vamos usar o pacote Get também para esta função.

Dentro da pasta logicHolders -> controllers, encontramos o arquivo ListScreenControllers.dart. O principal ponto aqui é a variável resultGroup, que é apenas um observável de uma lista comum. Desta forma, ao atualizar essa lista, como acontece no método setResultGroup, chamamos o update do GetxController para avisar os observadores que a lista foi alterada. Por fim, o método getTopRated faz uma chamada direta ao repositório. Perceba que no momento não estamos tratando a conectividade para chamar o remote ou o local.

class ListScreenController extends GetxController{

 final moviesRepositories = MoviesRepository();

 var resultGroup = List<Result>().obs;  //observável.. programação reativa

 setResultGroup(List<Result> results) {
   resultGroup.assignAll(results);
   update();
 }

 getTopRated() => moviesRepositories.getRemoteTopRated();

}

Camada de Widgets

E a última camada na nossa arquitetura é a de widgets. Na pasta screens temos uma sub-pasta customWidgets, onde ficam os widgets customizados no projeto. No nosso caso temos um TextFormField próprio.

No listScreen temos a definição do widget que mostra o formulário de login. Alguns detalhes merecem destaque:

A aquisição da instância de AppLocalizations logo no início do método build. A variável é usada em diversos momentos onde precisamos dos textos internacionalizados.
O uso do componente customizado em diversos momentos: customTextFormField.
A mudança para uma nova tela (na verdade outro Widget) foi feita também fazendo uso do Get. Veja o na linha Get.offNamed(listPageName). O nome da rota está no arquivo de definição de rotas: routesDefinitions.dart.

class LoginScreen extends StatelessWidget {

 TextEditingController _userController = TextEditingController();
 TextEditingController _passwordController = TextEditingController();

 final _formKey = GlobalKey<FormState>();

 @override
 Widget build(BuildContext context) {
   AppLocalizations appLocalizations = AppLocalizations.of(context);

   return Scaffold(
     appBar: AppBar(
       title: Text(appLocalizations.login),
     ),
     body: Padding(
       padding: EdgeInsets.all(12),
       child: Form(
         key: _formKey,
         child: Column(
           children: <Widget>[
             customTextFormField(
               appLocalizations.enterUser,
               appLocalizations.user,
               appLocalizations.pleaseEnterUser,
               _userController
             ),
             customTextFormField(
                 appLocalizations.enterPassword,
                 appLocalizations.password,
                 appLocalizations.pleaseEnterPassword,
                 _passwordController
             ),
             Padding(
               padding: EdgeInsets.symmetric(vertical: 16.0),
               child: ElevatedButton(
                 onPressed: () {
                   if (_formKey.currentState.validate()) {
                     Get.offNamed(listPageName);
                   }
                 },
                 child: Text(appLocalizations.login),
               ),
             ),
           ],
         ),
       ),
     ),
   );
 }
}

Já no listScreen usamos o Get de forma mais ampla. Temos um método de inicialização, apenas para inserir a instância do controlador nesta tela. Já no build, esta mesma instância singleton é recuperada.

No corpo deste Widget usamos o GetBuilder. Passamos a chamada ao getTopRated no initState. No dispose também chamamos o dispose do controller, para não usar recursos de forma desnecessária. E, por fim, no builder chamamos o método buildBodyWithController. Este método vai mostrar um loading circular ou, uma lista com os filmes mais bem ranqueados, dependendo do retorno das camadas inferiores ao widget dentro da nossa arquitetura.

class ListScreen extends StatelessWidget{

 ListScreen.initialize() {
   Get.put(ListScreenController(), permanent: true);
 }

 @override
 Widget build(BuildContext context) {
   ListScreenController controller = Get.find<ListScreenController>();

   return Scaffold(
     appBar: AppBar(
       title: Text("Top Rated"),
     ),
     body: GetBuilder<ListScreenController>(
       initState: (_) => controller.getTopRated(),
       dispose: (_) => controller.dispose(),
       builder: (controller) => buildBodyWithController(controller),
     ),
     //Obx(() => buildBody())
   );
 }

 Widget buildBodyWithController(ListScreenController controller){
   return controller.resultGroup.value == null ?
       CircularProgressIndicator() :
       ListView.builder(
           itemCount: controller.resultGroup.value.length,
           itemBuilder: (context, index) => buildItemList(controller.resultGroup.value[index])
       );
 }

 Widget buildItemList(Result result) => Card(
     child: ListTile(
       title: Text(result.title),
       subtitle: Text(result.overview),
     ),
 );

}