DESENVOLVIMENTO DE APLICATIVO ANDROID PARA O PORTAL DOALUNO DA UFRJ

Rafael Cardoso Ferreira

Projeto de Graduacao apresentado ao Cursode Computacao e Informacao da EscolaPolitecnica da Universidade Federal do Rio deJaneiro como parte dos requisitos necessariospara a obtencao do grau de Engenheiro deComputacao e Informacao.

Orientador: Jose Ferreira de Rezende

Rio de JaneiroJaneiro de 2017

DESENVOLVIMENTO DE APLICATIVO ANDROID PARA O PORTAL DOALUNO DA UFRJ

Rafael Cardoso Ferreira

PROJETO SUBMETIDO AO CORPO DOCENTE DO CURSO DECOMPUTACAO E INFORMACAO DA ESCOLA POLITECNICA DAUNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTEDOS REQUISITOS NECESSARIOS PARA A OBTENCAO DO GRAU DEENGENHEIRO DE COMPUTACAO E INFORMACAO.

Examinadores:

Prof. Jose Ferreira de Rezende, Dr.

Prof. Aloysio de Castro Pinto Pedroza, Dr.

Prof. Flavio Luis de Mello, D.Sc.

RIO DE JANEIRO, RJ – BRASILJANEIRO DE 2017

Ferreira, Rafael CardosoDesenvolvimento 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 RezendeProjeto (graduacao) – UFRJ/ Escola Politecnica/ Curso

de Computacao e Informacao, 2017.Referencias Bibliograficas: p. 46 – 49.1. Dispositivos moveis. 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 Politecnica/ Curso de Computacao e Informacao.III. Tıtulo.

iii

Agradecimentos

Primeiramente, agradeco aos meus pais por serem meu exemplo de vida e maiorescompanheiros. A minha famılia, pelo sempre presente carinho e amor por todaminha vida. A minha namorada, por sempre ter sido uma grande companheira nosmomentos bons e ruins.

Aos meus amigos de ECI, pelos incrıveis anos que passamos juntos; em especial,agradeco ao Rezende e Sab pelas incontaveis vezes que me ajudaram por toda tra-jetoria. Aos meus amigos do BQF por mostrarem que tempo e distancia sao apenasdetalhes quando se trata de amizade. Aos meus amigos do SIGA, e especialmenteao Ricardo Storino, por terem me dado a oportunidade de contribuir com a univer-sidade de alguma forma, e pela paciencia em me ensinar conceitos que eu jamaishavia conhecido.

Agradeco imensamente a Universidade Federal do Rio de Janeiro pela oportuni-dade de me tornar engenheiro, e a todos os professores do curso de Engenharia. Emespecial, ao professor Sergio Barbosa Villas-Boas, que foi alem de professor um bomamigo; e professor Jose Rezende, por aceitar a orientacao deste trabalho. Agradecotambem ao professor Paulo Oliva, por toda orientacao e contribuicao durante meutermo de intercambio academico, e aos professores Flavio Mello e Aloysio Pedroza,por participarem desta banca examinadora.

Por fim, agradeco a todas as pessoas que me ajudaram a ser uma pessoa melhorneste tempo de universidade.

iv

Resumo do Projeto de Graduacao apresentado a Escola Politecnica/COPPE/UFRJcomo parte dos requisitos necessarios para a obtencao do grau de Engenheiro deComputacao e Informacao.

DESENVOLVIMENTO DE APLICATIVO ANDROID PARA OPORTAL DO ALUNO DA UFRJ

Rafael Cardoso Ferreira

Janeiro/2017

Orientador: Jose Ferreira de Rezende

Curso: Engenharia de Computacao e Informacao

Com a grande popularizacao dos smartphones e seu crescente uso na sociedade,paralelo ao decrescente uso dos desktops para tarefas cotidianas, instituicoes queofereciam solucoes online tiveram que se adaptar para que essas solucoes tambemfossem viaveis em dispositivos moveis. O contexto da Universidade Federal do Riode Janeiro nao e diferente, e portanto oferecer as solucoes do Sistema Integrado deGestao Academica (SIGA) para dispositivos moveis fez-se necessario. Este trabalhotem como objetivo oferecer uma revisao sobre diferentes abordagens de desenvolvi-mento movel e descrever a implementacao de uma solucao para dispositivos Androidque possibilita o acesso ao SIGA.

Palavras-Chave: Dispositivos moveis, Android, REST, Hibrido, Nativo, Portaldo Aluno.

v

Abstract of the Undergraduate Project presented to Poli/COPPE/UFRJ as a partialfulfillment of the requirements for the degree of Computer and Information Engineer.

DEVELOPMENT OF UFRJ’S PORTAL DO ALUNO ANDROIDAPPLICATION

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 becomedecreasingly used, instituitons that offered online solutions were forced to adapt ina way so that these solutions became available for mobile devices. UniversidadeFederal 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 SistemaIntegrado de Gestao Academica (SIGA). This document offers a review of differentmobile development approaches, as well as a description of the implementation of amobile solution for Android devices that enables access to SIGA.

Keywords: Mobile, Android, REST, Hybrid development, Native development.

vi

Sumario

Lista de Figuras ix

Lista de Tabelas x

Lista de Abreviaturas xi

1 Introducao 11.1 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Conceitos Basicos 52.1 Desenvolvimento Nativo . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Desenvolvimento Hıbrido . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 REST vs SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Desenvolvimento Hıbrido e Nativo 133.1 Interface Grafica (UI ) . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Experiencia do Usuario (UX) . . . . . . . . . . . . . . . . . . . . . . 163.3 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4 Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.5 Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.6 Testes Automatizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.6.1 Testes unitarios . . . . . . . . . . . . . . . . . . . . . . . . . . 213.6.2 Testes de aceitacao . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Implementacao 234.1 Visao geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Interface Grafica (UI ) . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.1 Pagina Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

vii

4.2.2 Menu Principal & Explorador de Arquivos . . . . . . . . . . . 264.2.3 Salas de Aula . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2.4 Inscricao em Disciplinas . . . . . . . . . . . . . . . . . . . . . 30

4.3 Experiencia do Usuario (UX) . . . . . . . . . . . . . . . . . . . . . . 304.3.1 Norman’s Design Principles . . . . . . . . . . . . . . . . . . . 32

4.4 Desempenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5 Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.6 Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.7 Testes Automatizados . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.7.1 Testes Unitarios . . . . . . . . . . . . . . . . . . . . . . . . . . 394.7.2 Testes de Aceitacao . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Resultados 415.1 Estatısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6 Conclusoes e Trabalhos Futuros 446.1 Conclusoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Referencias Bibliograficas 46

viii

Lista de Figuras

1.1 Consumo em minutos por dia: mobile vs desktop . . . . . . . . . . . . 21.2 Pagina inicial do SIGA. Retirado de [1]. . . . . . . . . . . . . . . . . 3

2.1 Market share por sistema operacional . . . . . . . . . . . . . . . . . . 62.2 Diferenca de performance entre SOAP e REST [2]. . . . . . . . . . . 112.3 Aumento de APIs REST entre 2006 e 2011 [3]. . . . . . . . . . . . . 11

3.1 Sugestao do Material Design para listas. [4] . . . . . . . . . . . . . . 143.2 Diferenca de sub-menus . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Exemplos de menus laterais em frameworks hıbridos . . . . . . . . . . 17

4.1 Diagrama geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Aplicacao do Material Design na pratica . . . . . . . . . . . . . . . . 254.3 Detalhamento de menus disponıveis no app . . . . . . . . . . . . . . . 274.4 Paginas iniciais do app . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5 Tela de turmas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.6 Paginas de inscricao do app . . . . . . . . . . . . . . . . . . . . . . . 314.7 Feedback sobre o status disponıveis . . . . . . . . . . . . . . . . . . . 334.8 Dialogs sobre o status das requests. . . . . . . . . . . . . . . . . . . . 344.9 Opcoes para o perıodo de trancamento. . . . . . . . . . . . . . . . . . 35

5.1 Avaliacao dos usuarios. . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Total de instalacoes por usuario. . . . . . . . . . . . . . . . . . . . . . 425.3 Instalacoes do app por paıs. . . . . . . . . . . . . . . . . . . . . . . . 43

ix

Lista de Tabelas

2.1 Linguagens de programacao para desenvolvimento nativo por S.O. . . 6

x

Lista de Abreviaturas

API Application Programming Interfaces, p. 9

BOA Boletim de Orientacao Academica, p. 26

CRID Confirmacao de Registro de Inscricao em Disciplinas, p. 26

CRPID Confirmacao de Registro de Pedido de Inscricao 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 Gestao Academica, 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

Introducao

