UNIVERSIDADE FEDERAL DE SANTA CATARINA

Plataforma Web para execução de aplicativos Android

desenvolvidos com App Inventor

Darlan Brandt

Florianópolis
2021/2
 UNIVERSIDADE FEDERAL DE SANTA CATARINA
CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE SISTEMAS DE INFORMAÇÃO

Plataforma Web para execução de aplicativos Android desenvolvidos

com App Inventor

Darlan Brandt

Trabalho de Conclusão do Curso de

Graduação em Sistemas de Informação do
Centro Tecnológico da Universidade Federal
de Santa Catarina como parte dos requisitos
para a obtenção do Título de Bacharel em
Sistemas de Informação.
Orientador: Prof. Dr. Jean Carlo Rossa Hauck

Florianópolis
2021/2
 RESUMO

Em um mundo em constante evolução tecnológica, é importante que os estudantes

desenvolvam habilidades que os preparem para essas mudanças. Para tal, o ensino
do pensamento computacional desde os primeiros anos do Ensino Fundamental tem
auxiliado no desenvolvimento do pensamento lógico e da resolução de problemas.
Diversas iniciativas de ensino do pensamento computacional têm utilizado ambientes
como o App Inventor, que utiliza a programação em blocos para auxiliar no
desenvolvimento de aplicativos para dispositivos Android. O App Inventor permite a
visualização do app desenvolvido pelo estudante em tempo de desenvolvimento, por
meio do aplicativo AI2 Companion sem a necessidade de compilação e instalação do
app no celular do estudante, o que facilita o desenvolvimento das aplicações. No
entanto, devido ao fato de nem todo aluno possuir um smartphone ou limitações
tecnológicas das escolas, ocorrem dificuldades na implementação de iniciativas de
uso do App Inventor no ensino do pensamento computacional. Assim, este trabalho
apresenta o desenvolvimento de uma aplicação web que realize a comunicação com
o ambiente do App Inventor e permita a exibição em tempo de desenvolvimento das
telas dos apps implementados pelos estudantes. A aplicação web é modelada e
desenvolvida. São desenvolvidos: o protocolo de comunicação, back-end e front-end
da aplicação. A aplicação resultante dispensa a necessidade de uso de celular pelo
estudante em tempo de desenvolvimento, o que pode facilitar iniciativas de ensino do
pensamento computacional.

Palavras-chave: Computação na escola, App Inventor. Android, plataforma Web

 ABSTRACT

In a world in constantly evolving technology, it is important for students to develop skills

that prepare them for these changes. Therefore, teaching computational thinking since
their first years at school has helped on developing problem solving and logical
thinking. Various initiatives using computational thinking have used app development
environments such as App Inventor, which uses block-based programming to help with
the development of apps for Android. App Inventor allows visualizing the app as they
are being developed through the AI2 Companion application, without the need for
compiling or installing the full application on the student’s device, which makes it easier
to develop an application. Nonetheless, since not every student has access to a
smartphone, and some schools do not have access to a wireless connection, there
may be difficulties implementing initiatives teaching computational thinking with App
Inventor. Therefore, this paper aims to present the development of a web application
that allows exhibiting and testing apps as they are being developed by the students.
This web application is modeled and developed replicating the communication
protocol, creating a back-end server and a front-end application. The resulting
application does not require the students to have a smartphone for live testing. Thus,
this may facilitate initiatives in teaching computational thinking.

Keywords: School computing, App Inventor. Android, Web platform

 LISTA DE FIGURAS

Figura 1 – Interface do App Inventor no modo de edição de interface 17

Figura 2 – Interface do App Inventor no modo de edição de blocos 18
Figura 3 – Componentes do sistema e onde são executados, em vermelhos as partes
do App Inventor e em preto a infraestrutura externa 19
Figura 4 – Estrutura do arquivo .aia 20
Figura 5 – Exemplo de código YAIL 22
Figura 6 – Exemplo de aplicativo exibido de acordo com o código YAIL 23
Figura 7 – Conexão entre dispositivo-computador com o App Inventor via Wi-Fi 24
Figura 8 – Tela gerada para conexão pelo Companion 25
Figura 9 – Elementos e interações do sistema App Inventor 23
Figura 10 – Estrutura do App Inventor, criado com GWT 26
Figura 11 – Exemplo de um componente simples em React 28
Figura 12 – Exemplo de um componente dentro de outro componente 29
Figura 13 – Arquitetura da solução (FRANÇA, 2019) 34
Figura 14 – Arquitetura da solução (SPRANGER, 2019) 36
Figura 15 – Diagrama geral da solução 40
Figura 16 – Componentes da solução 41
Figura 17 – Protótipo da aplicação: Tela inicial 43
Figura 18 – Protótipo da aplicação: Iniciar conexão 44
Figura 19 – Protótipo da aplicação: Em execução 45
Figura 20 – Código da classe TopToolbar.java onde é iniciada a conexão 46
Figura 21 – Classe WirelessAction() que realiza a chamada da função 47
Figura 22 – Função getFromRendezvous() exibindo processo realizado para conexão
com o servidor Rendezvous() 48
Figura 23 – Comandos exibidos no console do navegador 49
Figura 24 – Log do console no navegador, nas ferramentas do desenvolvedor 50
Figura 25 – Interface do aplicativo criado no App Inventor 51
Figura 26 – Estrutura do aplicativo criado no App Inventor 52
Figura 27 – Código YAIL para a criação de uma tela 52
Figura 28 – Código YAIL com a adição de componentes na tela 53
Figura 29 – Comandos em bloco criados para o aplicativo 54
Figura 30 – Comandos em bloco em código YAIL 56
Figura 31 – Comandos em bloco em código JavaScript 56
Figura 32 – Comando responsável pela conexão com o celular no arquivo
replmgr.js 57
Figura 33 – Código do arquivo rendezvous.js para validação da conexão do
Companion 58
Figura 34 – Aba da ferramenta do desenvolvedor com os pacotes enviados pelo App
Inventor 59
Figura 35 – Código inicial do componente Button 61
Figura 36 – Estrutura inicial do projeto com componentes 61
Figura 37 – Comando ReplState enviado pelo App Inventor para o Companion 63
Figura 38 – Comando ReplState formatado para envio no Postman 64
Figura 39 – Dicionário criado para parse dos componentes 66
Figura 40 – Objeto JSON com as propriedades de um componente 67
Figura 41 – Componentes listados de forma 67
Figura 42 – Array de objetos JSON com variáveis globais 69
Figura 43 – Exemplo de objeto baseado nos comandos em bloco 69
Figura 44 – Comando em bloco no App Inventor 70
Figura 45 – Comando em bloco convertido em string a ser executada como
JavaScript 70
Figura 46 – Aplicação modelo gerada no App Inventor 72
Figura 47 – Comando em bloco para o clique em um botão numérico 73
Figura 48 – Código em bloco para as operações 74
Figura 49 – Comandos em bloco para exibição do resultado da operação 75
Figura 50 – Comandos em bloco para limpeza dos campos da tela 75
Figura 51 – Aplicação exibida no LIDEA-w 76
Figura 52 – Demonstração da tela criada para inserção da chave de 6 caracteres 77
Figura 53 – Aplicação cortada em tela com resolução inferior a 1024x768 pixels 79
LISTA DE TABELAS

Tabela 1 – Termos utilizados nas buscas 32

Tabela 2 – Primeira string de busca utilizada 32
Tabela 3 – Segunda string de busca utilizada 32
Tabela 4 – Terceira string de busca utilizada 32
Tabela 5 – Requisitos funcionais do LIDEA-w 32
Tabela 6 – Requisitos não funcionais do LIDEA-w 39
Tabela 7 – Demonstração da estrutura do aplicativo criado no App Inventor
por tipo 52
Tabela 8 – Código YAIL para a criação de tela e sua definição 53
Tabela 9 – Código YAIL para adição de componentes 54
Tabela 10 – Código YAIL gerado para comandos em bloco 55
Tabela 11 – Componentes visuais criados e que não foram criados 60
Tabela 12 – Comandos em bloco convertidos e que não foram convertidos 71
Tabela 13 – Evidências dos testes de requisitos funcionais do LIDEA-w 77
Tabela 14 – Evidências dos testes de requisitos não funcionais do LIDEA-w 78
 LISTA DE QUADROS

Quadro 1 – Termos utilizados nas buscas 27

 8

LISTA DE ABREVIATURAS E SIGLAS

AI2 App Inventor 2

AJAX Asynchronous JavaScript
API Application Programming Interface
ART Android Runtime
DOM Document Object Model
GWT Google Web Toolkit
JSON JavaScript Object Notation
JVM Java Virtual Machine
MIT Massachusetts Institute of Technology
REPL Read/Eval/Print/Loop
RPC Remote Procedure Call
SBC Sociedade Brasileira de Computação
UFSC Universidade Federal de Santa Catarina
YAIL Young Android Intermediate Language
 9

SUMÁRIO

1. INTRODUÇÃO ............................................................................................. 11
1.1 OBJETIVOS ................................................................................................. 13

1.1.1 Objetivo Geral ............................................................................................... 13

1.1.2 Objetivos Específicos ................................................................................... 13

1.2 LIMITAÇÃO DO ESCOPO ............................................................................ 13

2. FUNDAMENTAÇÃO TEÓRICA ................................................................... 15

2.1. COMPUTAÇÃO NA ESCOLA ...................................................................... 15

2.2. APP INVENTOR ........................................................................................... 16

2.3. MIT AI2 COMPANION .................................................................................. 23

2.4. GWT ............................................................................................................. 27

2.5. REACT.JS .................................................................................................... 28

2.6. NODE.JS ...................................................................................................... 29

3. ESTADO DA ARTE ...................................................................................... 31

3.1. DEFINIÇÃO E EXECUÇÃO DO MAPEAMENTO ......................................... 31

3.2. ANÁLISE DOS RESULTADOS ENCONTRADOS ........................................ 33

3.2.1. Ambiente Web integrado com App Inventor para execução de aplicações
Android ...................................................................................................................... 34

3.2.2. Live programming of mobile apps in App Inventor ........................................ 35

3.2.3. Ferramenta de Geração de Aplicativos Móveis Híbrido/Cross-platform

Baseada em Editor de Interface ................................................................................ 35

3.3. DISCUSSÃO ................................................................................................ 37

4. ANÁLISE E PROJETO ................................................................................ 38

4.1. REQUISITOS ............................................................................................... 38

4.2. MODELAGEM E PROPOSTA DE SOLUÇÃO .............................................. 39

4.3. PROTÓTIPOS DE TELA .............................................................................. 42

5. IMPLEMENTAÇÃO ...................................................................................... 46
5.1. ENGENHARIA REVERSA ............................................................................ 46
 10

5.1.1. Análise do código YAIL ................................................................................. 49

5.1.2. Conexão com o servidor Rendezvous .......................................................... 56

5.2. DESENVOLVIMENTO DA PLATAFORMA LIDEA-w.................................... 59

5.2.1. Desenvolvimento da interface ...................................................................... 60

5.2.2. Desenvolvimento do back-end ..................................................................... 62

5.2.3. Conversão de YAIL em objeto JSON para componentes visuais ................. 66

5.2.4. Conversão de YAIL para execução dos comandos em bloco ...................... 68

5.2.5. Conversão de YAIL em JavaScript executável ............................................. 69

5.3. TESTES FUNCIONAIS................................................................................. 71

5.3.1. Aplicação Modelo ......................................................................................... 72

5.3.2. Validação dos Requisitos ............................................................................. 76

5.4. CONSIDERAÇÕES FINAIS .......................................................................... 79

6. CONCLUSÃO............................................................................................... 81
6.1. TRABALHOS FUTUROS .............................................................................. 82

7. REFERÊNCIAS ............................................................................................ 84
 11

1. INTRODUÇÃO

Em um mundo cada vez mais conectado e tecnológico, algumas habilidades

importantes para os estudantes têm sido incluídas no processo educacional, como por
exemplo o ensino do pensamento computacional (BRENNAN e RESNICK, 2012).
Pensamento computacional é “o processo de pensamento relacionado a formular
problemas e suas soluções de forma que as soluções são representadas de uma
maneira que pode ser efetivamente executada por um agente de processamento de
informação” (BRENNAN e RESNICK, 2012). O ensino do pensamento computacional
nas escolas é um elemento importante na educação atual, pois auxilia no
desenvolvimento de habilidades como pensamento lógico e desperta o interesse na
descoberta e resolução de problemas (K–12 CS, 2016). Nesse sentido, há algumas
iniciativas dentro e fora do Brasil, como Computing at School1 e a Computação na
Escola2, dedicadas a “aumentar o ensino de computação no Ensino Fundamental e
Médio” utilizando diversas ferramentas computacionais para atingir esses objetivos.
Uma das formas de ensinar programação de forma lúdica e de fácil
compreensão é utilizando linguagens de programação baseadas em blocos. Nesse
tipo de linguagem são encaixadas peças que formam estruturas de programação, de
maneira que possuem não somente um nível de abstração maior, mas também são
visualmente mais simples para indicar o que cada bloco representa, reduzindo a carga
cognitiva necessária para o aprendizado, quando comparadas às tradicionais
linguagens de programação baseadas em texto (ALVES, WANGENHEIM e HAUCK,
2019). Para esse fim, há diversas ferramentas de programação baseadas em blocos
e voltadas para apoio ao ensino, como o App Inventor3 e o Scratch4.
A ferramenta App Inventor, criada pela Google e atualmente mantida pelo
Instituto de Tecnologia de Massachusetts (MIT), é usada para desenvolvimento de
aplicativos para dispositivos Android usando um navegador web, sem necessidade de
instalação de uma aplicação específica para desenvolvimento, como o Android Studio.
O App Inventor utiliza a linguagem de programação Java, através do framework GWT

1
https://www.computingatschool.org.uk/
2
https://www.computacaonaescola.ufsc.br/
3
https://appinventor.mit.edu/
4
https://scratch.mit.edu/
 12

para sua composição, que converte o seu código para JavaScript (GWT OPEN
SOURCE PROJECT, 2020). Para a criação dos aplicativos, é usada a linguagem de
programação visual Blockly, que permite a criação de aplicativos para dispositivos
com sistema operacional Android de forma visual e em menos tempo que ambientes
de programação tradicionais (MIT, 2021).
Outra ferramenta usada para o ensino de programação, a Scratch, também
utiliza a programação em blocos, da mesma forma que o App Inventor. A Scratch foi
desenvolvida para utilização de idades entre 8 e 16 anos (MIT, 2021) sendo bastante
utilizada em ambientes escolares, porém não permite a criação de um aplicativo de
fato (MIT, 2021). Para este trabalho optou-se pela utilização do App Inventor devido
ao vasto material já existente sobre esta ferramenta e pelo foco no desenvolvimento
de aplicativos móveis.
A visualização do aplicativo em desenvolvimento no App Inventor no celular é
realizada através do aplicativo AI2 Companion, que deve ser instalado em um
smartphone Android ou iOS. Ao acessar o aplicativo é necessário fazer a leitura de
um QR Code ou inserir o código exibido na tela, o que permite sincronizar a exibição
do aplicativo que está sendo desenvolvido com o celular em tempo de
desenvolvimento, sem necessidade de compilar e instalar um arquivo apk (Android
packaged application) no celular.
No entanto, o ensino de computação na educação básica no Brasil enfrenta
diversas limitações que dificultam a utilização desse tipo de ferramenta, como o App
Inventor. Os alunos podem não possuir um aparelho celular para realizar a
visualização do aplicativo criado no App Inventor por meio do AI2 Companion, a escola
pode ter uma internet de baixa velocidade ou computadores lentos que não suportam
a utilização de emuladores de aplicativos Android. Essas limitações têm sido também
percebidas nas aplicações voltadas ao ensino do pensamento computacional
realizadas pela Computação na Escola.
Assim, o presente projeto propõe o desenvolvimento de uma ferramenta que
permita a renderização e execução das telas de uma aplicação desenvolvida com App
Inventor, por meio de uma interface web, sem necessidade de criação de uma
máquina virtual, utilização de emuladores ou utilização de um smartphone Android ou
iOS.
 13

