• Nenhum resultado encontrado

CAFE Mobile

N/A
N/A
Protected

Academic year: 2021

Share "CAFE Mobile"

Copied!
131
0
0

Texto

(1)

F

ACULDADE DE

E

NGENHARIA DA

U

NIVERSIDADE DO

P

ORTO

CAFE Mobile

Amândio dos Santos

Mestrado Integrado em Engenharia Eletrotécnica e de Computadores Orientador: Professor Doutor Ademar Aguiar

Supervisor Externo: Engenheiro Miguel Ramalhão

(2)
(3)

Resumo

Nos dias que correm os dispositivos móveis, especialmente os smartphones são cada vez mais uma parte essencial da vida dos cidadãos, quer para utilização social, quer para uso no trabalho. Isto levou a um grande crescimento na área das aplicações móveis sendo que, hoje em dia, existe uma grande quantidade de soluções para a sua criação, tendo em conta o método de desenvolvi-mento preferido, e os seus requisitos bem como as limitações inerentes às características físicas e de hardware dos dispositivos móveis.

A IPBRICK S.A. possui serviços únicos utilizando diversos softwares open-source configu-rados especificamente para o contexto das soluções IPBrick como VoIP (Voice over IP), UCoIP (Unified Comunications over IP) e IM (Instant Messaging). O CAFE é uma rede social empresa-rial que integra estas soluções permitindo aos seus utilizadores efetuar chamadas de voz e vídeo entre si e bem como estabelecer conversas através de Instant Messaging. Além destes serviços, o CAFE proporciona funcionalidades características de redes sociais como fazer publicações, co-mentários, inquéritos ou criar álbuns. À data de início da realização desta dissertação, a solução existente para dispositivos móveis, o CAFE Mobile versão 2.3, consistia numa aplicação móvel híbrida funcional, mas muito problemática com grandes deficiências nas áreas da usabilidade e do desempenho o que impedem muitos utilizadores de usufruir da aplicação devido à frustração que esta causa. O objetivo desta dissertação é efetuar uma análise às soluções existentes para criação de aplicações móveis e avaliar os principais problemas do CAFE Mobile 2.3 de modo a desenvolver uma aplicação móvel do CAFE mais intuitiva, adaptável a dispositivos móveis e rápida.

A análise efetuada das soluções existentes concluiu que uma aplicação híbrida é adequada visto que permite grande compatibilidade entre sistemas operativos, tem um bom desempenho e é possível utilizar linguagens web, o que é essencial para a integração dos serviços IPBrick no CAFE Mobile. Foi considerado que a solução utilizada anteriormente com a framework Apache Cordova com o plugin Crosswalk é apropriada.

Para melhorar a usabilidade do CAFE Mobile 2.3 foram analisadas as suas funcionalidades bem como o seu layout. Tendo sempre presente boas práticas para obter um design responsivo, foi criado um novo layout de forma a tornar o CAFE mais simples e intuitivo. Foram resolvidos vários problemas de adaptação a dispositivos móveis como a janela de IM, página de álbuns e po-pupde imagens, fazendo um melhor aproveitamento do espaço disponível no ecrã do dispositivo. Para tirar vantagem das características dos dispositivos móveis e aproximar o CAFE Mobile de uma aplicação nativa, foi implementada a navegação utilizando comandos gestuais entre as suas principais páginas.

Foram também estudadas várias técnicas para melhorar o desempenho de uma aplicação e avaliada se a sua implementação traria benefícios à performance do CAFE Mobile. Técnicas como a minificação de ficheiros javascript e CSS, Conversão de GIF’s animados ou substituição de métodos JQuery por métodos HTML DOM Style foram testadas e os resultados obtidos que a sua implementação pode melhorar o desempenho das versões futuras do CAFE.

(4)
(5)

Abstract

Nowadays mobile devices, mainly smartphones, have become an essential part of every com-mon citizen’s daily routine, whether they use it in a social or work related way. This fact led to an enormous growth in the mobile app development community resulting in a large amount of solutions for most of the developers favorite development methods and app requirements taking into account mobile devices’ limitations due to their physical and hardware features.

IPBrick S.A. distributes unique services using open-source software specially configured for each IPBrick solution such as Voice over IP, Unified Communications over IP and Instant Mes-saging. CAFE is an enterprise social network which integrates these solutions allowing its users to begin voice and video calls as well as establishing Instant Messaging conversations. Besides, CAFE has social network features like publishing posts, comments, starting polls or creating al-bums. At the beginning of this thesis, the mobile device solution, CAFE Mobile 2.3, consisted on a working mobile hybrid app, with a great deal of problems and issues in its user experience and performance which stopped many users from using the app due to the frustration it’s use causes. The goal of this thesis is to analyze the existing solutions to create mobile apps and evaluate the main issues of CAFE Mobile 2.3 so that a faster and user and mobile friendlier version of CAFE Mobile is developed.

The research carried out concluded that a hybrid mobile app is suitable because of its good performance, great compatibility across operative systems and support for web programming lan-guages which is key to the integration of IPBrick services on CAFE Mobile. The frameworks used in version 2.3, Apache Cordova with Crosswalk plugin are proper solutions. In order to improve CAFE Mobile 2.3 user experience, it’s features and layout were evaluated. Bearing in mind the responsive design techniques, a new layout was developed with the goal of getting a simpler and more user-friendly mobile app. Various mobile-friendly issues were solved such as the IM win-dow, albums page or pictures popups, where a more efficient use of the available device screen was needed. To fully use the capabilities of mobile devices and give CAFE Mobile a native-like feeling, the support of touch gestures for the navigation between the application’s main pages was added.

Ultimately, some research was done on the performance enhancing methods evaluating whether they should be implemented on CAFE Mobile. Most of the methods such as minifying JavaScript and CSS, animated GIF conversion and replacing JQuery with HTML DOM Style were tested and their results turned out to be positive, meaning that the implementation of such methods could enhance CAFE Mobile’s performance.

(6)
(7)

Agradecimentos

Em primeiro lugar gostaria de agradecer aos meus pais que tudo fizeram para me proporcionar a melhor educação possível e, juntamente com o meu irmão, sempre me apoiaram nas decisões que tomei.

Gostaria de agradecer ao meu orientador, Professor Doutor Ademar Aguiar, porque foi essen-cial no decorrer do período da dissertação, estando sempre disponível para esclarecer dúvidas e ajudar-me a escolher o caminho a seguir.

Também agradeço ao Engenheiro Miguel Ramalhão que facilitou as melhores condições para desenvolver este projeto, ao Engenheiro Hélder Santos que me introduziu ao problema e, sempre que possível, esclareceu dúvidas e ajudou a ultrapassar os impasses no desenvolvimento do traba-lho, ao Engenheiro Anwaar Hussain que esteve sempre disponível para me ajudar, ao Engenheiro Tiago Rodrigues que me auxiliou na fase inicial deste projeto e ao restante departamento IPBrick RnD.

Por último, mas não menos importante, quero agradecer à minha namorada que sempre me apoiou e motivou para conseguir os meus objetivos e aos meus amigos, com especial foco aos quatro que moraram comigo no Porto e fizeram parte do meu percurso académico.

Amândio dos Santos

(8)
(9)

“Dentro de nós há uma coisa que não tem nome, essa coisa é o que somos”

José Saramago

(10)
(11)

Conteúdo

1 Introdução 1 1.1 IPBrick . . . 1 1.2 Enquadramento . . . 1 1.3 Motivação . . . 2 1.4 Objetivos . . . 2 2 Revisão Bibliográfica 3 2.1 Aplicações Nativas vs Híbridas vs Web . . . 3

2.1.1 Aplicações Web . . . 3

2.1.2 Aplicações Nativas . . . 4

2.1.3 Aplicações Híbridas . . . 5

2.1.4 Conclusão . . . 6

2.2 Frameworksde Desenvolvimento Aplicações Móveis . . . 7

2.2.1 Apache Cordova . . . 7 2.2.2 Crosswalk . . . 8 2.2.3 Bootstrap . . . 9 2.2.4 Ionic . . . 9 2.2.5 Appcelarator Titanium . . . 10 2.2.6 Foundation . . . 10 2.2.7 Comparação . . . 10

2.2.7.1 Apache Cordova + Crosswalk vs Ionic/Titanium . . . 11

2.2.7.2 Bootstrap vs Foundation . . . 11

2.3 Usabilidade . . . 12

2.4 Abordagens de Desenvolvimento de Aplicações Móveis . . . 13

2.4.1 Mobile First Design . . . 13

2.4.2 URL’s Separados . . . 14 2.4.3 DesignResponsivo . . . 14 2.4.4 Exibição Dinâmica . . . 15 2.4.5 Javascript/JQueryvs CSS . . . 16 3 Definição do Problema/Solução 17 3.1 Estrutura . . . 17 3.1.1 Yii Framework e MVC . . . 17

3.1.2 Estrutura da Versão Móvel . . . 18

3.2 Design Existente . . . 20

3.3 Objetivos . . . 23

3.4 Requisitos . . . 23

3.4.1 Requisitos Funcionais . . . 23 ix