O uso de smartphones e tablets faz parte do cotidiano da maioria dos brasileiros atu-almente. Segundo estatısticas [5], 76.1 milhoes de brasileiros utilizam smartphones,o que corresponde a aproximadamente 40% do total de brasileiros. Entretanto, essenumero sobe para 61% se considerarmos somente a populacao brasileira que utilizacelulares.

Paralelamente ao crescimento do uso de dispositivos moveis, ve-se o grandedeclınio do uso de computadores pessoais (desktops). O Grafico 1.1 ilustra esteevento comparando a proporcao do uso de dispositivos moveis e computadores desde2014, alem da projecao ate 2018.

Como consequencia, cada vez mais passa a ser menos comodo para os usuariosutilizar desktops para tarefas cotidianas. Isso reflete o significativo amadurecimentodo mercado de aplicativos para smartphones, que passou de 100.000 aplicativosdisponıveis em outubro de 2010 para incrıveis 2.400.000 em outubro de 2016.[6].Estes numeros sao referentes somente ao sistema operacional Android. Para iOS, osnumeros 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, com87.6%, enquanto o iOS tem 11.7% [8]. Os dois juntos dominam 99.3% do mercado. Orestante e dividido entre Windows Phone, BlackBerry e outros sistemas operacionaismenores, como webOS, Symbian OS e Ubuntu OS.

Com base nesses dados, nao ha razoes, portanto, para universidades nao seguiremessa crescente tendencia e se adaptarem para fornecer solucoes moveis.

1.1 Antecedentes

A UFRJ implantou nos anos 90 o Sistema Integrado de Gestao Academica (SIGA),visando melhorar e agilizar os processos academicos em geral. Antes da imple-mentacao do sistema, todos os processos academicos eram feitos presencialmente,

1

Figura 1.1: Consumo em minutos por dia: mobile vs desktop

ou seja, para tarefas como inscricao em disciplinas ou recuperacao de documentos,os alunos tinham que estar na faculdade em horarios e dias preestabelecidos. Com oSIGA, foi oferecida a possibilidade de fazer tais tarefas de qualquer lugar do mundocom acesso a Internet.

O SIGA engloba inumeras funcionalidades de diversos escopos, fazendo com quenao somente estudantes mas tambem professores, coordenadores de curso e tecnicos-administrativos, entre outras ocupacoes, utilizem o sistema.

1.2 Motivacao

A principal motivacao para este projeto comecou ainda no ano de 2013. Na epoca,o acesso ao SIGA era feito exclusivamente pela intranet da UFRJ, e o website dosistema em si era totalmente orientado a mouse, isto e, a usabilidade do sistemadependia de aspectos nao suportados por outras formas de navegacao, como o toque.Por exemplo, para abrir o menu superior do sistema, era necessario posicionar omouse por alguns segundos em cima do mesmo, ate que abrisse.

A Figura 1.2 ilustra a pagina inicial do sistema. Por ser um sistema desen-

2

Figura 1.2: Pagina inicial do SIGA. Retirado de [1].

volvidos em tecnologias antigas em um tempo em que a utilizacao de internet noscelulares era nula, ele nao oferecia suporte para celulares ou um layout responsivo.Consequentemente, nao era possıvel utilizar o sistema em varios celulares.

A ideia de desenvolver um aplicativo (app) comecou a partir desta dificuldade.O primeiro prototipo ficou pronto no dia primeiro de agosto de 2013, e foi lancadode forma extraoficial, sendo disponibilizado na Google Play de forma gratuita.

Com a grande aceitacao do aplicativo por parte dos usuarios, o projeto viria ase tornar o aplicativo oficial da UFRJ para Android no ano de 2014.

1.3 Objetivo

O objetivo da construcao do aplicativo foi nao somente colocar a UFRJ dentrodo mapa de inovacao de dispositivos moveis, atendendo os alunos via dispositivosmoveis, mas tambem garantir a grande maioria dos alunos um acesso rapido, seguroe eficaz ao Sistema Integrado de Gestao Academica.

O objetivo deste trabalho e sumarizar como foi feito o desenvolvimento do aplica-tivo para smartphones com sistema operacional Android, explicitando fatores comointerface grafica, experiencia do usuario, performance, usabilidade, comunicacao ex-terna com o servidor e seguranca, alem de demonstrar a importancia da qualidade

3

de codigo e os meios utilizados para atingi-la.Em adicao, o trabalho se propoe a expor eventuais dificuldades encontradas na

evolucao do projeto, assim como ressaltar pros e contras de diferentes abordagensde desenvolvimento, para que sirva como referencia e legado para iniciativas seme-lhantes.

1.3.1 Metodologia

Inicialmente, foi realizada uma revisao bibliografica acerca de desenvolvimento deaplicativos moveis, incluindo pesquisas quantitativas referentes a diversos elementosdo desenvolvimento, como performance, seguranca, interface grafica, usabilidade ecomunicacao com servidores.

Com base nesta revisao, foi implementado um software para o sistema operacio-nal Android de forma nativa para atender os alunos da UFRJ com acesso movel aoPortal Aluno, possibilitando acesso rapido ao SIGA e seus servicos.

Este trabalho foi dividido em 5 capıtulos, alem desta introducao. O Capıtulo 2refere-se a alguns conceitos basicos para auxiliar no entendimento deste trabalho,enquanto o Capıtulo 3 oferece uma revisao bibliografica sobre a polaridade de desen-volvimento nativo de aplicativos versus desenvolvimento hıbrido de aplicativos. NoCapıtulo 4 esta descrita a implementacao em si, explicitando cada componente doprojeto e justificativas para cada decisao tomada. Os resultados da implementacaodo projeto, incluindo dados sobre a aceitacao do produto por parte do publico eestatısticas de uso, estao dispostas no Capıtulo 5. O ultimo capıtulo refere-se asconclusoes tomadas e trabalhos futuros.

4

Capıtulo 2

Conceitos Basicos

Com a grande popularizacao de smartphones como visto na secao anterior, os prove-dores de servico tiveram que se adaptar e fornecer solucoes que tambem atendessema esse mercado.

O crescente numero de apps nas lojas online e um grande indicativo dessefenomeno. No entanto, um outro indicativo e tambem a popularizacao dos web-sites baseados no chamado design responsivo. Com diferentes tamanhos, resolucoesde telas e velocidade de conexao, e difıcil prever o contexto no qual um usuarioacessa a Internet. Dessa forma, cria-se uma necessidade de uso de novas tecnicaspara prover a melhor experiencia de usuario possıvel a qualquer um que possa vir autilizar um servico [9].

Aplicacoes que sao acessadas atraves de um navegador web sao comumente cha-madas de web applications [10]. Ao utilizar as tecnicas de design responsivo, essasaplicacoes ficam com a interface grafica muito parecida com a de um app comum desmartphones.

Essa e a ideia base de aplicativos hıbridos, como veremos nas secoes subsequen-tes. Em termos de desenvolvimento de aplicacoes que rodam no smartphones emsi, e nao na nuvem, existem duas vertentes principais: desenvolvimento hıbrido edesenvolvimento nativo.

2.1 Desenvolvimento Nativo

O desenvolvimento nativo consiste na escrita de codigo em linguagem nativa, uti-lizando um Software Development Kit (SDK) proprio para um certo sistema ope-racional. Consequentemente, a linguagem de programacao usada depende de cadasistema operacional. Na Tabela 2.1, podemos ver a variacao da linguagem adotadapor cada sistema. Os sistemas operacionais sao listados tambem com sua represen-tatividade em market share.

5

Tabela 2.1: Linguagens por Sistema Operacional

Sistema Operacional Linguagem Market ShareAndroid 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 tambem que Android e Apple iOS lideram o mercado desmartphones ha anos. Portanto, seus respectivos SDK s sao os mais utilizados paradesenvolvimento nativo.

2.2 Desenvolvimento Hıbrido

O desenvolvimento hıbrido consiste na utilizacao de algum framework que possibilitatransformar um codigo - escrito em uma unica linguagem - em apps nativos dediferentes plataformas.

Existem varios frameworks que atendem o desenvolvimento de aplicativos paradiferentes plataformas. Dentre tais frameworks, podemos citar os que utilizam abor-dagens web ou abordagens proprietarias, como veremos a seguir.

Este trabalho focara mais na metodologia web, visto que e a mais utilizada comoalternativa ao desenvolvimento nativo.

Abordagem web

O que esses frameworks costumeiramente fazem e envolver uma estrutura combinadade 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-secitar como exemplo os frameworks PhoneGap, Cordova e Ionic.

Dessa forma, o app hıbrido se assemelha muito a um nativo: ele e baixadode alguma store online, como a Apple AppStore ou o Google Play, instalado nosmartphone normalmente e utilizado como se fosse um aplicativo comum.