1.1 OBJETIVOS

1.1.1 Objetivo Geral

O presente trabalho tem por objetivo desenvolver um sistema web para a

execução, de forma funcional, de telas de aplicativos móveis desenvolvidos na
ferramenta App Inventor. O sistema web desenvolvido deve suportar a conexão com
a ferramenta App Inventor, permitindo a exibição funcional dos componentes visuais
e de layout definidos em tempo de desenvolvimento.

1.1.2 Objetivos Específicos

Para alcançar o objetivo final do projeto, os seguintes objetivos específicos são

requeridos:
● Analisar o estado da arte sobre ambientes web para execução de apps
desenvolvidas com App Inventor;
● Analisar o protocolo de comunicação utilizado entre a aplicação App
Inventor ao aplicativo AI2 Companion;
● Implementar a comunicação com o servidor Rendezvous simulando a
utilização do aplicativo AI2 Companion;
● Desenvolver uma aplicação web que exiba, em tempo de
desenvolvimento, na tela do navegador o aplicativo construído dentro
do App Inventor.

1.2 LIMITAÇÃO DO ESCOPO

Estão fora do escopo deste trabalho a implementação os seguintes tipos de

componentes:
● Sensores, como: acelerômetro, giroscópio, localização, entre outros;
● Gravadores de áudio e vídeo;
● Mapas;
 14

● Funcionalidades como Bluetooth;

● Criação de telas secundárias. Será usada apenas uma tela principal.
● Criação de procedures
 15

2. FUNDAMENTAÇÃO TEÓRICA

Este capítulo trata dos principais conceitos envolvidos no desenvolvimento

deste trabalho. São abordados o App Inventor, a ferramenta AI2 Companion e as
principais tecnologias utilizadas no seu desenvolvimento, como GWT e tecnologias
utilizadas como React.JS e Node.JS.

2.1. COMPUTAÇÃO NA ESCOLA

Com a evolução da tecnologia e crescimento de dispositivos tecnológicos

integrados ao cotidiano, a demanda por profissionais capacitados também tem
aumentado (K–12 CS, 2016). Cada vez mais será necessário que estes profissionais
possuam algumas habilidades relacionadas ao pensamento computacional, mesmo
para áreas que não trabalham diretamente com ciências da computação (K–12 CS,
2016). É importante que este conhecimento já seja desenvolvido desde cedo, de
forma que os estudantes de séries iniciais sejam capazes de desenvolver um
conhecimento em ciências computacionais e aprender novas formas de resolver
problemas, aproveitando o poder do conhecimento computacional (K–12 CS, 2016).
Ao redor do mundo há diretrizes e bases para o ensino da Computação na
educação básica (K–12 CS, 2016). Entre eles, o K-12 Computer Science Framework,
sendo amplamente reconhecido por apresentar padrões, guias, conceitos, práticas e
os benefícios da implementação do ensino da computação nas escolas, desde
estágios iniciais até as séries avançadas (K–12 CS, 2016).
No entanto, no Brasil o ensino de computação não é parte integrante dos
Parâmetros Curriculares Nacionais (PCN) (SBC, 2019). A computação faz parte
apenas como ensino de informática, servindo apenas para ensino do computador
como ferramenta auxiliar no ensino das demais disciplinas constantes nos PCN
(BNCC, 2018). A Sociedade Brasileira de Computação possui diretrizes para o ensino
de computação na educação básica, em que são tratados os conceitos, apresentadas
as competências desenvolvidas pela Computação, as habilidades da área no Ensino
Fundamental e no Ensino Médio (SBC, 2021).
 16

Com o intuito de incluir a programação no ensino, há a iniciativa Computação

na Escola, da Universidade Federal de Santa Catarina (INE/UFSC) em parceria com
o Instituto Federal de Santa Catarina (IFSC), que tem por objetivo aumentar o ensino
de computação no Ensino Fundamental e Médio e que todos os alunos em todas as
escolas possam ter a oportunidade de aprender computação (COMPUTAÇÃO NA
ESCOLA, 2021). São realizados diversos eventos buscando ampliar o ensino da
computação, incluindo oficinas, exposições, projetos de formações de tutores, entre
outros.
Entre seus objetivos estão:
● Motivar o ensino de computação para todos os alunos do Ensino
Fundamental e Médio no Brasil.
● Facilitar o ensino de computação no Ensino Fundamental e Médio pela
criação de unidades instrucionais de acordo com diretrizes de currículo
e adequadas às respectivas faixas etárias.
● Capacitar professores do Ensino Fundamental e Médio para o ensino de
computação.
● Compartilhar relatos de experiências e recursos referente ao ensino de
computação criando uma comunidade de prática.
● Aumentar o número de formados na área de computação (aumentando
também a representação de mulheres e minorias).

2.2. APP INVENTOR

O App Inventor é uma ferramenta usada para desenvolvimento de aplicativos

para dispositivos Android usando um navegador web. Lançado inicialmente em 2010
pela Google e atualmente mantido pelo MIT (MIT, 2021), o App Inventor é um
ambiente de programação baseado em blocos. Por meio do App Inventor, pessoas
com pouca ou nenhuma experiência em programação podem criar aplicativos
utilizando seu editor visual, onde é possível incluir componentes para a criação da
interface do aplicativo, arrastando elementos como caixas de texto, botões e/ou
imagens e programar seu funcionamento com o uso de programação baseada em
 17

blocos, no modo de edição de blocos (WANGENHEIM, HAUCK, et al., 2018). O modo

de edição visual é demonstrado na figura 1.

Figura 1: Interface do App Inventor no modo de edição de interface (Elaborado pelo autor)

Blocos são comandos em linguagem natural apresentados de forma visual e de

forma ordenada logicamente, ou de formas mais fáceis de buscar e navegar, e são
encaixáveis a fim de permitir a criação de um código executável (WEINTROP,
SHEPHERD, et al., 2017). Além disso, o fato de utilizar blocos que o usuário arrasta
e solta, ao invés de digitar comandos que ele não entende ou conhece, torna mais
fácil a assimilação do comando a ser executado (WEINTROP, SHEPHERD, et al.,
2017). A edição de blocos é apresentada na figura 2.
 18

Figura 2: Interface do App Inventor no modo de edição de blocos (Elaborado pelo autor)

O App Inventor é composto basicamente por dois módulos, sendo um módulo

servidor e um módulo cliente. O módulo cliente é onde o usuário desenvolve a
aplicação, sua interface e seu código, incluindo campos, botões, sensores, entre
outros, e o código que deve ser executado quando o usuário realizar alguma ação de
acordo com o componente. O módulo servidor contém a parte responsável por
autenticação e salvar os projetos criados pelo usuário (DOMINGUEZ e SPERTUS,
2021). A aplicação também possui componentes compartilhadas entre os dois
módulos, responsáveis basicamente pela comunicação entre ambos, que é realizada
por Remote Procedure Call (RPC), um protocolo para execução remota de procedures
em computadores ligados em rede (GARCIA, 2002).
A aplicação possui sete diretórios principais onde são encontrados:
● aiphoneapp: intérprete que roda no dispositivo móvel ou emulador
quando conectado ao computador onde o App Inventor está sendo
executado;
● aiplayapp: outro intérprete, ligado ao AI2 Companion que roda no
dispositivo móvel ou emulador quando conectado ao computador onde
o App Inventor é executado;
 19

● appengine: é diretório principal, onde encontra-se a aplicação GWT

(Google Web Toolkit), que fornece o lado cliente, para criação de
aplicativos, no navegador, bem como o lado servidor que salva e
recupera os projetos e envia requisições para o buildserver;
● blocklyeditor: o editor de blocos, integrado no lado cliente, no
navegador, utiliza a biblioteca Blockly. É usado também pelo
buildserver;
● buildserver: um servidor http que utiliza um arquivo zip como fonte e
gera um arquivo apk ou mensagens de erro;
● common: constantes e classes utilitárias usadas por outros sub-
projetos;
● components: código de apoio aos componentes do App Inventor, que
incluem anotações, implementações e scripts para extração de
informação necessária em outros sub-projetos.

A Figura 3 demonstra onde estes componentes são executados:

Figura 3: Componentes do sistema e onde são executados, em vermelho as partes do App

Inventor e em preto a infraestrutura externa (DOMINGUEZ e SPERTUS, 2021)

Dentro do App Inventor é possível exportar o projeto, ou o seu código fonte.

Também é possível importá-lo, caso tenha sido criado e exportado anteriormente. O
arquivo é exportado no formato .aia e possui todas as informações do aplicativo. Na
pasta assets, que é uma pasta do arquivo .aia, estão os arquivos de imagens e sons
usados. O código do aplicativo fica listado na pasta src e os arquivos são divididos em
 20

dois formatos principais: nos arquivos com extensão .scm estão listadas as
informações referentes ao layout da tela, em formato JSON, e nos arquivos com
extensão .bky está a informação relacionada à parte lógica, do código gerado com
os blocos, em formato XML. Há também uma pasta youngandroidproject que contém
apenas um arquivo, que lista as informações do projeto (nome, estrutura, nome das
telas).

Figura 4: Estrutura do arquivo aia. Baseado em (MIT APP INVENTOR COMMUNITY, 2019)

Um dos fatores chave no App Inventor é a possibilidade de comunicação com

o AI2 Companion de forma que o que está sendo desenvolvido na aplicação pode ser
testado pelo usuário. As alterações realizadas no App Inventor refletem no que é
exibido no AI2 Companion, que pode se conectar através do WiFi ou conectado a um
cabo USB. Quando realizada a conexão, são enviadas informações em linguagem
YAIL, que é uma implementação de outra linguagem de programação chamada Kawa
(CASAROTTO e CHISTE, 2003). Sempre que há uma alteração no código, dentro do
App Inventor, o Companion verifica se o código existente recebido é igual ao que
possui em cache e se for diferente, atualiza na tela. Esta funcionalidade é essencial
 21

pois habilita os desenvolvedores a interagir com o programa que está sendo criado.
O aplicativo desenvolvido pode ser testado através do Companion e pode também
gerar um arquivo apk que pode ser distribuído através da Play Store. Sempre que
esta opção é selecionada, o App Inventor realiza o upload do projeto completo e que
pode ser baixado através de um QR Code para distribuição. A geração do arquivo apk
também é realizada com a interpretação do código em linguagem YAIL, da mesma
forma que ocorre durante a execução do aplicativo desenvolvido pelo Companion.

2.2.1. Blockly

Blockly é uma biblioteca de código aberto para programação visual que utiliza
blocos para adição de código em uma aplicação em desenvolvimento (PASTERNAK,
FENICHEL e MARSHALL, 2017). Lançado inicialmente em 2012 como um projeto da
Google, é utilizado em uma vasta quantidade de projetos, principalmente voltados
para educação e ensino de programação, incluindo o App Inventor (GOOGLE, 2021).
Permite a extração do código criado em blocos para código baseado em texto, além
da criação de novos blocos conforme necessidade do usuário (GOOGLE, 2021).
É usado como editor visual de código sem depender do lado do servidor, sendo
este código desenvolvido pelo lado do cliente apenas (GOOGLE, 2021). Sua
biblioteca principal é escrita em JavaScript e possui suporte a cinco linguagens de
programação: JavaScript, Lua, PHP, Dart e Python.
Seus blocos representam conceitos como variáveis, expressões lógicas, loops,
entre outros, que permitem ao usuário aplicar princípios da programação sem se
preocupar com a sintaxe (GOOGLE, 2021).

2.2.2. YAIL

YAIL é a representação intermediária para as aplicações durante o processo

de compilação (SPERTUS, 2019). É uma linguagem com sintaxe baseada em
parênteses e é definida como uma coleção de macros e funções em Kawa. A
linguagem Kawa é um uma linguagem de programação de propósito geral que roda
 22

na plataforma Java, como uma extensão da linguagem Scheme, que é uma versão
estática e recursiva da linguagem de programação Lisp (CASAROTTO e CHISTE,
2003) que por sua vez é uma linguagem de programação funcional criada por Guy
Lewis Steele Jr. e Gerald Jay Sussman (CASAROTTO e CHISTE, 2003). Por este
motivo, programas em YAIL podem ser traduzidos por um compilador Scheme, com
os procedimentos e macros apropriados (SCHILLER, ABELSON, et al., 2014).

Figura 5: Exemplo de código YAIL (Elaborado pelo autor)

Na Figura 6 é demonstrado um exemplo do aplicativo gerado pelo App Inventor,

de acordo com o código demonstrado na Figura 5.
 23

Figura 6: Exemplo de aplicativo exibido de acordo com o código YAIL (Elaborado pelo autor)

YAIL, por ser baseado em Kawa, é parte importante para a execução do

aplicativo criado no App Inventor, por unir a flexibilidade da linguagem Scheme com a
habilidade de integrar bibliotecas Java e compilar em Java Virtual Machine (JVM)
(SCHILLER, ABELSON, et al., 2014). A linguagem Kawa possui um intérprete que age
como um Read/Eval/Print Loop (REPL), para avaliar expressões individualmente
diferentemente de linguagens como Java que não possui este ambiente de teste e a
aplicação deve ser compilada antes de ser executada (SCHILLER, ABELSON, et al.,
2014).

2.3. MIT AI2 COMPANION

O MIT AI2 Companion é um aplicativo mobile utilizado juntamente ao App

Inventor, no qual é possível realizar a conexão entre um dispositivo (smartphone ou
tablet) via USB ou conectado à internet via Wi-Fi para que o aplicativo gerado pelo
App Inventor seja executado no dispositivo que possui o aplicativo MIT AI2 Companion
instalado, para realização de testes e execução do código gerado. O aplicativo para
execução em smartphones e tablets pode ser instalado em dispositivos Android e iOS
(MIT, 2021).
Sua principal função é o live debugging, que é uma forma de obter uma forma
mais imediata as alterações realizadas no programa desenvolvido, o que permite ao
programador, em especial aos iniciantes, entender e experimentar o aplicativo criado
(SCHILLER, ABELSON, et al., 2014).
 24

A conexão entre o aplicativo e o App Inventor via Wi-Fi deve ser realizada
somente se ambos estiverem conectados à mesma rede local. A conexão entre o
computador, que está executando o App Inventor e o dispositivo onde está o
Companion é feita através do servidor Rendezvous do MIT. (MIT, 2021)
A Figura 7 demonstra um exemplo de solução ideal de como deve ser a
conexão entre os dispositivos pela internet.

Figura 7: Conexão entre dispositivo-computador com o App Inventor via Wi-Fi (MIT, 2021)

O processo da conexão é realizado em 6 passos:

1. O computador que executa o App Inventor se comunica com o servidor
enviando uma chave de 6 caracteres gerada pelo App Inventor para ser
preenchida no Companion;
2. O servidor Rendezvous grava o endereço IP do computador;
 25

3. O dispositivo realiza a comunicação com o servidor e envia a chave de