(12)

3.4.2 Requisitos Tecnológicos . . . 24

3.5 Problemas Atuais . . . 24

3.6 Solução proposta . . . 24

3.7 Tecnologias . . . 25

3.7.1 Ferramentas de Análise de Performance . . . 26

3.7.2 Ferramentas de Testes . . . 27

3.7.2.1 Testes no Browser . . . 27

3.7.2.2 Testes em Dispositivo Móvel Físico ou Emulado para Android 29 3.7.2.3 Testes em Dispositivo Móvel Emulado para iOS . . . 30

3.8 Evolução de Software . . . 31 3.8.1 Procedimento de Lançamento . . . 32 4 Usabilidade 35 4.1 DesignResponsivo . . . 35 4.2 Novo layout . . . 36 4.2.1 Situação 1 . . . 37 4.2.2 Situação 2 . . . 38 4.2.3 Outros exemplos . . . 39

4.2.4 Implementação do novo layout . . . 39

4.3 Janela de Instant Messaging . . . 49

4.3.1 Problemas . . . 49

4.3.2 Nova Janela de Instant Messaging . . . 50

4.4 Popupde Imagens . . . 52

4.4.1 Problema . . . 53

4.4.2 Nova Popup de Imagens . . . 53

4.5 Página de Álbuns . . . 55

4.5.1 Problema . . . 55

4.5.2 Nova Página de Álbuns . . . 56

4.6 Botões para editar/apagar post/comentário . . . 58

4.6.1 Problemas . . . 58

4.6.2 Novos botões para editar/apagar post/comentário . . . 59

4.7 Notificações . . . 60

4.7.1 Problema . . . 60

4.7.2 Implementação de Notificações . . . 60

4.8 Navegação com Comandos Gestuais . . . 65

4.8.1 Problema . . . 65

4.8.2 Implementação da Navegação com Comandos Gestuais . . . 65

5 Desempenho 71 5.1 Minificação . . . 71

5.2 HTTP/2 . . . 73

5.3 Otimização de Código . . . 73

5.3.1 Otimização de Ciclos . . . 74

5.3.2 Métodos JQuery vs HTML DOM Style . . . 75

5.3.3 Exibição Dinâmica . . . 78

5.4 Conversão de GIF’s animados . . . 80

5.5 Carregamento de ficheiro javascript . . . 84

(13)

CONTEÚDO xi

6 Conclusão 89

6.1 Validação . . . 90 6.2 Trabalho Futuro . . . 90

A Outras Melhorias de Usabilidade 93

A.1 Menu Lateral . . . 93 A.2 Botão de Retroceder . . . 94 A.3 Tamanho dos Botões . . . 95

B Outras Melhorias de Desempenho 97

B.1 Propriedade CSS "will-change" . . . 97 B.2 Substituição de javascript por CSS . . . 98

(14)
(15)

Lista de Figuras

1.1 screenshotda versão dektop do CAFE [1] . . . 2

2.1 Aplicação construída com HTML5 pode adaptar-se a uma vasta gama de disposi-tivos [2] . . . 3

2.2 Arquitetura de uma aplicação híbrida utilizando a framework Apache Cordova [3] 5 2.3 Aplicações móveis Web vs Híbrida vs Nativa [4] . . . 6

2.4 Lista de plugins disponibilizados pelo Apache Cordova para vários Sistemas Ope-rativos [5] . . . 7

2.5 As fases do desenvolvimento de design centrado no utilizador [6] . . . 13

2.6 Exemplo da utilização do método de URL’s separados [7] . . . 14

2.7 Exemplo da utilização Design responsivo [8] . . . 15

2.8 Exemplo da utilização exibição dinâmica [9] . . . 15

3.1 Esquema da arquitetura MVC [10] . . . 18

3.2 screenshotdo feed de notícias da aplicação atual do CAFE . . . 20

3.3 screenshotda barra lateral da aplicação atual do CAFE . . . 20

3.4 screenshotdo menu de comunicações unificadas da aplicação atual do CAFE . . 21

3.5 screenshotdo menu de VoIP da aplicação atual do CAFE . . . 21

3.6 screenshotda janela de chat da aplicação atual do CAFE . . . 21

3.7 screenshot da janela de chat da aplicação atual do CAFE com o smartphone na horizontal (landscape) . . . 21

3.8 screenshotda caixa de texto para publicar no feed da aplicação atual do CAFE . . 22

3.9 screenshotda janela de notícias da empresa da aplicação atual do CAFE . . . 22

3.10 screenshot da janela de definições pessoais da aplicação atual do CAFE . . . 22

3.11 screenshot da janela de autenticação da aplicação atual do CAFE . . . 22

3.12 Exemplo do uso do Chrome DevTools com o painel Network . . . 27

3.13 Exemplo do uso dos controlos de resolução da janela de visualização [11] . . . . 28

3.14 Exemplo do uso dos controlos de orientação e barra de navegação da janela de visualização [11] . . . 28

3.15 Exemplo do uso do painel de inspeção de elementos . . . 28

3.16 Exemplo do uso da consola . . . 29

3.17 Exemplo do uso da Android Emulator com CAFE Mobile 2.3 . . . 30

3.18 Exemplo do uso da iOS Simulator com CAFE Mobile 2.4 . . . 31

3.19 O processo de software evolution [12] . . . 31

3.20 Método de teste de software black-box [13] . . . 33

4.1 Resoluções de smartphones mais usadas (maio de 2016 a maio de 2017) [14] . . 36

4.2 Ícone de navegação para a página UCoIP no CAFE Mobile 2.3 . . . 37

4.3 Ícone de navegação para a página inicial no CAFE Mobile 2.3 . . . 38 xiii

(16)

4.4 Ícone de navegação para a página de notícias da empresa no CAFE Mobile 2.3 . . 38

4.5 Pesquisa de hashtags no CAFE 2.3 . . . 39

4.6 screenshotdo novo layout feed de notícias do CAFE Mobile . . . 40

4.7 screenshotdo novo layout da página UCoIP do CAFE Mobile . . . 40

4.8 screenshotdo novo layout da página do WebPhone do CAFE Mobile . . . 40

4.9 screenshotdo novo layout da página de notificações do CAFE Mobile . . . 40

4.10 Barra de navegação no CAFE Mobile 2.4 . . . 41

4.11 Página de Inquéritos no CAFE Mobile 2.4 . . . 44

4.12 Botão para voltar à página inicial no CAFE Mobile 2.4 . . . 44

4.13 Área de publicação de posts no CAFE Mobile 2.4 . . . 45

4.14 Área de publicação de posts, pronta a publicar, no CAFE Mobile 2.4 . . . 45

4.15 Botão para mostra a área de publicação de um novo post no CAFE Mobile 2.4 . . 45

4.16 Botão de publicação de um novo post no CAFE Mobile 2.4 . . . 46

4.17 Botão para inserir uma imagem no novo post . . . 46

4.18 Header do CAFE Mobile 2.4 com a pesquisa por hashtags . . . 47

4.19 Header do CAFE Mobile 2.4 com a pesquisa por hashtags ativa . . . 47

4.20 Layout do CAFE Mobile 2.3 com a janela de IM minimizada . . . 49

4.21 Janela de IM no CAFE Mobile 2.4 . . . 51

4.22 Layout do CAFE Mobile 2.4 com a janela de IM minimizada . . . 51

4.23 Janela de IM no CAFE Mobile 2.4 em landscape (horizontal) . . . 51

4.24 Ícone de janela de IM minimizada . . . 51

4.25 Ícone de janela de IM maximizada . . . 51

4.26 Popup de imagem de um post no CAFE Mobile 2.3 . . . 53

4.27 Popup de imagem de um post no CAFE Mobile 2.4 . . . 54

4.28 Botão para fechar popup no CAFE Mobile 2.4 . . . 54

4.29 Página de albuns do CAFE Mobile 2.3 com orientação portrait (vertical) . . . 56

4.30 Página de albuns do CAFE Mobile 2.3 com orientação landscape (horizontal) . . 56

4.31 Página de álbuns do CAFE Mobile 2.4 com orientação landscape (horizontal) com 3 álbuns por fila . . . 56

4.32 Página de álbuns do CAFE Mobile 2.4 com orientação portrait (vertical) . . . 57

4.33 Página de álbuns do CAFE Mobile 2.4 com orientação landscape (horizontal) com 4 álbuns por fila . . . 57

4.34 Botões de apagar/ editar post no CAFE Mobile 2.3 . . . 58

4.35 Botão de opções de post no CAFE Mobile 2.5 . . . 59

4.36 Botões de apagar/editar post no CAFE Mobile 2.5 . . . 59

4.37 Botões notificações com alerta no CAFE Mobile 2.4 . . . 60

4.38 Notificações num dispositivo móvel Android no CAFE Mobile 2.5 . . . 61

4.39 Comandos gestuais detetados pelo Hammer.js [15] . . . 65

4.40 Estrutura da implementação da navegação com comandos gestuais [16] . . . 66

4.41 Navegação utilizando comandos gestuais no CAFE Mobile 2.5 . . . 70