Portanto, a grande vantagem do desenvolvimento hıbrido e que um codigo unico eimplantado em varios sistemas operacionais diferentes, nao sendo necessario escreverum codigo diferente para cada sistema operacional utilizando cada SDK. Essa e umaestrategia muito utilizada para empresas e startups que querem cortar ao maximo ocusto de desenvolvimento.

Em teoria, a manutenibilidade se da de forma mais facil por conta do baixovolume de codigo, e a velocidade de lancamento de atualizacoes tambem. Comsenso, a probabilidade de bugs tambem e drasticamente reduzida, visto que nao enecessario replicar os algoritmos e mudancas em diversos codigo-fontes diferentes.

Abordagem proprietarias

No entanto, existem outras tecnicas de desenvolvimento hıbrido que utilizam tecno-logias diferentes das tecnologias padrao 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, nao se utiliza o SDKespecıfico regido por cada S.O, e sim um framework proprio feito com base nessesSDKs.

Os exemplos de codigo dispostos nos Quadros 2.1 e 2.2 mostram a similaridadedo codigo nativo do SDK do Android e o codigo do framework Xamarin.

O ponto positivo e que a performance final do app e consideravelmente superiora performance conseguida ao utilizar as tecnologias web, porque ele traduz o codigoescrito em C# para codigo nativo usando tecnicas de compilacao especıficas de cadaplataforma, 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 melhorexperiencia de usuario possıvel, o desenvolvedor acaba com varios codigos em vez deum so: havera um codigo para a interface grafica para Android, um para a interfacegrafica para iOS etc, apesar de toda logica de negocio poder ser compartilhada.

7

Arquivo 2.1: Codigo SDK do Xamarinpub 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: Codigo SDK do Androidpub 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 ideprotected 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 pelaEmbarcadero Technologies que permite o desenvolvimento de apps multi-plataformautilizando Delphi e C++. Ao contrario do framework Xamarin, o RAD Studio per-mite o desenvolvimento de um unico codigo para a interface grafica que e traduzidoem designs que seguem o padrao de cada plataforma suportada: Android, iOS eWindows Phone.

Estruturas de Projeto & IDEs

Integrated development environment (IDE) e um software que facilita o desenvol-vimento de programas de varias maneiras, das quais pode-se destacar a inclusaoautomatica de um compilador e processo de build, utilizacao de debugger e visua-lizacao da interface grafica em tempo real. Alem disso, eles podem oferecer umainterface simples de integracao com repositorios de bibliotecas de terceiros como omaven, NuGet entre outros.

Para desenvolvimento nativo Android, utiliza-se duas IDEs principais: Eclipse eAndroid Studio, sendo a ultima 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, nao ha regra. Entretanto, varios frameworks dis-

ponibilizam uma IDE propria que atende facilidades especıficas de cada uma.A estrutura dos projetos varia de acordo com cada framework.

2.3 APIs

Para comunicacao entre softwares, costuma-se utilizar Application Programming In-terfaces (API s). API s sao interfaces definidas por padroes de comunicacao prees-tabelecidos, tal que seja possıvel sistemas se comunicarem de forma automatizada.

No caso de servicos web, as chamadas web API s sao muito usadas. Web API spodem ser acessadas por qualquer sistema que consiga fazer requisicoes HypertextTransfer Protocol (HTTP), o que abrange uma gigantesca gama de sistemas in-cluindo todos os smartphones atuais.

Os padroes mais utilizados para comunicacao desse tipo sao os REST e SOAP.

2.3.1 REST vs SOAP

Representational state transfer (REST ) e um padrao definido por uma serie derestricoes e caracterısticas que tem como objetivo abstrair a comunicacao entre sis-temas. Pode-se citar, dentre estas restricoes e caracterısticas, tres principais[13]:

• Identificacao global

• Interfaces uniformes

• Stateless

O primeiro item destaca que os recursos sao identificados via uma URL; o se-gundo item ressalta que so deve haver um meio de acessar os servicos, e este e pormeio de requests (requisicoes) HTTP para a URL que os identificam; e por ultimo,todas as requisicoes sao stateless, isto e, eles nao devem guardar estado. Basica-mente, para cada requisicao (request) que recebe certos parametros predefinidos, haum processamento que gera uma resposta (response). Nao ha informacoes de sessoesde clientes ou similares guardadas no processo. Consequentemente, espera-se queaplicacoes e servicos 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 utilizacao de XML ou JSONpara transferencia de dados, visto que tais formatos sao amplamente utilizados porconta de sua simplicidade e facilidade no tratamento de informacoes.

Sao 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 deinformacoes de forma semelhante ao padrao REST, mas de forma mais robusta. Oprotocolo SOAP, originalmente desenvolvido pela Microsoft, nao restringe o acessosomente a HTTP.

Cada vertente tem seus pros e contras, porem ve-se uma incrıvel preferenciapor parte de desenvolvedores por APIs REST ful. O principal motivo e a granderapidez e simplicidade no envio e tratamento de dados em Javasript Object Notation(JSON), que faz muita diferenca para aplicativos moveis, principalmente por contada possibilidade de conexao instavel por conta de redes 3G. Uma outra alternativaseria o notavel Extensible Markup Language (XML), porem o trafego de dados emuito maior por conta de como o XML e estruturado: para cada tag aberta, outraexatamente igual e escrita para indicar o fim da mesma. O JSON evita este problemautilizando o caractere de chave e colchete para indicar abertura e fechamento deobjetos.

APIs SOAP, por sua vez, tem um set-up mais rapido, tendo as vezes auxılio dewizards que ja automatizam a estruturacao de toda conexao com o servidor. Alemdisso, suportam outros protocolos alem do HTTP, como o SMTP e SSH. No entanto,costumam pecar em performance.

A Figura 2.2 indica a grande diferenca no tempo de cada chamada a um web-service sobre varios celulares. O estudo foi feito pelo A-team da Oracle e visavaestudar a diferenca de performance entre os dois modos de comunicacao [2].

Como ja explicitado, performance e um fator muito importante para a aceitacaode aplicativos moveis, e portanto, e natural que a escolha de desenvolvedores sejaenviesada para o paradigma mais performatico - nesse caso, evidentemente o REST.

10

Figura 2.2: Diferenca de performance entre SOAP e REST [2].

Figura 2.3: Aumento de APIs REST entre 2006 e 2011 [3].

11

Esse fenomeno tambem leva aos provedores de informacao (nesse caso, os webservices e suas APIs) a utilizar protocolos mais amplamente performaticos, isto e,protocolos que satisfazem tambem o consumo mobile alem dos tradicionais desktops.

O Grafico 2.3 mostra o expressivo aumento do uso da tecnologia REST em APIs,e paralelamente, a diminuicao de sua maior contraparte, o SOAP.

12

Capıtulo 3

Desenvolvimento Hıbrido e Nativo

No capıtulo anterior, foi apresentada uma visao geral do panorama de desenvolvi-mento para dispositivos moveis. Esse capıtulo tem como objetivo melhor descreveras tecnicas e implementacoes para esse desenvolvimento, assim como explicitar asprincipais diferencas entre as duas diferentes abordagens.

3.1 Interface Grafica (UI )

A construcao da interface grafica (em ingles, User Interface, comumente referidocomo UI ) e sem duvida vital para o produto final, e impacta significativamente aexperiencia do usuario (comumente referida como UX) [14].

Para se ter uma ideia nao somente da importancia da UI mas tambem de seucusto, a maior alocacao de esforco no processo de construcao de um software estalocalizado exatamente no design e implementacao da interface grafica [15]. Conse-quentemente, os SDKs tentam prover o desenvolvedor de muitas ferramentas parafacilitar e amenizar o custo desse processo.

A Google, por exemplo, tem sua propria design language, chamada Google Ma-terial Design. Diz-se que uma design language - ou visual language - e um conjuntode padroes, configuracoes e esquemas graficos que norteia os produtos de uma linhae, consequentemente, guia usuarios e desenvolvedores. Microsoft, IBM, Apple entreoutras empresas tambem tem uma design language propria.

Veremos na proxima secao o porque de a design language ser tao importantepara a experiencia do usuario, e como o desenvolvimento hıbrido de aplicativos pecacriticamente neste quesito.

Nativo

No desenvolvimento nativo, a utilizacao da interface grafica e muito simples e javem de facil acesso nos SDKs. Consequentemente, a construcao das telas em acordo

13

(a) Lista de e-mails (b) Lista de pastas

Figura 3.1: Sugestao do Material Design para listas. [4]

com a design language em questao e imediata.Por exemplo, o Material Design da Google fornece padroes de cores, margens e