6 caracteres;
4. É registrado o endereço IP do dispositivo;
5. O servidor Rendezvous informa os endereços IP do dispositivo e o
computador, que tem a mesma chave de 6 caracteres, para o outro;
6. O dispositivo e o computador passam a se comunicar diretamente via
IP.

Figura 8: Tela gerada para conexão pelo Companion (Elaborado pelo autor)

O envio da chave de 6 caracteres para o servidor Rendezvous não é feito em

texto simples. Todas as comunicações são feitas utilizando o algoritmo de hash MD5.
Quando conectados, o computador funciona como um servidor web, que envia o
código YAIL para o dispositivo como uma chamada AJAX (SCHILLER, ABELSON, et
al., 2014). É possível visualizar na Figura 9 a comunicação direta entre o computador
e o dispositivo, enviando o código YAIL diretamente ao Companion, que possui um
interpretador deste código.
 26

Figura 9: Elementos e interações do sistema App Inventor (SCHILLER, ABELSON, et al.,

2014)

Há um quarto elemento na imagem, o servidor responsável pela compilação do

código do programa gerado no App Inventor em um arquivo para distribuição, o
arquivo apk. Quando a opção para criação de um arquivo apk é selecionada, os
componentes e blocos de cada tela do projeto são convertidos em YAIL, que então
compilados em bytecode JVM, que é convertido em bytecode Dalvik Virtual Machine
(DVM) para criação do arquivo apk (SCHILLER, ABELSON, et al., 2014). A DVM foi
substituída pelo Android Runtime (ART) a partir da versão 5, também conhecida como
Lollipop (SADOWSKA, 2021).
O Companion instalado no dispositivo possui um REPL Kawa que avalia
individualmente as expressões YAIL enviadas pelo navegador, onde o usuário está
desenvolvendo a aplicação. Sempre que um novo YAIL é gerado e difere da cópia em
cache, o navegador envia o novo código YAIL para o dispositivo, sem necessidade de
reinstalação do aplicativo (SCHILLER, ABELSON, et al., 2014).
Desta forma, o Companion atua como qualquer aplicativo gerado pelo App
Inventor e precisa de permissão de uso de todos os componentes.
 27

2.4. GWT

GWT é um conjunto de ferramentas de código aberto usado para criação de

aplicações complexas, como o App Inventor, em que seu código é escrito em Java,
utilizando suas bibliotecas de API, compilador e servidor de desenvolvimento (GWT
OPEN SOURCE PROJECT, 2020). Permite que sejam criadas aplicações em Java e
implementadas em JavaScript. Sendo assim, a aplicação desenvolvida utilizando
GWT pode ser executada em todos os browsers, incluindo para dispositivos móveis
(GWT OPEN SOURCE PROJECT, 2020). Também facilita para o desenvolvedor de
forma que este não precisa se preocupar com detalhes relacionados a RPC, com
exceção de callbacks explícitos (um para chamadas bem-sucedidas e outro para
chamadas com falha) (GWT OPEN SOURCE PROJECT, 2020).
O lado cliente da aplicação em GWT é traduzida para JavaScript, porém o lado
servidor não precisa ser traduzido, sendo assim, continua sendo desenvolvido em
Java. O lado servidor pode ser hospedado em um servidor local ou utilizar a Google
App Engine, que é uma plataforma para computação em nuvem que permite
programas escritos em Java ou Python sejam armazenados e executados nos
servidores da Google (DOMINGUEZ e SPERTUS, 2021).

Figura 10: Estrutura do App Inventor, criado com GWT (DOMINGUEZ e SPERTUS, 2021)

Aplicações em GWT podem ser executadas em dois modos: desenvolvimento

e produção. No modo de desenvolvimento a interação é feita em Java, sem
necessidade de tradução para JavaScript, utilizando a JVM. Quando executada em
modo de produção, a aplicação é executada em HTML e JavaScript, compilado e
traduzido do código Java (GWT OPEN SOURCE PROJECT, 2020).
 28

2.5. REACT.JS

React é uma biblioteca JavaScript de código aberto criada pela Facebook em

2012 (FACEBOOK INC., 2021). Seu foco é o uso front-end para criação de interfaces
para o usuário e componentes da interface do usuário.
Seu código é composto de entidades chamadas componentes que podem ser
renderizados em elementos do DOM, que é a estrutura dos elementos de uma página,
em uma estrutura de árvore em que cada nó é um elemento do documento HTML ou
XML, por exemplo. Seus componentes podem ser funcionais, em que são declarados
através de uma função, ou baseados em classe, utilizando as classes do ES6 ou
ECMAScript 6, uma revisão do JavaScript. (FACEBOOK INC., 2021). Um componente
React pode ser reaproveitado em interfaces comuns dentro do projeto, sendo útil para
botões, campos de texto, entre outros, inclusive dentro de outros componentes
(W3SCHOOLS,2021).

Figura 11: Exemplo de um componente simples em React. (FACEBOOK INC., 2021)

 29

Figura 12: Exemplo de um componente dentro de outro componente. Adaptado de

(W3SCHOOLS, 2021)

Nos exemplos das Figuras 11 e 12, o código está em JSX, que é uma extensão
da sintaxe do JavaScript similar a uma sintaxe XML. O JSX permite a utilização de
código HTML, em que são utilizados mesmos elementos da DOM. São produzidos
elementos do React a partir das tags HTML (W3SCHOOLS, 2021)
Um recurso importante do React é a utilização de um DOM virtual, em que uma
representação virtual da interface é mantida na memória e sincronizada com o DOM
real. Isto é realizado pela biblioteca ReactDOM, em um processo chamado
reconciliação. Assim o código escrito é executado como se toda a página fosse
alterada, porém as bibliotecas React renderizam apenas os componentes que têm seu
estado alterado, evitando recarregamentos desnecessários. (FACEBOOK INC., 2021)

2.6. NODE.JS

O Node.js é um ambiente de execução em JavaScript, utilizado para o

desenvolvimento de aplicações escaláveis (NODE.JS, 2022). Seu principal uso é
focado no lado servidor de uma aplicação. Por ser escalável e por sua arquitetura,
 30

flexibilidade e baixo custo, Node.js tem se tornado uma escolha para implementação
de microsserviços (OPUS, 2018), que são uma abordagem arquitetônica e
organizacional do desenvolvimento de software na qual o software consiste em
pequenos serviços independentes que se comunicam usando APIs bem definidas
(AMAZON, 2022). Além disso, por utilizar JavaScript, que é linguagem padrão para
navegadores web, o Node.js tem como vantagem o know-how de quem utiliza essa
linguagem de programação no desenvolvimento front-end; facilidade para instalação
de dependências, que tornam a plataforma mais flexível; e leveza por ser um ambiente
que não exige muitos recursos computacionais (OPUS, 2018).
 31

3. ESTADO DA ARTE

Para a realização da pesquisa do estado da arte foi realizada uma revisão

sistemática da literatura onde foram consideradas soluções e/ou ambientes para a
realização de live debugging que são pertinentes aos objetivos do presente trabalho.

3.1. DEFINIÇÃO E EXECUÇÃO DO MAPEAMENTO

Foi estabelecida uma questão central para esta etapa, que será respondida na
realização do mapeamento da literatura.
Serão analisados os resultados da busca que responde a seguinte pergunta de
pesquisa:
● Como são desenvolvidos os ambientes web de live debugging para App
Inventor?

Com o auxílio da ferramenta Google Scholar, que busca por artigos científicos,
foram realizadas pesquisas visando encontrar trabalhos correlatos ou similares
relacionados ao assunto deste trabalho. A partir da pergunta estabelecida, foram
definidos os termos da busca, começando uma busca mais restrita e partindo para
buscas mais abrangentes, caso não fossem encontrados resultados suficientes. As
buscas foram realizadas utilizando termos em português e em inglês.
Para inclusão/exclusão foram considerados os seguintes critérios:
● Incluir conceitos relacionados ao App Inventor, programação visual em
blocos e a como é realizada a comunicação ao Companion;
● Tratar o live debugging de forma explicativa ou conceitual realizado em
ambiente web;
● Trazer conteúdo relevante ao processo realizado neste trabalho pelo
objetivo realizado ou pelo uso de tecnologias similares;
● Excluídos os tutoriais ou trabalhos que apenas ensinam como utilizar o
App Inventor ou demonstram como conectar ao Companion.

A tabela a seguir mostra os termos de busca utilizados nas strings de busca

com seus sinônimos e traduções:
 32

TERMOS SINÔNIMOS INGLÊS

Ambiente IDE Environment
App Inventor
Web
Depuração Debugging
YAIL Young Android
Intermediate Language
Tabela 1: Termos utilizados nas buscas

Foram elaboradas algumas strings de busca para responder à pergunta listada

anteriormente.

String de busca "android” AND “web” AND "debugging" AND ("emulator" OR

"emulador") AND (“environment” OR "IDE" OR "ambiente")

Tabela 2: Primeira string de busca utilizada

Com a string de busca da Tabela 2, foram encontrados 3980 resultados no total

em maio de 2021, porém apenas dois trabalhos potencialmente relevantes (FRANÇA,
2019; GHATOL e PATEL, 2012), sendo apenas um que atende aos critérios de
inclusão/exclusão (FRANÇA, 2019). A partir desta string de busca foram localizados
trabalhos relacionados ao processo de debugging dentro do sistema operacional
Android e segurança do sistema, sem relação com o trabalho aqui proposto.
Então, decidiu-se por realizar uma nova busca com o intuito de localizar
trabalhos relacionados ao debugging no desenvolvimento de aplicações, utilizando a
string de busca a seguir:

String de busca “App Inventor” AND “live debugging”

Tabela 3: Segunda string de busca utilizada

Utilizando a string da Tabela 3, foram encontrados cinco resultados

(SCHILLER, ABELSON, et al., 2014; FRANÇA, 2019; CIORUȚA, COMAN e
CIORUTA, 2019; ABEYWARDENA, 2015; SIMPSON, 2015). Destes cinco, um deles
 33

(FRANÇA, 2019), já foi apresentado na busca anterior e o artigo de SCHILLER,

ABELSON, et al. (2014) foi incluído pois é relevante para a realização deste trabalho.
Por fim, foi realizada uma nova busca utilizando uma nova string de busca com
o objetivo de localizar trabalhos relacionados à linguagem YAIL e que permitam
compreender o processo de interpretação dentro do aplicativo Companion:

String de busca YAIL "Young Android Intermediate Language"

Tabela 4: Terceira string de busca utilizada

Com esta string, foram exibidos seis resultados, sendo um deles o artigo de
SCHILLER, ABELSON, et al. (2014) já listado anteriormente.
O resultado destas pesquisas não apresentou nenhum trabalho similar ao
proposto neste trabalho, com relação aos objetivos listados. Foram encontrados
trabalhos que apresentam informações sobre o App Inventor, guias de utilização ou a
realização de debugging, porém, nenhum com ambiente web.
Em busca realizada através do Google tradicional, não foram localizados
resultados com alguma relevância diferente dos já listados. Foram avaliados também
trabalhos de conclusão de curso de alunos do Departamento de Informática e
Estatística da UFSC que tratam de conceitos similares e, além do trabalho de
FRANÇA (2019) já listado, foi selecionado o trabalho de SPRANGER (2019).

3.2. ANÁLISE DOS RESULTADOS ENCONTRADOS

Entre os resultados apresentados foram analisados os seguintes trabalhos que

atenderam aos critérios de inclusão:
● Ambiente Web integrado com App Inventor para execução de aplicações
Android (FRANÇA, 2019)
● Live programming of mobile apps in App Inventor (SCHILLER,
ABELSON, et al., 2014)
● Ferramenta de Geração de Aplicativos Móveis Híbrido/Cross-platform
Baseada em Editor de Interface (SPRANGER, 2019)
 34

3.2.1. Ambiente Web integrado com App Inventor para execução de

aplicações Android

O trabalho desenvolvido por FRANÇA (2019) traz um ambiente web que é

executado como um emulador Android dentro do navegador, utilizando uma máquina
virtual para a execução do aplicativo Companion, permitindo que sejam realizados os
testes do código desenvolvido pelo App Inventor.

Figura 13: Arquitetura da solução (FRANÇA, 2019)

A comunicação entre o App Inventor e o ambiente de testes nesse trabalho é o

mesmo utilizado pelo próprio MIT Companion, já que o ambiente desenvolvido é um
emulador de Android que possui o Companion instalado. Sua interface é emulada no
navegador utilizando um AVD (Android Virtual Device - Dispositivo Virtual Android)
que é executado através do navegador. O trabalho foi desenvolvido em Python +
Django para o desenvolvimento do ambiente web.
Apesar de não ser um ambiente web, este trabalho apresenta objetivos
semelhantes e traz informações relevantes para o desenvolvimento do presente
projeto. Para esse trabalho, algumas funcionalidades não foram consideradas, como
GPS e acelerômetro, sendo que essas estão presentes nas outras ferramentas
encontradas no mercado. No entanto, a não utilização de tais sensores foi definida
nos requisitos para manter a criação da imagem do trabalho em tamanho minimalista.
 35

3.2.2. Live programming of mobile apps in App Inventor

Nesse artigo são descritas as funcionalidades do live programming do App

Inventor e explica como elas são implementadas, bem como as formas em que os
testes podem ser realizados. É demonstrado como o App Inventor é um ambiente de
programação para Android que utiliza a programação visual com o uso de blocos e é
usado por pessoas com pouca ou nenhuma experiência em programação.
O modo como a comunicação bidirecional com o Companion é realizada, para
a conexão entre as duas partes (navegador/dispositivo móvel ou seu emulador), que
é parte importante para a realização deste trabalho. A comunicação é assíncrona,
utilizando requisições AJAX.
Outra forma de realizar o live debugging é através de um cabo USB ou
utilizando um emulador, caso não seja possível realizar a conexão via WiFi. Para
ambos os casos não há necessidade de realizar a conexão com o servidor
Rendezvous.

3.2.3. Ferramenta de Geração de Aplicativos Móveis Híbrido/Cross-

platform Baseada em Editor de Interface

No trabalho realizado por SPRANGER (2019) foram avaliados conceitos,

devido ao seu objetivo de gerar o código a partir da aplicação apresentada em tela ser
o oposto ao deste, em que a tela será gerada dinamicamente a partir do código YAIL
enviado pelo App Inventor.
O desenvolvimento da interface do trabalho realizado por SPRANGER (2019)
foi realizado em React. Neste editor os componentes são incluídos e podem ser
arrastados de forma a gerar a interface gráfica similar a um smartphone. Ao finalizar
o desenvolvimento da interface de forma gráfica, é criado um projeto no padrão do
framework Flutter5.
Da mesma forma que o App Inventor gera aplicativos para Android, é possível
fazê-lo através do Flutter.

5
https://flutter.dev/
 36

Na solução proposta por SPRANGER (2019) é utilizado React Grid Layout6,

que permite o posicionamento de um componente React em um layout em grid. Este
componente pode ser arrastado ou redimensionado, mas também é possível utilizá-lo
para fixar de forma estática. Pelo fato de ser responsivo, é bastante útil nas aplicações
móveis e para o desenvolvimento de aplicações web.
Na Figura 14 é exibida a arquitetura da solução proposta pelo autor.

Figura 14: Arquitetura da solução (SPRANGER, 2019)

6
https://github.com/react-grid-layout/react-grid-layout
 37

Após a geração do arquivo com o código-fonte da aplicação criada pela