5.1 Tamanho dos ficheiros do CAFE antes da minificação . . . 72

5.2 Tamanho dos ficheiros do CAFE depois da minificação . . . 72

5.3 Versão do Apache numa IPBrick . . . 73

5.4 Consola do Chrome DevTools com os tempos de início e fim de execução da fun-ção4.3 . . . 77

5.5 Page Sourcedo Chrome DevTools com uma verificação de useragent (correspon-dente a um dispositivo móvel) em javascript . . . 79

(17)

LISTA DE FIGURAS xv

5.6 Page Source do Chrome DevTools antes da aplicação dos métodos de exibição

dinâmica . . . 80

5.7 Page Source do Chrome DevTools depois da aplicação dos métodos de exibição dinâmica . . . 80

5.8 Interesse na pesquisa do formato GIF ao longo do tempo [17] . . . 80

5.9 Menu Network do Chrome DevTools com os tempos de carregamento e tamanho de um GIF no CAFE Mobile 2.3 . . . 81

5.10 Menu Network do Chrome DevTools com os tempos de carregamento e tamanho de um ficheiro MP4 resultante da conversão de um GIF no CAFE Mobile 2.5 . . 83

5.11 Comparação entre os métodos de carregamento de ficheiros javascript [18] . . . 84

A.1 Menu lateral no CAFE Mobile 2.5 . . . 93

A.2 Exemplo de botão de retroceder virtual . . . 94

A.3 Exemplo de botão de retroceder físico [19] . . . 94

A.4 Área de contactos no CAFE Mobile 2.3 . . . 96

(18)
(19)

Lista de Tabelas

2.1 Percentagem de mercado dos Sistemas Operativos mais utilizados [20] . . . 5

2.2 Browsersdisponíveis para o Bootstrap [21] . . . 9

2.3 Browsersdisponíveis para o Foundation [21] . . . 10

2.4 Browsersdisponíveis para o Bootstrap e Foundation [21] . . . 11

2.5 Medições dos testes de comparação entre CSS e JQuery [22] . . . 16

3.1 Comparação da performance do Yii com outras frameworks [23] . . . 17

3.2 Comparação de desempenho entre Yii 2.0 e Laravel 5.0 [24] . . . 18

3.3 Tabela de preenchimento de testes . . . 32

4.1 Classe visible do Bootstrap [25] . . . 42

5.1 Resultados obtidos no website jsPerf em operações por segundo no browser Ch-romeversão 48.0.2564 [26] . . . 75

5.2 Tempos de navegação entre páginas, em milissegundos, utilizando "show()/hide()" na função4.3 . . . 77

5.3 Tempos de navegação entre páginas, em milissegundos, utilizando HTML DOM Style Objectna função4.3 . . . 77

5.4 Tabela com os resultados das medições de carregamento de javascript sem utilizar atributos (segundos) . . . 85

5.5 Tabela com os resultados das medições de carregamento de javascript utilizando o atributo "defer" (segundos) . . . 85

5.6 Tabela com os resultados das medições de carregamento de javascript utilizando o atributo "async" (segundos) . . . 85

5.7 Resultados dos testes de carregamento da aplicação . . . 86

(20)
(21)

Lista de Algoritmos

3.1 Condição de deteção de dispositivos móveis em javascript . . . 19

3.2 Exemplo de uma Media Query em CSS . . . 19

3.3 Exemplo de uma modificação de atributos de elementos utilizando jquery . . . . 19

4.1 Exemplo de Media Query em CSS com orientação landscape . . . 36

4.2 Estrutura do código de implementação da barra de navegação . . . 41

4.3 Estrutura do código da função de seleção de conteúdo a mostrar (javascript) . . . 43

4.4 Estrutura do código de implementação do botão de voltar à página inicial . . . . 44

4.5 Estrutura do código de implementação do botão para mostrar a área de publicação de novos posts . . . 46

4.6 Estrutura do código de implementação da mudança de estado do botão de publi-cação de posts . . . 47

4.7 Função usada para baixar a tonalidade da cor do Header . . . 48

4.8 Excerto do código utilizado para minimizar/maximizar a janela de IM . . . 52

4.9 Excerto do código utilizado para a implementação de Popup de imagens . . . 54

4.10 Excerto de CSS utilizado para a implementação da disposição de álbuns . . . 57

4.11 Excerto de código javascript utilizado para a implementação dos botões de edi-tar/apagar post/comentário . . . 60

4.12 Função para criar instâncias da API Web Notifications . . . 61

4.13 Excerto da action para obtenção da informação das notificações . . . 62

4.14 Pedido AJAX e envio de novas notificações . . . 64

4.15 Excerto de código HTML usado para implementar a navegação através de coman-dos gestuais . . . 66

4.16 Excerto de código javascript usado para implementar a deteção de início do gesto pan . . . 67

4.17 Excerto de código javascript usado para implementar a deteção do fim do gesto pan 68 4.18 Excerto de código javascript da função "goToSlide" . . . 69

5.1 Excerto de código PHP para minificação dos ficheiros do CAFE . . . 72

5.2 Excerto de código PHP para obtenção dos grupos do CAFE . . . 74

5.3 Excerto de código PHP para obtenção das variáveis de sessão com os grupos do CAFE . . . 75

5.4 Excerto de código javascript utilizando métodos HTML DOM Style Object . . . 76

5.5 Excerto de código javascript da função testada no website jsPerf [26] . . . 76

5.6 Excerto de código javascript para imprimir na consola do Chrome DevTools . . . 77

5.7 Excerto de código PHP para verificar o user agent . . . 78

5.8 Exibição dinâmica da propriedade tooltip . . . 79

5.9 Excerto de código PHP para efetuar a conversão de GIF’s para MP4 . . . 81

5.10 Excerto de código HTML para mostrar o ficheiro MP4 resultante de um GIF con-vertido . . . 83

(22)

5.11 Excerto de código HTML com o carregamento de ficheiros javascript com e sem atributos "defer" e "async" . . . 84 A.1 Excerto de código javascript de implementação das funcionalidades do botão para

retroceder . . . 95 B.1 Excerto de código CSS com a implementação da propriedade "will-change" . . . 97

(23)

Abreviaturas e Símbolos

UCoIP Unified Communications Over IP

IM Instant Messaging VoIP Voice over IP PC Personal Computer

HTML HyperText Markup Language CSS Cascading Style Sheets URL Uniform Resource Locator WebRTC Web Real-Time Communication SO Sistema Operativo

GPS Global Positioning System

API Application Programming Interface WebGL Web Graphics Library

CPU Central Processing Unit GPU Graphics Processing Unit ARM Advanced RISC Machine

RISC Reduced instruction set computing IE Internet Explorer

SASS Syntactically Awesome Style Sheets XML eXtensible Markup Language TSS Transformation Style Sheets APK Android Package Kit Yii Yes it is

MVC Model-View-Controller PHP PHP: Hypertext Preprocessor DB DataBase

RPS Request Per Second APC Alternative PHP Cache DOM Document Object Model RGB Red Green Blue

W3C World Wide Web Consortium SQL Structured Query Language JSON JavaScript Object Notation

AJAX Asynchronous JavaScript And XML HTTP HyperText Transfer Protocol

GIF Graphics Interchange Format IDE Integrated development environment

XMPP Extensible Messaging and Presence Protocol ORD Object-Relational Database

LAPP Linux Apache PostgreSQL PHP xxi

(24)
(25)

Capítulo 1

Introdução

Neste capítulo é feita uma introdução ao problema abordado nesta dissertação bem como as necessidades que o originaram e também o seu contexto empresarial.

1.1

IPBrick

A IPBrick S.A. é uma empresa que produz soluções de comunicações para empresas, com principal foco em cloud privada e on premises. Uma das suas principais filosofias é construir soluções utilizando software open-source. É uma empresa com vários parceiros e distribuidores, tanto em Portugal como em vários países no mundo [27].

Um dos principais produtos da empresa e o mais relevante para esta dissertação é o IPBrickOS. Baseado em Linux Debian, o IPBrickOS é uma plataforma de comunicações para sistemas de servidores de empresas que junta: comunicações unificadas, gestão de documentos e processos, email, groupware e uma rede social empresarial, o CAFE [28]. É um sistema LAPP, ou seja, baseado em Linux como sistema operativo, Apache como servidor web, PostgreSQL como base de dados e PHP como linguagem de programação backend.

1.2

Enquadramento

O IPBRICK.CAFE [1] é uma rede social empresarial que proporciona um espaço virtual co-mum, onde os colaboradores da mesma empresa podem trocar informações úteis, melhorar as suas relações e aumentar sobretudo a sua produtividade. Integra, também, todas as ferramentas de comunicação da IPBrick [27] (sistema UCoIP) e permite o acesso direto a aplicações empresariais. Hoje em dia, se um utilizador quiser utilizar o CAFE através do seu smartphone tem duas so-luções: aceder pelo browser ou utilizar uma aplicação (do tipo híbrida com WebView), já existente para dispositivos Android. No entanto, estas soluções têm imensos problemas que as impossi-bilitam de serem utilizadas pela maior parte dos utilizadores. Um deles é a falta de fluidez e rapidez da aplicação que se nota principalmente em smartphones que não sejam de gama alta e tenham capacidade de processamento baixa. Outro problema recai sobre algumas deficiências na