disposicao de elementos no aplicativo. As Figuras 3.1a e 3.1b mostram alguns dospadroes. Percebe-se que as margens a direita e a esquerda sao iguais, e o padrao dotopo tambem, apesar dos apps de exemplo serem totalmente diferentes: o primeiro,simula um app de e-mail, enquanto o ultimo simula um explorador de arquivos.

Um outro exemplo esta no site oficial da Apple para desenvolvedores. Na Figura3.2, ha a sugestao de que qualquer menu com opcoes de acao se abra na parteinferior. Analogamente, o Android sugere que um menu com acoes se abra na partesuperior ao final da toolbar localizada no topo da tela.

Estas configuracoes sao muito importantes para a experiencia do usuario, comosera relatado posteriormente neste trabalho. Um app com uma UX ruim tempouquıssimas chances de ser bem sucedido, uma vez que a experiencia do usuario ea melhor metrica possıvel de satisfacao de um aplicativo.

14

(a) iOS [16] (b) Android [4]

Figura 3.2: Diferenca de sub-menus

15

Hıbrido

O desenvolvimento hibrido, em contrapartida, nao tem um padrao definido. Comoas principais tecnologias envolvidas para a maioria dos frameworks sao HTML, CSSe Javascript, cabe ao usuario a total criacao da interface grafica.

Na verdade, ve-se que e muito comum a utilizacao de frameworks dentro doproprio 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 diferenca entre diferentes menus laterais de dois frameworksdiferentes: o primeiro que ja vem como parte do Ionic; e o segundo, da bibliotecapara UI Mobile Angular.

Claramente, nao se assemelha as design languages nativas, porem ainda saointuitivas aos usuarios por conta de outros elementos: o sımbolo localizado no cantoesquerdo ao topo e comumente utilizado para indicar menu; as setas ao lado de cadaitem do menu indicam que, se selecionado, o item levara o usuario a outra pagina;e a diferente coloracao de um dos itens do menu sugere selecao.

Esses aspectos acima citados fazem parte de uma design language universal, aqual todas as outras especıficas de cada SDK sao baseadas.

No entanto, alguns outros frameworks encontraram meios de parecer o maisnativo possıvel. Entre outros, um exemplo e o Onsen UI [17], que oferece umacompilacao visual diferente para Android e iOS com o mesmo codigo.

3.2 Experiencia do Usuario (UX)

A chamada UX (do ingles User eXperience) e estudada com o objetivo de aprimorarao longo do tempo a usabilidade e intuitividade da interacao homem-maquina [20] .

Indubitavelmente, o design de interfaces e um desafio para qualquer desenvolve-dor. A intencao na criacao de interfaces e que elas sejam intuitivas o suficiente talque o usuario nem perceba que esta lidando com uma maquina, isto e, o processode utilizacao de qualquer device deve ser o mais natural possıvel.

As ja citadas design languages tem como objetivo exatamente criar padroes bemdefinidos para que os aplicativos se assemelhem em estrutura. A ideia e o usuario,ao aprender a utilizar um aplicativo de um sistema, aprender a utilizar automatica-mente todos.

Consequentemente, a experiencia de usuario varia muito de sistema operacionalpara sistema operacional. E esperado que usuarios que ja estao acostumados com oiOS sintam muita diferenca ao migrar para Android, por exemplo.

Por outro lado, e muito mais provavel que usuarios ja acostumados com o Mate-rial Design da Google tenham uma boa experiencia 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 padrao dessa design language, do que com um aplicativo que nao sigaesse padrao.

Isso implica uma das maiores desvantagens do desenvolvimento hıbrido: a UXde um app hıbrido sera significativamente inferior a UX de um app nativo. Por maisque se tente utilizar HTML, CSS e Javascript para criar apps muito semelhantesa nativos, seria muito custoso e difıcil conseguir um resultado exatamente igual.E, mesmo se este resultado fosse conseguido, ele se assemelharia somente a umtipo de visual language especıfico. Por exemplo, se um app e disponibilizado naApple AppStore, Microsoft Store e Google Play mas seu design language e similar aoMaterial Design da Google, a experiencia de usuarios da Apple e da Microsoft seriamuito ruim. Isso se da porque eles nao estao acostumados ao padrao de design daGoogle, 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 sao a latencia e otempo de execucao [21]. Basicamente, a latencia diz respeito sobre o tempo relaci-onado a comunicacao do app com fontes externas (e.g. servidor na web). O tempode execucao, por sua vez, esta relacionado ao processamento local do codigo.

Apps nativos terao a melhor performance geral. Seu codigo ja e, por definicao,compilado de forma otima para o correspondente sistema operacional. Apps hıbridossao interpretados: seu codigo e rodado por uma especie de web browser. O webbrowser, por sua vez, e rodado pelo sistema. Portanto, ha uma camada adicional noproduto final do desenvolvimento hıbrido.

Essa camada adicional reflete um tempo de execucao maior e consequentemente,menor desempenho para hıbridos. Ademais, a latencia de hıbridos tambem temmaior probabilidade de ser maior, ja que e pratica comum de apps hıbridos baixarempela rede partes de sua view, isto e, de elementos que serao mostrados na tela. Issoacarreta maior tempo de comunicacao (latencia) e pode piorar a experiencia dousuario.

Um estudo [22] mostra o quao importante e a performance para usuarios finais.84% dos usuarios avaliados julgam performance um fator importante. Alem disso,48% dos usuarios responderam que estariam menos dispostos a utilizar um appcom UX ruim, 34% trocariam para o app do competidor e 31% recomendariamnegativamente para outros usuarios. Finalmente, 24% dos participantes disseramque olhariam para outros produtos da empresa sob uma perspectiva negativa e menosdispostos a tentar outros produtos.

18

Consequentemente, o desempenho impacta diretamente a experiencia do usuarioe pode ser fator decisivo para o sucesso de um aplicativo em relacao ao seus compe-tidores.

3.4 Seguranca

Seguranca e um fator que vem chamando bastante atencao no desenvolvimento mo-bile. Apesar do crescimento consideravel de aplicativos hıbridos devido ao baixocusto de desenvolvimento, aplicativos nativos sao mais seguros [23].

Esse fato ocorre pela maior integracao que apps nativos tem com as featuresdo sistema - inclusive as relacionadas a seguranca. Google, Apple e outras grandesempresas de tecnologia vem adicionando mais e mais funcionalidades para diminuirvulnerabilidades dos apps em seu sistema.

Por exemplo, apps Android sao postos naturalmente nas chamadas sandboxes[24], que isolam os dados de um app e sua execucao do codigo de dados e execucoesde outros apps. Alem disso, Android oferece um file system encriptado que podeser habilitado visando protecao em caso de perdas ou furtos. Tambem, ao lancaraplicativos na loja oficial da Google, o usuario tem que explicitamente listar nocodigo-fonte da aplicacao todas as permissoes que o aplicativo tem que ter para seuuso, e o usuario tem que aceitar uma a uma. Essas permissoes incluem acesso aomicrofone, camera, disco rıgido, internet etc.

Um outro exemplo sao metodologias implementadas pela Apple para garantir aautenticidade dos apps em sua loja. Uma delas e a chamada bootchain [25], em quecada etapa do processo de load de um app no iOS contem componentes criptografa-dos assinados somente pela Apple para garantir integridade. Outras tecnicas estaodescritas na documentacao oficial da empresa, e podem ser ressaltadas o Secureenclave, Touch ID e Data Encrypting [25].

Mesmo com todos os avancos em seguranca, hackers ainda exploram vulnerabi-lidades em aplicacoes moveis.

3.5 Comunicacao

A comunicacao do app com fatores externos (como disco, banco de dados ou servi-dores) se da de forma similar nos paradigmas hibrido e nativo.

Disco

Aplicacoes nativas tem funcionalidades ja embarcadas no SDK para acesso ao filesystem. No entanto, a gigantesca maioria dos frameworks hıbridos tambem ja fazem

19

o intermedio entre o sistema e o codigo 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 iOStambem oferece suporte ao SQLite.

O uso de bancos e recomendado para armazenamento de dados em quantidademais significativa. Para rapidos armazenamentos de objetivos primitivos, como in-teiros, strings e booleans, costuma-se utilizar solucoes mais performaticas como asShared Preferences (Android) e User Defaults (iOS). Como o nome sugere, e umaforma de armazenamento muito utilizada para guardar dados de configuracoes dousuario.

Em contrapartida, no caso de frameworks hıbridos, costuma-se utilizar as tec-nologias IndexedDB, WebSQL e localstorage. Essas tecnologias sao otimizadas paraweb browsers, e como os apps sao desenvolvidos para executar em uma especie debrowser, essas opcoes acabam sendo boas solucoes.