ferramenta desenvolvida por SPRANGER (2019), é possível visualizar a aplicação
Flutter gerada em um simulador iOS.

3.3. DISCUSSÃO

Os resultados encontrados atendem parcialmente às necessidades do projeto,

pois apesar de não se tratar especificamente de trabalhos voltados a criação de uma
ferramenta que utilize somente um navegador web, sem utilização de emuladores, os
conceitos aplicados e a forma como foram desenvolvidos colaborou com a
compreensão do App Inventor.
 38

4. ANÁLISE E PROJETO

Neste capítulo é apresentada a análise e projeto para o desenvolvimento da

aplicação LIDEA-w (web LIve DEbugging for App inventor). São apresentados os
requisitos funcionais e não funcionais, a modelagem e proposta de solução.

4.1. REQUISITOS

Para o levantamento dos requisitos foram analisados os aspectos necessários

para a realização da conexão do App Inventor com o aplicativo AI2 Companion. A
partir desta avaliação, foram criados os requisitos funcionais e não funcionais para o
desenvolvimento desta aplicação.
Os requisitos funcionais estão listados na tabela 5.

ID Requisito Descrição
O sistema deve permitir ao
O usuário deve ter a possibilidade de inserir a
usuário inclusão da chave de 6
RF01 caracteres gerada no App
chave de 6 caracteres para que seja realizada
a conexão com o servidor Rendezvous.
Inventor
A aplicação deve, com a chave de 6
O sistema deve realizar a
caracteres, conectar ao servidor Rendezvous
RF02 conexão entre a aplicação e o
para realizar o handshake entre os pontos,
servidor Rendezvous
habilitando a conexão.
O sistema deve permitir o
recebimento de código YAIL Ao receber o código YAIL, após a realização
RF03 para geração dinâmica de tela da conexão, este código deve ser processado
com base no código criado no para exibição na tela.
App Inventor
O sistema deve realizar a Com o processamento dos dados recebidos
conversão do código YAIL do App Inventor, deve ser realizada a
RF04 recebido em componentes conversão dos comandos em componentes
React para geração dinâmica de React dinâmicos, baseados nos comandos
tela YAIL.
O sistema deve exibir em tela,
Com a geração dos componentes dinâmicos,
no LIDEA-w, os itens criados no
RF05 estes devem ser exibidos em tela, de acordo
App Inventor, nas posições onde
com aplicativo criado no App Inventor.
foram criados.
 39

O usuário deve, além de ter a reprodução

O sistema deve permitir os
visual, executar as ações desenvolvidas na
testes com execução dos
RF06 tela onde são criados os comandos em
comandos desenvolvidos em
blocos. Os comandos executáveis estão
blocos
listados dentro do escopo de aplicação.
Tabela 5: Requisitos funcionais do LIDEA-w

ID Requisito Descrição
O sistema é uma plataforma web, sendo
O sistema deve ser executado em assim, deve ser executado em um
RNF01 navegadores web navegador Chrome versão 90 ou superior,
sem restrição de sistema operacional.
A aplicação deve ser executada em
O sistema deve ser executado em
computadores onde a tela possui resolução
RNF02 telas com resolução mínima de
superior a informada para que todos os
1024x768 pixels
elementos estejam visíveis.
A aplicação deve ser executada em qualquer
O sistema deve ser executado
navegador, sem que haja a necessidade da
RNF03 sem necessidade de instalação
execução de outro software ou plugin
de outros softwares ou plugins
adicional.
Tabela 6: Requisitos não-funcionais do LIDEA-w

4.2. MODELAGEM E PROPOSTA DE SOLUÇÃO

A solução proposta para o problema consiste no seguinte (Figura 15):

1. O usuário inicia a sessão. A partir deste momento é exibida

a tela onde o usuário incluirá a chave de 6 caracteres exibida no App
Inventor;
2. O usuário inicia a conexão no App Inventor, através do
menu “Conexão” e seleciona o AI2 Companion;
3. O sistema gera a chave de 6 caracteres. Essa chave
deverá ser preenchida na tela do LIDEA-w;
4. Enquanto o App Inventor gera a chave de 6 caracteres, é
também iniciada a comunicação com o servidor Rendezvous,
informando o IP de onde é executada a aplicação, registrando a sessão;
5. O usuário insere a chave de 6 caracteres no LIDEA-w;
 40

6. Após inserir a chave de 6 caracteres, o LIDEA-w registra a

sessão juntamente ao servidor Rendezvous;
7. Com o registro das duas sessões, utilizando a mesma
chave de 6 caracteres, o servidor retorna a mensagem OK, autorizando
a conexão entre os dois dispositivos;
8. O App Inventor já pode se comunicar diretamente ao
LIDEA-w, enviando as informações do aplicativo desenvolvido e que
será testado;
9. O LIDEA-w exibe dinamicamente o conteúdo recebido do
App Inventor.

Nas figuras 15 e 16 são demonstrados o diagrama geral da solução e os

componentes desenvolvidos no LIDEA-w.

Figura 15: Diagrama geral da solução (Elaborado pelo autor)

 41

Figura 16: Componentes da solução (Elaborado pelo autor)

Assim, os principais componentes da solução proposta (Figura 16) são:

- App Inventor: responsável pela geração de aplicativos,
utilizando um ambiente de programação em blocos. Também permite a
realização de debugging do código gerado através do aplicativo Companion,
de emuladores ou via USB utilizando um dispositivo Android;
- Servidor Rendezvous: responsável por realizar o handshake
entre dois pontos (App Inventor e LIDEA-w, no caso deste trabalho) e permitir
a conexão direta entre ambos;
- LIDEA-w: a aplicação objetivo deste trabalho faz o trabalho do
aplicativo Companion, em ambiente web, com algumas restrições, conforme
descrito no capítulo 1. Entre os módulos presentes na aplicação estão os
seguintes módulos:
- Módulo de Comunicação: responsável por realizar a
comunicação com o servidor Rendezvous para realizar a conexão
com o App Inventor, efetuando a leitura do código inserido na tela,
enviando para o servidor e retornando o resultado da solicitação
 42

de conexão. Composto pelo front-end para a inserção da chave

de 6 caracteres e pelo back-end para comunicação e handshake
com o servidor Rendezvous;
- Módulo de Geração dinâmica da interface: responsável por,
após a conexão com o App Inventor, receber os comandos YAIL,
interpretá-los e apresentar na tela, de acordo com os dados
recebidos.

4.3. PROTÓTIPOS DE TELA

Nesta seção são apresentados os protótipos de tela a serem desenvolvidos, de

forma a atender a solução proposta, conforme apresentado na Figura 14. Os
protótipos são apresentados agrupados de acordo com os passos da solução
proposta.

1. Iniciar Sessão
Na tela da Figura 17, o usuário acessa a tela inicial da plataforma para que seja
iniciada a sessão que permitirá a conexão do LIDEA-w ao servidor Rendezvous.
 43

Figura 17: Protótipo da aplicação: Tela inicial (Elaborado pelo autor)

2. Inserir código
Na tela da Figura 18, o usuário insere a chave de 6 caracteres exibida na tela
do App Inventor, e ao clicar em Iniciar conexão, é realizada a comunicação com o
Rendezvous. Assim que confirmado o handshake entre as duas partes, a
comunicação direta é estabelecida, permitindo que o App Inventor passe a enviar
automaticamente as alterações realizadas na tela para o LIDEA-w.
 44

Figura 18: Protótipo da aplicação: Iniciar conexão (Elaborado pelo autor)

3. Geração dinâmica das telas

Na tela da Figura 19 é exibido conteúdo recebido do App Inventor, já convertido
em conteúdo dinâmico React, para permitir a execução e teste do aplicativo
desenvolvido no App Inventor, consideradas as devidas limitações apresentadas no
capítulo 1 deste trabalho.
 45

Figura 19: Protótipo da aplicação: Em execução (Elaborado pelo autor)

A partir da modelagem da solução proposta neste capítulo, no capítulo 5 é

apresentada a implementação da ferramenta LIDEA-w.
 46

5. IMPLEMENTAÇÃO

Este capítulo apresenta o desenvolvimento do sistema LIDEA-w, passando

pela análise dos protocolos de comunicação do App Inventor, a implementação dos
componentes visuais e os testes realizados no sistema.
Uma das maiores complexidades técnicas do presente trabalho consiste no
entendimento do protocolo de comunicação do App Inventor com o Companion.
Assim, no sentido de minimizar os riscos técnicos, o desenvolvimento foi iniciado com
uma iteração de investigação dos protocolos e tecnologias envolvidas.

5.1. ENGENHARIA REVERSA

Para o início da implementação da aplicação, a documentação do App Inventor

foi analisada para localizar as classes responsáveis pela comunicação com o
aplicativo AI2 Companion.
Com a análise da documentação e da estrutura da aplicação, foi necessário
realizar a leitura do código de algumas classes que possuem relação com a conexão
com o AI2 Companion. Através da classe TopToolbar.java foi possível localizar a
função responsável pelo início da conexão com o dispositivo móvel.

Figura 20: Código da classe TopToolbar.java onde é iniciada a conexão (Elaborado pelo autor)
 47

A função cria uma nova WirelessAction() que verifica se é possível conectar a

um emulador ou dispositivo, caso um projeto tenha sido selecionado. Em seguida
ocorre a chamada da função startRepl, que, em todas as classes que a utilizam,
referem-se a Blockly.ReplMgr.

Figura 21: Classe WirelessAction() que realiza a chamada da função startRepl (Elaborado
pelo autor)

Este comando está presente no arquivo replmgr.js e é este arquivo o

responsável por estabelecer a comunicação do App Inventor com o servidor
Rendezvous, conforme Figura 22, que demonstra a função getFromRendezvous(). É
neste arquivo que estão os comandos para geração do QR Code e da chave de 6
caracteres.
 48

Figura 22: Função getFromRendezvous() exibindo processo realizado para conexão com o
servidor Rendezvous() (Elaborado pelo autor)

Foram incluídas linhas nesta função para exibição do conteúdo em console com
o intuito de identificar o conteúdo recebido e enviado para o servidor. O resultado de
alguns dos comandos exibidos no console é exibido na Figura 23:
 49

Figura 23: Comandos exibidos no console do navegador (Elaborado pelo autor)

Com o log nas ferramentas do desenvolvedor foi possível analisar o código

YAIL e analisar como é realizada a comunicação do App Inventor com o AI2
Companion. A primeira análise realizada foi do código YAIL, para que a ferramenta
LIDEA-w pudesse ser desenvolvida. Ao fim da análise do código e criação da
ferramenta, deu-se início ao desenvolvimento da comunicação com o servidor.

5.1.1. Análise do código YAIL

Para o desenvolvimento da ferramenta, foi realizada extensa análise do

código YAIL enviado pelo App Inventor. Este código é exibido no console do
navegador, através das ferramentas do desenvolvedor, conforme figura 24:
 50

Figura 24: Log do console no navegador, nas ferramentas do desenvolvedor (Elaborado

pelo autor)

O código YAIL gerado pelo App Inventor é enviado em um comando único

onde a primeira parte do código refere-se à interface gerada, com as posições, cores,
tamanho e demais propriedades de cada componente. A segunda parte refere-se aos
comandos em bloco que serão executados de acordo com as ações executadas.
 51

Para identificação do que representa cada comando do código YAIL, foi criado
um aplicativo simples que exibe um nome digitado no texto. Foram também criados
comandos em blocos a fim de reconhecer a estrutura de cada bloco em YAIL e
convertê-la em comandos JavaScript.
No aplicativo simples criado como exemplo foram definidas propriedades
referentes à exibição da tela, posicionamento dos campos e sua estrutura, além de
definir as ações ocorridas ao clicar nos botões.

Figura 25: Interface do aplicativo criado no App Inventor (Elaborado pelo autor)

A figura 25 exibe a interface do aplicativo criado e a figura 26 demonstra a sua

estrutura no App Inventor:
 52

Figura 26: Estrutura do aplicativo criado no App Inventor (Elaborado pelo autor)

Na tabela 7 os componentes estão listados de acordo com a estrutura da

figura 26, onde na coluna Componente está indicado o nome de cada componente:
Componente Tipo
Screen1 Tela principal com nome
VA1 Componente de layout do tipo VerticalArrangement
TextBox1 Componente de interface do tipo TextBox
Label1 Componente de interface do tipo Label
Button1 Componente de interface do tipo Button
Tabela 7: Demonstração da estrutura do aplicativo criado no App Inventor por tipo

O código YAIL enviado possui um padrão, onde a primeira parte do código

enviado é referente aos componentes visuais e a segunda é referente aos códigos em
bloco. O início da parte referente aos componentes visuais é composto por um
comando do-after-form-creation que é responsável por iniciar a criação de uma tela.
Os comandos em bloco são listados após um comando (init-runtime).
A figura 27 exibe um exemplo de código YAIL de criação de tela e a tabela 8
a seguir exibe a representação dos comandos e sua definição:

Figura 27: Código YAIL para a criação de uma tela (Elaborado pelo autor)

Comando YAIL Definição

do-after-form-creation Criação de uma nova tela
set-and-coerce-property! Define a propriedade de um item
'Screen1 Nome da tela
 53

'ActionBar #t ‘boolean Refere-se a uma propriedade da tela criada e seu valor

AppName Propriedade da tela
ShowListsAsJson Propriedade da tela
Sizing Propriedade da tela
Theme Propriedade da tela
Title Propriedade da tela
#t ‘boolean Indica o valor true para um campo. Caso o campo seja false,
a linha referente ao campo não é enviada
‘text Indica que o valor enviado é do tipo “texto”
Tabela 8: Código YAIL para a criação de tela e sua definição

Nos comandos listados na Tabela 8 estão apresentados comandos similares,

estes referem-se a propriedades listadas no App Inventor para a tela, como o nome
do aplicativo. Estas propriedades podem definir cores, tamanhos, versão do aplicativo
criado, alinhamento dos componentes na tela, entre outros valores.
Na figura 28 é exibida a continuação do código YAIL enviado, onde é
adicionado um componente do tipo VerticalArrangement, suas propriedades e
adicionado um outro componente dentro deste VerticalArrangement. Na tabela YY é
apresentada a definição de cada parte do código enviado.

Figura 28: Código YAIL com a adição de componentes na tela (Elaborado pelo autor)

A tabela 9 exibe a definição do código YAIL enviado para a adição de

componentes
Comando YAIL Definição
add-component Screen1 Indica a adição de um componente dentro da tela de nome
Screen1
com.google.appinventor.components. Indica o arquivo .java no App Inventor onde estão todas as
runtime.VerticalArrangement funcionalidades do componente do tipo VerticalArrangement
VA1 Nome do componente de layout do tipo VerticalArrangement
(definido pelo usuário)
 54

set-and-coerce-property! Define a propriedade de um item

'VA1 Indica o item a ter a propriedade modificada
'AlignHorizontal Propriedade da tela
3 'number Valor para a propriedade da tela, do tipo “número”
'BackgroundColor Propriedade da tela
'Width -2 'number Propriedade, valor e tipo do valor
add-component VA1 Indica a adição de um componente dentro de um
componente de layout
com.google.appinventor.components. Indica o arquivo .java no App Inventor onde estão todas as
runtime.TextBox funcionalidades do componente TextBox
Tabela 9: Código YAIL para adição de componentes

Conforme exibido na figura 26, além da tela, somente os componentes de