(26)

“User Interface”, por exemplo, a existência de ícones muito pequenos que dificultam a interação do utilizador com algumas funcionalidades. Estes são apenas alguns dos problemas que tornam a experiência atual de um utilizador com o CAFE Mobile frustrante e pouco útil.

Figura 1.1: screenshot da versão dektop do CAFE [1]

1.3

Motivação

Atualmente o uso de smartphones está cada vez mais presente no quotidiano da maioria dos cidadãos de países desenvolvidos. Segundo o Instituto Nacional de Estatística, através do Inquérito à Utilização de Tecnologias da Informação e da Comunicação pelas Famílias de 2015, “dois terços dos utilizadores de Internet acedem à rede em mobilidade, essencialmente através de telemóvel ou smartphone” [29]. Como tal, é necessário disponibilizar aos utilizadores soluções que lhes permitam aceder às suas aplicações (web, híbridas ou nativas), necessárias ao dia-a-dia de uma maneira simples, rápida e intuitiva.

Um utilizador do CAFE, hoje em dia, depara-se com uma grande dificuldade para utilizar a aplicação quando está longe de um computador devido aos problemas funcionais e de fluidez das soluções atuais para smartphone, quer quando o CAFE é acedido através do browser quer através da aplicação (Sistema Operativo Android). A motivação principal desta dissertação é resolver este problema, ou seja, tornar o CAFE numa aplicação rápida, fluida e útil para que os seus utilizadores a possam usar sem problemas numa grande gama de smartphones.

1.4

Objetivos

Os principais objetivos desta dissertação são:

• Efetuar uma análise ao layout e modo de funcionamento do CAFE quando acedido através de dispositivos móveis, identificando as principais lacunas;

• Idealizar e apresentar soluções para as situações identificadas no ponto anterior;

• Desenvolver o CAFE Mobile tendo em conta as soluções encontradas no ponto anterior, garantido sempre as boas práticas de “User Experience” e “User Interface”.

(27)

Capítulo 2

Revisão Bibliográfica

Este capítulo pretende descrever a pesquisa efetuada no âmbito das soluções para criação de aplicações móveis. Além de explorados os vários tipos de aplicações, são também analisadas a principais frameworks existentes bem como alguns métodos de desenvolvimento.

2.1

Aplicações Nativas vs Híbridas vs Web

O primeiro passo para desenvolver uma aplicação móvel é decidir que tipo de aplicação é o mais adequado. Atualmente existem três hipóteses, a aplicação pode ser nativa, híbrida ou web.

2.1.1 Aplicações Web

Uma aplicação Web é uma aplicação criada numa página web (normalmente usando HTML5), que se adapta a várias plataformas. Como é feita num browser pode ser utilizado num qualquer smartphonemoderno [30]. Uma aplicação web é normalmente descarregada do servidor sempre que é executada [31].

Figura 2.1: Aplicação construída com HTML5 pode adaptar-se a uma vasta gama de dispositivos [2]

A principal vantagem das aplicações web é a sua compatibilidade com a maior parte das plata-formas. A grande maioria dos smartphones têm um browser e como tal podem executar aplicações

(28)

web. Isto torna-as também baratas e fáceis de criar e manter porque HTML5 (HTML, javascript e CSS) não requer nenhum software em específico para criar/editar o código (um editor de texto é suficiente) e, como são executadas no browser do smartphone, não é necessário acompanhar as mudanças nos Sistemas Operativos e plataformas existentes.

Para o utilizador, a grande vantagem é não ter que descarregar a aplicação, para a executar basta abrir o browser do seu smartphone e aceder ao URL (Uniform Resource Locator) da aplicação [31].

A principal desvantagem das aplicações web são as limitações que podem ter ao aceder às fun-ções do smartphone como a câmara ou o microfone [32]. Estas limitações dependem do browser e Sistema Operativo e do protocolo de comunicações que utilizam. Por exemplo, se for utilizado um sistema browser - Sistema Operativo que utilize o protocolo WebRTC, é possível utilizar o microfone e a câmara do smartphone, no entanto nem todos os dispositivos usam protocolos em que isto seja possível [33]. Mesmo nos casos em que o protocolo utilizado é WebRTC (ou ou-tro semelhante), é impossível ou muito complicado aceder a outras características do smartphone como por exemplo a lista de contactos.

Outra desvantagem importante é a performance que tende a ser baixa quando comparada com aplicações nativas. Isto deve-se à utilização de javascript que é uma linguagem que não foi con-cebida para ter uma alta performance. Os PC’s conseguem executar uma aplicação web com javascript sem problemas porque têm uma boa capacidade de processamento e memória. No en-tanto, os smartphones têm memória mais limitada o que torna a execução de javascript mais lenta [32].

É também importante realçar que as aplicações web podem não funcionar, ou estar muito limitadas, quando não existe uma conexão à Internet o que também é uma desvantagem para o utilizador [31].

2.1.2 Aplicações Nativas

As aplicações consideram-se nativas se forem criadas para um Sistema Operativo em especí-fico utilizando as linguagens e software que esse S.O. suporta [34].

A principal vantagem das aplicações nativas é a performance e a user experience que transmite ao utilizador. Por norma estas aplicações têm animações mais rápidas e fluidas [32] e conseguem aceder ao hardware (câmara, microfone, GPS, etc) e software (contactos, email, calendário, etc) do smartphone [31].

Numa aplicação nativa, quando é lançado um novo hardware ou API de um determinado dispositivo, a tecnologia necessária para o aceder fica imediatamente disponível, algo que não acontece em HTML5 [32].

A grande desvantagem das aplicações nativas é serem totalmente dependentes do Sistema Operativo do dispositivo em causa.

Como se verifica na tabela2.1, embora atualmente o S.O. Android domine claramente o mer-cado, existem minorias não desprezáveis, principalmente o S.O. iOS. Como tal, para criar uma aplicação nativa competitiva teria que ser criada, pelo menos, para Android e iOS o que levaria a

(29)

2.1 Aplicações Nativas vs Híbridas vs Web 5

Período Android iOS Windows Phone Outros 2015Q4 79,6% 18,7% 1,2% 0,5% 2016Q1 83,5% 15,4% 0,8% 0,4% 2016Q2 87,6% 11,7% 0,4% 0,3% 2016Q3 86,8% 12,5% 0,3% 0,4%

Tabela 2.1: Percentagem de mercado dos Sistemas Operativos mais utilizados [20]

que fossem gastos recursos a criar duas aplicações com funcionalidades semelhantes mas com lin-guagens de programação e tecnologias diferentes bem como ser capaz de lidar com a manutenção de duas aplicações com as características anteriormente referidas. Tudo isto torna as aplicações nativas muito caras, especialmente quando comparadas com aplicações web [30].

2.1.3 Aplicações Híbridas

Uma aplicação híbrida é uma aplicação escrita utilizando linguagens e técnicas web (HTML, javascript e CSS) que executa contida numa framework de características de uma aplicação na-tiva [34]. Resumidamente, é uma aplicação web que executa num browser que está "embrulhado" numa aplicação nativa.

Figura 2.2: Arquitetura de uma aplicação híbrida utilizando a framework Apache Cordova [3] A principal vantagem das aplicações híbridas é conjugar as vantagens das aplicações web com as aplicações nativas, isto é, ser compatível com a maior parte dos dispositivos e Sistemas Operativos devido a ser criada com HTML5 e ter acesso ao software e hardware do smartphone através da framework que "embrulha" a parte de HTML5 (WebView) numa aplicação nativa [35]. As suas características também permite que o utilizador sinta que está a lidar com uma aplica-ção nativa devido à maneira como é descarregada (através de uma loja de aplicações), fica guar-dada no dispositivo e é executada através do menu ou ambiente de trabalho do dispositivo, como

(30)

uma aplicação nativa, no entanto o seu custo é menor porque não é necessário criar uma aplicação para cada Sistema Operativo [36].

A principal desvantagem das aplicações híbridas é serem semelhantes às aplicações web no que respeita à sua qualidade gráfica e performance e embora estes fatores tenham vindo melhorar nos últimos anos, ainda não atingiram o nível das aplicações nativas [37].

Outra desvantagem importante é requererem um conhecimento das frameworks (que permitem "embrulhar" o HTML5 numa app nativa) o que acrescenta alguma complexidade ao desenvolvi-mento da aplicação [37].

Segundo o estudo [38] em que foram analisadas as 500 aplicações mais populares de cada ca-tegoria do Google Play Store foi concluído que 3,73% das aplicações eram híbridas. No entanto, em aplicações de categorias cujo foco é a transmissão de informação (Finanças, Saúde, Trans-porte, Negócios, Lazer e Sociais) o número de aplicações híbridas é superior (por exemplo, nas aplicações de finanças, 11,54% são híbridas). Quando são aplicações que requerem animações sofisticadas e uma alta performance (Jogos, Música, Vídeo, Fotografia) a percentagem de aplica-ções híbridas é extremamente reduzida (as aplicaaplica-ções de jogos têm uma percentagem de apenas 0,2% de aplicações híbridas). Isto deve-se às características das aplicações híbridas que, como são baseadas em HTML5, são simples e eficazes na transmissão de informação e dados mas um pouco limitadas quando é necessário ter uma performance elevada e animações elaboradas [38].