O IndexedDB e um banco de dados baseado em Javascript e orientado a objetos.Essa implementacao substitui a antiga WebSQL, que teve seu suporte descontinuadopela W3C. O localstorage por sua vez e uma API leve para armazenamento depequenas quantidades de dados, mas seu acesso se da de forma sıncrona, o que podeser bem problematico visto que isso causa o travamento da interface grafica ate quea comunicacao seja finalizada.

Servidores

Como visto no Capıtulo 2, a comunicacao com os servidores se da majoritariamentepor dois paradigmas: Simple Object Access Protocol (SOAP) ou Representationalstate transfer (REST).

Nao ha diferenca na comunicacao com APIs externas no caso de desenvolvimentonativo contra hıbrido, uma vez que ambos sao capazes de se comunicar normalmentesem consideraveis diferenca no processo.

3.6 Testes Automatizados

Um fator extremamente importante no processo de desenvolvimento sao os testesautomatizados. Na verdade, testes automatizados nao agregam valor para o usuariodiretamente, mas sim indiretamente.

Testar o aplicativo de forma efetiva impede que bugs sejam embarcados com novasatualizacoes e assegura que o aplicativo sempre funcione como preestabelecido. Isso

20

inclui monitoramento de consumo de energia, monitoramento de desempenho doapp, seguranca de que a UI se comporta de maneira correta, certeza que logicas denegocio ainda sao cumpridas entre outros. [27]

Ha diversos tipos de testes automatizados, dos quais podemos citar testesunitarios, testes funcionarios e testes de interface grafica. Neste trabalho, cobri-remos somente o escopo de testes unitarios e de interface grafica.

3.6.1 Testes unitarios

Testes unitarios tem como objetivo testar unidades logicas de negocio de um pro-grama, isto e, testar as menores partes de um programa e assegurar que elas funcio-nam corretamente. A nıveis praticos, essas pequenas partes podem ser um conjuntode classes ou uma unica classe somente [28], tal que seus metodos sejam asseguradosde funcionalidade.

Em termos de desenvolvimento para dispositivos moveis, existem varios fra-meworks para testes unitarios.

Frameworks nativos

Para Android, o JUnit ja e disponibilizado como framework padrao para testesunitarios. Alem disso, a documentacao oficial da Google sugere a utilizacao doframework Mockito para satisfazer eventuais dependencias que os testes possam vira ter. O sistema operacional da Apple tambem ja disponibiliza ferramentas paratestes unitarios junto com o SDK pelo framework XCTest, assim como o WindowsPhone comporta ferramentas no conjunto de bibliotecas padrao do Visual Studio(Microsoft.VisualStudio.TestPlatform.UnitTestFramework).

Frameworks hıbridos

No desenvolvimento hıbrido, e muito comum utilizar ferramentas de teste unitariovoltadas para Javascript, especialmente a Angular - framework vastamente utilizadopara desenvolvimento hıbrido.

Um exemplo e o QUnit, que funciona muito bem com Apache Cordova e Phone-Gap.

3.6.2 Testes de aceitacao

Os testes de aceitacao tem como objetivo testar a interface grafica do aplicativo,simulando o operacional de um usuario. Consequentemente, o teste assegura que ainterface grafica funcione de forma esperada e exiba informacoes de forma devida.

21

No entanto, nao e papel dos testes de interface grafica testar a logica de negociosque acontece por tras no codigo. Este e um erro muito comum quando se trata detestes automatizados, visto que eles abordam a aplicacao de forma end-to-end, istoe, simula totalmente a operacao de um usuario do inıcio ao fim [29].

O ideal e se testar toda logica de negocios unitariamente, e fazer poucos testes detela, visto a grande demora na execucao dos testes de tela e baixa manutenibilidade.

Frameworks nativos

Para testes de tela nativo em Android, existem algumas opcoes, das quais a Googlerecomenda o framework chamado Espresso [30]. Esse framework tem um codigomuito simples e intuitivo, sendo facil escrever codigos de tela utilizando ele. Emcontrapartida, uma outra opcao e o Robotium, em que e possıvel gravar os passosa partir utilizando o Robotium Recorder. Portanto, utilizando esta abordagem, ficamais rapido de se criar testes, mas mais difıcil de mante-los.

Os testes automatizados para iOS e Windows Phone seguem uma linha parecidacom o Robotium. O framework para o sistema operacional da Apple e o mesmoutilizado para testes unitarios (XCTest) e permite gravar passo a passo a simulacaodo usuario. Para o sistema da Microsoft, utiliza-se o CodedUI, que e disponibilizadopor padrao em edicoes 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 tambem funcionam para testesde apps nativos, mas como as empresas mantenedores oferecem solucoes proprias,elas acabam sendo preferidas em relacao a estes.

22

Capıtulo 4

Implementacao

Visto todos os conceitos basicos descritos no capıtulo 2 e as visoes mais aprofundadassobre os aspectos de desenvolvimento hıbrido e nativo no capitulo 3, a intencao agorae detalhar cada item da implementacao do app deste trabalho.

Com base no que foi visto sobre o produto final resultante do desenvolvimentohıbrido comparado ao do desenvolvimento nativo, a decisao tomada foi seguir oparadigma nativo. Foi considerado que a melhor combinacao de UX, desempenho eseguranca so seria atingida com poder total sobre as funcionalidades do smartphonee 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 necessaria a busca pelomelhor produto para o usuario final possıvel. O ponto negativo deste tipo de desen-volvimento e o custo envolvido, que nao e tao significativo tomada a proporcao daUFRJ no cenario nacional.

Com a decisao de criacao do aplicativo nativo, um sistema operacional de inıciodeve tambem ser escolhido. Com base na analise de market share disposta na Figura2.1, o sistema operacional Android impactaria o maior numero absoluto de pessoas.

Portanto, justifica-se assim a escolha da utilizacao do Android SDK para o de-senvolvimento do software referenciado neste trabalho.

4.1 Visao geral

O funcionamento geral do aplicativo pode ser visto na Figura 4.1. O aplicativo fazrequisicoes HTTP para uma API RESTful. Essa API foi feita exclusivamente paraconsumo de dados desse aplicativo movel. E importante ressaltar que essa API naofoi, ate o momento de escrita deste trabalho, disponibilizada ao publico.

O aplicativo faz requisicoes GET e POST para a API, e esta por sua vez recuperaos dados do SIGA. Todo o framework web em que o SIGA e a API sao desenvolvidos

23

Figura 4.1: Diagrama geral

utilizam a linguagem de programacao Java, e portanto, toda a informacao no ladodo servidor e abstraıda como objetos Java.

A API e uma extensao dos modulos do sistema, de forma que consiga traduzirobjetos Java internos ao sistema para informacoes serializadas em JSON.

O aplicativo - ou qualquer outro consumidor de uma API - espera dados repre-sentados em alguma notacao universal - como o XML ou o ja citado JSON. Nesseesquema, fica claro que a API serve como uma interface de comunicacao entre doissistemas, transformando as requisicoes HTTP em chamadas especıficas a compo-nentes do sistema academico, e traduzindo o resultado dessas chamadas em umanotacao abstrata universal - nesse caso, o JSON.

O desenvolvimento total do aplicativo durou 7 meses. Nas proximas secoes, seraodetalhadas com profundidade os componentes do aplicativo e o que influenciou cadadecisao tomada.

No total, o aplicativo tem 8 telas: tela de login, menu principal, explorador dearquivos, salas de aula, adicionar pedidos de inscricao, visualizar/alterar pedidos etrancar inscricoes, buscar disciplinas e confirmacao de envio de pedidos de inscricao.

O publico-alvo do aplicativo sao estudantes da UFRJ. As funcionalidades inclusassao referentes a documentos, salas de aula e inscricao. Os documentos disponıveispara download sao dispostos na Lista 4.1.

4.2 Interface Grafica (UI )

A interface grafica do aplicativo foi feita seguindo a design language da Google. Todadisposicao de itens no aplicativo segue os padroes do Material Design, como serademonstrado nesta secao.

4.2.1 Pagina Inicial

A pagina inicial do app e exposta na Figura 4.2a

24

(a) Pagina inicial do app. (b) Padroes do Material Design [4]

Figura 4.2: Aplicacao do Material Design na pratica

25

• Boletim

• Boletim de Orientacao Academica(BOA)

• Historico

• Confirmacao de Registro de Inscricao em Disciplinas (CRID)

• Confirmacao de Registro de Pedido de Inscricao em Disciplinas (CRPID)

• Declaracao de Bolsista

• Declaracao de Cotista

• Declaracao de Nome Social

Lista 4.1: Documentos disponıveis para download

O botao disposto na parte inferior com o simbolo de + e chamado de FloatingAction Button (FAB). Seguindo a visual language em questao, este botao e recomen-dado para a acao mais utilizada na tela. Na tela em questao, e a acao de realizarum 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 tresbarras. Este sımbolo indica que ha um menu lateral disponıvel, como explicitadopela Figura 4.3a. A esquerda da toolbar tambem existe um sımbolo de tres pontosna vertical, que indica que ha um sub-menu com acoes disponıveis, como dispostopela Figura 4.3b