layout, listados na tabela 9, permitem o aninhamento de componentes.
Com a identificação dos comandos em YAIL para a exibição dos
componentes, iniciou-se a análise dos comandos em blocos. Para o aplicativo de
exemplo criado inicialmente, conforme a figura 25, foram criados os seguintes blocos
de comando, conforme figura 29:

Figura 29: Comandos em bloco criados para o aplicativo (Elaborado pelo autor)

Estes blocos geraram o código YAIL exibido na figura 30:

Figura 30: Comandos em bloco em código YAIL (Elaborado pelo autor)

Ao analisar o código enviado, foi identificada a estrutura dos comandos,

apresentada na tabela 10:
 55

Comando YAIL Definição

init-runtime Identifica o início de um comando em bloco
define-event Define o início de um evento
Button1 Informa em qual componente será executada a ação
Click() Evento que será iniciado, neste exemplo, quando o usuário
clicar no botão Button1
set-this-form Indica o início da ação
if Início do comando de bloco de estrutura condicional
call-yail-primitive Indica uma ação a ser realizada
yail-equal? Ação realizada, neste caso, comparação de valores
*list-for-runtime* Indica o início da listagem dos valores a serem comparados
get-property 'TextBox1 'Text Inicia a busca pelo valor de um campo, no caso, no
componente TextBox1, do tipo “texto”, sendo o primeiro valor
da comparação
"" Segundo valor da comparação, se o campo TextBox1 estiver
vazio
any any Indica que os campos a serem comparados podem ser de
qualquer tipo
= Indicador da ação para comparação
begin Início das ações a serem executadas dentro do bloco
condicional
set-and-coerce-property! Indicação de propriedade/valor a ser definido
'Label1 'Text Ação executada no componente Label1 do tipo “texto”
"Ol\u00e1, estranho!" ‘text String preenchida no texto, caso o campo esteja vazio. Os
caracteres acentuados são enviados em Unicode
begin Início da ação a ser realizada no comando else
set-and-coerce-property! Indicação de propriedade/valor a ser definido
'Label1 'Text Ação executada no componente Label1 do tipo “texto”
call-yail-primitive Indica uma ação a ser realizada
string-append Ação realizada para juntar duas strings
*list-for-runtime* Indica o início da listagem dos valores a serem unidos
"Ol\u00e1, " Primeiro valor a ser incluído na String
get-property 'TextBox1 'Text Busca pelo valor do componente TextBox1
text text Indica que ambos os campos são do tipo
join Indicador da ação para junção das strings
‘text Indica que o valor enviado é do tipo “texto”
call-Initialize-of-components Informa a inicialização dos componentes na tela
Tabela 10: Código YAIL gerado para comandos em bloco

O código YAIL será convertido para um código JavaScript similar ao

apresentado na figura 31:
 56

Figura 31: Comandos em bloco em código JavaScript (Elaborado pelo autor)

5.1.2. Conexão com o servidor Rendezvous

A comunicação com o servidor Rendezvous é realizada pelo App Inventor

através do arquivo replmgr.js. Neste arquivo estão listados os comandos e funções
para que seja realizado o envio de objeto JSON para o servidor Rendezvous com os
dados do App Inventor (chave de 6 dígitos e seu hash, IP). Após o handshake, o envio
dos códigos YAIL para dispositivo é feito para o AI2 Companion.
A parte responsável pela conexão com o servidor Rendezvous é apresentada
na figura 32.
 57

Figura 32: Comando responsável pela conexão com o celular no arquivo replmgr.js
(Elaborado pelo autor)

Após a realização da conexão do App Inventor com o servidor Rendezvous, o

servidor aguarda o envio da chave de 6 caracteres pelo AI2 Companion, para que seja
realizado o handshake e a sessão seja iniciada.
No código do AI2 Companion, presente no código fonte do App Inventor, o
arquivo PhoneStatus.java é o responsável por converter a chave de 6 caracteres
em um hash e por obter os dados de conexão do dispositivo que são usados no
arquivo ReplForm.java. Nesse arquivo também estão os comandos que verificam
se a conexão está sendo realizada via Wi-Fi (importante para a realização da conexão
com o Rendezvous).
Com as informações do dispositivo, a conexão é realizada através dos
comandos presentes no arquivo WebRTCNativeMgr.java. Nesse arquivo estão
listadas as funções responsáveis pelo envio de dados para o handshake no servidor
 58

Rendezvous. Se a conexão for bem-sucedida, o envio de código YAIL para o AI2

Companion é realizada pelo arquivo ReplForm.java, que envia o código YAIL e
informações necessárias para exibição do ao aplicativo criado no App Inventor e
código YAIL atualizado, caso haja alguma alteração no App Inventor.
Com estas informações, foi analisado o arquivo rendezvous.js, para
compreender quais são os dados recebidos no servidor e como é feita esta requisição.
O servidor Rendezvous recebe uma requisição do tipo POST com os dados recebidos
tanto pelo App Inventor, quanto pelo AI2 Companion, validando dos dados recebidos
pelo servidor e caso estejam de acordo, permite a conexão entre as partes.

Figura 33: Código do arquivo rendezvous.js para validação da conexão do Companion

(Elaborado pelo autor)

Para melhor compreensão, foi também analisado o envio dos dados do App
Inventor nas ferramentas do desenvolvedor do navegador web. Na aba “Rede” são
listados os pacotes enviados e através destes pacotes foram identificados os dados
enviados e recebidos pelo App Inventor. Para que estes dados fossem visualizados,
foi necessário selecionar a opção “Use Legacy Connection”, na tela inicial do AI2
Companion no aparelho celular.
 59

Até que a chave seja inserida no AI2 Companion, o App Inventor envia a cada
segundo, o hash da chave de 6 caracteres, para o Rendezvous. Assim que ela é
inserida pelo usuário, o Rendezvous realiza o handshake e após a validação, o App
Inventor passa a enviar pacotes com dados e o código YAIL para o AI2 Companion.

Figura 34: Aba da ferramenta do desenvolvedor com os pacotes enviados pelo App Inventor
(Elaborado pelo autor)

Com essas informações foi possível realizar o desenvolvimento do servidor

back-end responsável pelo recebimento da chave de 6 dígitos, bem como do código
YAIL para exibição do aplicativo criado no App Inventor na plataforma LIDEA-w

5.2. DESENVOLVIMENTO DA PLATAFORMA LIDEA-w

Para o desenvolvimento da aplicação, tanto back-end quanto front-end foi

utilizado o Visual Studio Code7, por sua facilidade de uso, amplo suporte a extensões
e linguagens de programação.

7
https://code.visualstudio.com/
 60

5.2.1. Desenvolvimento da interface

Após a análise dos códigos YAIL enviados pelo App Inventor, foi iniciada a
construção da plataforma LIDEA-w. A primeira parte realizada foi a criação do
esqueleto da aplicação. A estrutura inicial do projeto foi criada utilizando o comando
padrão para criação de aplicações em React. Esta estrutura inicial foi alterada para a
criação da interface da plataforma, de acordo com o protótipo exibido na figura 19,
ainda sem os componentes.
Com a interface definida, foram criados os componentes React baseados nos
componentes listados no App Inventor, do tipo User Interface e Layout, seguindo a
mesma nomenclatura para fácil identificação. Por limitações de tempo do projeto de
TCC e também por dificuldades técnicas de compreensão dos códigos YAIL, foram
priorizados os componentes visuais do App Inventor para implementação, tornando
possível a futuros trabalhos a continuidade do desenvolvimento. Assim, os demais
componentes do App Inventor não fazem parte do escopo deste trabalho.
Na tabela 11 estão listados os componentes que foram convertidos em
componentes React e os que não foram concluídos.

Tipo de componente Componentes implementados Componentes fora do escopo

Button Image
Checkbox ListView
DatePicker Notifier
Label
ListPicker
PasswordTextBox
User Interface
Slider
Spinner
Switch
TextBox
TimePícker
WebViewer
HorizontalArrangement HorizontalScrollArrangement
Layout TableArrangement VerticalScrollArrangement
VerticalArrangement
Tabela 11: Componentes visuais criados e componentes fora do escopo

Os componentes React criados inicialmente não possuíam nenhuma

propriedade, apenas um valor estático. A figura 35 demonstra o valor inicial do
componente Button.
 61

Figura 35: Código inicial do componente Button (Elaborado pelo autor)

A estrutura do projeto após a criação de todos os componentes é exibida na

figura 36:

Figura 36: Estrutura inicial do projeto com componentes (Elaborado pelo autor)
 62

5.2.2. Desenvolvimento do back-end

Após a criação da estrutura inicial do projeto, foi iniciada a criação do back-end

para a persistência do código YAIL em um local que permitisse seu acesso futuro.
Para isso foi criado um servidor Node.JS.
Com a criação do servidor Node.JS e criação de rotas, foi possível utilizar o
servidor como fonte do JSON enviado pelo App Inventor, com os componentes e
blocos. Para o envio das requisições para o servidor foi utilizado o programa
Postman8. O Postman é um cliente que facilita a criação e teste de interface de
programação de aplicação (API) (POSTMAN, 2022).
Um objeto importante identificado na análise dos logs de comunicação do App
Inventor por meio da ferramenta do desenvolvedor é o ReplState, pois nele são
enviadas as informações de componentes, blocos, bem como os dados do dispositivo
que o Companion está conectado, após o handshake no servidor Rendezvous.

8
https://www.postman.com/
 63

Figura 37: Comando ReplState enviado pelo App Inventor para o Companion (Elaborado
pelo autor)

Por estar formatado como um objeto JSON, o ReplState foi utilizado para
envio para o servidor do back-end.
 64

Figura 38: Comando ReplState formatado para envio no Postman (Elaborado pelo autor)

Com o recebimento deste objeto no back-end, foi analisado o que seria

importante para o desenvolvimento da aplicação, sendo mantidos dois valores:
blockYail e componentYail, pois mantém a divisão dos componentes e dos
comandos em bloco.
O servidor back-end criado também é o responsável pelo envio da chave de 6
caracteres para o servidor Rendezvous. Para que a conexão fosse possível, foi criada
uma rota que recebe a chave de 6 caracteres digitada pelo usuário e converte-a em
um hash, utilizando o algoritmo SHA1.
Para o envio para o servidor Rendezvous, é feita uma requisição POST
incluindo os seguintes pares chave-valor no corpo da requisição, conforme listados
abaixo:
• ipaddr: o IP do equipamento que receberá os comandos do App
Inventor. Definido dinamicamente no envio da requisição;
• port: a porta associada ao IP, esta é por padrão 8001, conforme o
código presente no arquivo replmgr.js;
 65

• webrtc: este valor indica se a API será utilizada para a comunicação.

Neste trabalho o seu valor será fixo como false;
• version: este valor refere-se à versão do aplicativo AI2 Companion e
está salvo no arquivo SystemVariables.env da aplicação LIDEA-
w, sendo necessária sua atualização caso o aplicativo seja atualizado
na Play Store;
• api: refere-se a versão da API do Android, também salvo no arquivo
SystemVariables.env, sendo necessário atualizar futuramente,
quando a API presente neste trabalho tornar-se obsoleta;
• installer: valor fixo referente ao pacote do aplicativo da Play Store;
• aid: é um número de identificação único referente ao equipamento
onde o AI2 Companion está instalado no padrão UUID. Para este
trabalho o valor gerado será um novo UUID a cada requisição;
• r2: valor fixo, definido como true

Nos headers enviados nesta requisição, o Content-Type enviado é do tipo

application/x-www-form-urlencode, pois o corpo da mensagem é uma longa
string, que usa pares chave-valor, separados por “&” com um “=” (MOZILLA, 2022).
Após o handshake, os dados do App Inventor são enviados para 3 rotas
distintas:
• _extensions: retorna uma mensagem vazia;
• _newblocks: retorna uma mensagem com status = OK e um payload
com o código YAIL da aplicação;
• _values: retorna uma mensagem com status = OK e seu payload é
ignorado. Se houver alteração no aplicativo desenvolvido no App
Inventor, a requisição efetuada para esta rota é responsável por
informar.

Com os valores recebidos da rota _newblocks, o código YAIL está pronto

para ser utilizado na aplicação.
 66

5.2.3. Conversão de YAIL em objeto JSON para componentes visuais

A partir do objeto criado no back-end foi necessário converter o código YAIL

em um novo objeto que pudesse ser lido de forma dinâmica para a exibição dos
componentes em tela. Pelo fato de seguir um padrão comum a todos os componentes,
os componentes visuais do App Inventor foram convertidos no objeto JSON
components.
Assim, foi criada uma classe com um dicionário para que cada componente
fosse reconhecido durante o parse do código YAIL, além de comandos comuns para
identificação dentro da string.

Figura 39: Dicionário criado para parse dos componentes (Elaborado pelo autor)

Em seguida foram criadas funções para que o código YAIL seja percorrido e
identificado cada componente. O resultado é um array de objetos JSON que lista o
tipo dos componentes, seus nomes e suas propriedades e se os seus componentes-
pai são a tela principal ou algum componente de layout. A posição é definida pelo tipo
de componente de layout e pela chave-valor parentIsScreen, se o componente
 67

está dentro da tela principal (parentIsScreen = true) ou componente de layout

(parentIsScreen = false)

Figura 40: Objeto JSON com as propriedades de um componente (Elaborado pelo autor)

Com a listagem dos componentes em um array, foi criada uma função que lista
todos os componentes em tela. Com esta função, os primeiros componentes foram
exibidos dentro do espaço definido e na ordem definida, porém sem estilização e sem
conteúdo dinâmico.

Figura 41: Componentes listados de forma dinâmica (Elaborado pelo autor)

 68

Como é possível definir diferentes propriedades para cada componente dentro

do App Inventor, é importante que estas características sejam reproduzidas dentro do
LIDEA-w. Para a estilização de cada componente foi utilizada a biblioteca de
estilização MUI9.
MUI ou Material-UI é uma biblioteca de componentes baseada para a criação
de interfaces em aplicações React (MUI, 2022). Criada em 2014 para unificar a criação
de aplicações em React ao Material Design10 (guia para estilização criado pela
Google) (MUI, 2022).

5.2.4. Conversão de YAIL para execução dos comandos em bloco

Seguindo a mesma lógica implementada para a criação de objetos JSON com

os componentes visuais, foram criados objetos JSON para que fossem listadas as
variáveis globais e os comandos em bloco que executarão ações nos componentes.
No array de objetos JSON “variables” são listados os nomes das variáveis
globais e seus respectivos valores iniciais. A figura 42 exibe um exemplo de um array
com variáveis globais.

Figura 42: Array de objetos JSON com variáveis globais (Elaborado pelo autor)

O array de objetos JSON blocks traz os blocos de comando, sendo que neste
objeto, os comandos permanecem em YAIL. Estes comandos serão convertidos em

9
https://mui.com/
10
https://material.io/
 69

JavaScript apenas no momento de execução de algum comando realizado pelo

usuário.

Figura 43: Exemplo de objeto baseado nos comandos em bloco (Elaborado pelo autor)

5.2.5. Conversão de YAIL em JavaScript executável

Com a listagem de todos os comandos, foi iniciado o processo de conversão