2.1.4 Conclusão

Figura 2.3: Aplicações móveis Web vs Híbrida vs Nativa [4]

Após avaliar os métodos para criar uma aplicação móvel, as suas vantagens e as suas desvan-tagens, posso concluir que a melhor opção é a que está atualmente em uso, uma aplicação híbrida. Embora com uma aplicação nativa se obtenha uma melhor performance e user experience, os cus-tos associados são demasiado elevados. Com uma aplicação híbrida consegue-se tirar partido da maior parte das vantagens de uma aplicação nativa sendo que os seus custos são menores. Além disto é possível reutilizar o código que existe para a aplicação desktop do CAFE ao contrário do que acontece numa aplicação nativa.

(31)

2.2 Frameworks de Desenvolvimento Aplicações Móveis 7

2.2

Frameworks de Desenvolvimento Aplicações Móveis

Para desenvolver aplicações móveis, principalmente no caso de híbridas ou web, é essencial o uso de frameworks. Nesta secção serão apresentadas as frameworks usadas no CAFE Mobile 2.3 bem como as principais alternativas. Serão descritas as suas principais vantagens e desvantagens e será feita uma comparação entre elas.

2.2.1 Apache Cordova

Como foi referido anteriormente na secção2.1.3, para transformar o código desenvolvido para uma aplicação web numa aplicação híbrida é necessário uma framework que "envolva" todo o HTML5, javascript e CSS numa aplicação de características nativas.

O Apache Cordova [3] é uma framework open-source de desenvolvimento de aplicações mó-veis que permite usar tecnologias e linguagens de programação web. É a framework que está a ser usada atualmente no CAFE Mobile. Na figura2.2encontra-se a arquitetura de uma aplicação híbrida usando o Apache Cordova [3].

Como o Apache Cordova é open-source, não comporta custo de aquisição da framework o que é uma enorme vantagem. Isto permitiu que fossem criadas outras versões do Apache Cordova por terceiros como o Adobe PhoneGap [39].

Figura 2.4: Lista de plugins disponibilizados pelo Apache Cordova para vários Sistemas Operati-vos [5]

Outra vantagem é a grande quantidade de plugins que o Apache Cordova disponibiliza (fi-gura2.4) o que permite à aplicação ter acesso às características do smartphone. Como o Apache

(32)

Cordova é open-source existe também uma grande quantidade de plugins disponibilizados por terceiros [5].

Uma das desvantagens das aplicações criadas utilizando o Apache Cordova é que, como têm características de aplicações web e de aplicações nativas, partilham dos riscos de segurança de ambos. Embora atualmente já existam ferramentas que melhoram a segurança destas aplicações no entanto ainda existem algumas lacunas [36].

Outra desvantagem do Apache Cordova é o WebView que utiliza que faz parte do Sistema Operativo do dispositivo. Se, por exemplo, estivermos a usar Android, algumas versões mais antigas têm um browser antigo o que lhes retira funcionalidades. No entanto, esta problema pode ser ultrapassado utilizando frameworks como o Crosswalk2.2.2.

2.2.2 Crosswalk

O Crosswalk Project [40] é um runtime que adiciona novas capacidades à aplicação híbrida criada. É um projeto open-source que foi criado pela Intel’s Open Source Technology Center. Funciona como um complemento ao Apache Cordova melhorando o seu WebView e acrescenta WebGL, WebAudio e WebRTC. Melhora também a performance em dispositivos Android nas versões acima do Android 4.0 [40].

A principal vantagem em usar o Crosswalk é uniformizar o Webview que a aplicação utiliza independentemente da versão do Sistema Operativo o que permite ao seu programador não ter que se preocupar com a diferença de características do WebView. Funciona em vários Sistemas Operativos como Android (versão 4.0 e acima), iOS, Linux(deb), e Tizen 3.0 [40].

Para Android o programador pode escolher a versão do Chromium que quer usar como Web-Viewo que trás tecnologias como WebRTC ou Web Components para a aplicação que pode não ser suportado pelo browser de defeito do Sistema Operativo [41].

Para iOS, o WebView usado na aplicação é o WKWebView, criado pela Apple para o iOS 8.0 e superiores que utiliza o motor de renderização WebKit [42].

Na Google Play Store, o Crosswalk já foi usado em mais de 6000 aplicações. A sua grande popularidade faz com que exista uma boa quantidade de conteúdo de suporte disponível e que haja regularidade no lançamento de atualizações que acrescentam novas funcionalidades e acom-panham o avanço da tecnologia [43].

A sua principal desvantagem é o tamanho que acrescenta à aplicação. Por exemplo, uma aplicação que tenha um tamanho 24 Kb, depois de ser aplicado o Crosswalk 10 (x86 Android) o tamanho da apk (Android Package) é de aproximadamente 20 Mb e quando instalada sobe para 58Mb [40].

Quando a aplicação é criada com Crosswalk não se torna numa única apk que funciona em qualquer arquitetura de CPU. Em vez disso é criada uma apk para cada arquitetura, uma para ARM (Advanced RISC Machine) e outra para x86, sendo necessário submeter as duas versões para a Google Play Store o que torna o processo de publicação da aplicação um pouco mais complexo [44].

(33)

2.2 Frameworks de Desenvolvimento Aplicações Móveis 9

2.2.3 Bootstrap

O Bootstrap [45] é uma framework open-source criada por funcionários do Twitter em 2010. O seu objetivo é tornar websites responsivos, de maneira a que se adaptem a ecrãs de vários tamanhos, com um foco especial nos dispositivos móveis [45]. Para transformar o CAFE no CAFE Mobile foi necessário utilizar o Bootstrap para transformar o código utilizado na versão desktopdo CAFE num código responsivo.

Existe uma grande quantidade de informação sobre o Bootstrap devido à sua popularidade e é atualizado frequentemente o que aumenta a probabilidade de os seus problemas serem resolvidos e novas funcionalidades adicionadas mais rapidamente [21]bem como tutoriais, plugins, extensões e temas [46]. Por exemplo, no repositório web GitHub, o Bootstrap tem mais de 105 000 stars (utilizadores a seguir o projeto) e mais de 47 000 forks (cópias do repositório usadas para fazer modificações ao projeto original) [47]. Além disto o Bootstrap mantém as suas características do website quando acedido através de vários browsers [21].

Chrome Firefox Safari IE11 IE10 IE9 Bootstrap X X (excepto Android) X (Excepto Win) X X Limitado

Tabela 2.2: Browsers disponíveis para o Bootstrap [21]

Quando o Bootstrap é usado para criar uma aplicação, o design que esta framework aplica no código já existente para tornar a aplicação responsiva é semelhante em todas as aplicações que usam Bootsrap e é complexo alterá-lo. Isto limita o programador se este quiser criar um design genuíno [48].

2.2.4 Ionic

O Ionic é uma framework para criar aplicações híbridas baseadas em HTML5 [49]. Foi criada com o Apache Cordova como suporte o que permite ter acesso aos seus plugins e ter assim acesso ao software e hardware do dispositivo móvel [50]. Embora seja possível usar o Ionic apenas com HTML, CSS e javascript, o seu potencial só é atingido usando AngularJS [49].

Os Sistemas Operativos que o Ionic suporta são o iOS 7 (e versões superiores) e o Android 4.1 (e versões superiores). É open-source e tem boa equipa de suporte e informação disponí-vel para ajudar no desenvolvimento da aplicação. Como o Ionic utiliza AngularJS, tem todas as vantagens associadas a isso incluindo ferramentas criadas pela equipa do AngularJS para efetuar debugging [51]. Para pré-compilar CSS, o Ionic utiliza SASS o que também acrescenta mais funcionalidades que não existem no CSS3 como variáveis, if ’s ou loops [52].

O principal problema do Ionic é o facto de utilizar AngularJS pode ser uma desvantagem porque implica que o programador que desenvolva a aplicações tenha esses conhecimentos [53].

Como referi anteriormente, o Ionic utiliza o Apache Cordova e os seus plugins. Também é pos-sível integrar o Crosswalk no Ionic o que trás as vantagens associadas ao uso do Crosswalk [54].

(34)

2.2.5 Appcelarator Titanium

O Appcelarator Titanium é uma framework para criar aplicações web ou nativas através de um código único de javascript [55]. Em semelhança com o Apache Cordova, tem a acesso a várias funções do telefone como a agenda, vibração ou microfone [56]. Ao contrário do Apache Cordova que utiliza um WebView para a interface gráfica da aplicação, o Titanium compila o código javas-cript resultando numa aplicação executável para cada Sistema Operativo de plataformas móveis (apenas iOS e Android) [35].