Ve-se tambem que as dimensoes do FAB sao identicas, assim como as dimensoesda toolbar ao topo. Alem disso, as margens a direita do botao tambem sao identicas.Como citado na secao 3.1, todos esses fatores sao dispostos de forma funcional epratica para o desenvolvedor atraves do proprio SDK. Evidentemente, o programa-dor pode customizar a seu modo. No entanto, e extremamente simples a criacao detelas em conformidade com a design language em questao.

Um ponto interessante a se notar e o sımbolo de engrenagem a direita do itemda lista. A engrenagem e um sımbolo universal utilizado para indicar que ha opcoesdisponıveis de configuracoes ou acoes adicionais que podem ser executadas. No caso,sao opcoes de remocao ou edicao 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 proprio, tal que facilite oacesso do usuario a qualquer arquivo baixado por dentro do aplicativo. No casodo Sistema Integrado de Gestao Academica, esses arquivos sao costumeiramentedocumentos academicos como boletins, historico escolar e comprovante de inscricao

26

(a) Menu lateral (b) Sub-menu com acoes

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: Paginas iniciais do app

em disciplinas; documentos oficiais como comprovante de matrıcula; e declaracoesda 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 padrao do Material Design de uniformizar osıcones no formato circular, como na Figura 3.1, foi seguido o padrao de ıcones noformato quadrado. Icones quadrados sao um grande legado do inicio da adocao decomputadores pessoais, principalmente no sistema operacional Windows. Portanto,apesar de fugir da linguagem visual da Google, ainda se faz intuitivo ao usuario.

No canto inferior direito da tela do explorador de arquivos, esta localizado umFAB com a opcao de deletar os arquivos salvos. O FAB some ao mover a tela paraa aba Sistemas.

O menu principal, demostrado na Figura 4.4a, mostra as opcoes disponıveis parao usuario logado. As opcoes variam de acordo com o usuario. Por exemplo, se ousuario for bolsista, tera a opcao de download de comprovacao de bolsista.

28

Figura 4.5: Tela de turmas

Alem disso, foi adicionado para as opcoes Salas de Aula e Inscricao uma seta adireita para demonstrar que o usuario saira da tela atual e ira para outra.

Para cada item do menu, uma acao correspondente e executada: ao clicar emalgum documento, o mesmo e baixado; ao clicar na opcao de Salas de Aula, o usuarioe direcionado para a tela com as informacoes de sala; e ao clicar em Inscricao, ousuario ira para a tela de inscricao em disciplinas.

4.2.3 Salas de Aula

Uma das funcionalidades do app e mostrar ao usuario suas salas de aula. A pagina esimples e segue os padroes da Google, principalmente por conta do uso dos cardviews.Os cardviews sao recomendados quando o tamanho do conteudo e variavel, alemde fazer parte da linguagem visual geral da Google [31]. Cardviews tem sido taoutilizado pela Google que ate websites responsivos para desktop o utilizam.

Na Figura 4.5, ve-se um exemplo real do uso da pagina. O primeiro cardview

29

foi ampliado - atraves de um toque - e os demais permaneceram colapsados. Oestado padrao dos cardviews e colapsado, tal que a tela nao fique poluıda assim queiniciada.

O tamanho de cada cardview pode variar muito visto que existem materias commuitos horarios diferentes. Ha materias registradas no SIGA com mais de 30 horariosdiferentes, tal que o carview expanda consideravelmente. Portanto, ao iniciar colap-sado, a identidade visual da pagina e preservada.

O detalhe ao topo tambem faz parte do Material Design: a seta a esquerda secontrapoe a seta a direita do item Salas de Aula do menu principal (Figura 4.4a),tal que se torna intuitivo ao usuario como a navegacao se da.

4.2.4 Inscricao em Disciplinas

O aplicativo tambem oferece os servicos de Inscricao, Alteracao e Trancamento deDisciplinas. Esse servico, atraves do website do Portal Aluno, e extremamente ori-entado a mouse. A intencao era fazer no app um servico totalmente orientado atoque. Por um lado, peca-se na visualizacao da grade horaria. Por outro, ganha-seem UX no processo do uso do servico.

A tela tambem faz uso de cardviews pelo mesmo motivo citado na secao da telade salas de aula: as informacoes sao expansıveis e variaveis. Ao final de cada item,temos o sımbolo de relogio com uma seta na parte de baixo. Intuitivamente, passa-sea informacao de que o carview expande com informacoes sobre horarios da disciplinaem questao.

Na segunda tab, ha informacoes sobre o status de cada pedido de inscricao. Oesquema seguido e muito similar ao da primeira tab.

E importante mencionar que a disposicao de elementos, apesar de diferentes,seguem a mesma estrutura do menu inicial (Figura 4.4a): toolbar ao topo com opcoescorrespondentes da pagina; duas tabs sobre informacoes relacionadas dividindo olayout; e itens dispostos verticalmente.

4.3 Experiencia do Usuario (UX)

Nesta secao, sera disposto elementos-chave que visam a melhor experiencia dousuario. O aplicativo, por sua natureza nativa, ja tem uma performance muito boatal que nao haja travamentos de tela nem delays nas transacoes de uma atividadepara outra. No entanto, isso nao garante que o usuario tera uma boa experiencia.

30

(a) Tab 1 : adicionar pedidos (b) Tab 2 : visualizar ou alterar pedidos

Figura 4.6: Paginas de inscricao 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 designde Norman [32].

Os princıpios estao listados abaixo.

Princıpios de Design de Norman

• Visibilidade

• Feedback

• Restricoes

• Mapeamento

• Consistencia

• Affordance

Cada item refere-se a um aspecto que interfaces homem-maquina devem ter paraatingir melhor usabilidade.

Visibilidade

Como o nome sugere, as funcoes as quais o usuario pode usufruir devem estar taovisıveis quanto possıvel. Quando muito escondidas (como exemplo, dentro de sub-menus dentro de menus), torna-se muito trabalhoso para o usuario encontrar algumafuncionalidade que deseja usar.

No aplicativo, foi tentado colocar todas as funcionalidades que o usuario tema disposicao na tela em si, e nao dentro de menus. Todas as acoes sao acessadasatraves da toolbar do app, localizada ao topo.

Como exemplo, a Figura 4.9 mostra diferentes toolbars em telas do aplicativo,mostrando ao usuario o que e possıvel fazer de acordo com aquele contexto.

Outro ponto importante e a pagina inicial, onde o usuario informa as credenciaispara autenticacao. Nesta pagina, e disposto o status do sistema com um sinal indi-cando disponibilidade, instabilidade ou indisponibilidade. Dessa forma, assim que ousuario abre o aplicativo, ele ja tem nocao se sera possıvel conectar aos servidores.Caso apareca status instavel, o usuario ja espera que certas tarefas demorem maisque o normal para ser completadas, ou talvez nao estejam acessıveis no momento.Caso seja status indisponıvel, o usuario ja tera nocao que deve tentar mais tarde.

Os status e suas representacoes estao expostos na Figura 4.7Por conta da API ser modularizada no servidor, ou seja, os diferentes compo-

nentes utilizados para constituir o SIGA nao dependerem entre si, e possıvel que omodulo de Documentos esteja funcionando corretamente mas o modulo de Inscricao

32

(a) Online (b) Instavel

(c) Indisponıvel (d) Carregando

Figura 4.7: Feedback sobre o status disponıveis

nao. O status do sistema e entao conseguido tratando a response obtida a partir derequests para cada modulo utilizado.

Feedback

O princıpio de feedback sugere que para toda acao que o usuario executar, devehaver algum retorno de informacao indicando o efeito dessa acao. Por exemplo,ao se discar um numero no telefone fixo, ha um som indicando que a tecla foipressionada. Analogamente, em smartphones, costuma haver uma suave vibracaona ponta do dedo do usuario.

O app prove feedback de varias formas. Destaca-se que, enquanto qualquer re-quest ao servidor estiver sido feito e aguardando uma response, um sımbolo de loadinge posto na tela, como nas Figuras 4.7d e 4.8.

Assim que uma response e recuperada com sucesso, o usuario e notificado comum sımbolo verde comumente usado como status OK.

Em adicao, o Android por default ja muda a cor de itens de listas quando tocadosou pressionados, tal que os desenvolvedores nao precisem implementar os feedbacksmais imediatos como este.

Restricoes