do código YAIL em JavaScript. Como o YAIL se trata de uma implementação
específica de Kawa, não foi possível utilizar nenhuma biblioteca já existente que
realizasse a conversão de Kawa para JavaScript. Sendo assim foi necessário
implementar a conversão de YAIL para JavaScript manualmente, criando cada um dos
possíveis blocos listados, a fim de identificar sua estrutura, posição inicial e final de
cada um.
Foi então criada uma função no arquivo componentActionHelper.js,
utilizada por todos os componentes, que usa o array de variáveis e de comandos que
executa a conversão do código YAIL em uma string com código em sequência que
será executado como JavaScript a partir da função eval. A função eval é uma função
de propriedade global que recebe como argumento uma string, avalia e, se for uma
expressão JavaScript válida, executa o comando (MOZILLA, 2022).
No arquivo commandParser.js estão as funções que fazem a conversão em
declarações que serão executadas. As funções criadas já realizam as validações,
busca por valores respectivos, bem como comparações, retornando o resultado da
comparação com os valores true ou false.
 70

Figura 44: Comando em bloco no App Inventor (Elaborado pelo autor)

A figura 44 exibe o comando em bloco criado no App Inventor e a figura 45

exibe a string gerada a partir da conversão em JavaScript.

Figura 45: Comando em bloco convertido em string a ser executada como JavaScript
(Elaborado pelo autor)

Na tabela 12 estão listados os comandos em bloco que não foram convertidos

em comandos JavaScript.

Tipo de comando Comandos convertidos Comandos que não foram criados

If.. then For each number from - to - by
If... then... else For each item in list
If... then... else if… then… else For each key with value in dictionary
While test do
Evaluate but ignore result
Open another screen
Open another screen with start value
Control
Get start value
Close screen
Close screen with value result
Close application
Get plain start text
Close screen with plain text
Break
Logic Todos os comandos convertidos
Math Todos os comandos convertidos
Join Obfuscated text
Text Length Replace all mappings in text
 71

Is empty
Compare texts
Trim
Upcase/Downcase
Starts at text... piece
Contains text... piece
Split text... at
Split at spaces
Segment text... start... length
Replace all text... segment
Is a string
Reverse
Lists Nenhum comando convertido
Dictionaries Nenhum comando convertido
Colors Criada função para converter
Initialize global variable Set variable
Variables Get variable
Initialize local variable
Procedures Nenhum comando convertido
Tabela 12: Comandos em bloco convertidos e que não foram convertidos

Devido à complexidade de sua estrutura baseada em parênteses, alguns

códigos YAIL referentes aos comandos em bloco enviados pelo App Inventor tornaram
difícil a conversão em JavaScript.
A partir da conversão dos comandos em bloco em JavaScript foi possível
tornar a aplicação funcional e executável, dadas as limitações de escopo e dos
comandos que foram convertidos.
O código-fonte da aplicação desenvolvida está disponível em:
<https://codigos.ufsc.br/gqs/lidea-w>

5.3. TESTES FUNCIONAIS

Devido às limitações impostas pela pandemia de COVID-19 não foi possível

realizar um estudo de caso para avaliação dos requisitos implementados e dos
impactos do uso do sistema no ensino do pensamento computacional.
No entanto, como parte do processo de desenvolvimento, os requisitos
funcionais e não-funcionais identificados foram avaliados por meio de testes
funcionais. Para a realização dos testes funcionais foi desenvolvida uma aplicação-
modelo em App Inventor.
 72

5.3.1. Aplicação Modelo

A aplicação-modelo para a realização dos testes simula uma aplicação que

poderia ser desenvolvida em um curso de ensino do pensamento computacional. A
aplicação escolhida para os testes foi uma calculadora simples.
Como possível contexto de uso dessa aplicação-modelo, pode-se imaginar um
cenário típico das atividades desenvolvidas pela Iniciativa Computação na Escola:
uma oficina de introdução à programação com App Inventor, realizada para
estudantes do Ensino Fundamental II como atividade em contraturno escolar. Os
estudantes não precisariam de conhecimentos prévios e durante a oficina
aprenderiam conceitos introdutórios de algoritmos e programação utilizando App
Inventor.
A figura 46 mostra a aplicação da calculadora.

Figura 46: Aplicação modelo gerada no App Inventor (Elaborado pelo autor)

Para o funcionamento da calculadora, foram gerados blocos para captura do

clique de cada botão listado.
 73

Figura 47: Comando em bloco para o clique em um botão numérico (Elaborado pelo autor)

A figura 47 exibe um comando em bloco para o clique em um botão numérico,

neste caso, o número 1. Foram criados dez blocos iguais a este em que a numeração
varia de 0 a 9, de acordo com o respectivo botão. Nestes blocos é verificado se, ao
digitar um número e não houver nenhuma operação preenchida no campo textual
específico, o valor digitado é preenchido no primeiro campo, tornando-o o primeiro
operando. Se o operador estiver preenchido, os números representarão o segundo
operando, assim, seguindo a lógica das operações realizadas matematicamente.
Com a utilização Procedures, que funcionam como funções, e permitem a
utilização de parâmetros, evita-se a repetição de comandos em blocos, como os
apresentados na figura 47 que se repetem nos botões de 0 a 9, porém, neste trabalho,
por limitações do escopo, as Procedures não foram implementadas.
Para a apresentação das operações matemáticas, assim que o usuário clica na
operação, ela é exibida em um campo textual próprio, conforme figura 48.
 74

Figura 48: Código em bloco para as operações (Elaborado pelo autor)

A figura 49 exibe os comandos executados quando o usuário clica no botão “=”

para exibição do resultado da operação.
 75

Figura 49: Comandos em bloco para exibição do resultado da operação (Elaborado pelo
autor)

Na figura 50 é apresentado o comando executado ao clicar no botão “C” para

limpar a tela, apagando operandos, a operação e o resultado prévios.

Figura 50: Comandos em bloco para limpeza dos campos da tela (Elaborado pelo autor)

A figura 51 mostra a aplicação exibida no LIDEA-w, após o recebimento do

código:
 76

Figura 51: Aplicação exibida no LIDEA-w (Elaborado pelo autor)

O projeto da aplicação modelo em formato .aia está disponível para download

em: <https://bit.ly/3L7J0CO>

5.3.2. Validação dos Requisitos

Os testes funcionais do sistema foram realizados pelo próprio autor, utilizando

o aplicativo de calculadora para validar os requisitos definidos.
Para o levantamento dos requisitos foram analisados os aspectos necessários
para a realização da conexão do App Inventor com o aplicativo AI2 Companion. A
partir desta avaliação, foram criados os requisitos funcionais e não funcionais para o
desenvolvimento desta aplicação.
Os requisitos funcionais e as respectivas evidências de teste estão listados na
tabela 13.
 77

Requisito Evidência

Criada tela para a inclusão da chave de 6 caracteres, exibida no App Inventor e

RF01
envio para o back-end

Criado do servidor back-end para recebimento da chave digitada e realização de

RF02
conexão com o servidor Rendezvous

Com a criação do servidor back-end para envio da chave, foi tratada a resposta
RF03
enviada pelo servidor, recebendo o código YAIL do App Inventor com sucesso

O código YAIL recebido no back-end é convertido em objetos JSON manipulados

RF04
na aplicação e que permitem a geração de componentes React dinamicamente

Através dos objetos JSON e recursão no código-fonte da aplicação foi possível

RF05
manter os objetos na mesma posição definida no App Inventor

Após extensa análise do código YAIL foi possível converter os comandos em bloco
RF06
em código JavaScript, convertido em tempo de execução da aplicação.
Tabela 13: Evidências dos testes de requisitos funcionais do LIDEA-w

Durante a criação da aplicação, os requisitos foram validados. Após a criação

do servidor back-end que permitiu a conexão com o servidor Rendezvous foi criada a
tela para inserção da chave de 6 caracteres, conforme RF01.

Figura 52: Demonstração da tela criada para inserção da chave de 6 caracteres (Elaborado
pelo autor)
 78

Após a inserção do código, a ferramenta aguarda o recebimento dos dados.

Assim que recebidos são tratados e então apresentados na tela, conforme figura 51,
validando requisitos RF02, RF03, RF04 e RF05.
Com os componentes em tela, foi possível validar o RF06, testando as
funcionalidades do código em bloco criados no App Inventor.

Requisito Evidência

A aplicação foi desenvolvida com foco em uso em navegadores web, com versões
RNF01 recentes, que compreendem os comandos realizados na aplicação, bem como
executam aplicações em React

Em resoluções inferiores a 1024x768 não é possível visualizar todo o aplicativo

RNF02 desenvolvido no App Inventor. É necessário rolar a tela ou definir o zoom em
valores abaixo de 100%

Por ter sido desenvolvida usando React e JavaScript, a plataforma LIDEA-w é

RNF03 executada em navegadores web de forma nativa, sem necessidade de instalação
de plugins ou programas adicionais
Tabela 14: Evidências dos testes de requisitos não funcionais do LIDEA-w

O RNF01 foi validado ao utilizar navegadores web atuais, onde a aplicação foi
executada com sucesso. Ao tentar executá-la em navegadores antigos e
desatualizados, como o Internet Explorer, não foi possível executar a aplicação.
O RNF02 foi validado ao utilizar as ferramentas do desenvolvedor do
navegador web Google Chrome, durante testes de tamanhos responsivos de tela. A
exibição em uma resolução de 800x600 pixels resulta em corte da imagem, conforme
figura 53.
 79

Figura 52: Aplicação cortada em tela com resolução inferior a 1024x768 pixels (Elaborado
pelo autor)

O RNF03 foi validado com o desenvolvimento da ferramenta durante a

realização de testes da aplicação em diferentes navegadores, como Internet Explorer,
e foi verificado que a aplicação não é executada, permanecendo uma tela em branco.

5.4. CONSIDERAÇÕES FINAIS

Este capítulo apresentou o desenvolvimento do sistema LIDEA-w para a

execução de aplicativos Android desenvolvidos com App Inventor, desde a
implantação do back-end ao front-end, e a análise do código YAIL enviado pelo App
Inventor.
As principais dificuldades técnicas foram a identificação do código YAIL que
utiliza comandos similares em diferentes partes do código e especialmente pela sua
estrutura que não segue padrões comuns usados em outras linguagens de
 80

programação. Durante o processo de conversão de YAIL para JavaScript e execução

do código foi necessário revisar todo o código já criado anteriormente. Durante a
conversão de blocos relacionados a operações matemáticas, o código YAIL foi tratado
para converter expressões matemáticas. Ao converter blocos relacionados a
operações de texto foi descoberto que várias partes do código são comuns, o que
causou erros na execução dos comandos funcionais, sendo necessário revisar o
trabalho e as conversões já concluídas.
As estratégias adotadas para a conversão de código YAIL em JavaScript por
tipo de comando ajudaram na implementação da ferramenta, pois foi identificado um
padrão no código YAIL e, desta forma, a conversão de comandos em blocos para
YAIL foi mais facilmente compreendida no decorrer do processo.
Infelizmente não foi possível realizar um estudo de caso para avaliação do
LIDEA-w devido à pandemia da COVID-19, mas foram realizados testes funcionais
para validação dos requisitos, por meio dos quais foi possível observar que os
requisitos foram atendidos conforme o esperado. Possibilita-se a criação da aplicação
onde o usuário insere a chave de 6 caracteres, recebe o código que permite a geração
do aplicativo, de forma funcional, através de um navegador web e visualiza e executa-
a para testes, sem necessidade da utilização de um aparelho celular.
 81

6. CONCLUSÃO

O objetivo principal deste trabalho foi desenvolver um sistema web para a

execução de telas de aplicativos móveis desenvolvidos na ferramenta App Inventor,
de forma funcional. No sistema desenvolvido foi realizada a conexão com a ferramenta
App Inventor, a fim de permitir a exibição funcional dos componentes visuais e de
layout definidos em tempo de desenvolvimento.
Para que este objetivo principal fosse atingido, foi analisado o estado da arte
sobre ambientes web para a execução de aplicações desenvolvidas com o App
Inventor. Foi realizada uma revisão sistemática da literatura e não foram localizados
resultados com trabalhos similares ao proposto neste trabalho, em relação ao objetivo
proposto.
Na sequência, foi analisado o protocolo de comunicação utilizado entre a
aplicação App Inventor e o aplicativo AI2 Companion, onde foi realizada uma
engenharia reversa para identificar os arquivos relacionados a este processo. Com a
identificação dos arquivos responsáveis pela comunicação, foram analisados códigos-
fonte das funções responsáveis pela comunicação entre a plataforma e o aplicativo
móvel.
Através da análise do código-fonte, foi implementada a comunicação com o
servidor Rendezvous, simulando a utilização do aplicativo AI2 Companion, utilizando
um servidor Node.js. A realização do handshake entre o App Inventor e a simulação
do AI2 Companion permitiu que o App Inventor enviasse o código YAIL com sucesso,
possibilitando a exibição do aplicativo criado nele.
A ferramenta foi desenvolvida após análise do processo de comunicação entre
o App Inventor e o servidor Rendezvous e como é realizado o envio do código YAIL
após o handshake. Após análises, foi desenvolvido um servidor back-end que recebia
o código YAIL através das requisições enviadas no programa Postman. Quando as
requisições foram bem-sucedidas, o servidor back-end foi refatorado para aceitar o
recebimento dinâmico direto do App Inventor. Com o código YAIL disponível para
acesso pela ferramenta, foi criado o front-end e desenvolvida a plataforma com
execução do código de forma dinâmica, conforme definição nos objetivos deste
trabalho.
 82

Por limitações de entendimento do código YAIL e sua complexidade e repetição

de códigos não foi possível implementar todos os componentes da forma pretendida,
porém, é possível que uma futura análise nos comandos possibilite a ampliação de
recursos na plataforma LIDEA-W.

6.1. TRABALHOS FUTUROS

Como sugestão de trabalhos futuros, baseando-se em componentes não

implementados e comandos em blocos que não foram convertidos, sugere-se a
implementação de componentes não-visuais como câmera, microfone. É importante
que sejam implementadas as Procedures, que funcionam como funções e dependem
de análise do código YAIL para sua conversão e execução em JavaScript
Além disso, outro possível aprimoramento do sistema seria a implementação
de uma conexão através de websockets, sem a necessidade de utilização de um
servidor back-end, desta forma, permitindo a conexão direta ao servidor Rendezvous
sem limitação de usuários por conexão.
Alguns componentes não visuais do App Inventor podem ser convertidos em
novos componentes, pois podem utilizar hardware disponível em computadores, como
microfone, caixas de som e câmera. A inclusão de tais componentes acrescenta
funcionalidades que tornar o ensino do uso da ferramenta mais divertido para os
estudantes.
Sugere-se assim, a implementação de Procedures, que agilizam a
implementação da aplicação, por evitarem repetição de blocos, bem como de código
em JavaScript, criando um código limpo após a conversão. Além disso, a
implementação de variáveis criadas dinamicamente e que podem ter seus valores
alterados globalmente permite o teste de aplicativos mais complexos dentro da
plataforma. Além das Procedures, também realizar a conversão dos comandos em
bloco relacionados a listas e dicionários, que não foram convertidos neste trabalho,
bem como blocos e componentes não concluídos.
Devido às limitações impostas pela pandemia de COVID-19, não foi possível
realizar uma aplicação prática do sistema desenvolvido em um ambiente educacional.
Assim, recomenda-se como trabalho futuro a realização de um estudo de caso com o
 83

sistema desenvolvido, de forma possibilitar a avaliação do seu impacto no apoio ao

ensino do pensamento computacional.
 84

7. REFERÊNCIAS

AMAZON. Microsserviços. AWS, 2022. Disponivel em:

<https://aws.amazon.com/pt/microservices/>. Acesso em: 20 mar. 2022.

ARMELIN, D. A. et al. A escola estratégica da aprendizagem (Learning by Interacting):

um estudo de caso da empresa LEGO®. Revista Científica UNAR, Araras, v. 12, n.
1, p. 11-41, Junho 2016.

