Desenvolvimento de Aplicativo Android para Portal do Aluno da UFRJ

•
UFRJ

Artigos e Atualidades
17/01/2023
E aí, curtiu este material?
Ajude a incentivar outros estudantes a melhorar o conteúdo
Gostou desse material? Compartilhe! 🧡
Administração

596.394 Materiais compartilhados
Baixe o app para aproveitar ainda mais
Leia os materiais offline, sem usar a internet. Além de vários outros recursos!
Prévia do material em texto
DESENVOLVIMENTO DE APLICATIVO ANDROID PARA O PORTAL DO
ALUNO DA UFRJ
Rafael Cardoso Ferreira
Projeto de Graduação apresentado ao Curso
de Computação e Informação da Escola
Politécnica da Universidade Federal do Rio de
Janeiro como parte dos requisitos necessários
para a obtenção do grau de Engenheiro de
Computação e Informação.
Orientador: José Ferreira de Rezende
Rio de Janeiro
Janeiro de 2017
DESENVOLVIMENTO DE APLICATIVO ANDROID PARA O PORTAL DO
ALUNO DA UFRJ
Rafael Cardoso Ferreira
PROJETO SUBMETIDO AO CORPO DOCENTE DO CURSO DE
COMPUTAÇÃO E INFORMAÇÃO DA ESCOLA POLITÉCNICA DA
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE
DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE
ENGENHEIRO DE COMPUTAÇÃO E INFORMAÇÃO.
Examinadores:
Prof. José Ferreira de Rezende, Dr.
Prof. Aloysio de Castro Pinto Pedroza, Dr.
Prof. Flávio Luis de Mello, D.Sc.
RIO DE JANEIRO, RJ – BRASIL
JANEIRO DE 2017
Ferreira, Rafael Cardoso
Desenvolvimento de Aplicativo Android para o Portal do
Aluno da UFRJ/Rafael Cardoso Ferreira. – Rio de Janeiro:
UFRJ/POLI – COPPE, 2017.
XI, 49 p.: il.; 29, 7cm.
Orientador: José Ferreira de Rezende
Projeto (graduação) – UFRJ/ Escola Politécnica/ Curso
de Computação e Informação, 2017.
Referências Bibliográficas: p. 46 – 49.
1. Dispositivos móveis. 2. Android. 3. REST. 4.
Hibrido. 5. Nativo. 6. Portal do Aluno. I. de Rezende,
José Ferreira. II. Universidade Federal do Rio de Janeiro,
Escola Politécnica/ Curso de Computação e Informação.
III. T́ıtulo.
iii
Agradecimentos
Primeiramente, agradeço aos meus pais por serem meu exemplo de vida e maiores
companheiros. À minha famı́lia, pelo sempre presente carinho e amor por toda
minha vida. À minha namorada, por sempre ter sido uma grande companheira nos
momentos bons e ruins.
Aos meus amigos de ECI, pelos incŕıveis anos que passamos juntos; em especial,
agradeço ao Rezende e Sab pelas incontáveis vezes que me ajudaram por toda tra-
jetória. Aos meus amigos do BQF por mostrarem que tempo e distância são apenas
detalhes quando se trata de amizade. Aos meus amigos do SIGA, e especialmente
ao Ricardo Storino, por terem me dado a oportunidade de contribuir com a univer-
sidade de alguma forma, e pela paciência em me ensinar conceitos que eu jamais
havia conhecido.
Agradeço imensamente à Universidade Federal do Rio de Janeiro pela oportuni-
dade de me tornar engenheiro, e à todos os professores do curso de Engenharia. Em
especial, ao professor Sérgio Barbosa Villas-Boas, que foi além de professor um bom
amigo; e professor José Rezende, por aceitar a orientação deste trabalho. Agradeço
também ao professor Paulo Oliva, por toda orientação e contribuição durante meu
termo de intercâmbio acadêmico, e aos professores Flávio Mello e Aloysio Pedroza,
por participarem desta banca examinadora.
Por fim, agradeço a todas as pessoas que me ajudaram a ser uma pessoa melhor
neste tempo de universidade.
iv
Resumo do Projeto de Graduação apresentado à Escola Politécnica/COPPE/UFRJ
como parte dos requisitos necessários para a obtenção do grau de Engenheiro de
Computação e Informação.
DESENVOLVIMENTO DE APLICATIVO ANDROID PARA O
PORTAL DO ALUNO DA UFRJ
Rafael Cardoso Ferreira
Janeiro/2017
Orientador: José Ferreira de Rezende
Curso: Engenharia de Computação e Informação
Com a grande popularização dos smartphones e seu crescente uso na sociedade,
paralelo ao decrescente uso dos desktops para tarefas cotidianas, instituições que
ofereciam soluções online tiveram que se adaptar para que essas soluções também
fossem viáveis em dispositivos móveis. O contexto da Universidade Federal do Rio
de Janeiro não é diferente, e portanto oferecer as soluções do Sistema Integrado de
Gestão Acadêmica (SIGA) para dispositivos móveis fez-se necessário. Este trabalho
tem como objetivo oferecer uma revisão sobre diferentes abordagens de desenvolvi-
mento móvel e descrever a implementação de uma solução para dispositivos Android
que possibilita o acesso ao SIGA.
Palavras-Chave: Dispositivos móveis, Android, REST, Hibrido, Nativo, Portal
do Aluno.
v
Abstract of the Undergraduate Project presented to Poli/COPPE/UFRJ as a partial
fulfillment of the requirements for the degree of Computer and Information Engineer.
DEVELOPMENT OF UFRJ’S PORTAL DO ALUNO ANDROID
APPLICATION
Rafael Cardoso Ferreira
January/2017
Advisor: José Ferreira de Rezende
Course: Computer and Information Engineering
As smartphones become increasingly popular in our society, and desktop become
decreasingly used, instituitons that offered online solutions were forced to adapt in
a way so that these solutions became available for mobile devices. Universidade
Federal do Rio de Janeiro’s context is not different, and therefore, it made neces-
sary to offer a mobile solution for the university’s academic system, named Sistema
Integrado de Gestão Acadêmica (SIGA). This document offers a review of different
mobile development approaches, as well as a description of the implementation of a
mobile solution for Android devices that enables access to SIGA.
Keywords: Mobile, Android, REST, Hybrid development, Native development.
vi
Sumário
Lista de Figuras ix
Lista de Tabelas x
Lista de Abreviaturas xi
1 Introdução 1
1.1 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Conceitos Básicos 5
2.1 Desenvolvimento Nativo . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Desenvolvimento Hı́brido . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 REST vs SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Desenvolvimento Hı́brido e Nativo 13
3.1 Interface Gráfica (UI ) . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Experiência do Usuário (UX) . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6 Testes Automatizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6.1 Testes unitários . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6.2 Testes de aceitação . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Implementação 23
4.1 Visão geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2 Interface Gráfica (UI ) . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Página Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
vii
4.2.2 Menu Principal & Explorador de Arquivos . . . . . . . . . . . 26
4.2.3 Salas de Aula . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.4 Inscrição em Disciplinas . . . . . . . . . . . . . . . . . . . . . 30
4.3 Experiência do Usuário (UX) . . . . . . . . . . . . . . . . . . . . . . 30
4.3.1 Norman’s Design Principles . . . . . . . . . . . . . . . . . . . 32
4.4 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.7 Testes Automatizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7.1 Testes Unitários . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7.2 Testes de Aceitação . . . . . . . . . . . . . . . . . . . . . . . . 39
5 Resultados 41
5.1 Estat́ısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6 Conclusões e Trabalhos Futuros 44
6.1 Conclusões . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . 44
6.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Referências Bibliográficas 46
viii
Lista de Figuras
1.1 Consumo em minutos por dia: mobile vs desktop . . . . . . . . . . . . 2
1.2 Página inicial do SIGA. Retirado de [1]. . . . . . . . . . . . . . . . . 3
2.1 Market share por sistema operacional . . . . . . . . . . . . . . . . . . 6
2.2 Diferença de performance entre SOAP e REST [2]. . . . . . . . . . . 11
2.3 Aumento de APIs REST entre 2006 e 2011 [3]. . . . . . . . . . . . . 11
3.1 Sugestão do Material Design para listas. [4] . . . . . . . . . . . . . . 14
3.2 Diferença de sub-menus . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Exemplos de menus laterais em frameworks h́ıbridos . . . . . . . . . . 17
4.1 Diagrama geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Aplicação do Material Design na prática . . . . . . . . . . . . . . . . 25
4.3 Detalhamento de menus dispońıveis no app . . . . . . . . . . . . . . . 27
4.4 Páginas iniciais do app . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5 Tela de turmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6 Páginas de inscrição do app . . . . . . . . . . . . . . . . . . . . . . . 31
4.7 Feedback sobre o status dispońıveis . . . . . . . . . . . . . . . . . . . 33
4.8 Dialogs sobre o status das requests. . . . . . . . . . . . . . . . . . . . 34
4.9 Opções para o peŕıodo de trancamento. . . . . . . . . . . . . . . . . . 35
5.1 Avaliação dos usuários. . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Total de instalações por usuário. . . . . . . . . . . . . . . . . . . . . . 42
5.3 Instalações do app por páıs. . . . . . . . . . . . . . . . . . . . . . . . 43
ix
Lista de Tabelas
2.1 Linguagens de programação para desenvolvimento nativo por S.O. . . 6
x
Lista de Abreviaturas
API Application Programming Interfaces, p. 9
BOA Boletim de Orientação Acadêmica, p. 26
CRID Confirmação de Registro de Inscrição em Disciplinas, p. 26
CRPID Confirmação de Registro de Pedido de Inscrição em Disciplinas,
p. 26
HTTP Hypertext Transfer Protocol, p. 9
REST Representational state transfer, p. 9
SDK Software Delopment Kit, p. 5
SIGA Sistema Integrado de Gestão Acadêmica, p. 1
SOAP Simple Object Access Protocol, p. 10
UI User Interface, p. 13
UX User Experience, p. 16
XML Extensible Markup Language, p. 10
xi
Caṕıtulo 1
Introdução
O uso de smartphones e tablets faz parte do cotidiano da maioria dos brasileiros atu-
almente. Segundo estat́ısticas [5], 76.1 milhões de brasileiros utilizam smartphones,
o que corresponde a aproximadamente 40% do total de brasileiros. Entretanto, esse
número sobe para 61% se considerarmos somente a população brasileira que utiliza
celulares.
Paralelamente ao crescimento do uso de dispositivos móveis, vê-se o grande
decĺınio do uso de computadores pessoais (desktops). O Gráfico 1.1 ilustra este
evento comparando a proporção do uso de dispositivos moveis e computadores desde
2014, além da projeção até 2018.
Como consequência, cada vez mais passa a ser menos cômodo para os usuários
utilizar desktops para tarefas cotidianas. Isso reflete o significativo amadurecimento
do mercado de aplicativos para smartphones, que passou de 100.000 aplicativos
dispońıveis em outubro de 2010 para incŕıveis 2.400.000 em outubro de 2016.[6].
Estes números são referentes somente ao sistema operacional Android. Para iOS, os
números variam de 100.000 para 2.000.000 no mesmo aproximado peŕıodo de tempo
[7].
Atualmente, a plataforma Android tem o maior market share do mercado, com
87.6%, enquanto o iOS tem 11.7% [8]. Os dois juntos dominam 99.3% do mercado. O
restante é dividido entre Windows Phone, BlackBerry e outros sistemas operacionais
menores, como webOS, Symbian OS e Ubuntu OS.
Com base nesses dados, não há razões, portanto, para universidades não seguirem
essa crescente tendência e se adaptarem para fornecer soluções móveis.
1.1 Antecedentes
A UFRJ implantou nos anos 90 o Sistema Integrado de Gestão Acadêmica (SIGA),
visando melhorar e agilizar os processos acadêmicos em geral. Antes da imple-
mentação do sistema, todos os processos acadêmicos eram feitos presencialmente,
1
Figura 1.1: Consumo em minutos por dia: mobile vs desktop
ou seja, para tarefas como inscrição em disciplinas ou recuperação de documentos,
os alunos tinham que estar na faculdade em horários e dias preestabelecidos. Com o
SIGA, foi oferecida a possibilidade de fazer tais tarefas de qualquer lugar do mundo
com acesso à Internet.
O SIGA engloba inúmeras funcionalidades de diversos escopos, fazendo com que
não somente estudantes mas também professores, coordenadores de curso e técnicos-
administrativos, entre outras ocupações, utilizem o sistema.
1.2 Motivação
A principal motivação para este projeto começou ainda no ano de 2013. Na época,
o acesso ao SIGA era feito exclusivamente pela intranet da UFRJ, e o website do
sistema em si era totalmente orientado a mouse, isto é, a usabilidade do sistema
dependia de aspectos não suportados por outras formas de navegação, como o toque.
Por exemplo, para abrir o menu superior do sistema, era necessário posicionar o
mouse por alguns segundos em cima do mesmo, até que abrisse.
A Figura 1.2 ilustra a página inicial do sistema. Por ser um sistema desen-
2
Figura 1.2: Página inicial do SIGA. Retirado de [1].
volvidos em tecnologias antigas em um tempo em que a utilização de internet nos
celulares era nula, ele não oferecia suporte para celulares ou um layout responsivo.
Consequentemente, não era posśıvel utilizar o sistema em vários celulares.
A ideia de desenvolver um aplicativo (app) começou a partir desta dificuldade.
O primeiro protótipo ficou pronto no dia primeiro de agosto de 2013, e foi lançado
de forma extraoficial, sendo disponibilizado na Google Play de forma gratuita.
Com a grande aceitação do aplicativo por parte dos usuários, o projeto viria a
se tornar o aplicativo oficial da UFRJ para Android no ano de 2014.
1.3 Objetivo
O objetivo da construção do aplicativo foi não somente colocar a UFRJ dentro
do mapa de inovação de dispositivos móveis, atendendo os alunos via dispositivos
móveis, mas também garantir à grande maioria dos alunos um acesso rápido, seguro
e eficaz ao Sistema Integrado de Gestão Acadêmica.
O objetivo deste trabalho é sumarizar como foi feito o desenvolvimento do aplica-
tivo para smartphones com sistema operacional Android, explicitando fatores como
interface gráfica, experiência do usuário, performance, usabilidade, comunicação ex-
terna com o servidor e segurança, além de demonstrar a importância da qualidade
3
de código e os meios utilizados para atingi-la.
Em adição, o trabalho se propõe a expor eventuais dificuldades encontradas na
evolução do projeto, assim como ressaltar prós e contras de diferentes abordagens
de desenvolvimento, para que sirva como referência e legado para iniciativas seme-
lhantes.
1.3.1 Metodologia
Inicialmente, foi realizada uma revisão bibliográfica acerca de desenvolvimento de
aplicativos móveis, incluindo pesquisas quantitativas referentes a diversos elementos
do desenvolvimento, como performance, segurança, interface gráfica, usabilidade e
comunicação com servidores.
Com base nesta revisão, foi implementado um software para o sistema operacio-
nal Android de forma nativa para atender os alunos da UFRJ com acesso móvel ao
Portal Aluno, possibilitando acesso rápido ao SIGA e seus serviços.
Este trabalho foi dividido em 5 caṕıtulos, além desta introdução. O Caṕıtulo 2
refere-se à alguns conceitos básicos para auxiliar no entendimento deste trabalho,
enquanto o Caṕıtulo 3 oferece uma revisão bibliográfica sobre a polaridade de desen-
volvimento nativo de aplicativos versus desenvolvimento h́ıbrido de aplicativos. No
Caṕıtulo4 está descrita a implementação em si, explicitando cada componente do
projeto e justificativas para cada decisão tomada. Os resultados da implementação
do projeto, incluindo dados sobre a aceitação do produto por parte do público e
estat́ısticas de uso, estão dispostas no Caṕıtulo 5. O último caṕıtulo refere-se às
conclusões tomadas e trabalhos futuros.
4
Caṕıtulo 2
Conceitos Básicos
Com a grande popularização de smartphones como visto na seção anterior, os prove-
dores de serviço tiveram que se adaptar e fornecer soluções que também atendessem
a esse mercado.
O crescente número de apps nas lojas online é um grande indicativo desse
fenômeno. No entanto, um outro indicativo é também a popularização dos web-
sites baseados no chamado design responsivo. Com diferentes tamanhos, resoluções
de telas e velocidade de conexão, é dif́ıcil prever o contexto no qual um usuário
acessa a Internet. Dessa forma, cria-se uma necessidade de uso de novas técnicas
para prover a melhor experiência de usuário posśıvel a qualquer um que possa vir a
utilizar um serviço [9].
Aplicações que são acessadas através de um navegador web são comumente cha-
madas de web applications [10]. Ao utilizar as técnicas de design responsivo, essas
aplicações ficam com a interface gráfica muito parecida com a de um app comum de
smartphones.
Essa é a ideia base de aplicativos h́ıbridos, como veremos nas seções subsequen-
tes. Em termos de desenvolvimento de aplicações que rodam no smartphones em
si, e não na nuvem, existem duas vertentes principais: desenvolvimento h́ıbrido e
desenvolvimento nativo.
2.1 Desenvolvimento Nativo
O desenvolvimento nativo consiste na escrita de código em linguagem nativa, uti-
lizando um Software Development Kit (SDK) próprio para um certo sistema ope-
racional. Consequentemente, a linguagem de programação usada depende de cada
sistema operacional. Na Tabela 2.1, podemos ver a variação da linguagem adotada
por cada sistema. Os sistemas operacionais são listados também com sua represen-
tatividade em market share.
5
Tabela 2.1: Linguagens por Sistema Operacional
Sistema Operacional Linguagem Market Share
Android Java 87.5%
iOS Swift 12.1%
Windows Phone .NET < 1%
Blackberry Java ME < 1%
UbuntuOS QML & Javascript < 1%
Figura 2.1: Market share por sistema operacional [11]
Na Figura 2.1, vemos também que Android e Apple iOS lideram o mercado de
smartphones há anos. Portanto, seus respectivos SDK s são os mais utilizados para
desenvolvimento nativo.
2.2 Desenvolvimento Hı́brido
O desenvolvimento h́ıbrido consiste na utilização de algum framework que possibilita
transformar um código - escrito em uma única linguagem - em apps nativos de
diferentes plataformas.
Existem vários frameworks que atendem o desenvolvimento de aplicativos para
diferentes plataformas. Dentre tais frameworks, podemos citar os que utilizam abor-
dagens web ou abordagens proprietárias, como veremos a seguir.
Este trabalho focará mais na metodologia web, visto que é a mais utilizada como
alternativa ao desenvolvimento nativo.
Abordagem web
O que esses frameworks costumeiramente fazem é envolver uma estrutura combinada
de HTML, CSS e Javascript em uma estrutura nativa semelhantes a um web browser
6
(como o Google Chrome ou o Internet Explorer) que roda em tela cheia [12]. Pode-se
citar como exemplo os frameworks PhoneGap, Cordova e Ionic.
Dessa forma, o app h́ıbrido se assemelha muito a um nativo: ele é baixado
de alguma store online, como a Apple AppStore ou o Google Play, instalado no
smartphone normalmente e utilizado como se fosse um aplicativo comum.
Portanto, a grande vantagem do desenvolvimento h́ıbrido é que um código único é
implantado em vários sistemas operacionais diferentes, não sendo necessário escrever
um código diferente para cada sistema operacional utilizando cada SDK. Essa é uma
estratégia muito utilizada para empresas e startups que querem cortar ao máximo o
custo de desenvolvimento.
Em teoria, a manutenibilidade se dá de forma mais fácil por conta do baixo
volume de código, e a velocidade de lançamento de atualizações também. Com
senso, a probabilidade de bugs também é drasticamente reduzida, visto que não é
necessário replicar os algoritmos e mudanças em diversos código-fontes diferentes.
Abordagem proprietárias
No entanto, existem outras técnicas de desenvolvimento h́ıbrido que utilizam tecno-
logias diferentes das tecnologias padrão web.
O Xamarin, por exemplo, é um framework que permite o desenvolvedor progra-
mar na linguagem C# e fazer o deploy de apps nativos em Android e iOS.
Apesar de entregar apps nativos para cada plataforma, não se utiliza o SDK
espećıfico regido por cada S.O, e sim um framework próprio feito com base nesses
SDKs.
Os exemplos de código dispostos nos Quadros 2.1 e 2.2 mostram a similaridade
do código nativo do SDK do Android e o código do framework Xamarin.
O ponto positivo é que a performance final do app é consideravelmente superior
à performance conseguida ao utilizar as tecnologias web, porque ele traduz o código
escrito em C# para código nativo usando técnicas de compilação espećıficas de cada
plataforma, em vez de simplesmente simular um website dentro de um aplicativo,
como é feito na abordagem web. O ponto negativo é que para se obter a melhor
experiência de usuário posśıvel, o desenvolvedor acaba com vários códigos em vez de
um só: haverá um código para a interface gráfica para Android, um para a interface
gráfica para iOS etc, apesar de toda lógica de negócio poder ser compartilhada.
7
Arquivo 2.1: Código SDK do Xamarin
pub l i c c l a s s M a i n A c t i v i t y : A c t i v i t y
{
protected o v e r r i d e void OnCreate ( Bundle s a v e d I n s t a n c e S t a t e )
{
base . OnCreate ( s a v e d I n s t a n c e S t a t e ) ;
SetContentView ( Resource . Layout . Main ) ;
Button button = FindViewById<Button>(Resource . I d . myButton ) ;
}
}
Arquivo 2.2: Código SDK do Android
pub l i c c l a s s M a i n A c t i v i t y extends A c t i v i t y
{
@Over r ide
protected void onCreate ( Bundle s a v e d I n s t a n c e S t a t e )
{
super . onCreate ( s a v e d I n s t a n c e S t a t e ) ;
s e tContentV iew (R . l a y o u t . main ) ;
Button t o o l b a r = ( Button ) f i ndV i ewBy Id (R . i d . myButton ) ;
}
}
Um outro exemplo é o RAD Studio. Este é um framework desenvolvido pela
Embarcadero Technologies que permite o desenvolvimento de apps multi-plataforma
utilizando Delphi e C++. Ao contrário do framework Xamarin, o RAD Studio per-
mite o desenvolvimento de um único código para a interface gráfica que é traduzido
em designs que seguem o padrão de cada plataforma suportada: Android, iOS e
Windows Phone.
Estruturas de Projeto & IDEs
Integrated development environment (IDE) é um software que facilita o desenvol-
vimento de programas de várias maneiras, das quais pode-se destacar a inclusão
automática de um compilador e processo de build, utilização de debugger e visua-
lização da interface gráfica em tempo real. Além disso, eles podem oferecer uma
interface simples de integração com repositórios de bibliotecas de terceiros como o
maven, NuGet entre outros.
Para desenvolvimento nativo Android, utiliza-se duas IDEs principais: Eclipse e
Android Studio, sendo a última a IDE oficial da Google e consequentemente reco-
mendada pela empresa. Para iOS, a IDE oficial é fornecida pela Apple e se chama
8
Xcode. Para Windows Phone, a IDE fornecida pela Microsoft é o Visual Studio.
Para desenvolvimento h́ıbrido, não há regra. Entretanto, vários frameworks dis-
ponibilizam uma IDE própria que atende facilidades espećıficas de cada uma.
A estrutura dos projetos varia de acordo com cada framework.
2.3 APIs
Para comunicação entre softwares, costuma-se utilizar Application Programming In-
terfaces (API s). API s são interfaces definidas por padrões de comunicação prees-
tabelecidos,tal que seja posśıvel sistemas se comunicarem de forma automatizada.
No caso de serviços web, as chamadas web API s são muito usadas. Web API s
podem ser acessadas por qualquer sistema que consiga fazer requisições Hypertext
Transfer Protocol (HTTP), o que abrange uma gigantesca gama de sistemas in-
cluindo todos os smartphones atuais.
Os padrões mais utilizados para comunicação desse tipo são os REST e SOAP.
2.3.1 REST vs SOAP
Representational state transfer (REST ) é um padrão definido por uma série de
restrições e caracteŕısticas que tem como objetivo abstrair a comunicação entre sis-
temas. Pode-se citar, dentre estas restrições e caracteŕısticas, três principais[13]:
• Identificação global
• Interfaces uniformes
• Stateless
O primeiro item destaca que os recursos são identificados via uma URL; o se-
gundo item ressalta que só deve haver um meio de acessar os serviços, e este é por
meio de requests (requisições) HTTP para a URL que os identificam; e por último,
todas as requisições são stateless, isto é, eles não devem guardar estado. Basica-
mente, para cada requisição (request) que recebe certos parâmetros predefinidos, há
um processamento que gera uma resposta (response). Não há informações de sessões
de clientes ou similares guardadas no processo. Consequentemente, espera-se que
aplicações e serviços baseados nesse modelo sejam idempotentes.
Denomina-se RESTful o sistema que segue os prinćıpios REST. Web APIs cos-
tumam ser RESTful, o que consequentemente sugere a utilização de XML ou JSON
para transferência de dados, visto que tais formatos são amplamente utilizados por
conta de sua simplicidade e facilidade no tratamento de informações.
São destacadas mensagems XML e JSON nos exemplos abaixo.
9
<aluno>
<nome>Rafae l </nome>
<i dade >22</idade>
<u n i v e r s i d a d e >U n i v e r s i d a d e F e d e r a l do Rio de Jane i r o </u n i v e r s i d a d e >
</aluno>
{
” a luno ” :
{
”nome” : ” R a f a e l ” ,
” i dade ” : ”22” ,
” u n i v e r s i d a d e ” : ” U n i v e r s i d a d e F e d e r a l do Rio de J a n e i r o ”
}
}
Simple Object Access Protocol (SOAP) é um protocolo que permite troca de
informações de forma semelhante ao padrão REST, mas de forma mais robusta. O
protocolo SOAP, originalmente desenvolvido pela Microsoft, não restringe o acesso
somente a HTTP.
Cada vertente tem seus prós e contras, porém vê-se uma incŕıvel preferência
por parte de desenvolvedores por APIs REST ful. O principal motivo é a grande
rapidez e simplicidade no envio e tratamento de dados em Javasript Object Notation
(JSON), que faz muita diferença para aplicativos móveis, principalmente por conta
da possibilidade de conexão instável por conta de redes 3G. Uma outra alternativa
seria o notável Extensible Markup Language (XML), porém o tráfego de dados é
muito maior por conta de como o XML é estruturado: para cada tag aberta, outra
exatamente igual é escrita para indicar o fim da mesma. O JSON evita este problema
utilizando o caractere de chave e colchete para indicar abertura e fechamento de
objetos.
APIs SOAP, por sua vez, tem um set-up mais rápido, tendo as vezes aux́ılio de
wizards que já automatizam a estruturação de toda conexão com o servidor. Além
disso, suportam outros protocolos além do HTTP, como o SMTP e SSH. No entanto,
costumam pecar em performance.
A Figura 2.2 indica a grande diferença no tempo de cada chamada a um web-
service sobre vários celulares. O estudo foi feito pelo A-team da Oracle e visava
estudar a diferença de performance entre os dois modos de comunicação [2].
Como já explicitado, performance é um fator muito importante para a aceitação
de aplicativos móveis, e portanto, é natural que a escolha de desenvolvedores seja
enviesada para o paradigma mais performático - nesse caso, evidentemente o REST.
10
Figura 2.2: Diferença de performance entre SOAP e REST [2].
Figura 2.3: Aumento de APIs REST entre 2006 e 2011 [3].
11
Esse fenômeno também leva aos provedores de informação (nesse caso, os web
services e suas APIs) a utilizar protocolos mais amplamente performáticos, isto é,
protocolos que satisfazem também o consumo mobile além dos tradicionais desktops.
O Gráfico 2.3 mostra o expressivo aumento do uso da tecnologia REST em APIs,
e paralelamente, a diminuição de sua maior contraparte, o SOAP.
12
Caṕıtulo 3
Desenvolvimento Hı́brido e Nativo
No caṕıtulo anterior, foi apresentada uma visão geral do panorama de desenvolvi-
mento para dispositivos móveis. Esse caṕıtulo tem como objetivo melhor descrever
as técnicas e implementações para esse desenvolvimento, assim como explicitar as
principais diferenças entre as duas diferentes abordagens.
3.1 Interface Gráfica (UI )
A construção da interface gráfica (em inglês, User Interface, comumente referido
como UI ) é sem dúvida vital para o produto final, e impacta significativamente a
experiência do usuário (comumente referida como UX) [14].
Para se ter uma ideia não somente da importância da UI mas também de seu
custo, a maior alocação de esforço no processo de construção de um software está
localizado exatamente no design e implementação da interface gráfica [15]. Conse-
quentemente, os SDKs tentam prover o desenvolvedor de muitas ferramentas para
facilitar e amenizar o custo desse processo.
A Google, por exemplo, tem sua própria design language, chamada Google Ma-
terial Design. Diz-se que uma design language - ou visual language - é um conjunto
de padrões, configurações e esquemas gráficos que norteia os produtos de uma linha
e, consequentemente, guia usuários e desenvolvedores. Microsoft, IBM, Apple entre
outras empresas também tem uma design language própria.
Veremos na próxima seção o porquê de a design language ser tão importante
para a experiência do usuário, e como o desenvolvimento h́ıbrido de aplicativos peca
criticamente neste quesito.
Nativo
No desenvolvimento nativo, a utilização da interface gráfica é muito simples e já
vem de fácil acesso nos SDKs. Consequentemente, a construção das telas em acordo
13
(a) Lista de e-mails (b) Lista de pastas
Figura 3.1: Sugestão do Material Design para listas. [4]
com a design language em questão é imediata.
Por exemplo, o Material Design da Google fornece padrões de cores, margens e
disposição de elementos no aplicativo. As Figuras 3.1a e 3.1b mostram alguns dos
padrões. Percebe-se que as margens à direita e à esquerda são iguais, e o padrão do
topo também, apesar dos apps de exemplo serem totalmente diferentes: o primeiro,
simula um app de e-mail, enquanto o último simula um explorador de arquivos.
Um outro exemplo está no site oficial da Apple para desenvolvedores. Na Figura
3.2, há a sugestão de que qualquer menu com opções de ação se abra na parte
inferior. Analogamente, o Android sugere que um menu com ações se abra na parte
superior ao final da toolbar localizada no topo da tela.
Estas configurações são muito importantes para a experiência do usuário, como
será relatado posteriormente neste trabalho. Um app com uma UX ruim tem
pouqúıssimas chances de ser bem sucedido, uma vez que a experiência do usuário é
a melhor métrica posśıvel de satisfação de um aplicativo.
14
(a) iOS [16] (b) Android [4]
Figura 3.2: Diferença de sub-menus
15
Hı́brido
O desenvolvimento hibrido, em contrapartida, não tem um padrão definido. Como
as principais tecnologias envolvidas para a maioria dos frameworks são HTML, CSS
e Javascript, cabe ao usuário a total criação da interface gráfica.
Na verdade, vê-se que é muito comum a utilização de frameworks dentro do
próprio framework, ou seja, utilizar algum segundo framework para lidar com a UI.
Por exemplo, o Mobile Angular UI baseado no framework bootstrap.
Na Figura 3.3 vê-se a diferença entre diferentes menus laterais de dois frameworks
diferentes: o primeiro que já vem como parte doIonic; e o segundo, da biblioteca
para UI Mobile Angular.
Claramente, não se assemelha às design languages nativas, porém ainda são
intuitivas aos usuários por conta de outros elementos: o śımbolo localizado no canto
esquerdo ao topo é comumente utilizado para indicar menu; as setas ao lado de cada
item do menu indicam que, se selecionado, o item levará o usuário a outra página;
e a diferente coloração de um dos itens do menu sugere seleção.
Esses aspectos acima citados fazem parte de uma design language universal, a
qual todas as outras espećıficas de cada SDK são baseadas.
No entanto, alguns outros frameworks encontraram meios de parecer o mais
nativo posśıvel. Entre outros, um exemplo é o Onsen UI [17], que oferece uma
compilação visual diferente para Android e iOS com o mesmo código.
3.2 Experiência do Usuário (UX)
A chamada UX (do inglês User eXperience) é estudada com o objetivo de aprimorar
ao longo do tempo a usabilidade e intuitividade da interação homem-máquina [20] .
Indubitavelmente, o design de interfaces é um desafio para qualquer desenvolve-
dor. A intenção na criação de interfaces é que elas sejam intuitivas o suficiente tal
que o usuário nem perceba que está lidando com uma máquina, isto é, o processo
de utilização de qualquer device deve ser o mais natural posśıvel.
As já citadas design languages tem como objetivo exatamente criar padrões bem
definidos para que os aplicativos se assemelhem em estrutura. A ideia é o usuário,
ao aprender a utilizar um aplicativo de um sistema, aprender a utilizar automatica-
mente todos.
Consequentemente, a experiência de usuário varia muito de sistema operacional
para sistema operacional. É esperado que usuários que já estão acostumados com o
iOS sintam muita diferença ao migrar para Android, por exemplo.
Por outro lado, é muito mais provável que usuários já acostumados com o Mate-
rial Design da Google tenham uma boa experiência com um novo aplicativo baixado
16
(a) Ionic [18] (b) Mobile Angular UI [19]
Figura 3.3: Exemplos de menus laterais em frameworks h́ıbridos
17
seguindo o padrão dessa design language, do que com um aplicativo que não siga
esse padrão.
Isso implica uma das maiores desvantagens do desenvolvimento h́ıbrido: a UX
de um app h́ıbrido será significativamente inferior à UX de um app nativo. Por mais
que se tente utilizar HTML, CSS e Javascript para criar apps muito semelhantes
a nativos, seria muito custoso e dif́ıcil conseguir um resultado exatamente igual.
E, mesmo se este resultado fosse conseguido, ele se assemelharia somente a um
tipo de visual language espećıfico. Por exemplo, se um app é disponibilizado na
Apple AppStore, Microsoft Store e Google Play mas seu design language é similar ao
Material Design da Google, a experiência de usuários da Apple e da Microsoft seria
muito ruim. Isso se dá porque eles não estão acostumados ao padrão de design da
Google, e sim ao de seus respectivos sistemas operacionais.
3.3 Desempenho
Outro item muito importante que impacta no sucesso de um produto é seu desem-
penho. Duas formas comumente usadas para medir desempenho são a latência e o
tempo de execução [21]. Basicamente, a latência diz respeito sobre o tempo relaci-
onado à comunicação do app com fontes externas (e.g. servidor na web). O tempo
de execução, por sua vez, está relacionado ao processamento local do código.
Apps nativos terão a melhor performance geral. Seu código já é, por definição,
compilado de forma ótima para o correspondente sistema operacional. Apps h́ıbridos
são interpretados: seu código é rodado por uma espécie de web browser. O web
browser, por sua vez, é rodado pelo sistema. Portanto, há uma camada adicional no
produto final do desenvolvimento h́ıbrido.
Essa camada adicional reflete um tempo de execução maior e consequentemente,
menor desempenho para h́ıbridos. Ademais, a latência de h́ıbridos também tem
maior probabilidade de ser maior, já que é pratica comum de apps h́ıbridos baixarem
pela rede partes de sua view, isto é, de elementos que serão mostrados na tela. Isso
acarreta maior tempo de comunicação (latência) e pode piorar a experiência do
usuário.
Um estudo [22] mostra o quão importante é a performance para usuários finais.
84% dos usuários avaliados julgam performance um fator importante. Além disso,
48% dos usuários responderam que estariam menos dispostos a utilizar um app
com UX ruim, 34% trocariam para o app do competidor e 31% recomendariam
negativamente para outros usuários. Finalmente, 24% dos participantes disseram
que olhariam para outros produtos da empresa sob uma perspectiva negativa e menos
dispostos a tentar outros produtos.
18
Consequentemente, o desempenho impacta diretamente a experiência do usuário
e pode ser fator decisivo para o sucesso de um aplicativo em relação ao seus compe-
tidores.
3.4 Segurança
Segurança é um fator que vem chamando bastante atenção no desenvolvimento mo-
bile. Apesar do crescimento considerável de aplicativos h́ıbridos devido ao baixo
custo de desenvolvimento, aplicativos nativos são mais seguros [23].
Esse fato ocorre pela maior integração que apps nativos tem com as features
do sistema - inclusive as relacionadas à segurança. Google, Apple e outras grandes
empresas de tecnologia vem adicionando mais e mais funcionalidades para diminuir
vulnerabilidades dos apps em seu sistema.
Por exemplo, apps Android são postos naturalmente nas chamadas sandboxes
[24], que isolam os dados de um app e sua execução do código de dados e execuções
de outros apps. Além disso, Android oferece um file system encriptado que pode
ser habilitado visando proteção em caso de perdas ou furtos. Também, ao lançar
aplicativos na loja oficial da Google, o usuário tem que explicitamente listar no
código-fonte da aplicação todas as permissões que o aplicativo tem que ter para seu
uso, e o usuário tem que aceitar uma a uma. Essas permissões incluem acesso ao
microfone, câmera, disco ŕıgido, internet etc.
Um outro exemplo são metodologias implementadas pela Apple para garantir a
autenticidade dos apps em sua loja. Uma delas é a chamada bootchain [25], em que
cada etapa do processo de load de um app no iOS contém componentes criptografa-
dos assinados somente pela Apple para garantir integridade. Outras técnicas estão
descritas na documentação oficial da empresa, e podem ser ressaltadas o Secure
enclave, Touch ID e Data Encrypting [25].
Mesmo com todos os avanços em segurança, hackers ainda exploram vulnerabi-
lidades em aplicações móveis.
3.5 Comunicação
A comunicação do app com fatores externos (como disco, banco de dados ou servi-
dores) se dá de forma similar nos paradigmas hibrido e nativo.
Disco
Aplicações nativas tem funcionalidades já embarcadas no SDK para acesso ao file
system. No entanto, a gigantesca maioria dos frameworks h́ıbridos também já fazem
19
o intermédio entre o sistema e o código interpretado.
Banco de Dados
O uso de banco de dados varia bastante de SDK para SDK. A plataforma Android,
por exemplo, oferece total suporte à bases de dados SQLite [26]. O sistema iOS
também oferece suporte ao SQLite.
O uso de bancos é recomendado para armazenamento de dados em quantidade
mais significativa. Para rápidos armazenamentos de objetivos primitivos, como in-
teiros, strings e booleans, costuma-se utilizar soluções mais performáticas como as
Shared Preferences (Android) e User Defaults (iOS). Como o nome sugere, é uma
forma de armazenamento muito utilizada para guardar dados de configurações do
usuário.
Em contrapartida, no caso de frameworks h́ıbridos, costuma-se utilizar as tec-
nologias IndexedDB, WebSQL e localstorage. Essas tecnologias são otimizadas para
web browsers, e como os apps são desenvolvidos para executar em uma espécie de
browser, essas opções acabam sendo boas soluções.
O IndexedDB é um banco de dados baseado em Javascript e orientadoa objetos.
Essa implementação substitui a antiga WebSQL, que teve seu suporte descontinuado
pela W3C. O localstorage por sua vez é uma API leve para armazenamento de
pequenas quantidades de dados, mas seu acesso se dá de forma śıncrona, o que pode
ser bem problemático visto que isso causa o travamento da interface gráfica até que
a comunicação seja finalizada.
Servidores
Como visto no Caṕıtulo 2, a comunicação com os servidores se dá majoritariamente
por dois paradigmas: Simple Object Access Protocol (SOAP) ou Representational
state transfer (REST).
Não há diferença na comunicação com APIs externas no caso de desenvolvimento
nativo contra h́ıbrido, uma vez que ambos são capazes de se comunicar normalmente
sem consideráveis diferença no processo.
3.6 Testes Automatizados
Um fator extremamente importante no processo de desenvolvimento são os testes
automatizados. Na verdade, testes automatizados não agregam valor para o usuário
diretamente, mas sim indiretamente.
Testar o aplicativo de forma efetiva impede que bugs sejam embarcados com novas
atualizações e assegura que o aplicativo sempre funcione como preestabelecido. Isso
20
inclui monitoramento de consumo de energia, monitoramento de desempenho do
app, segurança de que a UI se comporta de maneira correta, certeza que lógicas de
negócio ainda são cumpridas entre outros. [27]
Há diversos tipos de testes automatizados, dos quais podemos citar testes
unitários, testes funcionários e testes de interface gráfica. Neste trabalho, cobri-
remos somente o escopo de testes unitários e de interface gráfica.
3.6.1 Testes unitários
Testes unitários têm como objetivo testar unidades lógicas de negócio de um pro-
grama, isto é, testar as menores partes de um programa e assegurar que elas funcio-
nam corretamente. A ńıveis práticos, essas pequenas partes podem ser um conjunto
de classes ou uma única classe somente [28], tal que seus métodos sejam assegurados
de funcionalidade.
Em termos de desenvolvimento para dispositivos móveis, existem vários fra-
meworks para testes unitários.
Frameworks nativos
Para Android, o JUnit já é disponibilizado como framework padrão para testes
unitários. Além disso, a documentação oficial da Google sugere a utilização do
framework Mockito para satisfazer eventuais dependências que os testes possam vir
a ter. O sistema operacional da Apple também já disponibiliza ferramentas para
testes unitários junto com o SDK pelo framework XCTest, assim como o Windows
Phone comporta ferramentas no conjunto de bibliotecas padrão do Visual Studio
(Microsoft.VisualStudio.TestPlatform.UnitTestFramework).
Frameworks h́ıbridos
No desenvolvimento h́ıbrido, é muito comum utilizar ferramentas de teste unitário
voltadas para Javascript, especialmente à Angular - framework vastamente utilizado
para desenvolvimento h́ıbrido.
Um exemplo é o QUnit, que funciona muito bem com Apache Cordova e Phone-
Gap.
3.6.2 Testes de aceitação
Os testes de aceitação têm como objetivo testar a interface gráfica do aplicativo,
simulando o operacional de um usuário. Consequentemente, o teste assegura que a
interface gráfica funcione de forma esperada e exiba informações de forma devida.
21
No entanto, não é papel dos testes de interface gráfica testar a lógica de negócios
que acontece por trás no código. Este é um erro muito comum quando se trata de
testes automatizados, visto que eles abordam a aplicação de forma end-to-end, isto
é, simula totalmente a operação de um usuário do ińıcio ao fim [29].
O ideal é se testar toda lógica de negócios unitariamente, e fazer poucos testes de
tela, visto a grande demora na execução dos testes de tela e baixa manutenibilidade.
Frameworks nativos
Para testes de tela nativo em Android, existem algumas opções, das quais a Google
recomenda o framework chamado Espresso [30]. Esse framework tem um código
muito simples e intuitivo, sendo fácil escrever códigos de tela utilizando ele. Em
contrapartida, uma outra opção é o Robotium, em que é posśıvel gravar os passos
a partir utilizando o Robotium Recorder. Portanto, utilizando esta abordagem, fica
mais rápido de se criar testes, mas mais dif́ıcil de mantê-los.
Os testes automatizados para iOS e Windows Phone seguem uma linha parecida
com o Robotium. O framework para o sistema operacional da Apple é o mesmo
utilizado para testes unitários (XCTest) e permite gravar passo a passo a simulação
do usuário. Para o sistema da Microsoft, utiliza-se o CodedUI, que é disponibilizado
por padrão em edições Enterprise e superiores do Visual Studio.
Frameworks h́ıbridos
Para testes de tela de apps h́ıbridos, pode-se citar os frameworks Appium, Calabash,
Frank e MoneyTalk, dentre outros. Esses frameworks também funcionam para testes
de apps nativos, mas como as empresas mantenedores oferecem soluções próprias,
elas acabam sendo preferidas em relação a estes.
22
Caṕıtulo 4
Implementação
Visto todos os conceitos básicos descritos no caṕıtulo 2 e as visões mais aprofundadas
sobre os aspectos de desenvolvimento h́ıbrido e nativo no capitulo 3, a intenção agora
é detalhar cada item da implementação do app deste trabalho.
Com base no que foi visto sobre o produto final resultante do desenvolvimento
h́ıbrido comparado ao do desenvolvimento nativo, a decisão tomada foi seguir o
paradigma nativo. Foi considerado que a melhor combinação de UX, desempenho e
segurança só seria atingida com poder total sobre as funcionalidades do smartphone
e acesso direto à visual language do sistema.
Como o intuito é ser o aplicativo oficial da Universidade Federal do Rio de Ja-
neiro - uma das maiores universidades do páıs - julga-se necessária a busca pelo
melhor produto para o usuário final posśıvel. O ponto negativo deste tipo de desen-
volvimento é o custo envolvido, que não é tão significativo tomada a proporção da
UFRJ no cenário nacional.
Com a decisão de criação do aplicativo nativo, um sistema operacional de ińıcio
deve também ser escolhido. Com base na análise de market share disposta na Figura
2.1, o sistema operacional Android impactaria o maior número absoluto de pessoas.
Portanto, justifica-se assim a escolha da utilização do Android SDK para o de-
senvolvimento do software referenciado neste trabalho.
4.1 Visão geral
O funcionamento geral do aplicativo pode ser visto na Figura 4.1. O aplicativo faz
requisições HTTP para uma API RESTful. Essa API foi feita exclusivamente para
consumo de dados desse aplicativo móvel. É importante ressaltar que essa API não
foi, até o momento de escrita deste trabalho, disponibilizada ao público.
O aplicativo faz requisições GET e POST para a API, e esta por sua vez recupera
os dados do SIGA. Todo o framework web em que o SIGA e a API são desenvolvidos
23
Figura 4.1: Diagrama geral
utilizam a linguagem de programação Java, e portanto, toda a informação no lado
do servidor é abstráıda como objetos Java.
A API é uma extensão dos módulos do sistema, de forma que consiga traduzir
objetos Java internos ao sistema para informações serializadas em JSON.
O aplicativo - ou qualquer outro consumidor de uma API - espera dados repre-
sentados em alguma notação universal - como o XML ou o já citado JSON. Nesse
esquema, fica claro que a API serve como uma interface de comunicação entre dois
sistemas, transformando as requisições HTTP em chamadas espećıficas à compo-
nentes do sistema acadêmico, e traduzindo o resultado dessas chamadas em uma
notação abstrata universal - nesse caso, o JSON.
O desenvolvimento total do aplicativo durou 7 meses. Nas próximas seções, serão
detalhadas com profundidade os componentes do aplicativo e o que influenciou cada
decisão tomada.
No total, o aplicativo tem 8 telas: tela de login, menu principal, explorador de
arquivos, salas de aula, adicionar pedidos de inscrição, visualizar/alterar pedidos e
trancar inscrições, buscardisciplinas e confirmação de envio de pedidos de inscrição.
O publico-alvo do aplicativo são estudantes da UFRJ. As funcionalidades inclusas
são referentes a documentos, salas de aula e inscrição. Os documentos dispońıveis
para download são dispostos na Lista 4.1.
4.2 Interface Gráfica (UI )
A interface gráfica do aplicativo foi feita seguindo a design language da Google. Toda
disposição de itens no aplicativo segue os padrões do Material Design, como será
demonstrado nesta seção.
4.2.1 Página Inicial
A página inicial do app é exposta na Figura 4.2a
24
(a) Página inicial do app. (b) Padrões do Material Design [4]
Figura 4.2: Aplicação do Material Design na prática
25
• Boletim
• Boletim de Orientação Acadêmica(BOA)
• Histórico
• Confirmação de Registro de Inscrição em Disciplinas (CRID)
• Confirmação de Registro de Pedido de Inscrição em Disciplinas (CRPID)
• Declaração de Bolsista
• Declaração de Cotista
• Declaração de Nome Social
Lista 4.1: Documentos dispońıveis para download
O botão disposto na parte inferior com o simbolo de + é chamado de Floating
Action Button (FAB). Seguindo a visual language em questão, este botão é recomen-
dado para a ação mais utilizada na tela. Na tela em questão, é a ação de realizar
um novo login, podendo adicionar contas à lista de contas salva no processo..
Ao topo, há uma barra (denominada toolbar) com um śımbolo lateral de três
barras. Este śımbolo indica que há um menu lateral dispońıvel, como explicitado
pela Figura 4.3a. À esquerda da toolbar também existe um śımbolo de três pontos
na vertical, que indica que há um sub-menu com ações dispońıveis, como disposto
pela Figura 4.3b
Vê-se também que as dimensões do FAB são idênticas, assim como as dimensões
da toolbar ao topo. Além disso, as margens à direita do botão também são idênticas.
Como citado na seção 3.1, todos esses fatores são dispostos de forma funcional e
prática para o desenvolvedor através do próprio SDK. Evidentemente, o programa-
dor pode customizar à seu modo. No entanto, é extremamente simples a criação de
telas em conformidade com a design language em questão.
Um ponto interessante a se notar é o śımbolo de engrenagem à direita do item
da lista. A engrenagem é um śımbolo universal utilizado para indicar que há opções
dispońıveis de configurações ou ações adicionais que podem ser executadas. No caso,
são opções de remoção ou edição de algum item da lista (mudar os dados salvos).
4.2.2 Menu Principal & Explorador de Arquivos
O app tem em seu interior, um explorador de arquivos próprio, tal que facilite o
acesso do usuário a qualquer arquivo baixado por dentro do aplicativo. No caso
do Sistema Integrado de Gestão Acadêmica, esses arquivos são costumeiramente
documentos acadêmicos como boletins, histórico escolar e comprovante de inscrição
26
(a) Menu lateral (b) Sub-menu com ações
Figura 4.3: Detalhamento de menus dispońıveis no app
27
(a) Tab 1 : menu principal (b) Tab 2 : explorador de arquivos
Figura 4.4: Páginas iniciais do app
em disciplinas; documentos oficiais como comprovante de matŕıcula; e declarações
da universidade como certificado de bolsista.
O explorador de arquivos é uma lista de itens. Entretanto, preferiu-se por cus-
tomizar o ı́cone: em vez de seguir o padrão do Material Design de uniformizar os
ı́cones no formato circular, como na Figura 3.1, foi seguido o padrão de ı́cones no
formato quadrado. Ícones quadrados são um grande legado do inicio da adoção de
computadores pessoais, principalmente no sistema operacional Windows. Portanto,
apesar de fugir da linguagem visual da Google, ainda se faz intuitivo ao usuário.
No canto inferior direito da tela do explorador de arquivos, está localizado um
FAB com a opção de deletar os arquivos salvos. O FAB some ao mover a tela para
a aba Sistemas.
O menu principal, demostrado na Figura 4.4a, mostra as opções dispońıveis para
o usuário logado. As opções variam de acordo com o usuário. Por exemplo, se o
usuário for bolsista, terá a opção de download de comprovação de bolsista.
28
Figura 4.5: Tela de turmas
Além disso, foi adicionado para as opções Salas de Aula e Inscrição uma seta à
direita para demonstrar que o usuário sairá da tela atual e irá para outra.
Para cada item do menu, uma ação correspondente é executada: ao clicar em
algum documento, o mesmo é baixado; ao clicar na opção de Salas de Aula, o usuário
é direcionado para a tela com as informações de sala; e ao clicar em Inscrição, o
usuário irá para a tela de inscrição em disciplinas.
4.2.3 Salas de Aula
Uma das funcionalidades do app é mostrar ao usuário suas salas de aula. A página é
simples e segue os padrões da Google, principalmente por conta do uso dos cardviews.
Os cardviews são recomendados quando o tamanho do conteúdo é variável, além
de fazer parte da linguagem visual geral da Google [31]. Cardviews têm sido tão
utilizado pela Google que até websites responsivos para desktop o utilizam.
Na Figura 4.5, vê-se um exemplo real do uso da página. O primeiro cardview
29
foi ampliado - através de um toque - e os demais permaneceram colapsados. O
estado padrão dos cardviews é colapsado, tal que a tela não fique polúıda assim que
iniciada.
O tamanho de cada cardview pode variar muito visto que existem matérias com
muitos horários diferentes. Há matérias registradas no SIGA com mais de 30 horários
diferentes, tal que o carview expanda consideravelmente. Portanto, ao iniciar colap-
sado, a identidade visual da página é preservada.
O detalhe ao topo também faz parte do Material Design: a seta à esquerda se
contrapõe à seta à direita do item Salas de Aula do menu principal (Figura 4.4a),
tal que se torna intuitivo ao usuário como a navegação se dá.
4.2.4 Inscrição em Disciplinas
O aplicativo também oferece os serviços de Inscrição, Alteração e Trancamento de
Disciplinas. Esse serviço, através do website do Portal Aluno, é extremamente ori-
entado a mouse. A intenção era fazer no app um serviço totalmente orientado a
toque. Por um lado, peca-se na visualização da grade horária. Por outro, ganha-se
em UX no processo do uso do serviço.
A tela também faz uso de cardviews pelo mesmo motivo citado na seção da tela
de salas de aula: as informações são expanśıveis e variáveis. Ao final de cada item,
temos o śımbolo de relógio com uma seta na parte de baixo. Intuitivamente, passa-se
a informação de que o carview expande com informações sobre horários da disciplina
em questão.
Na segunda tab, há informações sobre o status de cada pedido de inscrição. O
esquema seguido é muito similar ao da primeira tab.
É importante mencionar que a disposição de elementos, apesar de diferentes,
seguem a mesma estrutura do menu inicial (Figura 4.4a): toolbar ao topo com opções
correspondentes da página; duas tabs sobre informações relacionadas dividindo o
layout; e itens dispostos verticalmente.
4.3 Experiência do Usuário (UX)
Nesta seção, será disposto elementos-chave que visam a melhor experiência do
usuário. O aplicativo, por sua natureza nativa, já tem uma performance muito boa
tal que não haja travamentos de tela nem delays nas transações de uma atividade
para outra. No entanto, isso não garante que o usuário terá uma boa experiência.
30
(a) Tab 1 : adicionar pedidos (b) Tab 2 : visualizar ou alterar pedidos
Figura 4.6: Páginas de inscrição do app
31
4.3.1 Norman’s Design Principles
Com isso em mente, a arquitetura da UI foi feita seguindo os prinćıpios de design
de Norman [32].
Os prinćıpios estão listados abaixo.
Prinćıpios de Design de Norman
• Visibilidade
• Feedback
• Restrições
• Mapeamento
• Consistência
• Affordance
Cada item refere-se a um aspecto que interfaces homem-máquina devem ter paraatingir melhor usabilidade.
Visibilidade
Como o nome sugere, as funções as quais o usuário pode usufruir devem estar tão
viśıveis quanto posśıvel. Quando muito escondidas (como exemplo, dentro de sub-
menus dentro de menus), torna-se muito trabalhoso para o usuário encontrar alguma
funcionalidade que deseja usar.
No aplicativo, foi tentado colocar todas as funcionalidades que o usuário tem
a disposição na tela em si, e não dentro de menus. Todas as ações são acessadas
através da toolbar do app, localizada ao topo.
Como exemplo, a Figura 4.9 mostra diferentes toolbars em telas do aplicativo,
mostrando ao usuário o que é posśıvel fazer de acordo com aquele contexto.
Outro ponto importante é a página inicial, onde o usuário informa as credenciais
para autenticação. Nesta página, é disposto o status do sistema com um sinal indi-
cando disponibilidade, instabilidade ou indisponibilidade. Dessa forma, assim que o
usuário abre o aplicativo, ele já tem noção se será posśıvel conectar aos servidores.
Caso apareça status instável, o usuário já espera que certas tarefas demorem mais
que o normal para ser completadas, ou talvez não estejam acesśıveis no momento.
Caso seja status indispońıvel, o usuário já terá noção que deve tentar mais tarde.
Os status e suas representações estão expostos na Figura 4.7
Por conta da API ser modularizada no servidor, ou seja, os diferentes compo-
nentes utilizados para constituir o SIGA não dependerem entre si, é posśıvel que o
módulo de Documentos esteja funcionando corretamente mas o módulo de Inscrição
32
(a) Online (b) Instável
(c) Indispońıvel (d) Carregando
Figura 4.7: Feedback sobre o status dispońıveis
não. O status do sistema é então conseguido tratando a response obtida a partir de
requests para cada módulo utilizado.
Feedback
O prinćıpio de feedback sugere que para toda ação que o usuário executar, deve
haver algum retorno de informação indicando o efeito dessa ação. Por exemplo,
ao se discar um número no telefone fixo, há um som indicando que a tecla foi
pressionada. Analogamente, em smartphones, costuma haver uma suave vibração
na ponta do dedo do usuário.
O app provê feedback de várias formas. Destaca-se que, enquanto qualquer re-
quest ao servidor estiver sido feito e aguardando uma response, um śımbolo de loading
é posto na tela, como nas Figuras 4.7d e 4.8.
Assim que uma response é recuperada com sucesso, o usuário é notificado com
um śımbolo verde comumente usado como status OK.
Em adição, o Android por default já muda a cor de itens de listas quando tocados
ou pressionados, tal que os desenvolvedores não precisem implementar os feedbacks
mais imediatos como este.
Restrições
Para que uma interface seja a mais intuitiva posśıvel para o usuário, é bom que
haja um - e somente um - modo de executar cada tarefa. Dessa forma, restringir o
usuário pode leva-lo rapidamente e intuitivamente a tentar de outra maneira. Por
exemplo, construir um espaço para o cartão de memória em uma máquina fotográfica
33
(a) Autenticando usuário (b) Carregando página de inscrição
Figura 4.8: Dialogs sobre o status das requests.
que trave quando o cartão é posto do lado errado faz o usuário intuitivamente não
tentar forçar o cartão nesta posição, e procurar alternativas.
O app restringe usuários de opções que não seriam posśıveis por conta de algum
motivo espećıfico. Por exemplo, se o usuário tem uma matéria trancada, a única
opção posśıvel para ele é destranca-la (desde que dentro do peŕıodo de datas em que
isto é posśıvel). O mesmo vale para uma matéria não trancada. A Figura 4.9 expõe
esse prinćıpio. Dessa forma, é evitado que o usuário tente realizar alguma ação que
não é viável naquele momento.
Mapeamento
O mapeamento refere-se à uma conexão entre itens da interface gráfica e o mundo
real. Por exemplo, no teclado de um notebook existe uma tecla com um śımbolo
de mega-fone com várias ondas saindo dele; e outra com poucas ondas. Há dois
mapeamentos com o mundo real nesse caso: o mega-fone indica sáıda de áudio,
portanto, as teclas devem estar relacionadas com a sáıda de áudio do aparelho; e
a quantidade de ondas sugere maior quantidade ou menor quantidade de algo, no
caso, de ”barulho”. Portanto, é fácil chegar à conclusão de que as teclas se referem
ao volume do dispositivo.
Uma aplicação do mapeamento na implementação do aplicativo foi a escolha
das cores para o status do sistema, como demostrado nas Figuras 4.7a, 4.7b e 4.7c.
As cores são intuitivas principalmente por conta das cores do semáforo: verde para
livre, amarelo para atenção e vermelho para parar, não continuar.
34
(a) Restrição à opção de trancamento (b) Restrição à opção de destrancamento
Figura 4.9: Opções para o peŕıodo de trancamento.
35
Consistência
O prinćıpio da consistência sugere que o método para atingir algum resultado seja
o mesmo por toda a aplicação. Por exemplo, se em determinada tela o usuário
precisar tocar rapidamente sobre um item para selecionar esse item em uma lista,
seria inconsistente se em outa tela ele devesse tocar e segurar.
Cada tela do app se comporta de maneira semelhante. A Figura 4.4a por exem-
plo, exemplifica este caso. Para os itens sem seta, a ação mais esperada (download do
documento) é iniciada imediatamente. Os itens com seta indicam que outra página
irá se abrir.
Affordance
O termo affordance não tem uma tradução literal para o português mas está rela-
cionado com a capacidade de um objeto de transmitir a maneira em que se deve
interagir com ele. Um exemplo simples são teclas em um teclado, que sugerem ser
pressionadas por conta de seu ligeiro alto relevo.
Itens dispostos em lista e ações na toolbar são em de acordo com a visual language
da Google e se tornam intuitivas para o usuário. No caso de um usuário novo, a
ambientação com o sistema Android é necessária, mas por ser algo viśıvel e com
feedbacks presentes, ela se torna rápida.
4.4 Desempenho
O desempenho do app é consideravelmente alto por conta de dois fatores: sua natu-
reza nativa, que maximiza todas as otimizações feitas pelo SDK do Android, e sua
simplicidade.
O aplicativo não utiliza nenhum banco de dados local, visto sua natureza sta-
teless. A única informação guardada pelo aplicativo são tokens de autenticação, e
todo resto do processamento é feito no server-side, isto é, no servidor.
Somado a esse fato, o app não acessa servidores internacionais ou faz chamadas
de longa duração. Os servidores são dispostos próximos de onde a maioria dos
usuários utilizam e todas as chamadas têm tráfego baix́ıssimo de dados, visto a
natureza de comunicação REST ful utilizando JSON. A comunicação do aplicativo
será mais aprofundada na seção sobre este assunto mais a frente.
Portanto, a latência - como visto na seção 3.3 - é mı́nima. Ademais, o tempo de
execução é baix́ıssimo, visto que não há código interpretado em runtime momento
algum.
36
4.5 Segurança
O aplicativo utiliza técnicas para evitar a utilização de engenharia reversa. A Go-
ogle oferece ferramentas built-in com esta finalidade, além de existir frameworks
proprietários também com este fim. Um bom exemplo são os ofuscadores de código,
que geram um código totalmente ileǵıvel por humanos mas funcional da mesma
maneira.
Além disso, o app usufrui de todas as medidas de segurança providas pelo sis-
tema operacional (como as sandboxes citadas na seção 3.4). Todas as informações
salvas pelo aplicativo, que são as informações de login e senha do usuário, são crip-
tografadas. É importante frisar que essas informações só são guardadas se for de
escolha do usuário.
4.6 Comunicação
Para o aplicativo funcionar, foi estruturada uma API REST ful privada nos servi-
dores da UFRJ. Por ser REST ful, a API não guarda dados sobre os usuários que a
acessam, com exceçãode dados que sejam necessários como parâmetro de algumas
requests, como matŕıcula e eventuais tokens de autenticação.
Toda comunicação é feita em JSON, por conta da simplicidade de uso e menor
overhead (resultando em maior performance). Para o parsing de dados, foi criado
um JSON parser que trata os dados vindos do servidor. Toda lógica é testada via
testes unitários para assegurar a qualidade do comportamento das regras de negócio.
Um exemplo de response da API do servidor está disposto abaixo, além de como
se extrai informação dessa response. O exemplo de JSON de turma é tratado e
disposto em um objeto do tipo org.json.JSONObject. O pacote org.json já é incluso
por padrão no SDK do Android. Para recuperar informações como o código da
turma, é utilizado o método getString, como exemplificado no Arquivo 4.2. Para re-
cuperar os demais elementos do JSON, métodos semelhantes são utilizados: sempre
recuperando o valor pela chave correspondente.
37
Arquivo 4.1: JSON retornado ao recuperar uma sala de aula
{
” cod igo ” : ”EEL874” ,
” i n f o ” :
{
” loca lD iaSemana ” :
[
{ ” andar ” : ”02” ,
” b l o co ” : ”H” ,
” ho ra r i oF im ” : ” 12 :00 ” ,
” diaSemana ” : ”Seg” ,
” h o r a r i o I n i c i o ” : ” 10 :00 ” ,
” l o c a l i z a c a o ” : ” E s co l a P o l i t e c n i c a ” ,
”numero” : ” 0213 ”
} ,
{ ” andar ” : ”02” ,
” b l o co ” : ”H” ,
” ho ra r i oF im ” : ” 12 :00 ” ,
” diaSemana ” : ” Sex ” ,
” h o r a r i o I n i c i o ” : ” 10 :00 ” ,
” l o c a l i z a c a o ” : ” E s co l a P o l i t e c n i c a ” ,
”numero” : ” 0213 ”
}
] ,
” nomeCursoOferec ido ” : ” Engenhar i a de Computacao e In fo rmacao ” ,
” n o m e D i s c i p l i n a ” : ” I n t e l i g e n c i a A r t i f i c a l ”
}
}
Arquivo 4.2: Exemplo de parsing do JSON
JSONObject j s o n = new JSONObject ( . . . ) ;
S t r i n g cod igo = j s o n . g e t S t r i n g ( ” cod igo ” ) ;
4.7 Testes Automatizados
Para manter a lógica dos testes com qualidade, melhorar a manutenibilidade e au-
xiliar novos programadores sobre as funcionalidades do app, foram feitos testes au-
tomatizados extensivos por toda aplicação.
Para a lógica de negócios, foi utilizado o framework JUnit para testes unitários.
Para testes de UI, optou-se pelo Espresso, que é um framework desenvolvido espe-
cialmente para testes em Android.
38
4.7.1 Testes Unitários
Os testes unitários foram realizados com o aux́ılio da biblioteca Mockito. Essa
biblioteca permite criar objetos manipuláveis que seriam muito trabalhosos de criar
”na mão”, e com isso, testar lógicas internas do software.
Um exemplo de teste envolvendo Mockito está disposto abaixo, fornecido pelo
website do framework [33].
L i n k e d L i s t mockedL i s t = mock ( L i n k e d L i s t . c l a s s ) ;
// s t ubb i ng appea r s b e f o r e the a c t u a l e x e c u t i o n
when ( mockedL i s t . ge t (0 ) ) . thenReturn ( ” f i r s t ” ) ;
// the f o l l o w i n g p r i n t s ” f i r s t ”
System . out . p r i n t l n ( mockedL i s t . ge t (0 ) ) ;
// the f o l l o w i n g p r i n t s ” n u l l ” because ge t (999) was not s tubbed
System . out . p r i n t l n ( mockedL i s t . ge t (999) ) ;
Como pode ser visto, uma LinkedList jamais foi realmente criada. Não há uti-
lização do operador new em lugar algum, nem a adição do item ”first” à lista.
Entretanto, o objeto criado ainda funciona de acordo com o esperado.
Esta técnica pode ser muito útil ao testar lógicas internas que dependem de
objetos mais complexos.
4.7.2 Testes de Aceitação
Os testes de UI, comumente referidos como testes de aceitação, têm como objetivo
garantir que a interface gráfica se comporta da maneira esperada e monitorar se há
mudança de performance das telas do aplicativo ao longo do tempo.
Isso significa que se algum teste falha, provavelmente alguma funcionalidade da
tela deveria ter acontecido mas não aconteceu. Por exemplo, se ao se clicar em
certo botão, um dialog de confirmação deveria aparecer - mas não apareceu - o teste
reportará falha. Ao passo que, se não há adição de novo testes ou mudança no
emulador do Android e o tempo de execução dos testes começa a aumentar muito,
provavelmente adicionou-se algum algoritmo novo ou código que está prejudicando
a performance geral do app em certa tela.
Para criação dos testes automatizados, utilizou-se a biblioteca Espresso. Essa
biblioteca tem uma maneira de escrita incrivelmente fácil e intuitiva, assim como o
Mockito.
Um exemplo de teste feito com Espresso está disposto abaixo. O exemplo foi
retirado da documentação oficial da biblioteca [30].
39
@Test
pub l i c void g r e e t e r S a y s H e l l o ( ) {
onView ( w i t h I d (R . i d . n a m e f i e l d ) ) . pe r fo rm ( typeText ( ” Steve ” ) ) ;
onView ( w i t h I d (R . i d . g r e e t b u t t o n ) ) . pe r fo rm ( c l i c k ( ) ) ;
onView ( wi thText ( ” H e l l o Steve ! ” ) ) . check ( matches ( i s D i s p l a y e d ( ) ) ) ;
}
Analisando o código, vê-se que inicialmente, o Espresso performa escrita do texto
Steve na View com id name field; depois, performa um clique na View com id greet -
button; e finalmente, checa se alguma view com o texto Hello Steve! foi mostrada
na tela.
O código é simples e parece uma frase normal escrita em inglês. Essa biblioteca
foi escolhida para os testes de tela por conta da simplicidade de escrita, ótima
funcionalidade, recomendação do Google e performance.
O aplicativo tem 141 testes automatizados utilizando o Espresso. O tempo médio
de execução de todos os testes é de 3 minutos e 30 segundos, o que traduz uma média
de 1.4 segundo por teste. Em contexto de testes de aceitação, é uma performance
muito boa.
40
Caṕıtulo 5
Resultados
O app final está em produção desde fevereiro de 2016. A avaliação geral do app no
dia 9 de janeiro de 2017 é de 4, 715 em uma escala de 1, 0 até 5, 0.
5.1 Estat́ısticas
O aplicativo conta com mais de 15 mil instalações totais. Todas as estat́ısticas
apresentadas neste trabalho são fornecidas pelo Google Developer Console, que é a
plataforma por onde se publica apps na Google Play Store.
Há um fenômeno interessante ao analisar as estat́ısticas providas. Usuários cos-
tumam desinstalar o aplicativo durante os meses durante o peŕıodo, mas há súbitos
picos de downloads nas datas de final e ińıcio de peŕıodos. A explicação é que o
acesso ao sistema acadêmico é muito reduzido durante o peŕıodo, porém com a ne-
cessidade de visualizar notas, aprovações e reprovações, além de inscrição, alteração
e trancamento de disciplinas, os acessos aos finais dos termos acadêmicos aumentam
significativamente.
A avaliação dos usuários, como citado, foi excelente. A Figura 5.1 foi retirada
do Google Developer Console e confere estat́ısticas sobre a avaliação dos usuários,
como quantidade de avaliações e o rating de cada uma.
Como pode ser visto aproximadamente 83% das avaliações foi a nota máxima
Figura 5.1: Avaliação dos usuários.
41
Figura 5.2: Total de instalações por usuário.
posśıvel (exposta como 5), e 93% das avaliações totais foi de 4 ou 5.
A Figura 5.2 mostra o número total de usuários únicos que já instalaram o app
em algum dispositivo. Vê-se um crescimento constante no número de usuários que
fazem o download do aplicativo, com exceção de um ponto em abril/2016. Neste
mês, mais especificamente no dia 12 de abril, foi enviado um e-mail através do
SIGA informando sobre o aplicativo. Até então, ele não tinha sido divulgado de
forma oficial, e esta é a razão do pico de downloads no peŕıodo.
A Figura 5.3, também disponibilizado pelo console da Google, mostra a quanti-
dade de downloads de acordo com a localidade. Vê-se que, como esperado, o Brasil
é o principal local de onde o app é baixado, com uma porcentagem de 98.02% do
total de downloads. No entanto, outros páıses, como os Estados Unidos, França e
Portugal, também tem participação no gráfico.Isso sugere que alunos da UFRJ
em intercâmbio acadêmico também utilizam o aplicativo no peŕıodo em que estão
no exterior, indicando que o produto final agrega valor para os estudantes em seu
tempo fora.
42
Figura 5.3: Instalações do app por páıs.
43
Caṕıtulo 6
Conclusões e Trabalhos Futuros
6.1 Conclusões
Como analisado nos Caṕıtulos 2 e 3, o desenvolvimento utilizando a abordagem
nativa garante o melhor desempenho e experiência do usuário posśıvel. Esses dois
fatores contribuem com um peso muito grande para a aceitação do produto final,
como explicitado na Seção 3.3.
O grande ponto negativo da abordagem nativa é o custo da operação. É ne-
cessário desenvolver o mesmo produto várias vezes: uma para cada plataforma esco-
lhida. Outro problema é a manutenibilidade, visto que será necessária uma equipe
especializada em cada SDK de cada sistema operacional para que o produto con-
tinue a receber atualizações e eventuais correções de bugs. Todo este processo é
custoso não somente com relação a dinheiro mas também a tempo.
Em contrapartida, a abordagem h́ıbrida web oferece soluções mais baratas: re-
quer equipes menores e espaços de tempo menores para lançamento e atualização
dos produtos, visto que se trabalha somente com um código base. No entanto a
experiência do usuário é significativamente inferior quando comparada à abordagem
nativa.
Um outro ponto negativo da abordagem h́ıbrida web é que não existe um fra-
mework oficial para este tipo de desenvolvimento, e considerando a possibilidade
de surgimento de vários novos frameworks ao longo do tempo, a decisão de qual
framework utilizar para desenvolver um produto, pensando no longo prazo, é uma
decisão grande a se tomar.
Portanto, o desenvolvimento nativo leva a maior vantagem na maioria dos que-
sitos analisados, como interface gráfica, experiência do usuário, segurança e per-
formance, levando ao melhor produto final posśıvel, apesar do considerável maior
custo.
44
6.2 Trabalhos Futuros
O próximo passo depois da release da versão Android foi o desenvolvimento do app
para iOS, o segundo maior market share como conferido pela Figura 2.1. Dessa
forma, a grande maioria dos alunos é atendida com aplicativos com a maior perfor-
mance e satisfação de experiência de usuário posśıvel.
Além disso, com as tecnologias utilizadas e o aplicativo já em produção e devi-
damente testados, há a abertura para expansão do conceito para escopos diferentes
do SIGA. Um exemplo é estender as funcionalidades para utilização de professores e
coordenadores de curso da UFRJ, assim como algumas funcionalidades de técnicos-
administrativos.
45
Referências Bibliográficas
[1] MARCIO, F. “Blog Licenciados em Graduação UFRJ”. . https://
licenciadosemgraduacaoufrj.wordpress.com/, 2005.
[2] A-TEAM ORACLE. “Performance Study – REST vs SOAP for
Mobile Applications”. . http://www.ateam-oracle.com/
performance-study-rest-vs-soap-for-mobile-applications/,
feb. 2015. Acessado em Janeiro de 2017.
[3] INFOQ. “Is REST Successful in the Enterprise?” . https://www.infoq.com/
news/2011/06/Is-REST-Successful, jun 2011. Acessado em Janeiro de
2017.
[4] GOOGLE. “Google Material Design website”. . https://
material.io/guidelines/layout/metrics-keylines.html#
metrics-keylines-keylines-spacing, . Acessado em Janeiro de
2017.
[5] VALOR. “Número de usuários de smartphones no Brasil cresce 483o
trimestre”. . http://www.valor.com.br/empresas/4327844/
numero-de-usuarios-de-smartphones-no-brasil-cresce-48-no-3-trimestre,
nov. 2015.
[6] STATISTA. “Number of available applications in the Go-
ogle Play Store from December 2009 to December
2016”. . https://www.statista.com/statistics/266210/
number-of-available-applications-in-the-google-play-store/.
Acessado em Janeiro de 2017.
[7] “Number of available apps in the Apple App Store from July 2008 to
January 2017”. . https://www.statista.com/statistics/263795/
number-of-available-apps-in-the-apple-app-store/.
[8] IDC. “Smartphone OS Market Share, 2016 Q3”. . http://www.idc.com/
prodserv/smartphone-os-market-share.jsp, nov. 2016. Acessado em
Janeiro de 2017.
46
https://licenciadosemgraduacaoufrj.wordpress.com/
https://licenciadosemgraduacaoufrj.wordpress.com/
http://www.ateam-oracle.com/performance-study-rest-vs-soap-for-mobile-applications/
http://www.ateam-oracle.com/performance-study-rest-vs-soap-for-mobile-applications/
https://www.infoq.com/news/2011/06/Is-REST-Successful
https://www.infoq.com/news/2011/06/Is-REST-Successful
https://material.io/guidelines/layout/metrics-keylines.html#metrics-keylines-keylines-spacing
https://material.io/guidelines/layout/metrics-keylines.html#metrics-keylines-keylines-spacing
https://material.io/guidelines/layout/metrics-keylines.html#metrics-keylines-keylines-spacing
http://www.valor.com.br/empresas/4327844/numero-de-usuarios-de-smartphones-no-brasil-cresce-48-no-3-trimestre
http://www.valor.com.br/empresas/4327844/numero-de-usuarios-de-smartphones-no-brasil-cresce-48-no-3-trimestre
https://www.statista.com/statistics/266210/number-of-available-applications-in-the-google-play-store/
https://www.statista.com/statistics/266210/number-of-available-applications-in-the-google-play-store/
https://www.statista.com/statistics/263795/number-of-available-apps-in-the-apple-app-store/
https://www.statista.com/statistics/263795/number-of-available-apps-in-the-apple-app-store/
http://www.idc.com/prodserv/smartphone-os-market-share.jsp
http://www.idc.com/prodserv/smartphone-os-market-share.jsp
[9] BADER, W. I., HAMMOURI, A. I. “Responsive Web Design Techni-
ques”, International Journal of Computer Applications, v. 150, n. 2,
pp. 18–27, Sep 2016. ISSN: 0975-8887. doi: 10.5120/ijca2016911463.
Dispońıvel em: ¡http://www.ijcaonline.org/archives/volume150/
number2/26066-2016911463¿.
[10] DANIEL NATIONS. “Improve Your Understanding of Web Applications”.
. https://www.lifewire.com/what-is-a-web-application-3486637,
out. 2016. Acessado em Janeiro de 2017.
[11] ANANYA BHATTACHARYA. “Android just hit a re-
cord 88smartphones”. . https://qz.com/826672/
android-goog-just-hit-a-record-88-market-share-of-all-smartphones,
nov. 2016.
[12] JOHN BRISTOWE. “What is hybrid mobile app”. . http://developer.
telerik.com/featured/what-is-a-hybrid-mobile-app/, mar. 2015.
[13] NUNES, S., DAVID, G. “Uma Arquitectura Web para Serviços Web”. . http:
//hdl.handle.net/10216/281, 2005.
[14] HASSENZAHL, M. “User Experience (UX): Towards an Experiential Pers-
pective on Product Quality”. In: Proceedings of the 20th Conference on
L’Interaction Homme-Machine, IHM ’08, pp. 11–15, New York, NY, USA,
2008. ACM. ISBN: 978-1-60558-285-6. doi: 10.1145/1512714.1512717.
Dispońıvel em: ¡http://doi.acm.org/10.1145/1512714.1512717¿.
[15] TSAI, M.-J., CHEN, D.-J. “Generating user interface for mobile phone de-
vices using template-based approach and generic software framework”,
WOS:000248237300016, 2007. Dispońıvel em: ¡https://ir.nctu.edu.
tw/handle/11536/10634¿.
[16] APPLE. “Apple design website”. . https://developer.apple.com/ios/
human-interface-guidelines/ui-views/action-sheets/. Acessado
em Janeiro de 2017.
[17] ONSEN UI. “Onsen UI website”. . https://onsen.io. Acessado em Janeiro
de 2017.
[18] IONIC. “Ionic website”. . https://developer.apple.com/ios/
human-interface-guidelines/ui-views/action-sheets/. Aces-
sado em Janeiro de 2017.
47
http://www.ijcaonline.org/archives/volume150/number2/26066-2016911463
http://www.ijcaonline.org/archives/volume150/number2/26066-2016911463
https://www.lifewire.com/what-is-a-web-application-3486637
https://qz.com/826672/android-goog-just-hit-a-record-88-market-share-of-all-smartphones
https://qz.com/826672/android-goog-just-hit-a-record-88-market-share-of-all-smartphones
http://developer.telerik.com/featured/what-is-a-hybrid-mobile-app/
http://developer.telerik.com/featured/what-is-a-hybrid-mobile-app/
http://hdl.handle.net/10216/281
http://hdl.handle.net/10216/281
http://doi.acm.org/10.1145/1512714.1512717
https://ir.nctu.edu.tw/handle/11536/10634