A linguagem de programação web utilizada é javascript e XML (eXtensible Markup Lan-guage) para o layout e TSS (o correspondente a CSS para o Titanium). Como o seu modo de funcionamento é compilar o código para nativo, as aplicações criadas com o Titanium têm poten-cial para ser mais rápidas e fluidas porque são mais próximas de aplicações nativas [35].

A principal desvantagem do Appcelarator Titanium é o facto de só usar javascript como lin-guagem de programação o que implicaria redesenhar o código base do CAFE. Para além disso, existem alguns condicionamentos no uso de API’s de acesso às funcionalidades do dispositivo devido a só ser possível usar API’s do Titanium [53]. Embora o Appcelarator Titanium se auto-intitule open-source, na verdade existem limitações para utilizadores gratuitos e só é possível usufruir de todas as potencialidades do Titanium se for um utilizador com subscrição [57].

2.2.6 Foundation

A framework Foundation foi lançada em 2011 pela ZURB tem como objetivo, tal como o Bo-otstrap, tornar websites responsivos, de modo a que adaptem o seu layout de acordo com o tamanho do ecrã do dispositivo em que estão a ser visualizados. Utiliza tecnologias como jQuery, HTML5 Boilerplate, Normalizr e SASS [58]. É uma framework com uma popularidade considerável como mostram as mais de 24000 stars e mais de 5000 forks no repositório web GitHub [59].

Chrome Firefox Safari IE11 IE10 IE9

Foundation X X X X X X

Tabela 2.3: Browsers disponíveis para o Foundation [21]

O Foundation acrescenta a característica style automaticamente às tags no CSS o que é uma limitação para um programador que já tenha o design do website concluído e pode tornar a tarefa de reverter para o design original complexa e frustrante [21].

2.2.7 Comparação

Para concluir quais as frameworks mais adequadas para o CAFE Mobile é necessário comparar os aspetos positivos e negativos entre as frameworks abordadas anteriormente bem como perceber quais as mais indicadas para que o máximo de requisitos referidos em3.4sejam cumpridos.

(35)

2.2 Frameworks de Desenvolvimento Aplicações Móveis 11

2.2.7.1 Apache Cordova + Crosswalk vs Ionic/Titanium

Um dos requisitos tecnológicos é que a aplicação deve usar tecnologias de programação web semelhantes à aplicação CAFE para uma migração de atualizações/modificações mais fácil, ou seja, utilizar HTML, CSS e javascript. Este requisito pode-se tornar complicado de cumprir caso seja utilizado Ionic ou Titanium. No primeiro caso é essencial utilizar AngularJS e no segundo apenas javacript. Embora seja possível contornar estes impedimentos e utilizar HTML, CSS e javascript, estas frameworks não foram criadas para ser usadas desta maneira e como tal, para conseguir todas as potencialidades do Ionic e Titanium devem ser utilizadas as linguagens reco-mendadas por elas o que dificultaria a migração de conteúdo do CAFE para o CAFE Mobile [53]. Como foi referido em 2.2.4, o Ionic foi criado com o Apache Cordova como suporte o que lhe permite ter as suas vantagens, e como utiliza AngularJS, SASS e pode ser integrado com o Crosswalk, traz também os benefícios associados a essas tecnologias, como por exemplo, melhor performance (AngularJS) [60] e mais funcionalidades associadas à CSS (SASS) [61].

O Appcelarator Titanium, como mencionado em 2.2.5, apresenta uma melhor performance pois, como compila o código em javascript para nativo, as aplicações criadas com Titanium aproximam-se mais de aplicações nativas [35].

Tendo estas vantagens e desvantagens em conta, é possível concluir que se a solução atual para a aplicação móvel (Apache Cordova + Crosswalk) fosse substituída por Ionic ou Titanium pode-riam existir ganhos em performance e/ou algumas funcionalidades. No entanto esta substituição implicaria que o código da aplicação CAFE Mobile teria que ser totalmente remodelado e ficaria muito diferente da aplicação desktop CAFE o que tornaria a migração de conteúdo da aplicação desktop para a aplicação móvel muito complicada o que resultaria em mais custos de tempo e recursos para a equipa de desenvolvimento aplicar atualizações/modificações no CAFE Mobile.

2.2.7.2 Bootstrap vs Foundation

Para tornar o website do CAFE responsivo é necessário utilizar uma framework como o Bo-otstrap ou o Foundation. Para perceber qual é a mais indicada, é necessário comparar as suas características referidas em2.2.3e2.2.6.

Para perceber as suas compatibilidades com os browsers é necessário comparar as tabelas 2.3e2.2. Analisando o resultado desta comparação na tabela2.4verifica-se que o Foundation é ligeiramente mais compatível.

Chrome Firefox Safari IE11 IE10 IE9

Bootstrap X X (Excepto Android) X (Excepto Win.) X X Limitado

Foundation X X X X X X

Tabela 2.4: Browsers disponíveis para o Bootstrap e Foundation [21]

Ambas as frameworks podem apresentar complicações quando o programador tenta modificar algumas opções de design aplicadas no código. As suas diferenças residem essencialmente em

(36)

aspetos de sintaxe e de métodos usados na codificação pois as suas capacidades são semelhantes sendo que a sua preferência depende normalmente das preferências do programador em relação a estes métodos.

Embora o Foundation seja uma framework popular, ainda não é comparável com o Bootstrap neste aspeto. A sua enorme popularidade traz mais documentação e tutoriais e faz com que os seus problemas sejam resolvidos mais rápido, haja mais atualizações e mais plugins de tercei-ros [47] [59]. Concluindo, a alta popularidade do Bootstrap faz com que a solução atual seja indicada e não se justifique trocar para o Foundation.

2.3

Usabilidade

A usabilidade é a capacidade de uma interface ser compreendida, usada e atrativa para o uti-lizador [62]. É uma componente essencial de CAFE Mobile pois reflete a qualidade da interface para os utilizadores. Segundo [63], a qualidade de uso de uma interface pode ser medida através dos atributos:

• Intuitividade que é a facilidade dos utilizador aprenderem a utilizar a interface;

• Eficiência que é a rapidez que a interface permite aos utilizadores completarem as suas tarefas;

• Memorabilidade reflete-se na organização da interface permite ao utilizador lembrar de como utilizar o sistema sem ter que aprender a cada vez que o usa;

• A quantidade de erros deve ser minimizada;

• A satisfação que é o feedback positivo dado pelos utilizadores que usam a interface. Para melhorar a experiência dos utilizadores de uma interface é necessário aplicar métodos do ramo de Engenharia de Usabilidade [63]. Segundo [64], a engenharia de usabilidade deve ter três fases:

• Foco inicial nos utilizadores e tarefas, em que se pretende obter informação sobre os utili-zadores e as tarefas que vão realizar na interface;

• Análise empírica que se refere aos testes que devem ser feitos ao design da interface; • Design iterativo, após a análise empírica, deve-se alterar o design de acordo com os

resulta-dos.

Nas plataformas móveis a usabilidade assume um papel crucial porque se não for bem apli-cada, resulta numa experiência frustrante para o utilizador. A performance de smartphones ainda é muito inferior a computadores e isto nota-se, por exemplo, em páginas web ou aplicações com animações complexas em dispositivos de gama baixa. Além disso, os smartphones têm tendência

(37)

2.4 Abordagens de Desenvolvimento de Aplicações Móveis 13

a ser usados em espaços exteriores onde têm uma ligação à rede mais suscetível a falhas o que significa que páginas web ou aplicações que requerem, por exemplo, o descarregamento de muitas imagens podem tornar a aplicação mais lenta [65].

Os dispositivos móveis são também limitados pelo tamanho do seu ecrã, que pode ser redu-zido dependendo do modelo do dispositivo em causa, e do teclado virtual, que quando ativado pode ocupar mais de metade do ecrã. A grande diversidade de resoluções e tamanhos de ecrã disponíveis implica que a interface se adapte a vários tamanhos e proporções de ecrã o que, se o desenvolvimento não for bem feito, pode comprometer a usabilidade. Outra grande diferença que deve ser tida em conta no desenvolvimento de aplicações móveis é que os dispositivos móveis fo-ram concebidos para interagirem com utilizador através do toque. Ao contrário de um computador que usa um hardware específico para o efeito, na conceção de uma interface móvel tem que ser tida em conta a imprecisão do dedo humano bem como o seu tamanho que pode variar de pessoa para pessoa. Além disso, os ecrãs de dispositivos móveis não oferecem qualquer tipo de feed-backquando são tocados ao contrário de teclados tradicionais e também não oferecem algumas funções que os ratos de computador oferecem como vários botões e a possibilidade da interface reagir quando o cursor apenas "sobrevoa" uma determinada área. Todos estes fatores tornam os ecrãs tácteis mais propícios a erros provocados acidentalmente pelo utilizador [65]. Para criar um designcom qualidade é importante seguir as fases de desenvolvimento da figura2.5.

Figura 2.5: As fases do desenvolvimento de design centrado no utilizador [6]

2.4

Abordagens de Desenvolvimento de Aplicações Móveis

2.4.1 Mobile First Design

Uma abordagem diz-se Mobile First quando uma aplicação é criada especificamente para pla-taformas móveis. Embora possa ser adaptada para desktop, uma aplicação mobile first foi criada