BNCC. Base nacional Currícular Comum, 2018. Disponivel em:

<http://basenacionalcomum.mec.gov.br/images/BNCC_EI_EF_110518_versaofinal_s
ite.pdf>. Acesso em: 11 abr. 2021.

BRENNAN, K.; RESNICK, M. New frameworks for studying and assessing the
development of computational thinking. American Educational Research
Association, Vancouver, 2012. 25.

CASAROTTO, D. C.; CHISTE, J. G. S. A Linguagem Scheme. Universidade Federal

de Santa Catarina. Florianópolis. 2003.

CHIAVENATO, I. Introdução à teroria geral da administração. 7ª. ed. Rio de

Janeiro: Elsevier, 2003.

DEMETRIO, M. F. Desenvolvimento de um analisador e avaliador de código de

App Inventor para ensino de computação. Universidade Federal de Santa Catarina.
Florianópolis, p. 125. 2017.

DOMINGUEZ, J.; SPERTUS, E. App Inventor Developer Overview. MIT App Inventor
Sources, 2021. Disponivel em: <https://docs.google.com/document/u/0/d/1hIvAtbNx-
eiIJcTA2LLPQOawctiGIpnnt0AvfgnKBok/pub>. Acesso em: 18 mar. 2021.

FACEBOOK INC. React – Uma biblioteca JavaScript para criar interfaces de usuário.
Reactjs.org, 2021. Disponivel em: <https://pt-br.reactjs.org>. Acesso em: 21 mar.
2021.
 85

FREE SOFTWARE FOUNDATION. The Kawa Scheme language. Kawa: The Kawa
Scheme language, 2021. Disponivel em: <https://www.gnu.org/software/kawa/>.
Acesso em: 16 mar. 2021.

GARCIA, L. F. F. RPC - Remote Procedure Call. Repositório de Documentos

Técnicos do Grupo de Redes - UFRGS, 2002. Disponivel em:
<http://penta.ufrgs.br/rc952/trab1/rpc.html#rpc>. Acesso em: 19 mar. 2022.

GOOGLE. Blockly, 2021. Disponivel em: <https://developers.google.com/blockly>.

Acesso em: 05 jan. 2021.

GWT OPEN SOURCE PROJECT. GWT Project, 2020. Disponivel em:

<http://www.gwtproject.org/>. Acesso em: 04 jan. 2021.

K–12 CS. K–12 Computer Science Framework, 2016. Disponivel em:

<https://k12cs.org/wp-content/uploads/2016/09/K%E2%80%9312-Computer-
Science-Framework.pdf>. Acesso em: 18 dez. 2020.

MEC. Parâmetros curriculares nacionais: terceiro e quarto ciclos do ensino

fundamental: introdução aos Parâmetros curriculares nacionais. [S.l.]: [s.n.], 1998. 174
p. Disponivel em: <http://portal.mec.gov.br/seb/arquivos/pdf/introducao.pdf>. Acesso
em: 11 abr. 2021.

MIT. Scratch, 2021. Disponivel em: <https://scratch.mit.edu/>. Acesso em: 04 jan.

2021.

MIT. MIT App Inventor, 2021. Disponivel em: <https://appinventor.mit.edu/>. Acesso

em: 04 jan. 2021.

MIT APP INVENTOR COMMUNITY. AIA file structure. MIT App Inventor
Community, 2019. Disponivel em: <https://community.appinventor.mit.edu/t/aia-file-
structure/219>. Acesso em: 14 mar. 2021.

MOZILLA. Eval. MDN Web Docs, 2022. Disponivel em:

<https://developer.mozilla.org/pt-
BR/docs/Web/JavaScript/Reference/Global_Objects/eval>. Acesso em: 20 fev. 2022.
 86

MOZILLA. POST. MDN Web Docs, 2022. Disponivel em:

<https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Methods/POST>. Acesso em:
13 fev. 2022.

MUI. MUI. MUI, 2022. Disponivel em: <https://mui.com/>. Acesso em: 19 fev. 2022.

NODE.JS. Sobre | Node.js. Node.js, 2022. Disponivel em: <https://nodejs.org/pt-

br/about/>. Acesso em: 25 fev. 2022.

OPUS. Node.js - O que é, como funciona e quais as vantagens | OPUS. Opus

Software, 2018. Disponivel em: <https://www.opus-software.com.br/node-js/>.
Acesso em: 25 fev. 2022.

PASTERNAK, E.; FENICHEL, R.; MARSHALL, A. N. Tips for Creating a Block

Language with Blockly. 2017 IEEE Blocks and Beyond Workshop. Raleigh: IEEE.
2017. p. 21-24.

POSTMAN. Postman. Postman, 2022. Disponivel em: <https://www.postman.com/>.

Acesso em: 19 fev. 2022.

SADOWSKA, P. Android Runtime — How Dalvik and ART work? ProAndroidDev,

2021. Disponivel em: <https://proandroiddev.com/android-runtime-how-dalvik-and-art-
work-6e57cf1c50e5>. Acesso em: 20 mar. 2022.

SBC. Sociedade Brasileira de Computação. Diretrizes para ensino de Computação

na Educação Básica, 2019. Disponivel em: <https://www.sbc.org.br/documentos-da-
sbc/send/203-educacao-basica/1220-bncc-em-itinerario-informativo-computacao-2>.
Acesso em: 11 abr. 2021.

SCHILLER, J. et al. Live programming of mobile apps in App Inventor. PROMOTO

'14: Proceedings of the 2nd Workshop on Programming for Mobile & Touch. Portland:
Association for Computing Machinery. 2014. p. 1-8.

SPERTUS, E. How to Add a Component. MIT App Inventor Sources, 2019.

Disponivel em: <https://docs.google.com/document/pub?id=1xk9dMfczvjbbwD-wMsr-
ffqkTlE3ga0ocCE1KOb2wvw>. Acesso em: 18 mar. 2021.
 87

SPRANGER, R. A. Ferramenta de Geração de Aplicativos Móveis Híbrido/Cross-

platform Baseada em Editor de Interface. Universidade Federal de Santa Catarina.
Florianópolis, p. 97. 2019.

TANG, D. Empowering Novices to Understand and Use Machine Learning With

Personalized Image Classification Models, Intuitive Analysis Tools, and MIT App
Inventor. Massachusetts Institute of Technology. Cambridge, MA, p. 131. 2019.

W3SCHOOLS. React Getting Started. W3Schools, 2021. Disponivel em:

<https://www.w3schools.com/react/react_getstarted.asp>. Acesso em: 10 abr. 2021.

WANGENHEIM, C. G. V. et al. CodeMaster – Automatic Assessment and Grading of

App Inventor and Snap! Programs. Informatics in Education, v. 17, n. 1, p. 117-150,
2018.

WANGENHEIM, C. G. V.; ALVES, N. C.; HAUCK, J. C. R. Approaches to Assess

Computational Thinking Competences Based on Code Analysis in K-12 Education: A
Systematic Mapping Study. Informatics in Education, v. 18, n. 1, p. 17-39, 2019.

WEINTROP, D. et al. Blockly Goes to Work: Block-based Programming for Industrial

Robots. 2017 IEEE Blocks and Beyond Workshop. Raleigh: IEEE. 2017. p. 29-36.
 88

Apêndice I - Artigo

Ambiente Web integrado com App Inventor para execução

de aplicações Android

Darlan Brandt1
1
Departamento de Informática e Estatística (INE) Universidade Federal de Santa
Catarina (UFSC) – Florianópolis, SC – Brazil

darlanbrandt@gmail.com

Abstract. In a world in constantly evolving technology, it is important for

students to develop skills that prepare them for these changes. Various
initiatives using computational thinking have used app development
environments such as App Inventor, which uses block-based programming to
help with the development of apps for Android. App Inventor allows
visualizing the app as they are being developed through the AI2 Companion
application, without the need for compiling or installing the full application on
the student’s device, which makes it easier to develop an application.
Therefore, this paper aims to present the development of a web application
that allows exhibiting and testing apps as they are being developed by the
students. Thus, this may facilitate initiatives in teaching computational
thinking.

Resumo. Em um mundo em constante evolução tecnológica, é importante que

os estudantes desenvolvam habilidades que os preparem para essas
mudanças. Diversas iniciativas de ensino do pensamento computacional têm
utilizado ambientes como o App Inventor, que utiliza a programação em
blocos para auxiliar no desenvolvimento de aplicativos para dispositivos
Android. O App Inventor permite a visualização do app desenvolvido pelo
estudante em tempo de desenvolvimento, por meio do aplicativo AI2
Companion sem a necessidade de compilação e instalação do app no celular
do estudante, o que facilita o desenvolvimento das aplicações. Assim, este
trabalho apresenta o desenvolvimento de uma aplicação web que realize a
comunicação com o ambiente do App Inventor e permita a exibição em tempo
de desenvolvimento das telas dos apps implementados pelos estudantes. A
aplicação web é modelada e desenvolvida. A aplicação resultante pode
facilitar iniciativas de ensino do pensamento computacional.

1. Introdução
Em um mundo cada vez mais conectado e tecnológico, algumas habilidades
importantes para os estudantes têm sido incluídas no processo educacional, como por
exemplo o ensino do pensamento computacional (BRENNAN e RESNICK, 2012).
Pensamento computacional é “o processo de pensamento relacionado a formular
problemas e suas soluções de forma que as soluções são representadas de uma maneira
 89

que pode ser efetivamente executada por um agente de processamento de informação”

(BRENNAN e RESNICK, 2012).
Uma das formas de ensinar programação de forma lúdica e de fácil compreensão
é utilizando linguagens de programação baseadas em blocos. Nesse tipo de linguagem
são encaixadas peças que formam estruturas de programação, de maneira que possuem
não somente um nível de abstração maior, mas também são visualmente mais simples
para indicar o que cada bloco representa, reduzindo a carga cognitiva necessária para o
aprendizado, quando comparadas às tradicionais linguagens de programação baseadas
em texto (ALVES, WANGENHEIM e HAUCK, 2019).
A ferramenta App Inventor, criada pela Google e atualmente mantida pelo
Instituto de Tecnologia de Massachusetts (MIT), é usada para desenvolvimento de
aplicativos para dispositivos Android usando um navegador web, sem necessidade de
instalação de uma aplicação específica para desenvolvimento, como o Android Studio.
A visualização do aplicativo em desenvolvimento no App Inventor no celular é
realizada através do aplicativo AI2 Companion, que deve ser instalado em um
smartphone Android ou iOS. Ao acessar o aplicativo é necessário fazer a leitura de um
QR Code ou inserir o código exibido na tela, o que permite sincronizar a exibição do
aplicativo que está sendo desenvolvido com o celular em tempo de desenvolvimento,
sem necessidade de compilar e instalar um arquivo do tipo apk, que é o tipo de arquivo
instalador de aplicativos Android, no celular.
No entanto, o ensino de computação na educação básica no Brasil enfrenta
diversas limitações que dificultam a utilização desse tipo de ferramenta, como o App
Inventor. Os alunos podem não possuir um aparelho celular para realizar a visualização
do aplicativo criado no App Inventor por meio do AI2 Companion, a escola pode ter
uma internet de baixa velocidade ou computadores lentos que não suportam a utilização
de emuladores de aplicativos Android. Essas limitações têm sido também percebidas
nas aplicações voltadas ao ensino do pensamento computacional realizadas pela
Computação na Escola.
Assim, o presente projeto propõe o desenvolvimento de uma ferramenta que
permita a renderização e execução das telas de uma aplicação desenvolvida com App
Inventor, por meio de uma interface web, sem necessidade de criação de uma máquina
virtual, utilização de emuladores ou utilização de um smartphone Android ou iOS.

2. Conceitos importantes

Este capítulo trata dos principais conceitos envolvidos no desenvolvimento deste

trabalho. São abordados o App Inventor, a ferramenta AI2 Companion e a computação
na escola.

2.1 Computação na escola

Com a evolução da tecnologia e crescimento de dispositivos tecnológicos

integrados ao cotidiano, a demanda por profissionais capacitados também tem
aumentado (K–12 CS, 2016). Cada vez mais será necessário que estes profissionais
possuam algumas habilidades relacionadas ao pensamento computacional, mesmo para
áreas que não trabalham diretamente com ciências da computação (K–12 CS, 2016). É
importante que este conhecimento já seja desenvolvido desde cedo, de forma que os
estudantes de séries iniciais sejam capazes de desenvolver um conhecimento em
 90

ciências computacionais e aprender novas formas de resolver problemas, aproveitando o

poder do conhecimento computacional (K–12 CS, 2016).
Ao redor do mundo há diretrizes e bases para o ensino da Computação na
educação básica (K–12 CS, 2016). Entre eles, o K-12 Computer Science Framework,
sendo amplamente reconhecido por apresentar padrões, guias, conceitos, práticas e os
benefícios da implementação do ensino da computação nas escolas, desde estágios
iniciais até as séries avançadas (K–12 CS, 2016).
No entanto, no Brasil o ensino de computação não é parte integrante dos
Parâmetros Curriculares Nacionais (PCN) (SBC, 2019). A computação faz parte apenas
como ensino de informática, servindo apenas para ensino do computador como
ferramenta auxiliar no ensino das demais disciplinas constantes nos PCN (BNCC,
2018). A Sociedade Brasileira de Computação possui diretrizes para o ensino de
computação na educação básica, em que são tratados os conceitos, apresentadas as
competências desenvolvidas pela Computação, as habilidades da área no Ensino
Fundamental e no Ensino Médio (SBC, 2021).
Com o intuito de incluir a programação no ensino, há a iniciativa Computação
na Escola, da Universidade Federal de Santa Catarina (INE/UFSC) em parceria com o
Instituto Federal de Santa Catarina (IFSC), que tem por objetivo aumentar o ensino de
computação no Ensino Fundamental e Médio e que todos os alunos em todas as escolas
possam ter a oportunidade de aprender computação (COMPUTAÇÃO NA ESCOLA,
2021). São realizados diversos eventos buscando ampliar o ensino da computação,
incluindo oficinas, exposições, projetos de formações de tutores, entre outros.

2.2 App Inventor

O App Inventor é uma ferramenta usada para desenvolvimento de aplicativos

para dispositivos Android usando um navegador web. Lançado inicialmente em 2010
pela Google e atualmente mantido pelo MIT (MIT, 2021), o App Inventor é um
ambiente de programação baseado em blocos. Por meio do App Inventor, pessoas com
pouca ou nenhuma experiência em programação podem criar aplicativos utilizando seu
editor visual, onde é possível incluir componentes para a criação da interface do
aplicativo, arrastando elementos como caixas de texto, botões e/ou imagens e programar
seu funcionamento com o uso de programação baseada em blocos, no modo de edição
de blocos (WANGENHEIM, HAUCK, et al., 2018).
Blocos são comandos em linguagem natural apresentados de forma visual e de
forma ordenada logicamente, ou de formas mais fáceis de buscar e navegar, e são
encaixáveis a fim de permitir a criação de um código executável (WEINTROP,
SHEPHERD, et al., 2017). Além disso, o fato de utilizar blocos que o usuário arrasta e
solta, ao invés de digitar comandos que ele não entende ou conhece, torna mais fácil a
assimilação do comando a ser executado (WEINTROP, SHEPHERD, et al., 2017).

2.3 MIT AI2 Companion

O MIT AI2 Companion é um aplicativo mobile utilizado juntamente ao App