Para que uma interface seja a mais intuitiva possıvel para o usuario, e bom quehaja um - e somente um - modo de executar cada tarefa. Dessa forma, restringir ousuario pode leva-lo rapidamente e intuitivamente a tentar de outra maneira. Porexemplo, construir um espaco para o cartao de memoria em uma maquina fotografica

33

(a) Autenticando usuario (b) Carregando pagina de inscricao

Figura 4.8: Dialogs sobre o status das requests.

que trave quando o cartao e posto do lado errado faz o usuario intuitivamente naotentar forcar o cartao nesta posicao, e procurar alternativas.

O app restringe usuarios de opcoes que nao seriam possıveis por conta de algummotivo especıfico. Por exemplo, se o usuario tem uma materia trancada, a unicaopcao possıvel para ele e destranca-la (desde que dentro do perıodo de datas em queisto e possıvel). O mesmo vale para uma materia nao trancada. A Figura 4.9 expoeesse princıpio. Dessa forma, e evitado que o usuario tente realizar alguma acao quenao e viavel naquele momento.

Mapeamento

O mapeamento refere-se a uma conexao entre itens da interface grafica e o mundoreal. Por exemplo, no teclado de um notebook existe uma tecla com um sımbolode mega-fone com varias ondas saindo dele; e outra com poucas ondas. Ha doismapeamentos com o mundo real nesse caso: o mega-fone indica saıda de audio,portanto, as teclas devem estar relacionadas com a saıda de audio do aparelho; ea quantidade de ondas sugere maior quantidade ou menor quantidade de algo, nocaso, de ”barulho”. Portanto, e facil chegar a conclusao de que as teclas se referemao volume do dispositivo.

Uma aplicacao do mapeamento na implementacao do aplicativo foi a escolhadas cores para o status do sistema, como demostrado nas Figuras 4.7a, 4.7b e 4.7c.As cores sao intuitivas principalmente por conta das cores do semaforo: verde paralivre, amarelo para atencao e vermelho para parar, nao continuar.

34

(a) Restricao a opcao de trancamento (b) Restricao a opcao de destrancamento

Figura 4.9: Opcoes para o perıodo de trancamento.

35

Consistencia

O princıpio da consistencia sugere que o metodo para atingir algum resultado sejao mesmo por toda a aplicacao. Por exemplo, se em determinada tela o usuarioprecisar 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 acao mais esperada (download dodocumento) e iniciada imediatamente. Os itens com seta indicam que outra paginaira se abrir.

Affordance

O termo affordance nao tem uma traducao literal para o portugues mas esta rela-cionado com a capacidade de um objeto de transmitir a maneira em que se deveinteragir com ele. Um exemplo simples sao teclas em um teclado, que sugerem serpressionadas por conta de seu ligeiro alto relevo.

Itens dispostos em lista e acoes na toolbar sao em de acordo com a visual languageda Google e se tornam intuitivas para o usuario. No caso de um usuario novo, aambientacao com o sistema Android e necessaria, mas por ser algo visıvel e comfeedbacks presentes, ela se torna rapida.

4.4 Desempenho

O desempenho do app e consideravelmente alto por conta de dois fatores: sua natu-reza nativa, que maximiza todas as otimizacoes feitas pelo SDK do Android, e suasimplicidade.

O aplicativo nao utiliza nenhum banco de dados local, visto sua natureza sta-teless. A unica informacao guardada pelo aplicativo sao tokens de autenticacao, etodo resto do processamento e feito no server-side, isto e, no servidor.

Somado a esse fato, o app nao acessa servidores internacionais ou faz chamadasde longa duracao. Os servidores sao dispostos proximos de onde a maioria dosusuarios utilizam e todas as chamadas tem trafego baixıssimo de dados, visto anatureza de comunicacao REST ful utilizando JSON. A comunicacao do aplicativosera mais aprofundada na secao sobre este assunto mais a frente.

Portanto, a latencia - como visto na secao 3.3 - e mınima. Ademais, o tempo deexecucao e baixıssimo, visto que nao ha codigo interpretado em runtime momentoalgum.

36

4.5 Seguranca

O aplicativo utiliza tecnicas para evitar a utilizacao de engenharia reversa. A Go-ogle oferece ferramentas built-in com esta finalidade, alem de existir frameworksproprietarios tambem com este fim. Um bom exemplo sao os ofuscadores de codigo,que geram um codigo totalmente ilegıvel por humanos mas funcional da mesmamaneira.

Alem disso, o app usufrui de todas as medidas de seguranca providas pelo sis-tema operacional (como as sandboxes citadas na secao 3.4). Todas as informacoessalvas pelo aplicativo, que sao as informacoes de login e senha do usuario, sao crip-tografadas. E importante frisar que essas informacoes so sao guardadas se for deescolha do usuario.

4.6 Comunicacao

Para o aplicativo funcionar, foi estruturada uma API REST ful privada nos servi-dores da UFRJ. Por ser REST ful, a API nao guarda dados sobre os usuarios que aacessam, com excecao de dados que sejam necessarios como parametro de algumasrequests, como matrıcula e eventuais tokens de autenticacao.

Toda comunicacao e feita em JSON, por conta da simplicidade de uso e menoroverhead (resultando em maior performance). Para o parsing de dados, foi criadoum JSON parser que trata os dados vindos do servidor. Toda logica e testada viatestes unitarios para assegurar a qualidade do comportamento das regras de negocio.

Um exemplo de response da API do servidor esta disposto abaixo, alem de comose extrai informacao dessa response. O exemplo de JSON de turma e tratado edisposto em um objeto do tipo org.json.JSONObject. O pacote org.json ja e inclusopor padrao no SDK do Android. Para recuperar informacoes como o codigo daturma, e utilizado o metodo getString, como exemplificado no Arquivo 4.2. Para re-cuperar os demais elementos do JSON, metodos semelhantes sao utilizados: semprerecuperando 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 JSONJSONObject 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 logica 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 aplicacao.

Para a logica de negocios, foi utilizado o framework JUnit para testes unitarios.Para testes de UI, optou-se pelo Espresso, que e um framework desenvolvido espe-cialmente para testes em Android.

38

4.7.1 Testes Unitarios

Os testes unitarios foram realizados com o auxılio da biblioteca Mockito. Essabiblioteca permite criar objetos manipulaveis que seriam muito trabalhosos de criar”na mao”, e com isso, testar logicas internas do software.