(38)

para um público alvo que a acede preferencialmente através de plataformas móveis e o seu princi-pal problema é a pouca usabilidade que pode ter no dektop [66].

2.4.2 URL’s Separados

Neste método de desenvolvimento o URL da aplicação web é diferente para desktop ou dis-positivos móveis (ex: www.example.com para desktop, www.m.example.com para disdis-positivos móveis). Desta maneira o código fonte HTML e CSS disponibilizados para cada caso serão dife-rentes [7].

Figura 2.6: Exemplo da utilização do método de URL’s separados [7]

As principais vantagens são: boa otimização da aplicação para dispositivos móveis visto que o código fonte é específicos para isso; boa performance porque é algum código destinado a ver-sões desktop não precisa de ser descarregado e renderizado; a separação de código entre verver-sões traz ao programador maior flexibilidade de desenvolvimento pois não tem que se preocupar com problemas que poderia causar na versão desktop [67].

Como o código desenvolvido vai ser diferente para dispositivos móveis ou desktop, os cus-tos de implementação e manutenção são mais elevados. Além disso, mesmo com uma versão desenvolvida especificamente para dispositivos móveis, vai sempre ser necessário elementos res-ponsivos para que haja uma adaptação à vasta gama de ecrãs o que vai ao encontro da abordagem descrita na secção2.4.3. Outra grande desvantagem prende-se com a existência de dois URL’s di-ferentes o que pode resultar em mais redirecionamentos, e consequentemente mais pedidos HTTP para o utilizador, o que diminui a usabilidade [67].

2.4.3 Design Responsivo

Uma abordagem de desenvolvimento de uma aplicação web com Design Responsivo significa que é sempre enviado pelo servidor o mesmo HTML, enquanto que o CSS é processado de maneira a alterar o comportamento da aplicação, dependendo do tamanho do ecrã do dispositivo [8].

Um design responsivo permite que a aplicação perceba o meio pelo qual está a ser acedida e se adapte de acordo com o tamanho de ecrã do mesmo. O principal problema desta abordagem é que torna o desenvolvimento da aplicação mais complexo porque tem que ser tido em conta a interface da aplicação para vários intervalos de tamanhos de ecrã. Se o desenvolvimento não for feito corretamente, corre-se o risco de concluir com uma aplicação defeituosa para plataformas

(39)

2.4 Abordagens de Desenvolvimento de Aplicações Móveis 15

Figura 2.7: Exemplo da utilização Design responsivo [8]

móveis e para desktop [66]. Além disso, como o código disponibilizado é o mesmo, o tamanho dos ficheiros a serem enviados pelo servidor vai ser maior, o que irá diminuir o desempenho. Isto também leva a que parte da informação que os utilizadores estejam a descarregar, não seja necessária [67].

As principais vantagens desta abordagem são: uma melhor acessibilidade visto que, como só existe um URL, não é necessário redirecionamentos; os custos de implementação e desenvolvi-mento vão ser mais baixos porque o HTML é o mesmo para todos os dispositivos; se for bem implementada, a aplicação vai dar resposta para uma vasta game de ecrãs de uma maneira fluida e robusta [67].

2.4.4 Exibição Dinâmica

Uma abordagem de exibição dinâmica refere-se a quando o servidor envia código fonte dife-rente (HTML e/ou CSS) dependendo do user agent que faça o pedido, utilizando o mesmo URL [9]. O user agent é uma string contida num pedido HTTP que contém a informação do tipo de aplicação, sistema operativo, distribuidor do software ou versão do software. Com esta informação é possível saber que tipo de dispositivo está a aceder à aplicação [68].

(40)

As principais vantagens deste método são: só utiliza um URL, ou seja, evita redirecionamen-tos desnecessários; como o código fonte varia com o tipo dispositivo, tem um bom desempenho porque não é descarregado e/ou renderizado código desnecessário [67].

A maior desvantagem é o grande custo de desenvolvimento e manutenção devido a existirem códigos fonte diferentes [67].

2.4.5 Javascript/JQuery vs CSS

Uma das grandes questões do desenvolvimento de aplicações para dispositivos móveis é saber quando se deve utilizar CSS ou javascript. Um dos casos mais evidentes onde ambas as linguagens podem ser usadas são animações de elementos.

As animações a partir de CSS devem ser usadas nos casos em que se trata de uma animação simples como uma transição de um elemento. Animações javascript são uteis quando se tratam de animações muito complexas como pausar uma transição de um elemento [69]. Por norma, as animações implementadas em CSS têm um melhor desempenho pois libertam o processamento do browsere usam em vez disso a GPU (placa gráfica) [70].

Quando a biblioteca javascript JQuery é usada, as diferenças de desempenho são mais acentu-adas. A equipa de desenvolvimento do browser Opera efetuou uma série de testes que envolviam executar animações do mesmo tipo, em CSS e JQuery, em 300 elementos e registar, para cada caso, o número de ações executadas, o tempo da animação e o consumo de memória [22].

Tabela 2.5: Medições dos testes de comparação entre CSS e JQuery [22] Número de ações executadas Tempo de execução da animação (s) Memória Consumida (MB) JQuery 2119 5 6 CSS 100 2.9 1.5 Diferença 2009 (95%) 2.1 (42%) 4.5 (75%)

Como se pode verificar na tabela2.5, os resultados alcançados pela equipa do browser Opera mostram uma clara vantagem de CSS em todos os aspetos. Isto deve-se a, além do processamento de CSS poder ser feito na GPU, o processador de CSS é escrito em C++ ou em código nativo, ambos muito eficientes. O código escrito em JQuery ainda terá que ser interpretado pelo browser o que compromete o seu desempenho [22].

(41)

Capítulo 3

Definição do Problema/Solução

Para saber qual a melhor solução a implementar, em primeiro lugar é necessário explorar a solução já existente, quais as suas características e funcionalidades e quais os seus principais problemas. Neste capítulo será descrito o problema de uma forma detalhada bem como analisada a solução proposta e as ferramentas e tecnologias a serem usadas.

3.1

Estrutura

O CAFE Mobile é concebido através do mesmo código de fonte da versão desktop do CAFE. Como tal, para perceber qual a melhor abordagem para o CAFE Mobile é necessário em primeiro lugar compreender como está estruturado a versão desktop do CAFE.

3.1.1 Yii Framework e MVC

A framework Yii (Yes it is) versão 1.1 é usada como base para o desenvolvimento do CAFE. É escrita em PHP5 e é grátis e open-source primando pela eficiência e rapidez [71]. Esta framework é baseada na arquitetura MVC (Model-View-Controller).

Yii 1.0.2 CodeIgniter 1.7.0 Zend 1.7.3 CakePHP 1.2.1 Prado 3.1.3 Symfony 1.2.2

RPS com APC 673 206 83 79 75 50

RPS sem APC 93 79 38 29 24 18

Tabela 3.1: Comparação da performance do Yii com outras frameworks [23]

A tabela3.1demonstra uma comparação da performance do Yii 1.0.2 com outras frameworks existentes à data de lançamento desta versão do Yii. Essa performance é medida em RPS (Re-quests Per Second) que se refere à quantidade de pedidos que a aplicação consegue processar por segundo. Quanto maior for o RPS, mais eficiente é a framework. É também feita uma compara-ção com ou sem APC. A Alternative PHP Cache é uma extensão da framework Yii que, quando ativada, aumenta substancialmente a performance da mesma [23].

(42)

Quando o desempenho da versão mais recente do Yii é comparada com a framework concor-rente mais popular, Laravel, verificam-se os resultados da tabela3.2:

Tabela 3.2: Comparação de desempenho entre Yii 2.0 e Laravel 5.0 [24] Yii 2.0 Laravel 5.0

RPS 392.31 69.81 Memória

Usada (MB) 1.5 2.75

Como se pode verificar em ambas as tabelas,3.2e3.1, a framework Yii cumpre as suas pre-missas pois, quando comparada com outras frameworks, tem um desempenho elevado.

A arquitetura MVC, utilizada pelo Yii, tem como objetivo a criação de aplicações e é, como o nome indica, estruturada em três partes: M (Model); V (View); C(Controller) [10].

• O Model é a parte responsável pela leitura e escrita na base de dados e que define as suas relações e regras.

• View refere-se à parte do código responsável pela apresentação do conteúdo ao utilizador, sem fazer cálculos complexos. Apenas reúne os dados necessários e apresenta-os.

• O Controller é a parte que decide e processa de acordo com os dados ou ações do utilizador e chama os Views e Models sempre que necessário [10].

Figura 3.1: Esquema da arquitetura MVC [10]

3.1.2 Estrutura da Versão Móvel

Para converter a versão desktop na versão de aplicação web (acedida pelo browser do dispo-sitivo móvel) existem alterações no código fonte como: condições que verificam se o utilizador está a aceder ao CAFE através de um PC ou um dispositivo móvel o que permite alterar o compor-tamento da aplicação dependendo da condição; diferenças na CSS da aplicação utilizando media queries. Media Queries são funções usadas em CSS que permitem definir estilos para vários tipos de dispositivos [72].