Inventor, no qual é possível realizar a conexão entre um dispositivo (smartphone ou
tablet) via USB ou conectado à internet via Wi-Fi para que o aplicativo gerado pelo App
Inventor seja executado no dispositivo que possui o aplicativo MIT AI2 Companion
instalado, para realização de testes e execução do código gerado. O aplicativo para
 91

execução em smartphones e tablets pode ser instalado em dispositivos Android e iOS

(MIT, 2021).
Sua principal função é o live debugging, que é uma forma de obter uma forma
mais imediata as alterações realizadas no programa desenvolvido, o que permite ao
programador, em especial aos iniciantes, entender e experimentar o aplicativo criado
(SCHILLER, ABELSON, et al., 2014).
A conexão entre o aplicativo e o App Inventor via Wi-Fi deve ser realizada
somente se ambos estiverem conectados à mesma rede local. A conexão entre o
computador, que está executando o App Inventor e o dispositivo onde está o Companion
é feita através do servidor Rendezvous do MIT. (MIT, 2021)
O envio da chave de 6 caracteres para o servidor Rendezvous não é feito em
texto simples. Todas as comunicações são feitas utilizando o algoritmo de hash MD5.
Quando conectados, o computador funciona como um servidor web, que envia o código
YAIL para o dispositivo como uma chamada AJAX (SCHILLER, ABELSON, et al.,
2014).
YAIL é a representação intermediária para as aplicações durante o processo de
compilação (SPERTUS, 2019). É uma linguagem com sintaxe baseada em parênteses e
é definida como uma coleção de macros e funções em Kawa. A linguagem Kawa é um
uma linguagem de programação de propósito geral que roda na plataforma Java, como
uma extensão da linguagem Scheme, que é uma versão estática e recursiva da linguagem
de programação Lisp (CASAROTTO e CHISTE, 2003) que por sua vez é uma
linguagem de programação funcional criada por Guy Lewis Steele Jr. e Gerald Jay
Sussman (CASAROTTO e CHISTE, 2003).
O Companion instalado no dispositivo possui um REPL (Read Eval Print Loop)
Kawa que avalia individualmente as expressões YAIL enviadas pelo navegador, onde o
usuário está desenvolvendo a aplicação. Sempre que um novo YAIL é gerado e difere
da cópia em cache, o navegador envia o novo código YAIL para o dispositivo, sem
necessidade de reinstalação do aplicativo (SCHILLER, ABELSON, et al., 2014).
Desta forma, o Companion atua como qualquer aplicativo gerado pelo App
Inventor e precisa de permissão de uso de todos os componentes.

3. Análise e Projeto

Neste capítulo é apresentada a análise e projeto para o desenvolvimento da

aplicação LIDEA-w (web LIve DEbugging for App inventor).
A solução proposta para o problema consiste na figura 1:
 92

Figura 1. Diagrama proposto para a solução

3.1. Engenharia Reversa

Para o início da implementação da aplicação, a documentação do App Inventor
foi analisada para localizar as classes responsáveis pela comunicação com o aplicativo
AI2 Companion. Com a análise da documentação e da estrutura da aplicação, foi
necessário realizar a leitura do código de algumas classes que possuem relação com a
conexão com o AI2 Companion.
O arquivo replmgr.js é responsável por estabelecer a comunicação do App
Inventor com o servidor Rendezvous. É neste arquivo que estão os comandos para
geração do QR Code e da chave de 6 caracteres. Foram incluídas linhas nesse arquivo
para exibição do conteúdo em console com o intuito de identificar o conteúdo recebido
e enviado para o servidor. Com o log nas ferramentas do desenvolvedor foi possível
analisar o código YAIL e analisar como é realizada a comunicação do App Inventor
com o AI2 Companion. A primeira análise realizada foi do código YAIL, para que a
ferramenta LIDEA-w pudesse ser desenvolvida. Ao fim da análise do código e criação
da ferramenta, deu-se início ao desenvolvimento da comunicação com o servidor.

3.2 Análise do Código YAIL

Para o desenvolvimento da ferramenta, foi realizada extensa análise do código
YAIL enviado pelo App Inventor. O código YAIL gerado pelo App Inventor é enviado
em um comando único onde a primeira parte do código refere-se à interface gerada,
com as posições, cores, tamanho e demais propriedades de cada componente. A segunda
parte refere-se aos comandos em bloco que serão executados de acordo com as ações
executadas.
Para identificação do que representa cada comando do código YAIL, foi criado
um aplicativo simples que exibe um nome digitado no texto. Foram também criados
 93

comandos em blocos a fim de reconhecer a estrutura de cada bloco em YAIL e

convertê-la em comandos JavaScript. Com a identificação dos comandos em YAIL para
a exibição dos componentes, iniciou-se a análise dos comandos em blocos.

3.3 Conexão com o servidor Rendezvous

Após a realização da conexão do App Inventor com o servidor Rendezvous, o
servidor aguarda o envio da chave de 6 caracteres pelo AI2 Companion, para que seja
realizado o handshake e a sessão seja iniciada.
No código do AI2 Companion, presente no código fonte do App Inventor, o arquivo
PhoneStatus.java é o responsável por converter a chave de 6 caracteres em um hash
e por obter os dados de conexão do dispositivo que são usados no arquivo
ReplForm.java. Nesse arquivo também estão os comandos que verificam se a
conexão está sendo realizada via Wi-Fi (importante para a realização da conexão com o
Rendezvous).
Com as informações do dispositivo, a conexão é realizada através dos comandos
presentes no arquivo WebRTCNativeMgr.java. Nesse arquivo estão listadas as
funções responsáveis pelo envio de dados para o handshake no servidor Rendezvous. Se
a conexão for bem-sucedida, o envio de código YAIL para o AI2 Companion é
realizada pelo arquivo ReplForm.java, que envia o código YAIL e informações
necessárias para exibição do ao aplicativo criado no App Inventor e código YAIL
atualizado, caso haja alguma alteração no App Inventor.
Com estas informações, foi analisado o arquivo rendezvous.js, para
compreender quais são os dados recebidos no servidor e como é feita esta requisição. O
servidor Rendezvous recebe uma requisição do tipo POST com os dados recebidos tanto
pelo App Inventor, quanto pelo AI2 Companion, validando dos dados recebidos pelo
servidor e caso estejam de acordo, permite a conexão entre as partes.

4. Desenvolvimento da plataforma
Após a análise dos códigos YAIL enviados pelo App Inventor, foi iniciada a
construção da plataforma LIDEA-w. A primeira parte realizada foi a criação do
esqueleto da aplicação. A estrutura inicial do projeto foi criada utilizando o comando
padrão para criação de aplicações em React. Esta estrutura inicial foi alterada para a
criação da interface da plataforma, de acordo com o protótipo exibido na figura 19,
ainda sem os componentes.
Com a interface definida, foram criados os componentes React baseados nos
componentes listados no App Inventor, do tipo User Interface e Layout, seguindo a
mesma nomenclatura para fácil identificação.
Após a criação da estrutura inicial do projeto, foi iniciada a criação do back-end
para a persistência do código YAIL em um local que permitisse seu acesso futuro. Para
isso foi criado um servidor Node.JS.
Com a criação do servidor Node.JS e criação de rotas, foi possível utilizar o
servidor como fonte do JSON enviado pelo App Inventor, com os componentes e
blocos.
O servidor back-end criado também é o responsável pelo envio da chave de 6
caracteres para o servidor Rendezvous. Para que a conexão fosse possível, foi criada
 94

uma rota que recebe a chave de 6 caracteres digitada pelo usuário e converte-a em um
hash, utilizando o algoritmo SHA1.

4.1 Conversão de YAIL em JavaScript executável

Com a listagem de todos os comandos, foi iniciado o processo de conversão do
código YAIL em JavaScript. Como o YAIL se trata de uma implementação específica
de Kawa, não foi possível utilizar nenhuma biblioteca já existente que realizasse a
conversão de Kawa para JavaScript. Sendo assim foi necessário implementar a
conversão de YAIL para JavaScript manualmente, criando cada um dos possíveis blocos
listados, a fim de identificar sua estrutura, posição inicial e final de cada um.
Foi então criada uma função no arquivo componentActionHelper.js,
utilizada por todos os componentes, que usa o array de variáveis e de comandos que
executa a conversão do código YAIL em uma string com código em sequência que será
executado como JavaScript a partir da função eval. A função eval é uma função de
propriedade global que recebe como argumento uma string, avalia e, se for uma
expressão JavaScript válida, executa o comando (MOZILLA, 2022).
Devido à complexidade de sua estrutura baseada em parênteses, alguns códigos
YAIL referentes aos comandos em bloco enviados pelo App Inventor tornaram difícil a
conversão em JavaScript.
A partir da conversão dos comandos em bloco em JavaScript foi possível tornar
a aplicação funcional e executável, dadas as limitações de escopo e dos comandos que
foram convertidos.

5. Testes
Uma aplicação-modelo para a realização dos testes simula uma aplicação que
poderia ser desenvolvida em um curso de ensino do pensamento computacional. A
aplicação escolhida para os testes foi uma calculadora simples.
Como possível contexto de uso dessa aplicação-modelo, pode-se imaginar um
cenário típico das atividades desenvolvidas pela Iniciativa Computação na Escola: uma
oficina de introdução à programação com App Inventor, realizada para estudantes do
Ensino Fundamental II como atividade em contraturno escolar. Os estudantes não
precisariam de conhecimentos prévios e durante a oficina aprenderiam conceitos
introdutórios de algoritmos e programação utilizando App Inventor. A aplicação gerada
no App Inventor é exibida na figura 2.
 95

Figura 2. Aplicação modelo gerada no App Inventor

A figura 3 mostra a aplicação exibida no LIDEA-w, após o recebimento do código.

Figura 3. Aplicação exibida no LIDEA-w

 96

6. Conclusão
O objetivo principal deste trabalho foi desenvolver um sistema web para a
execução de telas de aplicativos móveis desenvolvidos na ferramenta App Inventor, de
forma funcional. No sistema desenvolvido foi realizada a conexão com a ferramenta
App Inventor, a fim de permitir a exibição funcional dos componentes visuais e de
layout definidos em tempo de desenvolvimento.
Para que este objetivo principal fosse atingido, foi analisado o protocolo de
comunicação utilizado entre a aplicação App Inventor e o aplicativo AI2 Companion,
onde foi realizada uma engenharia reversa para identificar os arquivos relacionados a
este processo. Com a identificação dos arquivos responsáveis pela comunicação, foram
analisados códigos-fonte das funções responsáveis pela comunicação entre a plataforma
e o aplicativo móvel.
Através da análise do código-fonte, foi implementada a comunicação com o
servidor Rendezvous, simulando a utilização do aplicativo AI2 Companion, utilizando
um servidor Node.js. A realização do handshake entre o App Inventor e a simulação do
AI2 Companion permitiu que o App Inventor enviasse o código YAIL com sucesso,
possibilitando a exibição do aplicativo criado nele.
A ferramenta foi desenvolvida após análise do processo de comunicação entre o
App Inventor e o servidor Rendezvous e como é realizado o envio do código YAIL após
o handshake. Após análises, foi desenvolvido um servidor back-end que recebia o
código YAIL através das requisições enviadas no programa Postman. Quando as
requisições foram bem-sucedidas, o servidor back-end foi refatorado para aceitar o
recebimento dinâmico direto do App Inventor. Com o código YAIL disponível para
acesso pela ferramenta, foi criado o front-end e desenvolvida a plataforma com
execução do código de forma dinâmica, conforme definição nos objetivos deste
trabalho.
Por limitações de entendimento do código YAIL e sua complexidade e repetição
de códigos não foi possível implementar todos os componentes da forma pretendida,
porém, é possível que uma futura análise nos comandos possibilite a ampliação de
recursos na plataforma LIDEA-W.

Referências
BNCC. Base nacional Currícular Comum, 2018. Disponivel em:
<http://basenacionalcomum.mec.gov.br/images/BNCC_EI_EF_110518_versaofinal_
site.pdf>. Acesso em: 11 abr. 2021.
Brennan, K.; Resnick, M. New frameworks for studying and assessing the development
of computational thinking. American Educational Research Association, Vancouver,
2012. 25.
Casarotto, D. C.; Chiste, J. G. S. A Linguagem Scheme. Universidade Federal de Santa
Catarina. Florianópolis. 2003.
Dominguez, J.; Spertus, E. App Inventor Developer Overview. MIT App Inventor
Sources, 2021. Disponivel em:
<https://docs.google.com/document/u/0/d/1hIvAtbNx-
eiIJcTA2LLPQOawctiGIpnnt0AvfgnKBok/pub>. Acesso em: 18 mar. 2021.
 97

Facebook Inc. React – Uma biblioteca JavaScript para criar interfaces de usuário.
Reactjs.org, 2021. Disponivel em: <https://pt-br.reactjs.org>. Acesso em: 21 mar.
2021.
FREE SOFTWARE FOUNDATION. The Kawa Scheme language. Kawa: The Kawa
Scheme language, 2021. Disponivel em: <https://www.gnu.org/software/kawa/>.
Acesso em: 16 mar. 2021.
K–12 CS. K–12 Computer Science Framework, 2016. Disponivel em:
<https://k12cs.org/wp-content/uploads/2016/09/K%E2%80%9312-Computer-
Science-Framework.pdf>. Acesso em: 18 dez. 2020.
MEC. Parâmetros curriculares nacionais: terceiro e quarto ciclos do ensino
fundamental: introdução aos Parâmetros curriculares nacionais. [S.l.]: [s.n.], 1998.
174 p. Disponivel em: <http://portal.mec.gov.br/seb/arquivos/pdf/introducao.pdf>.
Acesso em: 11 abr. 2021.
MIT. MIT App Inventor, 2021. Disponivel em: <https://appinventor.mit.edu/>. Acesso
em: 04 jan. 2021.
Mozilla. Eval. MDN Web Docs, 2022. Disponivel em:
<https://developer.mozilla.org/pt-
BR/docs/Web/JavaScript/Reference/Global_Objects/eval>. Acesso em: 20 fev. 2022.
Mozilla. POST. MDN Web Docs, 2022. Disponivel em:
<https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Methods/POST>. Acesso em:
13 fev. 2022.
SBC. Sociedade Brasileira de Computação. Diretrizes para ensino de Computação na
Educação Básica, 2019. Disponivel em: <https://www.sbc.org.br/documentos-da-
sbc/send/203-educacao-basica/1220-bncc-em-itinerario-informativo-computacao-2>.
Acesso em: 11 abr. 2021.
Schiller, J. et al. Live programming of mobile apps in App Inventor. PROMOTO '14:
Proceedings of the 2nd Workshop on Programming for Mobile & Touch. Portland:
Association for Computing Machinery. 2014. p. 1-8.
Spertus, E. How to Add a Component. MIT App Inventor Sources, 2019. Disponivel
em: <https://docs.google.com/document/pub?id=1xk9dMfczvjbbwD-wMsr-
ffqkTlE3ga0ocCE1KOb2wvw>. Acesso em: 18 mar. 2021.
Wangenheim, C. G. V.; Alves, N. C.; Hauck, J. C. R. Approaches to Assess
Computational Thinking Competences Based on Code Analysis in K-12 Education:
A Systematic Mapping Study. Informatics in Education, v. 18, n. 1, p. 17-39, 2019.
Weintrop, D. et al. Blockly Goes to Work: Block-based Programming for Industrial
Robots. 2017 IEEE Blocks and Beyond Workshop. Raleigh: IEEE. 2017. p. 29-36.