Um exemplo de teste envolvendo Mockito esta disposto abaixo, fornecido pelowebsite 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 nwhen ( 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 tubbedSystem . 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. Nao ha uti-lizacao do operador new em lugar algum, nem a adicao do item ”first” a lista.Entretanto, o objeto criado ainda funciona de acordo com o esperado.

Esta tecnica pode ser muito util ao testar logicas internas que dependem deobjetos mais complexos.

4.7.2 Testes de Aceitacao

Os testes de UI, comumente referidos como testes de aceitacao, tem como objetivogarantir que a interface grafica se comporta da maneira esperada e monitorar se hamudanca de performance das telas do aplicativo ao longo do tempo.

Isso significa que se algum teste falha, provavelmente alguma funcionalidade datela deveria ter acontecido mas nao aconteceu. Por exemplo, se ao se clicar emcerto botao, um dialog de confirmacao deveria aparecer - mas nao apareceu - o testereportara falha. Ao passo que, se nao ha adicao de novo testes ou mudanca noemulador do Android e o tempo de execucao dos testes comeca a aumentar muito,provavelmente adicionou-se algum algoritmo novo ou codigo que esta prejudicandoa performance geral do app em certa tela.

Para criacao dos testes automatizados, utilizou-se a biblioteca Espresso. Essabiblioteca tem uma maneira de escrita incrivelmente facil e intuitiva, assim como oMockito.

Um exemplo de teste feito com Espresso esta disposto abaixo. O exemplo foiretirado da documentacao oficial da biblioteca [30].

39

@Testpub 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 codigo, ve-se que inicialmente, o Espresso performa escrita do textoSteve 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 mostradana tela.

O codigo e simples e parece uma frase normal escrita em ingles. Essa bibliotecafoi escolhida para os testes de tela por conta da simplicidade de escrita, otimafuncionalidade, recomendacao do Google e performance.

O aplicativo tem 141 testes automatizados utilizando o Espresso. O tempo mediode execucao de todos os testes e de 3 minutos e 30 segundos, o que traduz uma mediade 1.4 segundo por teste. Em contexto de testes de aceitacao, e uma performancemuito boa.

40

Capıtulo 5

Resultados

O app final esta em producao desde fevereiro de 2016. A avaliacao geral do app nodia 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 instalacoes totais. Todas as estatısticasapresentadas neste trabalho sao fornecidas pelo Google Developer Console, que e aplataforma por onde se publica apps na Google Play Store.

Ha um fenomeno interessante ao analisar as estatısticas providas. Usuarios cos-tumam desinstalar o aplicativo durante os meses durante o perıodo, mas ha subitospicos de downloads nas datas de final e inıcio de perıodos. A explicacao e que oacesso ao sistema academico e muito reduzido durante o perıodo, porem com a ne-cessidade de visualizar notas, aprovacoes e reprovacoes, alem de inscricao, alteracaoe trancamento de disciplinas, os acessos aos finais dos termos academicos aumentamsignificativamente.

A avaliacao dos usuarios, como citado, foi excelente. A Figura 5.1 foi retiradado Google Developer Console e confere estatısticas sobre a avaliacao dos usuarios,como quantidade de avaliacoes e o rating de cada uma.

Como pode ser visto aproximadamente 83% das avaliacoes foi a nota maxima

Figura 5.1: Avaliacao dos usuarios.

41

Figura 5.2: Total de instalacoes por usuario.

possıvel (exposta como 5), e 93% das avaliacoes totais foi de 4 ou 5.A Figura 5.2 mostra o numero total de usuarios unicos que ja instalaram o app

em algum dispositivo. Ve-se um crescimento constante no numero de usuarios quefazem o download do aplicativo, com excecao de um ponto em abril/2016. Nestemes, mais especificamente no dia 12 de abril, foi enviado um e-mail atraves doSIGA informando sobre o aplicativo. Ate entao, ele nao tinha sido divulgado deforma oficial, e esta e a razao do pico de downloads no perıodo.

A Figura 5.3, tambem disponibilizado pelo console da Google, mostra a quanti-dade de downloads de acordo com a localidade. Ve-se que, como esperado, o Brasile o principal local de onde o app e baixado, com uma porcentagem de 98.02% dototal de downloads. No entanto, outros paıses, como os Estados Unidos, Franca ePortugal, tambem tem participacao no grafico. Isso sugere que alunos da UFRJem intercambio academico tambem utilizam o aplicativo no perıodo em que estaono exterior, indicando que o produto final agrega valor para os estudantes em seutempo fora.

42

Figura 5.3: Instalacoes do app por paıs.

43

Capıtulo 6

Conclusoes e Trabalhos Futuros

6.1 Conclusoes

Como analisado nos Capıtulos 2 e 3, o desenvolvimento utilizando a abordagemnativa garante o melhor desempenho e experiencia do usuario possıvel. Esses doisfatores contribuem com um peso muito grande para a aceitacao do produto final,como explicitado na Secao 3.3.

O grande ponto negativo da abordagem nativa e o custo da operacao. E ne-cessario desenvolver o mesmo produto varias vezes: uma para cada plataforma esco-lhida. Outro problema e a manutenibilidade, visto que sera necessaria uma equipeespecializada em cada SDK de cada sistema operacional para que o produto con-tinue a receber atualizacoes e eventuais correcoes de bugs. Todo este processo ecustoso nao somente com relacao a dinheiro mas tambem a tempo.

Em contrapartida, a abordagem hıbrida web oferece solucoes mais baratas: re-quer equipes menores e espacos de tempo menores para lancamento e atualizacaodos produtos, visto que se trabalha somente com um codigo base. No entanto aexperiencia do usuario e significativamente inferior quando comparada a abordagemnativa.

Um outro ponto negativo da abordagem hıbrida web e que nao existe um fra-mework oficial para este tipo de desenvolvimento, e considerando a possibilidadede surgimento de varios novos frameworks ao longo do tempo, a decisao de qualframework utilizar para desenvolver um produto, pensando no longo prazo, e umadecisao grande a se tomar.

Portanto, o desenvolvimento nativo leva a maior vantagem na maioria dos que-sitos analisados, como interface grafica, experiencia do usuario, seguranca e per-formance, levando ao melhor produto final possıvel, apesar do consideravel maiorcusto.

44

6.2 Trabalhos Futuros

O proximo passo depois da release da versao Android foi o desenvolvimento do apppara iOS, o segundo maior market share como conferido pela Figura 2.1. Dessaforma, a grande maioria dos alunos e atendida com aplicativos com a maior perfor-mance e satisfacao de experiencia de usuario possıvel.

Alem disso, com as tecnologias utilizadas e o aplicativo ja em producao e devi-damente testados, ha a abertura para expansao do conceito para escopos diferentesdo SIGA. Um exemplo e estender as funcionalidades para utilizacao de professores ecoordenadores de curso da UFRJ, assim como algumas funcionalidades de tecnicos-administrativos.

45

Referencias Bibliograficas

[1] MARCIO, F. “Blog Licenciados em Graduacao UFRJ”. . https://licenciadosemgraduacaoufrj.wordpress.com/, 2005.

[2] A-TEAM ORACLE. “Performance Study – REST vs SOAP forMobile 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 de2017.

[4] GOOGLE. “Google Material Design website”. . https://material.io/guidelines/layout/metrics-keylines.html#metrics-keylines-keylines-spacing, . Acessado em Janeiro de2017.

[5] VALOR. “Numero de usuarios 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 December2016”. . 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 toJanuary 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 emJaneiro de 2017.

46

[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 Servicos 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 onL’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/. Acessadoem Janeiro de 2017.

[17] ONSEN UI. “Onsen UI website”. . https://onsen.io. Acessado em Janeirode 2017.

[18] IONIC. “Ionic website”. . https://developer.apple.com/ios/human-interface-guidelines/ui-views/action-sheets/. Aces-sado em Janeiro de 2017.

47

[19] MOBILE ANGULAR. “Mobile Angular website”. . http://mobileangularui.com/. Acessado em Janeiro de 2017.

[20] KUJALA, S., ROTO, V., VAANANEN-VAINIO-MATTILA, K., et al. “UXCurve: A Method for Evaluating Long-term User Experience”, Interact.Comput., v. 23, n. 5, pp. 473–483, set. 2011. ISSN: 0953-5438. doi:10.1016/j.intcom.2011.06.005. Disponıvel em: ¡http://dx.doi.org/10.1016/j.intcom.2011.06.005¿.

[21] CHARLAND, A., LEROUX, B. “Mobile Application Development: Web vs.Native”, Commun. ACM, v. 54, n. 5, pp. 49–53, maio 2011. ISSN: 0001-0782. doi: 10.1145/1941487.1941504. Disponıvel em: ¡http://doi.acm.org/10.1145/1941487.1941504¿.

[22] COMPOWARE. “Mobile Apps: What Consumers Really Need and Want”.. https://info.dynatrace.com/rs/compuware/images/Mobile_App_Survey_Report.pdf. Acessado em Janeiro de 2017.

[23] APPVIGIL. “Native v/s Hybrid Apps: Security As-pects”. . https://www.appvigil.co/blog/2015/06/native-vs-hybrid-apps-security-aspects-of-each-of-the-apps/.Acessado em Janeiro de 2017.

[24] ANDROID. “Android Training - Security Tips”. . https://developer.android.com/training/articles/security-tips.html. Acessado emJaneiro de 2017.

[25] APPLE. “iOS Security”. . https://www.apple.com/business/docs/iOS_Security_Guide.pdf, may 2016. Acessado em Janeiro de 2017.

[26] “Data Storage - Android Docs”. . https://developer.android.com/guide/topics/data/data-storage.html.

[27] MUCCINI, H., DI FRANCESCO, A., ESPOSITO, P. “Software Testing of Mo-bile Applications: Challenges and Future Research Directions”. In: Proce-edings of the 7th International Workshop on Automation of Software Test,AST ’12, pp. 29–35, Piscataway, NJ, USA, 2012. IEEE Press. ISBN: 978-1-4673-1822-8. Disponıvel em: ¡http://dl.acm.org/citation.cfm?id=2663608.2663615¿.

[28] XIE, T., TANEJA, K., KALE, S., et al. “Towards a Framework for DifferentialUnit Testing of Object-Oriented Programs”. In: Proceedings of the SecondInternational Workshop on Automation of Software Test, AST ’07, pp.

48

5–, Washington, DC, USA, 2007. IEEE Computer Society. ISBN: 0-7695-2971-2. doi: 10.1109/AST.2007.15. Disponıvel em: ¡http://dx.doi.org/10.1109/AST.2007.15¿.

[29] WACKER, M. “Just Say No to More End-to-EndTests”. . https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html, 2015.

[30] “Espresso Website”. . https://google.github.io/android-testing-support-library/docs/espresso/. Acessadoem Janeiro de 2017.

[31] GOOGLE. “Cards”. . https://material.io/guidelines/components/cards.html#cards-usage, . Acessado em Janeiro de 2017.

[32] NORMAN, D. A. The Design of Everyday Things. New York, NY, USA, BasicBooks, Inc., 2002. ISBN: 9780465067107.

[33] “Mockito Website”. . http://site.mockito.org/. Acessado em Janeiro de2017.

49