(43)

3.1 Estrutura 19 1 i f( / A n d r o i d | webOS | i P h o n e | i P a d | i P o d | B l a c k B e r r y | I E M o b i l e | O p e r a 2 M i n i / i . t e s t ( n a v i g a t o r . u s e r A g e n t ) ) { 3 i s M o b i l e = t r u e; 4 e l s e 5 i s M o b i l e = f a l s e; 6 7 i f ( i s M o b i l e ) 8 / / c o d i g o a e x e c u t a r s e f o r um d s p o s i t i v o movel 9 e l s e 10 / / c o d i g o a e x e c u t a r s e f o r a v e r s a o d e s k t o p

Algoritmo 3.1: Condição de deteção de dispositivos móveis em javascript

1 @media s c r e e n and (min−w i d t h : 480 px ) { 2 . c l a s s 1 {

3 f o n t −s i z e : 14 px ;

4 }

5 }

Algoritmo 3.2: Exemplo de uma Media Query em CSS

O excerto de código3.1é um exemplo da utilização de uma condição que verifica a presença de um dispositivo móvel em javascript.

No excerto de código 3.2 encontra-se um exemplo da utilização de uma Media Query em CSS. Neste exemplo, vai ser atribuída à classe "class1" um tamanho de fonte de 14px apenas para dispositivos de largura de ecrã máxima de 480px.

Na versão 2.3 do CAFE (a versão em uso aquando do início da escrita da presente dissertação) a principal abordagem utilizada é a descrita no excerto de código 3.1 sendo que a maior parte das alterações de estilo de elementos são efetuadas utilizando jquery como demonstra o excerto de código3.3. Neste exemplo, a classe "class1" vai ter azul como cor de fundo para dispositivos móveis e preto para a versão desktop. As Media Queries são usadas mas de uma forma muito superficial.

1 i f ( i s M o b i l e )

2 $ (" . c l a s s 1 ") . c s s (" b a c k g r o u n d −c o l o r ", " b l u e ") ; 3 e l s e

4 $ (" . c l a s s 1 ") . c s s (" b a c k g r o u n d −c o l o r ", " b l a c k ") ;

Algoritmo 3.3: Exemplo de uma modificação de atributos de elementos utilizando jquery Além destas técnicas, para conceber o CAFE Mobile a partir da versão de desktop do CAFE é também usada a framework Bootstrap que será detalhada em2.2.3.

Para converter a aplicação web numa aplicação híbrida e gerar uma APK(Android Package Kit) são utilizas as frameworks referidas e detalhadas em2.2.

(44)

3.2

Design Existente

As imagens3.2 até3.11são screenshots do CAFE Mobile 2.3 e pretendem mostrar as suas principais janelas onde se encontram as funcionalidades mais relevantes.

Figura 3.2: screenshot do feed de notí-cias da aplicação atual do CAFE

Figura 3.3: screenshot da barra lateral da aplicação atual do CAFE

(45)

3.2 Design Existente 21

Figura 3.4: screenshot do menu de comunicações unificadas da aplicação atual do CAFE

Figura 3.5: screenshot do menu de VoIP da aplicação atual do CAFE

Figura 3.6: screenshot da janela de chatda aplicação atual do CAFE

Figura 3.7: screenshot da janela de chatda aplicação atual do CAFE com o smartphonena horizontal (landscape)

(46)

Figura 3.8: screenshot da caixa de texto para publicar no feed da aplica-ção atual do CAFE

Figura 3.9: screenshot da janela de no-tícias da empresa da aplicação atual do CAFE

Figura 3.10: screenshot da janela de definições pessoais da aplicação atual do CAFE

Figura 3.11: screenshot da janela de autenticação da aplicação atual do CAFE

(47)

3.3 Objetivos 23

3.3

Objetivos

Os principais objetivos do CAFE MOBILE são:

• Transportar para smartphones as funcionalidades do CAFE e permitir que os colaboradores de uma empresa não necessitem de estar ao pé de um computador para poderem aceder à rede social da empresa.

• Dar aos colaboradores a possibilidade de interagirem entre si através das ferramentas de comunicação que o CAFE oferece como Instant Messaging, chamada de voz ou VoIP (Voice over IP).

• Ser uma aplicação rápida e atrativa e que cause poucos embaraços ou frustrações aos seus utilizadores.

• Estar disponível para os Sistemas Operativos mais utilizados e para uma grande gama de smartphones, dependendo o menos possível da qualidade do hardware da máquina para um funcionamento aceitável.

3.4

Requisitos

Tendo em conta os objetivos descritos anteriormente em3.3, os seus requisitos foram elabora-dos para que estes sejam cumprielabora-dos.

3.4.1 Requisitos Funcionais

Os requisitos funcionais descrevem as funções que o sistema deve ter para que cumpra os seus objetivos. Neste caso o sistema tem que:

• ter uma janela em que o utilizador pode ver os posts dos outros utilizadores (feed de notícias) e fazer os seus próprios posts em que pode incluir imagens ou vídeo;

• ter uma janela de notícias da empresa;

• ser capaz de criar um chat (Instant Messaging), chamadas de voz (VoIP) e vídeo entre utilizadores;

• ter uma janela em que utilizador pode visualizar os estados de outros utilizadores, e uma caixa de texto de pesquisa de utilizadores;

(48)

3.4.2 Requisitos Tecnológicos

Os requisitos tecnológicos referem-se às tecnologias e aspetos tecnológicos usados no sistema de forma a que cumpra os objetivos. Mais concretamente, para o CAFE Mobile são:

• ter boa performance, isto é, o utilizador não se deve sentir limitado ou frustrado por a apli-cação demorar demasiado tempo a responder aos seus comandos;

• estar disponível para uma vasta gama de smartphones sem que a sua performance seja gra-vemente afetada;

• ser facilmente atualizável ou modificável, ou seja, as tecnologias, linguagens de programa-ção e frameworks utilizadas devem permita à equipa de desenvolvimento efetuar atualiza-ções ao sistema ou corrigir erros com facilidade;

• utilizar linguagens e tecnologias de programação web semelhantes à aplicação CAFE para desktop para permitir que modificações que sejam feitas no CAFE sejam facilmente migra-das para o CAFE Mobile;

• as tecnologias, linguagens de programação e frameworks utilizadas devem permitir aceder a funções do smartphone como a câmara ou o microfone.

3.5

Problemas Atuais

A aplicação atual do CAFE Mobile está funcional mas não disponível no mercado. Isto prende-se com os seus problemas atuais que a tornam demasiado inadequada para que seja di-vulgada.

Um dos problemas da aplicação existente do CAFE Mobile é a sua performance. Esta fica muito aquém do exigido manifesta-se principalmente quando o utilizador tenta mudar de janela ou efetuar uma ação que envolva iniciar uma funcionalidade. Este problema torna-se ainda mais grave se o smartphone usado não possuir um hardware de processamento de gama alta.

Outro problema atual é em alguns casos a interface gráfica não estar perfeitamente adaptada para plataformas móveis, tornando pior a usabilidade da aplicação. Isto verifica-se, por exemplo, na figura3.4, onde os ícones para iniciar uma chamada de voz ou Instant Messaging são pequenos o que dificulta a tarefa do utilizador quando os tenta aceder através do toque. Outro exemplo encontra-se nas figuras3.6e3.7onde se verifica claramente que a janela de IM tem um formato mais adequado para ser visualizada num PC devido ao seu tamanho reduzido.

3.6

Solução proposta

A solução para o problema definido em 3 passa por continuar a avaliação da aplicação já existente e resolver os problemas atuais3.5tornando o CAFE Mobile numa aplicação útil e numa ótima experiência para o utilizador.

Referências

Documentos relacionados

Estes eventos complementam os iniciais, sendo responsáveis por uma série de informações que validam os eventos não periódicos e periódicos, e buscam otimização na geração

Um outro ataque de natureza mais gravosa é o ataque de sulfatos aos CSH com formação de taumasite, esta acção é usual em estruturas de betão em contacto com o solo húmido,

yglesias si no fueren los clerigos o fundadores dellas» (GARCIA Y GARCIA, 1982: 252).. fontes sugere, no entanto, que as coisas de passavam de outro modo; os concílios alertam

CACIQUE DE CAFE SOLUVEL 4 SP MITSUI ALIMENTOS LTDA.. 5 MG CAFE BOM

Quero ir com o avô Markus buscar a Boneca-Mais-Linda-do-Mundo, quero andar de trenó, comer maçãs assadas e pão escuro com geleia (17) de framboesa (18).... – Porque é tão

O método proposto é baseado na binarização de imagens utilizando a Entropia Relativa Generalizada (ERG) através da Distância Kullback-Leibler Generalizada entre dois

o ` u$ caso de conWito de interessesDdireitos (direito da liberdade de ` u$ caso de conWito de interessesDdireitos (direito da liberdade de eRpress9o para interesse pPblico

Novamente os estudos publicados fazem esta avaliação sensorial em novilhos de raça pura: Chambaz et al., (2003) nos resultados de painel sensorial de carne de novilhos