Arquitetura Front-end: Web Components, Single-Page...

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Arquitetura Front-end: WebComponents, Single-Page, Responsive e

Offline-first

Rui Tiago Bugalho Monteiro

PREPARAÇÃO DA DISSERTAÇÃO

Mestrado Integrado em Engenharia Informática e Computação

Orientador: Prof. João Correia Lopes

3 de Março de 2015

Arquitetura Front-end: Web Components, Single-Page,Responsive e Offline-first

Rui Tiago Bugalho Monteiro

Mestrado Integrado em Engenharia Informática e Computação

3 de Março de 2015

Conteúdo

1 Introdução 11.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Problemas da Web Atual 52.1 Compatibilidade entre Navegadores . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Regras de CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Suporte para Tecnologias Recentes . . . . . . . . . . . . . . . . . . . . 6

2.2 Interfaces de Utilizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1 Ecrãs de Pequenas Dimensões . . . . . . . . . . . . . . . . . . . . . . . 72.2.2 Ecrãs de Alta Definição . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 Métodos de Interação com o Utilizador . . . . . . . . . . . . . . . . . . 8

2.3 Funcionamento Offline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Complexidade do Código-Fonte . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Possíveis Soluções . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Web Components 113.1 Linguagens Declarativas nas Aplicações Web . . . . . . . . . . . . . . . . . . . 11

3.1.1 MXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.2 XAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.3 HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Custom Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 HTML Imports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 HTML Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5 Shadow DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.6 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.6.1 Polymer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.6.2 AngularJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Offline-first 194.1 Aplicações Web Offline-first . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Vantagens do Offline-first . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 NoBackend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.4 Comunicação Assíncrona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.5 Sincronização de Dados na Interface . . . . . . . . . . . . . . . . . . . . . . . . 21

4.5.1 Método “observe” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

i

CONTEÚDO

4.5.2 Programação Reativa Assíncrona . . . . . . . . . . . . . . . . . . . . . 224.6 Tecnologias HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.6.1 Service Workers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.6.2 Application Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.6.3 Web Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.7 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.7.1 Hoodie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.7.2 Meteor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.7.3 Parse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Responsive Web Design 275.1 Origem do Responsive Web Design . . . . . . . . . . . . . . . . . . . . . . . . 275.2 Mobile First . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285.3 Material Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.3.1 Propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.4 Construção de Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.4.1 Cascading Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.4.2 Syntactically Awesome Style Sheets . . . . . . . . . . . . . . . . . . . . 295.4.3 Framework Compass . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5 Web Animations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.6 Responsive Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Single-Page Applications 356.1 Aparecimento das SPAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2 Architectural Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2.1 Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2.2 Model-View-Presenter . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2.3 Model-View-ViewModel . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.3 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.3.1 Categorias de Design Patterns . . . . . . . . . . . . . . . . . . . . . . . 406.3.2 Desing Patterns Emergentes . . . . . . . . . . . . . . . . . . . . . . . . 41

6.4 Testes Unitários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.4.1 Mocha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.4.2 Chai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.4.3 Sinon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7 Proposta de Trabalho 457.1 Arquitetura de Front-end Moderna . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.1.1 Web Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.1.2 Offline-first . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.3 Responsive Web Design . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.4 Single-Page Applications . . . . . . . . . . . . . . . . . . . . . . . . . . 467.1.5 Arquitetura Exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.2 Prova de Conceito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.2.1 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8 Conclusões e Trabalho Futuro 498.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

ii

CONTEÚDO

Referências 53

iii

CONTEÚDO

iv

Lista de Figuras

2.1 Interface do Facebook para computadores pessoais . . . . . . . . . . . . . . . . 72.2 Código HTML da aplicação Web atual do Facebook . . . . . . . . . . . . . . . . 9

5.1 Código exemplo de uma Web Animation . . . . . . . . . . . . . . . . . . . . . . 315.2 Código exemplo da aplicação da tag “picture” . . . . . . . . . . . . . . . . . . . 335.3 Código exemplo da aplicação da tag “img” . . . . . . . . . . . . . . . . . . . . 33

6.1 Teste unitário implementado com Mocha e Chai . . . . . . . . . . . . . . . . . . 42

8.1 Diagrama de Gantt do plano de trabalhos . . . . . . . . . . . . . . . . . . . . . . 50

v

LISTA DE FIGURAS

vi

Lista de Tabelas

2.1 A instrução de CSS "border-radius" . . . . . . . . . . . . . . . . . . . . . . . . 6

vii

LISTA DE TABELAS

viii

Abreviaturas e Símbolos

WWW World Wide WebAJAX Asynchronous JavaScript and XMLCSS Cascading Style SheetsHTML HyperText Markup LanguageW3C World Wide Web ConsortiumDOM Document Object ModelUI User InterfaceMXML Magic eXtensible Markup LanguageXAML eXtensible Application Markup LanguageIDE Integrated Development EnvironmentAPI Application Programming InterfaceHTTP Hypertext Transfer ProtocolMVC Model-View-ControllerMVP Model-View-PresenterMVVM Model-View-ViewModelAsync Asynchronous JavaScriptSass Syntactically Awesome Style SheetsGPU Graphics Processing UnitCPU Central Processing UnitSPA Single-Page Application

ix

Capítulo 1

Introdução

Quando, em 1991, a World Wide Web foi aberta ao mundo e passou a ser uma plataforma

global, era impensável antever a diversidade de dispositivos e de contextos de utilização que iam

fazer parte do seu ecossistema quase três décadas depois. O aparecimento, nos últimos anos, dos

dispositivos móveis, das redes sem fios e a evolução das tecnologias Web têm vindo a tornar ne-

cessário pensar-se em novas formas de se desenvolverem Aplicações Web, adequadas ao contexto

tecnológico e aos paradigmas de utilização da Web atuais.

1.1 Contexto

Hoje em dia, desenvolver software para a Web significa desenvolver software que esteja pre-

parado para correr em diferentes sistemas operativos, tanto de computadores pessoais como de

dispositivos móveis, e em ecrãs com resoluções e densidades diferentes. Deve significar ainda

desenvolver software que não perca funcionalidade quando os métodos tradicionais de interação

com o utilizador, como o rato e o teclado, são substituídos por novos, como o touch e o aceleró-

metro, por exemplo, ou quando a ligação à Internet não é estável, como acontece frequentemente

em tablets e smartphones.

O desenvolvimento de Aplicações Web que satisfaçam estes requisitos é um processo exigente.

De um ponto de vista empresarial, cada um destes requisitos tem custos monetários associados.

Por essa razão, pode-se justificar que, por vezes, se definam standards de qualidade mais baixos

para uma Aplicação Web, por o desenvolvimento da ideia original apresentar custos demasiado

elevados. Pode, inclusive, justificar-se que se sacrifique, por completo, a compatibilidade da apli-

cação com um navegador ou uma plataforma em específico, por os custos associados ao seu desen-

volvimento serem demasiado elevados, mesmo que isso implique a perda de todos os utilizadores

dessa plataforma ou navegador.

Existem, contudo, alguns conceitos e tecnologias relativamente recentes que já têm vindo a

tentar simplificar o processo de desenvolvimento e otimizar os seus resultados: o conceito de

1

Introdução

Web Components vem melhorar a experiência de desenvolvimento e de manutenção das Aplica-

ções Web; já estão disponíveis algumas tecnologias que resolvem parte dos problemas da Web

associados às ligações à Internet e que facilitam a criação de aplicações que seguem a filosofia

Offline-first; o Responsive Web Design é outro conceito que tem vindo a ganhar popularidade nos

últimos anos e que permite a criação de aplicações que se ajustam automaticamente a ecrãs de re-

soluções e densidades diferentes; e, por fim, o desenvolvimento de Single-Page Applications tem

sido outra tendência dos últimos anos que tem contribuído para o enriquecimento da experiência

do utilizador nas Aplicações Web.

1.2 Motivação

O aparecimento, nos últimos anos, de tecnologias que já implementam e se guiam pelos con-

ceitos de Web Components, Offline-first, Responsive Web Design e Single-Page Applications vem

motivar o estudo das suas vantagens e dos seus contratempos, bem como a descoberta de novas

arquiteturas que suportem o desenvolvimento de Aplicações Web, que tirem o máximo partido do

seu uso conjunto.

É uma visão aliciante, pensar-se numa World Wide Web onde as aplicações sejam capazes

de proporcionar uma experiência de utilização semelhante à das aplicações nativas1, sejam mais

fáceis de desenvolver e de manter e que, por não deixarem de ser Aplicações Web, continuem a

ser compatíveis com todas as plataformas e dispositivos que lhes garantem acesso. A principal

motivação desta dissertação é acreditar que as tecnologias que vão ser abordadas, ao longo do

plano de trabalho desta dissertação, vão fazer parte do próximo passo a dar nesse sentido.

1.3 Objetivos

Esta dissertação tem como principais objetivos:

• Explorar os tópicos Web Components, Offline-first, Responsive Web Design e Single-Page

Applications e as tecnologias já existentes que neles se baseiem;

• Avaliar as vantagens e desvantagens das frameworks já existentes que implementem essas

tecnologias;

• Descobrir um modelo de desenvolvimento de Aplicações Web que concilie os pontos fortes

dessas tecnologias;

• Melhorar a experiência de desenvolvimento e de utilização das Aplicações Web modernas;

1Aplicações desenvolvidas para uma plataforma em específico.

2

Introdução

1.4 Estrutura da Dissertação

Para além da introdução, esta dissertação contém mais 6 capítulos. No capítulo 2 são descritos

alguns dos principais problemas que se observam atualmente no mundo da World Wide Web. Nos

capítulos 3, 4, 5 e 6 é descrito o estado da arte das tecnologias Web Components, Offline-first,

Responsive Web Design e Single-Page Applications, respetivamente, e são abordadas e compara-

das algumas frameworks que já implementam algumas destas tecnologias. No capítulo 7 é descrita

a perspetiva de solução defendida por esta dissertação. Por fim, no capítulo 8 é feita uma conclusão

que diz respeito ao trabalho realizado ao longo da Unidade Curricular de “Preparação da Disserta-

ção” e uma previsão dos resultados que se esperam obter com a realização desta dissertação. São

ainda referidas as tarefas que integram o plano de trabalho deste projeto bem como o seu plano de

execução, no modelo de um diagrama de Gantt.

3

Introdução

4

Capítulo 2

Problemas da Web Atual

Neste capítulo serão descritos alguns dos problemas mais comuns às Aplicações Web dos dias

de hoje, que esta dissertação irá tratar, associados ao aparecimento dos dispositivos móveis, das

redes sem fios, dos ecrãs de alta definição e da diversificação de plataformas e de navegadores que

permitem o acesso à World Wide Web.

2.1 Compatibilidade entre Navegadores

É vasta a lista de navegadores e de sistemas operativos que asseguram o acesso à Web. Google

Chrome, Firefox, Safari, Opera, Internet Explorer [W3S14] - estes são apenas alguns exemplos

dos navegadores que os utilizadores da Web mais usam, atualmente, para navegar na WWW. São

precisos ter alguns cuidados para se assegurar a compatibilidade das Aplicações Web com, pelo

menos, a maior parte dos navegadores mais usados.

2.1.1 Regras de CSS

É frequente navegadores diferentes exigirem código fonte diferente para a implementação das

mesmas funcionalidades, ao nível do CSS. Isto acontece por esses navegadores recorrerem a dife-

rentes motores de renderização1 para processarem o resultado visual das aplicações Web. Alguns

desses motores (ou algumas das suas versões) não adotam a especificação standard do World Wide

Web Consortium2 e, para se assegurar que o código desenvolvido seja compatível, tanto com os

navegadores que usem esses motores como com outros que sigam os standards do W3C ou que

usem motores diferentes, é preciso repetir blocos de código que produzem o mesmo efeito prático.

Um exemplo de uma situação em que este problema acontece: quando se pretende atribuir a

um elemento HTML a regra de CSS que define que os seus vértices serão arredondados, com um

raio de 5 pixeis:

1Componente do navegador que cria um resultado visual a partir do código HTML e CSS de uma página Web.2Organização internacional responsável por definir as principais convenções que uniformizam a World Wide Web.

5


Tabela 2.1: A instrução de CSS "border-radius"

Código Navegadores compatíveisborder-radius: 5px; Versões mais recentes do Go-

ogle Chrome, do Safari e doOpera

-webkit-border-radius: 5px; Versões mais antigas do Go-ogle Chrome e do Safari

-moz-border-radius: 5px; Firefox-ms-border-radius: 5px; Internet Explorer-o-border-radius: 5px; Outras versões do Opera

Para garantir a correta visualização, em todos os navegadores mencionados na Tabela 2.1, do

componente da aplicação ao qual esta regra pretende ser aplicada, devem ser usadas, em simultâ-

neo, todas as instruções enumeradas na mesma tabela [Sit].

No desenvolvimento de aplicações de escala maior, onde este tipo de situações acontece com

grande frequência, replicar constantemente estes blocos de instruções leva a que se perca legibili-

dade no código da aplicação e a que a sua manutenção, no futuro, seja igualmente dificultada.

2.1.2 Suporte para Tecnologias Recentes

Em suma, alguns navegadores amplamente usados atualmente não suportam nativamente al-

gumas das tecnologias Web mais recentes. Para se emular as funcionalidades suportadas por essas

tecnologias nesses navegadores, é preciso desenvolver código adicional, que poderá ser mais ou

menos complexo de desenvolver, dependendo da funcionalidade que se pretenda implementar.

Por algumas dessas tecnologias serem complexas e difíceis de emular, os navegadores que não

as suportam são ignorados e a experiência de utilização das aplicações desenvolvidas defeituosa

nesses navegadores.

2.2 Interfaces de Utilizador

Antes do aparecimento dos dispositivos móveis, desenvolver Aplicações Web capazes de pro-

porcionar boas experiências de utilização em ecrãs de pequenas dimensões não era uma preocu-

pação. Da mesma forma, não era, na altura, preocupação as Aplicações Web disponibilizarem as

imagens, que usam como recursos, em vários tamanhos, que previssem a execução dessas aplica-

ções em dispositivos com ecrãs tanto de altas como de baixas densidades.

Para além disso, os métodos de interação com o utilizador das Aplicações Web dessa altura

eram maioritariamente o rato e o teclado. Por essa razão, não havia também ainda a preocupação

de se desenhar interfaces preparadas para serem práticas e intuitivas quando usadas em dispositivos

táteis.

6


2.2.1 Ecrãs de Pequenas Dimensões

As interfaces das Aplicações Web que já existiam, antes do aparecimento dos dispositivos

móveis, estavam previstas para serem usadas em ecrãs de grandes dimensões, como os dos com-

putadores pessoais. Este tipo de interfaces é, no entanto, pouco adequado, quando usado em

tablets ou em smartphones. A Figura 2.1 ilustra a visualização de uma interface deste tipo num

smartphone.

Figura 2.1: Interface do Facebook para computadores pessoais

A execução, em dispositivos com ecrãs de pequenas dimensões, de aplicações desenvolvidas

com este tipo de interfaces torna o seu conteúdo pouco legível e obriga os seus utilizadores a

recorrerem constantemente a funcionalidades de zoom para o poderem avaliar corretamente.

2.2.2 Ecrãs de Alta Definição

É frequente as Aplicações Web desenvolvidas atualmente disponibilizarem apenas um tama-

nho para cada uma das imagens que usam como recursos. É também frequente que, por essa

razão, ou sejam carregadas pelo navegador imagens com tamanhos desnecessariamente grandes

para os ecrãs pequenos e de baixa densidade, ou que sejam usadas imagens demasiado pequenas

em dispositivos com ecrãs de grandes dimensões e com densidades altas.

Quando as imagens são desnecessariamente grandes, é usada uma largura de banda superior

superior à que poderia ser usada, se a aplicação disponibilizasse imagens com tamanhos adequa-

dos ao dispositivo. Como consequência, a aplicação irá demorar mais tempo a carregar todos os

seus recursos e perderá fluidez desnecessariamente. Quando acontece o oposto e as imagens dis-

ponibilizadas são demasiado pequenas, tendo em conta as propriedades do ecrã do dispositivo de

visualização, as imagens são ampliadas, em relação ao seu tamanho original, e perdem nitidez.

7


2.2.3 Métodos de Interação com o Utilizador

A implementação de interfaces como a ilustrada pela Figura 2.1 dificulta ainda a interação do

utilizador com as Aplicações Web em dispositivos que usem o touch como método de interação

principal. Um dos problemas mais comuns é os elementos de interação, na interface, serem de

pequenas dimensões e, por essa razão, de difícil interação.

Para além disso, neste tipo de dispositivos, não é possível oferecer um feedback intuitivo ao

utilizador sobre os elementos da interface com os quais ele pode interagir, como acontece, por

exemplo, quando um elemento de texto é sublinhado quando é sobreposto pelo ponteiro do rato,

num computador pessoal.

2.3 Funcionamento Offline

O desenvolvimento de Aplicações Web que não dependam da existência constante de uma

ligação à Internet não é ainda, nos dias de hoje, uma preocupação. Como consequência disto,

sempre que reabrimos, atualmente, uma aplicação num navegador, o seu código-fonte e grande

parte dos seus recursos são transferidos, mesmo que já o tenham sido anteriormente.

Caso a ligação à Internet falhe, mesmo que o utilizador já esteja a navegar na aplicação, é co-

mum a aplicação ficar completamente inutilizável ou até ser substituída por uma mensagem de erro

do navegador, provocada pela falha na ligação. Em casos em que existam dados temporariamente

guardados ao nível do front-end, este tipo de falhas pode resultar na sua perda.

Por último, esta dependência das Aplicações Web atuais na existência e na qualidade das

ligações à rede tem consequências diretas no desempenho dessas aplicações e na qualidade da

experiência de utilização que oferecem aos seus utilizadores. Interações do utilizador com a apli-

cação que exijam uma troca de dados com um servidor remoto condicionarão o uso da aplicação

durante o espaço de tempo em que essa troca ocorrer.

2.4 Complexidade do Código-Fonte

Outro problema atualmente bastante visível no desenvolvimento de Aplicações Web é a ele-

vada complexidade, e consequente baixa legibilidade, dos seus códigos-fonte.

JavaScript é uma linguagem de programação que permite a implementação de funções call-

back3. É ainda possível recorrer ao uso de funções callback no corpo de outras funções callback.

Por esta razão, são frequentes as situações em que várias camadas de funções deste tipo são usa-

das no código-fonte de Aplicações Web, dando origem a pirâmides de código JavaScript pouco

legível.

É ainda comum ver-se atualmente, no código-fonte de Aplicações Web, sequências de tags

HTML cujo significado e a funcionalidade não são facilmente percetíveis para o programador.

Não o são, pelo menos, sem o programador ter um conhecimento prévio do código ou sem este

3Uma função callback é passada como argumento a outra função, que pode chamar, posteriormente, a funçãocallback.

8


Figura 2.2: Código HTML da aplicação Web atual do Facebook

ser fazer um estudo mais aprofundado do código, na tentativa de deduzir a sua funcionalidade. A

Figura 2.2 demonstra bem este problema, na aplicação Web do Facebook.

2.5 Possíveis Soluções

Nos últimos anos, foram introduzidas várias tecnologias Web que oferecem respostas para os

problemas que foram descritos neste capítulo.

Os Web Components prometem ser uma boa solução para reduzir a complexidade do código-

fonte das Aplicações Web e oferecem algumas vantagens ao nível da compatibilidade dessas

aplicações em navegadores que ainda não suportam nativamente as últimas tecnologias Web. O

Offline-first introduz a filosofia de que as Aplicações Web devem ser funcionais offline e oferece

algumas tecnologias que contribuem para que o desenvolvimento dessas aplicações evolua nesse

sentido. O conceito de Responsive Web Design vem trazer respostas para os problemas relacio-

nados com interfaces do utilizador e as Single-Page Applications parecem garantir uma melhor

organização e qualidade global no código-fonte do front-ends das Aplicações Web.

Os próximos capítulos descreverão o estado da arte destas quatro tecnologias.

9


10

Capítulo 3

Web Components

HTML é a principal linguagem de programação que suporta a World Wide Web desde o seu

aparecimento. Um dos seus principais pontos fortes é ser uma linguagem declarativa e de uso sim-

ples. Porém, por oposição, um dos seus principais pontos desfavoráveis é ser obrigada a servir-se

de outras linguagens, como o JavaScript, para colmatar as suas limitações, ao nível da complexi-

dade, e conseguir desempenhar algumas tarefas mais complexas. Os Web Components procuram

tirar proveito da simplicidade de desenvolvimento de aplicações com programação declarativa, ao

mesmo tempo que trazer para a parte declarativa do desenvolvimento das Aplicações Web funcio-

nalidades mais complexas.

Existem quatro tecnologias que integram o grupo de tecnologias dos Web Components - Cus-

tom Elements, HTML Imports, HTML Templates e Shadow DOM. Neste capítulo, será feita uma

descrição do estado da arte de cada uma delas.

3.1 Linguagens Declarativas nas Aplicações Web

As linguagens declarativas têm um papel importante no desenvolvimento de Aplicações Web.

Na maior parte dos casos, este tipo de linguagens é o usado para a construção das interfaces do

utilizador, tanto em Aplicações Web como em aplicações nativas de outras plataformas, como o

iOS ou o Android, por exemplo. O código das linguagens declarativas tem uma relação bastante

próxima do seu resultado. No contexto de desenvolvimento de UIs1, o programador declara no

código os componentes de UI que pretende usar na interface e o interpretador da linguagem é o

responsável por perceber como há-de construir os resultados esperados para o código desenvol-

vido. Em contraste, o uso de linguagens imperativas para este fim implicaria que o programador

especificasse no código-fonte todos os passos necessários para que cada um desses componen-

tes de UI fossem construídos. Por esta razão, as linguagens declarativas desempenham um papel

importante na simplificação do processo de desenvolvimento das Aplicações Web [Sma].

1User Interfaces.

11

Web Components

Contudo, o HTML não é a única linguagem de programação declarativa usada no desenvolvi-

mento de Aplicações Web. Existem outras, como é o caso do MXML, usado na framework Adobe

Flex, ou o XAML, por exemplo, usado com o Silverlight, da Microsoft. Ambas estas lingua-

gens apresentam vantagens e desvantagens em comparação com o HTML5 e de acordo com a sua

especificação atual [LL].

3.1.1 MXML

MXML é, como já foi dito, a linguagem de programação usada na framework Flex, da Adobe,

e possui algumas vantagens em relação ao HTML5. O desenvolvimento de aplicações com a fra-

mework Adobe Flex é mais simples do que com HTML5, CSS e JavaScript, IDEs desenvolvidos

para esse propósito. Por só dependerem da instalação de um plugin Flash para serem executadas,

não existe a necessidade de se desenvolver código diferente para assegurar a compatibilidade deste

tipo de aplicações com todos os navegadores. Para além disso, as aplicações desenvolvidas com

a framework Adobe Flex são executadas através de um ficheiro executável que é transferido de

um servidor remoto e que contém a parte da lógica de negócio da aplicação. Durante a execução

da aplicação, a comunicação com esse servidor é assíncrona e limita-se às trocas de dados neces-

sárias aos processos de lógica de negócio da aplicação, garantindo-se assim uma experiência de

utilização, para este tipo de aplicações, mais fluída e próxima da das aplicações nativas.

Porém, a instalação do plugin Flash necessário à execução das aplicações Flex não é possível

na maioria das plataformas dos dispositivos móveis, o que é um grave entrave ao seu uso, quando

este tipo de dispositivos já é uma realidade com bastante presença no ecossistema da Web. Para

além disso, as aplicações Flex não possuem multithreading, o que constitui outra grande desvan-

tagem [LL].

3.1.2 XAML

A linguagem XAML, usada na framework Silverlight, da Microsoft, é, em bastantes aspetos,

semelhante ao MXML, do Adobe Flex. Por um lado, oferece ferramentas de desenvolvimento

bastante sofisticadas, que facilitam o desenvolvimento das aplicações, e permitem criar aplica-

ções que se assemelham mais a aplicações nativas. Mas, por outro, não é compatível com grande

parte dos navegadores, não é suportado pelos dispositivos móveis e algumas das suas funciona-

lidades só funcionam corretamente se as aplicações forem executadas em ambientes de execução

Windows [PO].

3.1.3 HTML5

O HTML5 não apresenta, de momento, as facilidades de desenvolvimento que as suas alter-

nativas oferecem, e ainda peca na diversidade de funcionalidades que disponibiliza nativamente.

Porém, o código-fonte das suas aplicações é aberto, bem como aos seus conteúdos, tornando possí-

vel, desta forma, que se estabeleçam relações entre conteúdos de várias aplicações; tem ainda uma

performance elevada, por não depender da instalação de plugins externos para ser interpretada;

12

Web Components

é compatível com todos os navegadores e plataformas, embora apenas parcialmente em alguns

deles; e está ainda em constante crescimento. Os Web Components foram uma das adições mais

recentes à sua especificação [PO].

3.2 Custom Elements

Existem várias tags de HTML com funcionalidades específicas. É o caso da tag “img”, que

representa uma imagem numa Aplicação Web, indicada num atributo onde é definido o caminho

para a sua localização. Existem outras tags que assumem as suas próprias funcionalidades: as tags

“video”, “select” e “form” são exemplos de outras. Contudo, com a rápida expansão da World

Wide Web, se, antes, existirem tags dedicadas à inserção de imagens, de vídeos, de tabelas, entre

outras que implementavam outras funcionalidades comuns a muitas aplicações, hoje são cada vez

mais os propósitos e as funcionalidades atribuídas às Aplicações Web e as tags implementadas

nativamente na especificação do HTML começam a deixar de ser suficientes.

Funcionalidade

Com a introdução dos Custom Elements, o programador passa a ter a possibilidade de criar

os seus próprios elementos HTML/DOM, com tags próprias, e cuja funcionalidade pode ser pro-

gramada em JavaScript. É ainda possível extender elementos já existentes, sejam eles nativos ou

outros Custom Elements, e esses elementos herdarão as propriedades e funcionalidades dos seus

ancestrais na hierarquia. Os Custom Elements facilitam a reutilização de código, visto que, de-

finido uma vez, um novo elemento customizável pode ser instanciado indefinidamente e são um

forte contributo para a simplificação e para o aumento da legibilidade do código-fonte. A utili-

zação de Web Components pode ser uma solução para melhorar a legibilidade de códigos-fonte

como o ilustrado pela Figura 2.2 [Htma].

Suporte

Atualmente, o suporte nativo para Custom Elements é ainda apenas suportado pelos seguintes

quatro navegadores: Chrome 33+, Opera 25+, Android Browser 4.4.4+ e Chrome para Android

38+.

3.3 HTML Imports

Sem se recorrer a HTML Imports, não existem muitas formas de se reutilizar outras páginas

HTML, completas, incluindo os ficheiros de JavaScript e os estilos de CSS associados, em HTML.

Uma forma seria recorrer à tag de HTML “iframe”, que cria alguns obstáculos ao uso JavaScript

13

Web Components

ou CSS nas páginas importadas. Outra forma seria recorrer a AJAX2 que, embora resolvesse os

problemas levantados pelo “iframe”, envolveria o recurso a JavaScript.

Funcionalidade

Os HTML Imports trazem à Web uma forma simples de se fazer a reutilização de páginas

HTML. Contudo, e em suma, permitem ainda a reutilização de HTML proveniente de endereços

externos que incluam a declaração de Custom Elements. Desta forma, o uso de HTML Imports

aliado ao uso de Custom Elements facilita a reutilização de código, no desenvolvimento de Apli-

cações Web [Pola].

Suporte

Atualmente, os seguintes navegadores incluem suporte nativo para HTML Imports: Firefox

35+, Chrome 36+, Opera 25+, Android Browser 37+, Chrome para Android 38+.

3.4 HTML Templates

Antes do aparecimento dos Web Components, já várias frameworks recorriam ao uso de tem-

plates HTML. Recorrendo ao uso de templates, durante o desenvolvimento de uma aplicação Web,

é possível declarar blocos de código HTML que podem, mais tarde, ser instanciados e reutilizados

na aplicação. Ruby on Rails, Smarty e Django são alguns exemplos de frameworks que recor-

rem ao uso de templates HTML. Porém, atribuem ao servidor a responsabilidade de construir o

resultado visual das aplicações e, cada vez mais, começam a ser vistas aplicações que seguem um

paradigma diferente, passando o cliente a ser cada vez mais responsável pela componente visual e

interativa das aplicações.

Desta forma, o recurso ao uso de HTML Templates processados no browser passa a ganhar

mais relevância.

Funcionalidade

Já existiam algumas soluções, anteriormente à introdução dos HTML Templates dos Web Com-

ponents, capazes de oferecer respostas a este problema. Uma delas seria declarar templates em

HTML, dentro de uma tag “div”, invisível com o auxílio de código CSS. Adoptando esta possível

solução, embora não seja visível quando a página é carregada, o conteúdo do template é sempre

carregado, independentemente de o template ser ou usado não pela aplicação. Por esta razão, esta

não é uma opção ideal.

Outra opção seria recorrer a uma tag “script” para declarar o template. Esta seria uma boa solu-

ção, visto que, por as tags “script” terem a propriedade de CSS “display: none” por pré-definição,

o conteúdo do template é invisível, no momento em que a página é carregada, e interpretado pelos

2Tecnologia que permite fazer trocas de dados com um servidor remoto assincronamente e fazer alterações a ele-mentos DOM de páginas Web dinamicamente.

14

Web Components

navegadores como uma string, resolvendo o problema do carregamento desnecessário de elemen-

tos que possam estar contidos na declaração do template. Contudo, igualmente por recorrer à tag

de HTML “script”, o conteúdo do template é convertido para DOM e fica facilmente acessível

através da propriedade de DOM “.innerHTML”. Este aspecto aumenta a possibilidade de existên-

cia de vulnerabilidades de XSS nas aplicações Web e é esse o motivo de esta também não ser a

solução ideal [Htmc].

Com o aparecimento dos HTML Templates dos Web Components, nasceu a tag nativa “tem-

plate”, de HTML, que veio dar resposta a estes problemas. A renderização de templates declarados

com esta tag também não é feita até o template ser usado, como acontecia com as duas últimas

alternativas, e quaisquer conteúdos presentes no template não são carregados ou acessíveis antes

do seu uso [Web].

Suporte

Os HTML Templates são suportados nativamente pelos seguintes navegadores: Firefox 31+,

Chrome 31+, Safari 7.1+, Opera 25+, iOS Safari 8+, Android Browser 4.4+, Chrome para Android

38+.

3.5 Shadow DOM

O DOM de uma página Web está organizado hierarquicamente numa estrutura em árvore. O

elemento “document” representa a raiz da árvore e todos os restantes elementos que constituem a

página descendem desse elemento. Devido a este tipo de estrutura, quando é feita uma alteração

num dos nós da árvore, é provável que os descendentes desse nó sejam afetados também por essa

alteração.

Para além disso, com o uso de Custom Elements e de HTML Imports, passa a ser relativamente

simples importar elementos HTML de páginas exteriores e construir aplicações Web de uma forma

mais modular. É provável que esses Custom Elements importados já tenham estilos de CSS asso-

ciados, ou scripts de Javascript, que, após incluídos numa aplicação, poderão não ter o aspecto ou

a funcionalidade que tinham originalmente [Htmd].

Funcionalidade

O Shadow DOM traz o conceito de encapsulamento para os Web Components e estabelece

uma barreira dentro da hierarquia do HTML. Com o Shadow DOM, passa a ser possível isolar

elementos de uma página Web das regras de CSS e do código JavaScript que se aplica ao resto da

página.

Suporte

Esta tecnologia é suportada nativamente pelos seguintes navegadores: Chrome 31+, Opera

25+, Android Browser 4.4+ e Chrome para Android 38+.

15

Web Components

3.6 Frameworks

Serão descritas, de seguida, duas frameworks. O Polymer é uma framework que já implementa

as tecnologias dos Web Components. Por outro lado, o AngularJS, na versão disponível atualmente

(1.x), apesar de não suportar ainda Web Components, oferece algumas funcionalidades alternativas

que garantem efeitos semelhantes.

3.6.1 Polymer

O Google Polymer é uma framework que se foca na implementação de Web Components. A

framework é constituída por três camadas fundamentais:

1. Web Components: Nesta camada, o Polymer disponibiliza um conjunto de APIs - polyfills

- que emulam o suporte para Web Components em navegadores que ainda não os suportam

nativamente. Durante a execução da aplicação, o Polymer recorre à implementação nativa

de Web Components nos navegadores que incluam o seu suporte, ou opta por recorrer a esta

camada de polyfills, caso o navegador não suporte estas tecnologias nativamente;

2. Biblioteca do Polymer: Esta biblioteca oferece uma sintaxe alternativa, mais simples e que

envolve a criação de menos código, para a declaração de Web Components. Para além disso,

são ainda implementadas, nesta camada, outras funcionalidades úteis no desenvolvimento

de front-end de Aplicações Web, como data-binding e o suporte a eventos touch;

3. Elements: Por último, o Polymer oferece uma camada com vários Custom Elements já im-

plementados, que prevêm algumas das funcionalidades mais comuns nas Aplicações Web.

Esta camada inclui a implementação dos Core elements, que permitem criar declarativa-

mente desde pedidos HTTP a um servidor remoto a animações e transições entre páginas

e a eventos de input como o drag and drop, e os Paper elements, que incluem alguns ele-

mentos da interface do utilizador que seguem os princípios do Material Design (5.3), da

Google [Polb].

3.6.2 AngularJS

Embora o AngularJS não inclua, ainda, Web Components na sua especificação, a framework

disponibiliza algumas funcionalidades que produzem efeitos semelhantes.

O AngularJS não permite a criação de Custom Elements recorrendo às APIs que fazem parte

da especificação dos Web Components. No entanto, é possível criar directives, que se traduzem

em elementos HTML customizados, com tags próprias, - um conceito semelhante ao de Custom

Elements. Para além disso, é possível criar templates HTML, à semelhança do que acontece com

o Polymer. No entanto, os templates criados com o AngularJS não fazem uso da tag “template”,

que integra a especificação dos Web Components [Sha].

Não existe Shadow DOM em AngularJS. Porém, o conceito de encapsulamento existe na fra-

mework e é definir que, por exemplo, métodos que compõem uma directive de AngularJS não

16

Web Components

podem ser acedidos fora da declaração da diretiva, ou por um Controller (6.2.1) que não seja o

que contém essa directive.

Contudo, o AngularJS é uma framework que, embora ainda estranha às APIs recentes dos

Web Components, é mais matura no desenvolvimento de Aplicações Web em relação ao Polymer.

O AngularJS implementa, em front-end, um padrão de arquitetura MVC (6.2.1) e disponibiliza

várias APIs que são úteis no desenvolvimento de Aplicações Web para produção, permitindo a

implementação de routes3, data-binding, animações, testes unitários, entre outras funcionalida-

des [Ang].

Deve ainda ser referido que a versão 2.0 do AngularJS está já em desenvolvimento e que os

Web Components são uma das tecnologias apontadas a integrar a sua especificação. No entanto,

não será descrita em maior detalhe nesta dissertação, por ainda não estar disponível para experi-

mentação.

3Permitem, em AngularJS, associar um URL a uma interface do utilizador em específico.

17

Web Components

18

Capítulo 4

Offline-first

Hoje em dia, não se pode partir do princípio de que todos os utilizadores da Web têm um acesso

constante e de boa qualidade à rede global. São comuns as situações em que isso não é possível:

numa viagem de avião, por exemplo, não é permitido o acesso a redes móveis; o sinal das redes

wireless perde-se com facilidade, quando existem superfícies bem isoladas a separar o recetor da

fonte do sinal; até mesmo nas cidades mais desenvolvidas tecnologicamente, é frequente não se

ter um acesso à Internet com uma boa qualidade e sem falhas.

É neste contexto que surge a necessidade de se pensar em formas de desenvolver aplicações

para a Web que não estejam tão dependentes de uma ligação constante à Internet, como estavam as

que se desenvolviam no passado. Algumas tecnologias, que também foram surgindo ao longo dos

últimos anos, já fizeram alguns avanços. A introdução do conceito de comunicação assíncrona e

de outras tecnologias front-end passaram a permitir a criação de aplicações Web modulares, com

ecrãs constituídos por vários componentes, por oposição às anteriores páginas Web estáticas. A

evolução das tecnologias de front-end, bem como o aumento da capacidade de processamento dos

dispositivos que permitem o acesso à Web, vieram tornar possível implementar do lado do cliente

um maior número de funcionalidades, que antes só podiam ser processadas ao nível do servidor, e

motivaram novas formas de pensar na arquitetura das aplicações Web. É neste contexto que surge

o conceito de Offline-first.

4.1 Aplicações Web Offline-first

A existência de uma base de dados do lado do cliente é importante. A informação deve ser

sempre guardada localmente, para que, caso hajam falhas na ligação à Internet, a aplicação possa

continuar a ser funcional e a informação retida possa continuar a estar acessível. Existem algumas

APIs disponíveis que simplificam o processo de armazenamento local da informação: HTML5

Web Storage, IndexedDB e Filesystem API são alguns exemplos.

19

Offline-first

A informação armazenada localmente deve ser sincronizada com a informação mantida as-

sincronamente numa base de dados remota, desta forma não condicionando o uso continuo da

aplicação por parte do utilizador.

Para além disso, para que a aplicação possa ser usável e, como tal, o utilizador possa usufruir

das suas funcionalidades, toda a componente funcional da aplicação que não necessite de ser

integrada no backend deve ser implementada no front-end.

O estado da aplicação deve ainda ser guardado também localmente, bem como os próprios fi-

cheiros de código-fonte, para que, sempre que a aplicação for fechada ou interrompida por alguma

razão, o utilizador possa retomar o seu estado sem perder informação ou que tenha de transferir

novamente todos os ficheiros de que precisa para correr a aplicação.

4.2 Vantagens do Offline-first

O interesse principal de um utilizador final, seja de uma Aplicação Web ou de qualquer outro

tipo de aplicação ou sistema, é que a aplicação sirva o seu propósito e as suas necessidades. A

dificuldade de se conseguir, muitas vezes, uma ligação à Internet de boa qualidade é um problema

frequente para grande parte dos utilizadores da Web, nos dias de hoje.

A introdução do conceito de Offline-first e a possível introdução deste conceito na arquite-

tura de Aplicações Web ajudaria a colmatar problemas como este e a potenciar aos utilizadores

da Web uma melhor experiência de utilização das suas aplicações. Problemas como tempos de

espera, para o utilizador final, por respostas a pedidos de informação feitos ao servidor, seriam

resolvidos e seria dada a possibilidade das Aplicações Web passarem a poder ser utilizadas offline,

à semelhança do que acontece com aplicações nativas.

4.3 NoBackend

Embora continuem a existir plataformas que exigem a implementação de um backend dedi-

cado, muitas são as aplicações que seguem os mesmos padrões de funcionalidades ao nível do

front-end: registo, autenticação, armazenamento de dados, chat, email, etc. O conceito de NoBac-

kend vem tentar simplificar o processo de desenvolvimento de aplicações deste tipo, tirando a ta-

refa da implementação dos seus backends da responsabilidade dos seus programadores. O objetivo

desta abordagem ao desenvolvimento de Aplicações Web é permitir aos engenheiros de software

focarem-se ao máximo na funcionalidade e no resultado final esperado das aplicações, ignorando

as suas exigências do ponto de vista do backend. Questões como a escalabilidade da aplicação ou a

disponibilidade dos seus servidores ou até mesmo com questões de segurança deixam igualmente

de ser preocupações para os programadores das Aplicações Web e, por esta abordagem exigir das

aplicações um maior cuidado com a sua arquitetura, na medida em que devem ser modulares o

suficiente para conseguirem integrar as soluções NoBackend, uma possível troca do sistema que

é usado como backend, no futuro, passa igualmente a ser uma tarefa simples. Para além disso,

20

Offline-first

os custos de desenvolvimento do backend e de manutenção de servidores deixam de fazer parte,

igualmente, do domínio do de quem desenvolve a aplicação.

O Hoodie (4.7.1) é um exemplo de uma framework que introduz este conceito. A framework

disponibiliza uma API em JavaScript que reduz todas as tarefas de backend, sejam elas a adi-

ção de dados, sincronização, entre outras, a funções de JavaScript de alto nível que permitem ao

programador abstrair-se de todo o processo.

4.4 Comunicação Assíncrona

A introdução da comunicação assíncrona no funcionamento das Aplicações de Web foi uma

das grandes inovações recebidas pela WWW desde a sua criação. Antes do Async1, a maior parte

das Aplicações Web eram baseadas em páginas HTML completas que tinham de ser carregadas

na íntegra para que o utilizador as pudesse visualizar e continuar a navegar. Todo o conteúdo

de cada página seria portanto apagado e redesenhado sempre que o utilizador interagisse com a

aplicação, mesmo que grande parte do conteúdo da nova página fosse semelhante ou igual ao da

página anterior.

Tornando possível a comunicação em background das Aplicações Web com os servidores,

passou a ser possível desenvolverem-se Aplicações Web dinâmicas. Isto é, passou ser possível

transferir-se apenas as partes das páginas Web que apresentariam necessariamente um conteúdo

diferente, e assim evitar a troca de dados necessários através da rede e otimizar o desempenho

das aplicações; passou a poder-se alterar o conteúdo mostrado ao utilizador apenas quando toda

a informação já tenha sido recebida pela aplicação, e desta forma não tornar inutilizável, para o

utilizador, a aplicação, enquanto estivessem a ser feitos pedidos de dados ao servidor; passou ainda

a ser possível concentrar um maior número de funcionalidades no front-end.

4.5 Sincronização de Dados na Interface

4.5.1 Método “observe”

Uma das adições mais recentes feita à especificação do JavaScript foi o método “observe”.

Este método permite monitorizar assincronamente as alterações sofridas por um objeto declarado

com a linguagem e, com base nisso, associar eventos a essas alterações.

Já era possível monitorizar as mudanças aplicadas a um objeto de JavaScript antes da introdu-

ção do método “observe”. Muitas frameworks de front-end serviam-se de algumas bibliotecas que

permitiam implementar esta funcionalidade para tornar possível fazer binding2 de dados dentro

de aplicações Web e, desta forma, desenvolver Aplicações Web dinâmicas de uma forma mais

prática. Porém, o desempenho das abordagens implementadas por essas bibliotecas ofereciam um

desempenho significativamente inferior ao do uso deste novo método: a função “observe” conse-

gue resultados até cerca de 20 vezes mais otimizados do que as abordagens tradicionais. [HR1]1Comunicação assíncrona.2Sincronização dos dados entre a camada de lógica de negócio e a interface de uma aplicação.

21

Offline-first

Com a introdução do “Object.observe()”, é possível associar eventos a quaisquer tipo de alte-

rações feitas diretamente a um objeto de JavaScript, é possível saber quando foram adicionadas,

alteradas ou removidas propriedades a esse elemento, fazer binding de eventos a operações de

adição ou de remoção de elementos de um array ou saber quando o protótipo3 de um objeto for

alterado. Todas estas possibilidades, bem como o conceito de data-binding, ganham especial re-

levância quando se pretende conceder uma aplicação Web usando uma arquitetura Model-View

Controller, como uma forma simples de estabelecer uma relação direta entre os dados disponíveis

do controlador da aplicação e o que é visível ao utilizador, descrito no HTML.

Porém, é também importante referir que o método “observe” ainda só é suportado pelo nave-

gador Google Chrome, a partir da versão 36.

4.5.2 Programação Reativa Assíncrona

Com a introdução do conceito de programação reativa, passa a ser possível fazer-se um binding

direto entre as informações visíveis ao utilizador final, na interface de uma aplicação, e os dados

de backend que fornecem essas informações à componente visual da aplicação.

Antes da programação reativa assíncrona, uma das formas de se atualizar um valor no front-

end de uma aplicação, conforme os dados fossem alterados no seu backend, seria comunicando

periodicamente com o servidor na esperança de que, a qualquer momento, as novas alterações

surgissem na base de dados remota e que fosse necessário atualizar a aplicação. Outra possibi-

lidade seria criar eventos que seriam despoletados assim que as alterações fossem feitas ao nível

do servidor. Para monitorizar essas alterações, a aplicação deveria implementar os mecanismos

necessários para que pudesse estar constantemente à espera de que novas alterações fossem feitas

aos dados e que algum desses eventos fosse acionado.

Adotando um paradigma de programação declarativo, com programação reativa, passa a ser

necessário ao programador declarar apenas que dados vai usar, disponíveis no backend, direta-

mente na especificação da interface da aplicação e os processos de sincronização e de tratamento

de alterações feitas a nível de backend deixa de ser uma preocupação do programador. A infor-

mação é enviada, do servidor para a aplicação, assim que os dados são alterados no backend e o

estado da aplicação é, também ele, atualizado em tempo real, consoante as alterações ocorridas.

Para além disso, sendo estes processos assíncronos, a experiência de utilização de uma aplicação

deste género é fluída e os tempos de espera para carregamento de dados do servidor podem ser,

sempre que pretendido, omitidos ao utilizador.

4.6 Tecnologias HTML5

Com a introdução da versão 5 do HTML, foram adicionadas novas APIs à sua especificação

com o propósito de facilitar o armazenamento de dados das Aplicações Web em front-end. Três

que devem ser mencionados são: Service Workers, Application Cache e Web Storage.

3Objetos de JavaScript que são criados a partir de um protótipo herdão os seus métodos e as suas propriedades.

22

Offline-first

4.6.1 Service Workers

Tornando possível manipular os recursos carregados por uma página, bem como a forma e

a localização a partir dos quais esses recursos são carregados, os Service Workers tornam des-

necessário o recurso à rede para o carregamento de páginas Web em alguns casos. Depois de

armazenados em cache, os recursos necessários ao funcionamento de uma página Web podem ser

carregados localmente, motivo pelo qual os Service Workers se revelam uma ferramenta interes-

sante quando se fala de aplicações offline-first e que descartam a dependência absoluta de uma

ligação à Internet para o seu correto funcionamento [W3Cb].

4.6.2 Application Cache

Complementando os Service Workers, a Application Cache permite armazenar localmente,

temporariamente, ficheiros HTML, imagens e outros tipos de documentos Web necessários ao

carregamento de uma página, contribuindo igualmente para a independência das Aplicações Web

de uma ligação à rede [W3Ca].

4.6.3 Web Storage

Com a introdução do HTML5 e do conceito de Web Storage, passou a ser simples para as

Aplicações Web armazenarem informação localmente, de uma forma segura e sem prejudicar o

desempenho das aplicações. Não sendo, esses dados, transferidos para um servidor, não tendo

um tempo limite de vida (a menos que definido pelo programador) e oferecendo um espaço de

armazenamento bastante superior ao disponibilizado pela cache de um navegador, esta é uma

boa solução para o armazenamento de dados de uma Aplicação Web. Com o aparecimento desta

tecnologia, foi possível criarem-se diversas APIs de armazenamento de bases de dados offline, do

lado do cliente. Dois exemplos de APIs deste tipo são a IndexedDB e a Web SQL Database [HR2].

4.7 Frameworks

Existem já algumas frameworks que implementam alguns destes conceitos. Nesta secção será

feita uma descrição de três delas: Hoodie, Meteor e Parse.

4.7.1 Hoodie

O Hoodie é uma framework de código aberto dedicada ao desenvolvimento de Aplicações Web

e móveis com uma arquitetura baseada em ambos os conceitos de NoBackend e de Offline-first.

Foi desenvolvida com JavaScript e NodeJS e recorre a bases de dados schemaless, PouchDB e

CouchDB, para armazenar dados localmente e no servidor, respetivamente.

Disponibilizando uma API em JavaScript de alto nível, para gerir e simplificar todos os pro-

cessos de lógica de negócio das Aplicações Web e móveis, permite criar aplicações offline-first,

com sincronização com um backend remoto. Permite ainda a adição de plugins de NodeJS ao

23

Offline-first

backend, que lhe conferem funcionalidades mais complexas, como o envio de uma mensagem de

correio eletrónico ou o processamento de uma transação monetária, por exemplo.

Quando uma ação é despoletada, na aplicação, pelo utilizador, através de uma chamada de API

do Hoodie, a ação vai ser processada pelo motor do Hoodie, no front-end, e armazenada na Web

Storage do navegador. De seguida, é verificada a existência de uma ligação à internet e, quando a

ligação for bem sucedida, a ação é enviada pela rede ao backend do Hoodie e armazenada numa

base de dados CouchDB. Caso a ligação não exista, o Hoodie tentará fazer a sincronização numa

outra altura. Quando a informação estiver presente na base de dados do backend, caso deva ser

processada por um plugin de NodeJS, a ação é transmitida pela base de dados ao plugin para ser

concretizada.

4.7.2 Meteor

O Meteor, também com uma arquitetura preparada para Offline-first, é uma framework full-

stack4 que, ao contrário do Hoodie - que ganha na simplicidade -, disponibiliza APIs para a cria-

ção de templates HTML, para gerir sessões, para trabalhar com dados nas bases de dados locais

e remotas, e para outras necessidades comuns a grande parte das Aplicações Web dos dias de

hoje. Um aspeto interessante desta framework é a integração do conceito de Programação Reativa

(4.5.2). As aplicações desenvolvidas tendo por base esta framework são real-time por omissão

e o front-end é atualizado automaticamente, de acordo com as alterações que se verificarem ao

nível do backend. Tal como o Hoodie, o Meteor serve-se de duas bases de dados schemaless -

MongoDB - para o lado do cliente (minimongo) e para o backend. Mais uma vez, tal como acon-

tece com o Hoodie, a API disponibilizada para o tratamento de dados nas bases de dados é de

alto nível, simples de usar e implementada em JavaScript. O Meteor não dispensa, no entanto, da

implementação do backend das aplicações, embora as APIs isomórficas que são disponibilizadas

pela a framework, que tornam possível que o mesmo código JavaScript possa ser corrido tanto no

cliente como no servidor, tenham o propósito de ajudar na sua implementação.

4.7.3 Parse

O Parse, uma framework proprietária que faz parte do património do Facebook, insere-se num

tipo diferente e mais específico de frameworks NoBackend - Backend as a Service. Funcionalida-

des como notificações Push e associar GeoPontos a dados guardados na base de dados são apenas

algumas das funcionalidades que o Parse oferece. Para além disso, permite a implementação de

funções ao nível do servidor - cloud functions - que podem ser usadas para se processarem tarefas

que possam exigir demasiado da capacidade de processamento de um smartphone ou até de um

computador pessoal. O Parse é, portanto, uma framework Backend as a Service bastante completa.

Sendo um serviço, não é gratuito e tem custos associados, dependendo do tipo de funcionali-

dades que se decidir usar e do tráfego que se espera ter com a aplicação que tiver como backend

4Framework que auxilia o desenvolvimento de uma aplicação em todas as suas camadas, desde a responsável pelotratamento de dados até à que trata da interface.

24

Offline-first

o serviço Parse. No entanto, dependendo da aplicação que se pretenda desenvolver, a implemen-

tação de um backend customizado tem também custos associados que, em muitos casos, podem

justificar o recurso a plataformas como o Parse.

25

Offline-first

26

Capítulo 5

Responsive Web Design

Este capítulo descreverá o conceito de Responsive Web Design e apresentará algumas tecno-

logias, conceitos e frameworks que foram criadas com o propósito de responder às exigências

impostas à World Wide Web, com a introdução dos dispositivos com ecrãs de pequenas dimensões

e com o aparecimento dos ecrãs de maiores densidades.

5.1 Origem do Responsive Web Design

Ethan Marcotte, um web developer e web designer com um interesse paralelo em arquitetura,

fala, num dos seus livros, de um tipo de arquitetura - Responsive Arquitecture -, recente na altura,

que diz ter sido uma das inspirações para a sua introdução do conceito de Responsive Web Design.

Edifícios com estruturas móveis e paredes com cores alternáveis foram alguns dos conceitos que

despertaram o seu interesse e que o inspiraram a querer trazer esse conceito para o mundo da Web.

A ideia seria oferecer aos utilizadores da Web um design adaptável ao contexto de visualização de

cada utilizador [Mar10].

Os principais objetivos do desenvolvimento de aplicações para a Web com este tipo de design

seriam:

• Criar layouts adaptáveis a ecrãs de todos os tamanhos, deste ecrãs widescreen de alta reso-

lução a ecrãs de pequenas dimensões como os de grande parte dos smartphones;

• Redimensionar imagens de forma a manter a sua legibilidade em ecrãs pequenos;

• Utilizar imagens, nos dispositivos móveis, que necessitem de uma largura de banda menor;

• Simplificar a estrutura das páginas nos dispositivos móveis;

• Omitir elementos desnecessários em ecrãs de pequenas dimensões;

• Aumentar o tamanho das componentes de interação das interfaces nos dispositivos móveis,

para a navegação em dispositivos táteis ser mais prática;

27


• Aproveitar algumas funcionalidades dos dispositivos móveis, como a Geolocalização e a

orientação do dispositivo, para adequar a experiência de utilização das aplicações a cada

contexto de utilização.

5.2 Mobile First

Mobile first é uma filosofia que se tem tornado popular nos últimos tempos, desde que o con-

ceito de Responsive Web Design foi introduzido por Marcotte, em 2010. De uma forma sucinta,

consiste em desenvolver aplicações primeiro para os dispositivos móveis e só então fazer as adap-

tações necessárias para que elas corram corretamente em dispositivos com ecrãs maiores também.

Os dispositivos móveis têm, de uma forma geral, menos capacidade de processamento e ecrãs

com dimensões inferiores às dos computadores portáteis ou fixos e, como consequência, o soft-

ware desenvolvido para esses dispositivos tem algumas limitações. Da mesma forma, a maioria

dos browsers disponíveis para as plataformas móveis não têm um leque de funcionalidades tão

vasto e rico como os browsers para desktops. Desta forma, se desenvolvermos uma aplicação a

pensar só no seu resultado quando for utilizada através de um computador fixo e, mais tarde, a

quisermos adaptar aos dispositivos móveis, é provável que sejamos obrigados a remover algumas

funcionalidades e a ter o trabalho complicado.

Por oposição, focar o desenvolvimento das Aplicações Web, numa primeira fase, na sua cor-

reta visualização e numa boa experência de utilização em dispositivos móveis, garantindo que

apenas são usadas as tecnologias disponíveis e compatíveis com a maior parte dos browsers mais

usados nesses dispositivos, e só mais tarde fazer a sua adaptação a dispositivos de maiores dimen-

sões, deverá resultar, no final, em aplicações com uma boa experiência de utilização em todas as

plataformas [Mar10].

5.3 Material Design

Uma projeto desenvolvido pela Google que reúne um grande conjunto de boas práticas de

design, que procura respeitar também os princípios do Responsive Web Design e ainda simplificar

e unificar o processo de desenvolvimento da parte visual das Aplicações Web para todo o tipo

de dispositivos. O Material Design recorre a características como a luminosidade e sombras, e a

movimentações das superfícies que compõem a aplicação, para ajudar o utilizador a perceber de

que forma essas superfícies se relacionam entre si, num espaço tridimensional, e para evidenciar

formas de interação entre o utilizador e a aplicação.

No Material Design, elementos como a tipografia, grelhas, espaço em branco, dimensões,

cores e imagens e vídeo são tidos em consideração no sentido de dar significado aos componentes

visuais das Aplicações Web, de criar uma hierarquia entre eles e de manter o utilizador focado no

que é essencial e desta forma tornar o uso destas aplicações o mais intuitivo possível [Mat].

28


5.3.1 Propriedades

O Material Design segue algumas regras que lhe garantem coerência e consistência. A den-

sidade de um ecrã é medida pelo número de píxeis desenhados no ecrã por cada polegada, o

que implica que seja possível desenhar-se um maior número de píxeis em ecrãs de densidades

maiores, para um mesmo dado valor de área. No Material Design, é usada a unidade de medida

density-independent pixel, que permite ao programador abstrair-se deste problema e trabalhar com

os mesmos valores de dimensão para ecrãs de todas as densidades. Os density-independent pixels

são, quando a aplicação é corrida, convertidos para píxeis reais de uma forma proporcional ao valor

da densidade do ecrã do dispositivo de visualização e garantem dessa forma um resultado visual

idêntico tanto em dispositivos com ecrãs de elevada densidade como de baixa densidade [Goo13].

Todas as superfícies, no Material Design, devem ter uma espessura de 1 density-independent pixel.

Ainda no Material Design, as sombras visíveis ao utilizador são usadas para transmitir a elevação

de superfícies de acordo com o eixo das ordenadas e a interação do utilizador com estas superfícies

é evidenciada por alterações feitas à elevação dessas superfícies e, consequentemente, às sombras

causadas por essas superfícies.

5.4 Construção de Interfaces

5.4.1 Cascading Style Sheets

Desde o aparecimento do HTML, houve várias propostas para uma linguagem de mark-up para

customizar o aspeto das páginas Web. Alguma da pouca customização que podia ser feita nessa

altura era escrita diretamente no HTML e dizia respeito a alterações pequenas, ao nível das fontes

usadas, de tamanhos de letra e pouco mais. À medida que o HTML foi evoluindo, foi surgindo

a necessidade de se criar um método melhor para se customizar as páginas Web e, em 1996, o

World Wide Web Consortium propôs o uso de CSS para fazer este tipo de customização. Com

a introdução do CSS, passou a ser possível fazer esta costumização em ficheiros de código fonte

independentes dos ficheiros HTML. Porém, as alterações que podiam ser feitas com as primeiras

versões do CSS eram ainda bastante limitadas [F+11].

A última versão do CSS lançada até à data, por sua vez, foi a primeira a considerar já o

conceito de responsividade e a permitir criar layouts adaptáveis a diferentes resoluções e a ecrãs

de diferentes dimensões, possibilitando a criação de grelhas fluídas, imagens flexíveis e media

queries. Para além disto, a versão 3 do CSS passou também a incluir algumas funcionalidades

nativamente que viriam a melhorar consideravelmente a usabilidade das Aplicações Web, como a

introdução de sombras e de CSS Animations [Sam13].

5.4.2 Syntactically Awesome Style Sheets

Sass é uma linguagem que estende a funcionalidade do CSS, adicionando-lhe algumas pro-

priedades que simplificam e que tornam mais organizado o processo de customização visual das

Aplicações Web. O código desenvolvido em Sass precisa, no entanto, de ser compilado para

29


código CSS para poder ser usado na Web e reconhecido pelos navegadores. Em Sass existem va-

riáveis; é possível usar seletores dentro de outros seletores - nesting -, evitando a necessidade de

repetir o seletor mais genérico para cada regra aplicada a outro seletor que dele dependa; é possível

criar ficheiros Sass parciais, com partes de código que podem ser posteriormente reutilizadas por

ficheiros de código diferentes; existem mixins, que permitem agrupar várias linhas de Sass numa

para facilitar a sua reutilização; existe polimorfismo, sendo possível criar seletores que estendem

outros mais genéricos; e é possível ainda trabalhar com valores com os operadores matemáticos

de adição, subtração, multiplicação, divisão e de cálculo do resto. Para além disso, o Sass pode

ainda ser usado em conjunto com código CSS simples [Sas].

5.4.3 Framework Compass

O Compass é uma framework baseada em Sass que resolve alguns dos problemas mais comuns

existentes no CSS3 e otimiza o desenvolvimento da componente visual das Aplicações Web. Tal

como na linguagem Sass, com o Compass, é possível usar variáveis, mixins, fazer nesting de

seletores e processar cálculos matemáticos. Quando usamos CSS3, ou até mesmo Sass, é frequente

sermos obrigados e escrever várias linhas de código que produzem o mesmo efeito visual, mas

que se aplicam a navegadores diferentes. O Compass abstrai-nos deste problema e assegura-se

de que todo o código produzido é compatível com todas as plataformas desejadas. Para além

disso, o Compass permite definir ainda propriedades, como as cores de uma hiperligação, por

exemplo, para todos os estados, recorrendo apenas a uma linha, ou definir as propriedades de CSS

de uma lista HTML usando, da mesma forma, apenas uma linha de código da API do Compass. É

ainda possível usar plugins adicionais para usar funcionalidades que não são disponibilizadas por

omissão na API da framework, como sistemas grelhas responsivas, widgets, esquemas de cores,

entre outras [Fra13].

5.5 Web Animations

Já existem pelo menos 4 formas conhecidas e bastante usadas de se fazer animações para a

Web:

• CSS Transitions e CSS Animations - embora consumam poucos recursos e sejam rápidas,

construir animações através do CSS tem algumas limitações, não permitindo fazer anima-

ções mais complexas e sequenciais ou construir animações compostas por várias animações;

para além disso, este tipo de animações têm de ser implementadas ao nível do CSS e não

podem ser customizadas com JavaScript;

• SVG Animations - embora permita fazer animações com um maior nível de complexidade, as

SVG Animations são pesadas para os navegadores, são difíceis de construir e não permitem

animar elementos HTML;

30


• O método “requestAnimationFrame” - exige o uso da thread principal onde correm os even-

tos de front-end e, caso essa thread esteja a ser usada, as animações não vão ser ativadas de

imediato.

As Web Animations são uma alternativa e uma resposta às limitações destas 4 tecnologias já

existentes.

De uma maneira geral, os navegadores mais recentes recorrem a 2 threads para fazerem o ren-

der de uma página Web. Uma delas, a thread principal, é normalmente a responsável por correr o

código JavaScript da página, por processar os estilos CSS associados a essa página, por converter

o resultado visual dos vários componentes da página em imagens e por os enviar para a segunda

thread, que se irá ocupar de apresentar essas imagens ao utilizador. Grande parte das tarefas en-

caminhadas para esta segunda thread são processadas em paralelo, ao nível da GPU (Graphics

Processing Unit) e a sua performance não é afetada pelo que possa estar a acontecer no CPU

(Central Processing Unit). Para além disso, as tarefas de desenhar imagens no ecrã, seja em dife-

rentes sítios do ecrã, em diferentes ângulos ou em diferentes tamanhos, são extremamente rápidas,

quando processadas ao nível da GPU. Tal como as CSS Transitions e as CSS Animations, também

as Web Animations tiram partido do uso desta segunda thread e do poder de processamento da

GPU para otimizarem as suas animações e, desta forma, permitem criar animações tão eficientes

como as implementadas em CSS, exclusivamente com o recurso a JavaScript, e com um maior

grau de complexidade [Ado].

Implementação

Figura 5.1: Código exemplo de uma Web Animation

A Figura 5.1 ilustra um exemplo genérico de construção de uma Web Animation em JavaS-

cript. O objeto “element” deve conter o elemento HTML que se pretende animar e as variáveis

“cssProperty” devem ser substituídas pelas propriedades de CSS que se pretendem alterar para

construir a animação. Em baixo, onde se encontram as propriedades “duration”, “iterations” e

“delay”, existe um vasto conjunto de propriedades que são opcionais [W31]:

• duration: duração da animação;

31


• iterations: número de repetições da animação;

• iterationStart: o número da repetição em que a animação deverá começar (podem ser usa-

dos valores decimais para apontar para frações da iteração);

• fill: como a animação irá ser mostrada quando não estiver a correr;

• delay: tempo de espera antes de começar a animação;

• playbackRate: velocidade da animação;

• direction: valor que possibilita as animações correrem no início para o fim, ao contrário ou

alternadamente;

• easing: modo como os valores definidos em cima, nas propriedades do CSS, vão ser altera-

dos consoante o decorrer da animação.

Suporte

As Web Animations são atualmente suportadas pelos seguintes navegadores: Chrome 36+,

Opera 26+, Android Browser 37+ e Chrome for Android 39+.

5.6 Responsive Images

Já vimos que, com a introdução do CSS3, passou a ser não só possível mas simples redimen-

sionar, reposicionar e ajustar os layouts de uma Aplicação Web a ecrãs de diferentes tamanhos.

Porém, o conceito de Responsive Web Design não se limita aos layouts. É importante ter-se tam-

bém em atenção as dimensões de conteúdo como imagens e vídeos nas Aplicações Web e tentar

assegurar que os recursos usados numa aplicação num telemóvel têm as dimensões adequadas ao

dispositivo. Da mesma forma que se deve procurar garantir que uma imagem que deverá ocupar

completamente um ecrã com uma resolução de alta definição não deverá ser a mesma do que a

carregada pela mesma aplicação num telemóvel. Estas considerações deverão ser tidas no sentido

de se prevenir a deformação desses recursos em qualquer um desses monitores, bem como de

garantir que recursos com definição demasiado alta não são carregados e não gastam largura de

banda desnecessária em dispositivos que também não o exigem. As Responsive Images surgem

portanto como uma possível resposta a este problema.

Implementação

Já existe, desde a introdução do HTML5, a tag “video”, que permite a atribuição de vários

ficheiros de vídeo possíveis para reprodução, para garantir que, mesmo que um navegador não

suporte um dos formatos, o programador possa definir outro opcional compatível com esse na-

vegador. Da mesma forma, também a tag “picture”, recentemente introduzida na especificação

do HTML, permite que um navegador carregue uma de várias opções de imagens definidas pelo

32


programador, no sentido de carregar aquela que se melhor se adeque às características do ecrã de

cada dispositivo.

Figura 5.2: Código exemplo da aplicação da tag “picture”

A Figura 5.2 representa um exemplo de uso da tag “picture”. Nos elementos “source” são

definidos os caminhos para as opções de imagens disponíveis, associados a media queries, que

asseguram que essas imagens só são carregadas quando as dimensões da janela do navegador

satisfazem os valores nelas definidos. No valor do atributo “srcset”, juntamente com o caminho

para o ficheiro de imagem, encontra-se um valor que assegura o carregamento de imagens com

dimensões diferentes para os ecrãs de maiores resoluções.

Dentro da tag “picture” encontra-se ainda um elemento “img”, que garante que, caso o na-

vegador não seja compatível ainda com este elemento “picture”, irá mostrar na mesma mostrar

uma imagem. Outros atributos, embora opcionais, da tag “source”, são ainda o atributo “sizes”,

que permite atribuir um comprimento à imagem, relativo ao tamanho do viewport1, e o atributo

“type”, que serve para especificar o formato da imagem, de forma a que o navegador carregue uma

imagem compatível.

Também a tag “img”, na nova especificação do HTML, sofreu algumas alterações e permite

agora implementar este tipo de funcionalidade:

Figura 5.3: Código exemplo da aplicação da tag “img”

O exemplo representado pela Figura 5.3, recorrendo ao atributo “sizes”, atribui à imagem

dimensões diferentes consoante as dimensões do viewport, para além de carregar ficheiros de

imagem diferentes consoante a densidade de píxeis do ecrã onde a imagem é carregada [HTMb].

Suporte

As Responsive Images são atualmente compatíveis com os seguintes navegadores: Chrome

38+, Opera 26+ e Chrome for Android 39+.

1Área onde são desenhados todos os componentes da interface de uma aplicação.

33


34

Capítulo 6

Single-Page Applications

Desde o início da World Wide Web e até há relativamente poucos anos, a interatividade visível

nas Aplicações Web que já existiam era bastante limitada. Para todos os pedidos enviados pelo

front-end ao servidor, consequentes da navegação nessas aplicações, era processada, ao nível do

servidor, e carregada pelo cliente uma nova página HTML completa. Muitas vezes, as diferenças

entre as duas páginas HTML eram parciais e o carregamento integral de uma nova página não se

justificava. Também em situações onde a ligação entre o cliente e o servidor falhasse ou tivesse

uma baixa velocidade, o estado da aplicação anterior à interação do utilizador com a aplicação era

perdido e a aplicação ficava inutilizável até ser novamente possível obter uma resposta do servidor.

Este processo foi usado durante vários anos, enquanto as redes sem fios ainda não eram uma

realidade, nem um problema. Para além disso, as contrapartidas que apresentavam eram necessá-

rias numa altura em que o poder de processamento de grande parte dos dispositivos que permitiam

aceder a Web era limitado e, por essa razão, tarefas de processamento mais complexas tinham

obrigatoriamente de pertencer ao domínio do servidor.

6.1 Aparecimento das SPAs

Com o aparecimento gradual de dispositivos com maior poder de processamento, do aumento

da probabilidade de ocorrência de falhas nas ligações a Internet, com o aparecimento das redes sem

fios, e, mais tarde, com a explosão tecnológica que deu origem aos dispositivos móveis, passou não

só a ser possível passar para o front-end das Aplicações Web algumas operações mais complexas

de processamento, mas também a ser mais importante dar resposta às limitações impostas pela

Web estática, pobre na interatividade e na experiência utilização que proporcionava ao utilizador

final.

Aumentar o nível de interatividade, de cooperação e, como consequência, tornar a Web numa

plataforma mais dinâmica foram algumas das ideias introduzidas com a Web 2.0. Foi também

com o aparecimento da Web 2.0 que tecnologias como código JavaScript assíncrono e algumas

35


linguagens de anotação, como o XML e o JSON, começaram a ser cada vez mais faladas. O

desenvolvimento deste tipo de tecnologias foi o primeiro passo dado no sentido de possibilitar a

criação de Aplicações Web dinâmicas, mais eficientes, na troca de dados entre o front-end e o ser-

vidor, mais ricas, no que toca à experiência de utilização proporcionada ao utilizador final, e com

mais funcionalidades e uma maior complexidade ao nível do front-end. Este tipo de aplicações

são conhecidas por Single-Page Applications, ou Single-Page Interfaces, e vieram revolucionar a

forma como as Aplicações Web são estruturadas, tanto ao nível do backend e como do front-end.

6.2 Architectural Patterns

Com o aumento da complexidade de uma aplicação, seja ela Web ou não, cresce também a

importância de se manter o código-fonte organizado, documentado e separado, normalmente por

funcionalidades e por partes lógicas. Desta forma, garante-se que o código é legível para todos os

programadores que estejam encarregues do desenvolvimento e da manutenção da aplicação, bem

como para programadores que possam vir a estar envolvidos no seu desenvolvimento no futuro.

Os Architectural Patterns resultam normalmente do trabalho e da experiência de programadores

que já tiveram de lidar com este tipo de questões e resumem-se a conjuntos de regras e de boas

práticas que podem ser seguidos em engenharia de software.

Antes do aparecimento das Single-Page Applications, os servidores eram responsáveis pelo

processamento da maior parte das funcionalidades das Aplicações Web. Por esta razão, alguns

padrões de arquitetura, como o MVC (Model-View-Controller), o MVP (Model-View-Presenter) e

o MVVM (Model-View-ViewModel), já eram bastante usados no desenvolvimento de Aplicações

Web, embora apenas ao nível do servidor. A introdução do conceito de Single-Page Applications e,

por consequência, o aumento da complexidade dos front-ends das Aplicações Web mais recentes

levou a que se começasse a falar de implementações desses Architectural Patterns em JavaScript

e aplicados ao desenvolvimento de front-end [Pet12].

6.2.1 Model-View-Controller

Model-View-Controller é um padrão de arquitetura que promove a separação de código por

tipos de tarefas, no desenvolvimento de software. No contexto do desenvolvimento de Aplicações

Web, com o MVC, o código responsável por trabalhar com os dados da aplicação - Model - deverá

ficar isolado do código que se encarrega de desenhar a interface do utilizador - View e estes dois

módulos deverão ser independentes em relação a um terceiro, responsável por trabalhar toda a

lógica de negócio da aplicação, bem como por processar e dar resposta a inputs do utilizador -

Controller [Osm12].

Serão agora descritos em maior detalhe o propósito e a funcionalidade normalmente atribuídos

a cada uma dessas três partes:

36


Model

Como já foi dito, os Models contém a parte do código-fonte que é responsável por trabalhar

com os dados da aplicação.

Existem várias frameworks que implementam o padrão de arquitetura MVC e as funcionalida-

des atribuídas aos Models podem variar ligeiramente entre elas. Porém, normalmente um Model

serve de modelo para a criação de representações de objetos do mundo real, que pertençam ao

domínio de conhecimento que envolve a aplicação, numa linguagem de programação. Cada Mo-

del tem atributos que representam as propriedades de um tipo de objeto em específico e fazem

a validação desses atributos, de forma a manter a informação da aplicação coerente. Quando os

dados de um Model são alterados, dependendo do estado da aplicação, poderão haver Views que

estejam a mostrar essa informação na aplicação nesse momento. Nesse caso, o Model é também

responsável por informar as Views em questão das alterações feitas, de forma a que o estado visual

da aplicação continue atualizado. Ainda com o propósito de manter os dados da aplicação devi-

damente atualizados, a sincronização de dados, em cache, recorrendo ao localstorage do HTML5

ou a bases de dados externas, pode ser feita ao nível do Model.

Os Models são ainda independentes tanto da componente lógica da aplicação - Controllers -

como da componente visual - Views. Isto quer dizer que, à partida, se um Model for alterado, por

exemplo para se fazer manutação ao código-fonte de uma aplicação, sem que, claro, seja removida

nenhuma funcionalidade que já esteja a priori funcional na aplicação, o sistema continuará a

funcionar sem problemas e não teremos de fazer quaisquer modificações a Controllers ou a Views.

View

As Views encarregam-se então da componente visual da aplicação.

Uma View está associada normalmente a um Controller e pode comunicar com zero, um ou

mais Models, dependendo do tipo de informação que esteja encarregue de desenhar na interface do

utilizador. Quando os dados de um Model são modificados, a View que esteja a mostrar esses dados

no momento da alteração é notificada e atualiza os dados em questão. No contexto das aplicações

Web, isto significa criar ou apagar elementos DOM ou alterar as suas propriedades. Para além

disso, as Views são a componente da aplicação com a qual os utilizadores vão interagir. É através

delas que os utilizadores vão conseguir ler e editar os dados armazenados nos Models, embora

seja só ao nível do Controller que as alterações são processadas e não diretamente nas Views. Os

templates1 são bastante usados para desenhar Views, em várias frameworks de JavaScript que im-

plementam o padrão de arquitetura MVC no desenvolvimento de Single-Page Applications. Eles

permitem criar HTML dinamicamente, com os dados obtidos a partir dos Models, por exemplo.

Sendo os templates construídos com código HTML, a sua implementação é declarativa e portanto

mais simples em relação ao uso de JavaScript para se obterem os mesmos resultados.

1Blocos de HTML que são instanciados várias vezes por uma Aplicação Web.

37


Controller

Os Controllers servem de intermediário entre as Views e os Models e são os responsáveis por

fazer as alterações necessárias ao nível dos Models, sempre que o utilizador criar interações com

as Views que assim o exijam.

Mais uma vez, no contexto do desenvolvimento de SPAs, quando um evento é despoletado,

numa View, devido à interação do utilizador, essa View pode ativar outro evento, ao nível do

Controller, que tratará de processar as tarefas de lógica de negócio.

Benefícios do MVC

Os principais benefícios que a implementação do Architectural Pattern MVC traz para o

mundo das Aplicações Web são:

• Facilita a manutenção das Aplicações Web; por exemplo, possíveis alterações a serem feitas

à interface da aplicação serão independentes do código dos Models e dos Controllers;

• Facilita a implementação de testes unitários à lógica de negócio da aplicação, por separar o

código das aplicações por partes lógicas;

• Para aplicações de maiores dimensões e que estejam à responsabilidade de equipas com-

postas por vários elementos, ou até por várias equipas, simplifica o desenvolvimento em

paralelo das várias componentes da aplicação.

6.2.2 Model-View-Presenter

O MVP é um padrão de arquitetura semelhante ao MVC. Como principal diferença, neste

Arquitectural Pattern, os Controllers são substituídos por Presenters e, para além de continuarem a

ser esses os responsáveis pela lógica de negócio na arquitetura, à semelhança do que acontecia com

os Controllers no MVC, no MVP, os Presenters ganham um papel mais relevante no tratamento

dos dados que são mostrados ao utilizador através das Views.

No Model-View-Presenter, os Presenters passam a ser os responsáveis por fazer binding aos

dados representados nos Models (quando ocorrem alterações ao nível de um Model, um Presenter

deverá ser informado dessas alterações), pela manipulação desses dados e pelo envio dos resul-

tados às Views encarregadas de os desenhar na interface do utilizador. No MVC, o binding aos

Models podia ser feito diretamente ao nível das Views, o que, por um lado, permitia a criação de

Controllers menos complexos e tornava mais prático o desenvolvimento de aplicações com inter-

faces mais simples. Por outro lado, porém, quando é exigido um maior nível de complexidade no

tratamento de dados na interface, pode ser útil passar essa lógica para um Presenter e continuar

a manter simples o processo de criação de Views, que apenas terão o propósito de representar

os dados já trabalhados pelo Presenter. Em algumas implementações de MVP, a comunicação

do front-end da aplicação com um back-end, ou simplesmente o armazenamento do estado da

aplicação, é também tratada ao nível do Presenter.

38


Para além disso, neste padrão de arquitetura, os dados são tratados antes de serem enviados

para a interface do utilizador e esta comunicação é feita através de uma interface de programação.

Desta forma, passa a ser mais simples substituir Views por uma camada de testes unitários que teste

o comportamento da aplicação. Ainda por a interface do utilizador, no MVP, ser independente de

todo o tipo de tarefas de lógica de negócio e de manipulação de dados, este padrão de arquitetura

permite que as Views sejam desenvolvidas em paralelo com os restantes componentes da aplicação

e que, mais uma vez, para aplicações aplicações de maior complexidade, se consiga uma melhor

produtividade [Osm12].

Benefícios do MVP

Os principais benefícios que a implementação do MVP traz são:

• Manutenção mais simples;

• Desenvolvimento em paralelo da UI e de toda a lógica funcional da aplicação;

• Implementação de testes unitários facilitada, em relação ao MVC, por centrar nos Models e

nos Presenters toda a parte funcional das aplicações.

6.2.3 Model-View-ViewModel

Baseado no MVC e no MVP, o Model-View-ViewModel é semelhante aos dois anteriores. A

principal diferença reside no facto de, neste Architectural Pattern, o Controller, ou o Presenter,

ser substituído pelo ViewModel. Tal como acontece no MVP, no MVVM, a manipulação de dados

não acontece ao nível das Views, que, como consequência irão ser mais simples de desenvolver

e implicarão menos código. Em vez disso, no MVVM, os dados são manipulados ao nível dos

ViewModels. No MVVM, as Views devem fazer binding aos dados trabalhados pelos ViewModels,

que representam o estado da aplicação, e devem comunicar os eventos de input do utilizador igual-

mente aos ViewModels, que se encarregarão de os processar e de fazer as alterações necessárias

ao nível dos Models. Os ViewModels atuam então como um intermediário entre as Views e os

Models e permitem manter um elevado nível de separação de código entre a componente visual

da aplicação e a sua lógica de negócio, como acontece com o MVP, o que, mais uma vez, facilita

a integração de testes unitários e o desenvolvimento em simultâneo da interface e da componente

lógica deste tipo de aplicações [Osm12].

Benefícios do MVVM

Os principais benefícios que a implementação do MVVM traz são:

• Manutenção mais simples;

• Desenvolvimento em paralelo da UI e de toda a lógica funcional da aplicação;

• Implementação de testes unitários facilitada;

39


• Two-way data-binding entre Views e ViewModels dá mais liberdade a designers para usarem

os dados de formas diferentes na interface do utilizador.

6.3 Design Patterns

Design Patterns são boas práticas de resolução de problemas que ocorrem com frequência no

processo de desenvolvimento de software. Os Design Patterns oferecem técnicas que ajudam a

resolver esses problemas de uma forma robusta e que resultam da experiência e do conhecimento

dos programadores que os formularam, bem como do contributo dos programadores que os usaram

e que, de alguma forma, os aperfeiçoaram e lhe acrescentaram valor.

São soluções genéricas que podem ser aplicadas a um grupo de problemas semelhantes, ao

longo do desenvolvimento de um aplicação, e o seu uso recorrente resulta, normalmente, na pro-

dução de código mais robusto, organizado e legível.

Para além disso, tendo normalmente uma estrutura e um vocabulário próprio, os Design Pat-

terns ajudam os programadores a comunicarem e a expressarem problemas mais complexos com

um maior nível de abstração, recorrendo a esse vocabulário.

6.3.1 Categorias de Design Patterns

No domínio do desenvolvimento de Single-Page Applications, existem 3 tipos de Design Pat-

terns principais: Design Patterns de criação, de estrutura e de comportamento [Osm12].

Design Patterns de Criação

Focam-se nos mecanismos de criação de objetos e procuram oferecer um maior controlo so-

bre esses processos. São usados para se tentar evitar a necessidade de serem usadas soluções

complexas, num estado mais avançado do desenvolvimento das aplicações, devido a problemas

relacionados com esses mecanismos de criação.

Alguns dos Design Patterns que se incluem nesta categoria são: Constructor, Factory, Abstract,

Prototype, Singleton e Builder.

Design Patterns de Estrutura

Procuram oferecer formas simples de criar relações entre objetos diferentes, com o propósito

de evitar a necessidade de serem feitas alterações à estrutura global de uma aplicação em situações

em que apenas um, ou alguns dos seus componentes sofrem modificações.

Exemplos deste tipo de Design Patterns são: Decorator, Facade, Flyweight, Adapter e Proxy.

Design Patterns de Comportamento

Procuram melhorar os processos de interação e de comunicação entre os vários componentes

de uma aplicação.

40


Estes são alguns dos Design Patterns deste tipo: Iterator, Mediator, Observer e Visitor.

6.3.2 Desing Patterns Emergentes

Existe uma vasta lista de Design Patterns de JavaScript que podem ser usados e trazer benefí-

cios ao desenvolvimento de Aplicações Web em diversas situações. No contexto das Single-Page

Applications, porém, há alguns que têm particular interesse e que serão descritos a seguir [Osm12].

Module Pattern

A modularidade é um aspeto fundamental nas SPAs. É o que torna possível implementar

Arquitecture Patterns como o MVC, o MVP ou o MVVM e é um fator fundamental quando se

pretende desenvolver aplicações que incorporem testes unitários e cuja sua manutenção, no futuro,

seja simples e não implique grandes alterações ao nível da aplicação como um todo. Para além

disso, o próprio conceito de SPA implica ser possível criar interfaces modulares, compostas por

vários componentes que podem ser reutilizados em ecrãs diferentes da aplicação e que estejam

associados a funcionalidades diferentes.

O Module Pattern é usado para emular o conceito de classes, não suportado nativamente em

JavaScript, e oferece uma forma de se emular a criação de métodos públicos e privados na lingua-

gem, que produzem um efeito semelhante ao uso de classes noutras linguagens de programação

orientada a objetos. Este é um Design Pattern importante na implementação de componentes

em SPAs, uma vez que, por trazer o conceito de encapsulamento de métodos para o JavaScript,

impede que esses métodos entrem em conflito com métodos de outros componentes do sistema e

concedem ao código um maior nível de organização, tornando possível incorporar funcionalidades

semelhantes num mesmo módulo e esconder e separar toda a sua lógica dos restantes componentes

da aplicação.

O Module Pattern pode ser considerado um Design Pattern de criação e de estrutura.

Prototype Pattern

É usado para implementar heranças, em JavaScript. Permite, portanto, criar objetos com as

mesmas propriedades de outros objetos e adicionar-lhes novas propriedades e funcionalidades.

Todos os métodos implementados no objeto-pai são referenciados no objeto descendente, sendo

que, quando é chamado um desses métodos no objeto-filho, é chamada a implementação desse

método no objeto-pai.

O Prototype Pattern é considerado um Design Pattern de criação.

Observer Pattern

O Observer Pattern é usado, no desenvolvimento de SPAs, para implementar o conceito de

data-binding. Na sua implementação, os objetos que dependam dos dados armazenados por outro

41


objeto são adicionados a uma lista guardada neste último e, sempre que esses dados sofram alte-

rações, esse objeto irá transmitir o novo estado a todos os elementos que constem nessa lista, em

tempo real.

O Observer Pattern é considerado um Design Pattern de comportamento.

Facade Pattern

O objetivo deste Design Pattern é abstrair o programador de blocos de código longos e de

maior complexidade, criando abstrações, simples e reutilizáveis, que permitam correr as funcio-

nalidades desses blocos de código.

O Facade Pattern é considerado um Design Pattern de estrutura.

6.4 Testes Unitários

Existem já algumas bibliotecas e frameworks que podem ser usadas em conjunto para se con-

seguir uma implementação completa de testes unitários ao front-end de Aplicações Web. Três

exemplos são o Mocha, o Chai e o Sinon [Man].

6.4.1 Mocha

O Mocha é uma framework que oferece uma API para a criação de testes unitários em Ja-

vaScript e um ambiente gráfico onde revela os resultados desses testes. Com o Mocha, é ainda

possível avaliar o resultado de métodos assíncronos, como é o caso de uma função que executa um

pedido a um servidor remoto e que fica à espera de uma resposta, enquanto a aplicação executa

outras tarefas [Moc].

6.4.2 Chai

O Chai é a biblioteca de funções que permite fazer as comparações entre os resultados espe-

rados e obtidos dos testes unitários declarados com a framework Mocha. A Figura 6.1 mostra um

exemplo da implementação de um teste unitário simples com a framework Mocha e este biblioteca:

Figura 6.1: Teste unitário implementado com Mocha e Chai

42


No exemplo, é criado um ambiente de testes para os objetos criados a partir do objeto “Per-

son” e é implementado teste ao método construtor que verifica que todos os objetos de “Person”

instanciados com o construtor genérico têm o nome “Pessoa” [Man].

6.4.3 Sinon

O Sinon é uma biblioteca que simula um ambiente de execução real para os testes unitários a

serem executados. O seu uso é útil em situações em que os métodos que pretendem ser testados

afetam o estado do ambiente em que são executados, por oposição a retornarem diretamente os

seus resultados [Sin].

43


44

Capítulo 7

Proposta de Trabalho

Neste capítulo é descrita a proposta de trabalho desta dissertação. Será proposta uma arqui-

tetura de front-end moderna que beneficie das vantagens das tecnologias faladas nos capítulos

anteriores de forma a oferecer soluções para os problemas mais comuns visíveis atualmente na

World Wide Web. No plano de trabalhos desta dissertação está ainda uma prova de conceito que

consistirá numa aplicação Web desenvolvida com essa arquitetura e que terá o propósito de validar

os resultados obtidos na concretização da dissertação.

7.1 Arquitetura de Front-end Moderna

Como já foi visto, o HTML5 é a linguagem declarativa de eleição para o desenvolvimento

de Aplicações Web que proporcionem uma boa experiência de utilização ao longo de todos os

dispositivos que permitem o acesso à Web. A arquitetura que irá ser proposta por esta disser-

tação irá consistir num modelo de desenvolvimento de Aplicações Web baseado em tecnologias

HTML5, CSS e JavaScript e servir-se-á da capacidade das tecnologias que integram o domínio dos

Web Components, do Offline-first, do Responsive Web Design e das Single-Page Applications para

simplificar o desenvolvimento dessas aplicações, para melhorar, em simultâneo, o código-fonte

dessas aplicações, para habilitar o seu funcionamento offline e para melhorar a sua experiência de

utilização, de forma a aproximar, nesses aspetos, as Aplicações Web das aplicações nativas.

7.1.1 Web Components

Os Web Components (3) permitem a criação de Custom Elements, que dão um forte contributo

na organização e na legibilidade do código-fonte das Aplicações Web. Porém, para além disso,

tornam ainda possível importar outros Custom Elements declarativamente, inclusive de fontes ex-

teriores, e incorporá-los diretamente na aplicação ou em outros Custom Elements mais complexos.

Desta forma, é possível garantir ao código desenvolvido um maior nível de abstração.

Pretende-se assim tirar partido desta tecnologia para se conceder às aplicações desenvolvidas

com a arquitetura a ser proposta uma fácil reutilização de código, de organização de código, de

45


abstração e, como consequência desta última, tornar mais simples desenvolver aplicações mais

complexas. À partida, será usada a framework Polymer na implementação da arquitetura.

7.1.2 Offline-first

Propõe-se aliar aos Web Components, na arquitetura a ser proposta, as tecnologias Offline-first,

descritas no capítulo 4, para habilitar o funcionamento normal nas Aplicações Web em situações

em que não é possível ter-se um acesso estável à Internet. Será usada uma framework para se que

permita a integração de uma base de dados front-end e que garanta e simplifique o processo de

sincronização de dados com um serviço de backend. É ainda esperado que essa framework forneça

uma API que abstraia o programador de trabalhar diretamente com pedidos feitos a essas bases de

dados.

Pretende-se, com a incorporação das tecnologias Offline-first nas Aplicações Web, tornar pos-

sível criar aplicações que não dependam de ligações à Internet sem falhas para proporcionarem

experiências de utilização fluídas e minimizar situações em que são perdidos dados devido a fa-

lhas nessas ligações.

7.1.3 Responsive Web Design

As tecnologias pertencentes ao domínio do Responsive Web Design servirão, na arquitetura,

o propósito de eliminar código-fonte repetido, usado para satisfazer as necessidades de compati-

bilidade de navegadores diferentes, e de garantir que as aplicações desenvolvidas, com o modelo

de desenvolvimento a ser proposto, integram interfaces intuitivas, fluídas e adaptáveis aos vários

tamanhos e densidades de ecrãs disponíveis atualmente.

7.1.4 Single-Page Applications

Por último, pretende-se ainda garantir que a arquitetura a ser proposta usufrua das boas práticas

de programação associadas ao conceito de Single-Page Applications e que possibilite a integração

de testes unitários às aplicações que sigam o seu modelo de desenvolvimento.

7.1.5 Arquitetura Exemplo

Uma proposta exemplo de uma arquitetura de front-end, baseada nas tecnologias abordadas

nesta dissertação, deverá contemplar o desenvolvimento das seguintes partes lógicas de uma apli-

cação Web:

• Interface do Utilizador - O desenvolvimento dos vários componentes que compõem a UI

de uma aplicação Web podem ser desenvolvidos recorendo à framework Polymer, tirando

assim partido das vantagens oferecidas pelo uso das tecnologias dos Web Components. Para

o design desses componentes, poderá ser usada a framework de CSS Compass, que asse-

gurará a correta visualização da UI da aplicação na grande maioria dos navegadores mais

recentes, e poderão ser usadas as funcionalidades do Polymer que permitem a criação de

46


layouts adaptáveis, de forma a garantir que a aplicação terá uma interface do utilizador que

aplica as noções de Responsive Web Design. Para além disso, deverão ser usadas ainda, no

desenvolvimento da UI, as tecnologias Web Animations e Responsive Images, de forma a que

a interface resultante deste processo tenha uma navegação rica e fluída e seja corretamente

visível em todos os tipos de ecrãs.

• Lógica de Negócio - Para fazer o tratamento e armazenamento de dados na aplicação, po-

derá ser usada a framework Hoodie, que, sendo uma framework NoBackend, dispensará o

programador da implementação do backend da aplicação e tornará possível armazenar da-

dos numa base de dados front-end, recorrendo à API simples de tratamento de dados que

integra a sua especificação. O Hoodie assegurará ainda o correto funcionamento offline da

aplicação e garantir-lhe-á uma experiência de utilização mais fluída.

Para além estas duas partes, poder-se-á ainda aliar a framework AngularJS ao Polymer e ao

Hoodie e implementar, na aplicação, o architectural pattern MVC, que ajudará a conceder à apli-

cação um maior nível de separação e de organização de código e que garantirá a sua testabilidade.

Para a implementação de testes unitários, poderão ser usadas as frameworks/bibliotecas de funções

Chai, Mocha e Sinon.

Deverão também ser implementados, durante o desenvolvimento, os design patterns associa-

dos ao desenvolvimento de Single-Page Applications, de forma a garantir a robustez do código-

fonte das aplicações desenvolvidas.

7.2 Prova de Conceito

Como prova de conceito da arquitetura a ser proposta, será desenvolvida uma aplicação. Essa

aplicação servirá o propósito de fazer encomendas de refeições a serviços de restauração e de

atribuir a responsabilidade de entregar essas encomendas a pessoas que se estarão registadas na

aplicação como estafetas.

A aplicação terá, então, dois tipos de utilizadores: o utilizador comum, que só terá permissões

para navegar na lista dos restaurantes disponíveis e para fazer a encomenda de refeições a esses

estabelecimentos; e o utilizador estafeta, que às permissões de acesso do utilizador comum soma

as de poder receber e tratar pedidos de encomendas, em tempo-real.

7.2.1 Funcionalidades

De seguida, será feito uma descrição das funcionalidades mais importantes da aplicação:

• O registo e a autenticação na aplicação serão feitos recorrendo à API do Facebook;

• Os utilizadores poderão pesquisar por restaurantes por proximidade, recorrendo à sua posi-

ção GPS;

47


• Os utilizadores terão acesso à lista dos pratos disponíveis em cada estabelecimento e terão

acesso a outra vista, que mostrará em detalhe as informações de cada prato;

• Os utilizadores terão acesso a uma interface onde poderão concluir uma encomenda;

• Os utilizadores terão acesso, em tempo-real, ao estado das suas encomendas;

• Um estafeta poderá definir o seu estado como “ocupado” e impedir, dessa forma, que lhe

sejam solicitadas encomendas;

• Os estafetas poderão aceitar ou recusar os pedidos de encomendas que recebam;

• Será possível fazer a avaliação tanto dos clientes como dos estafetas registados na aplicação.

48

Capítulo 8

Conclusões e Trabalho Futuro

Neste capítulo será feita uma reflexão sobre o trabalho realizado no âmbito da unidade curri-

cular de Preparação da Dissertação e serão apontados os planos de trabalho para o futuro.

8.1 Conclusões

Esta dissertação trata alguns dos problemas mais falados atualmente no desenvolvimento de

aplicações para a Web: é uma ideia utópica a de que, pelo menos dentro de poucos anos, ter-

se-ão ligações à Internet fiáveis a tempo inteiro e em todo os pontos do globo; a experiência

de utilização das Aplicações Web é bastante inferior à das aplicações nativas, em particular nos

dispositivos móveis; é difícil desenvolver aplicações que sejam compatíveis com um leque tão

vasto de dispositivos como o que existe na atualidade - já não é uma tarefa simples desenvolver

uma aplicação sem essas preocupações, que envolva a implementação de um backend e um front-

end. Isto para dizer que será um desafio grande, oferecer respostas a todos estes problemas. Porém,

por outro lado e pela mesma razão, será maior a motivação.

A proposta de trabalho feita irá reunir quatro tecnologias que são ainda bastante recentes no

contexto da World Wide Web, cada uma delas composta por várias frameworks, filosofias e concei-

tos que ainda são pouco falados e visíveis nas Aplicações Web desenvolvidas atualmente. Espera-

se que os resultados desta dissertação reflitam o poder dessas tecnologias no desenvolvimento de

Aplicações Web e que a arquitetura de front-end proposta, como resultado deste trabalho, atinja os

seus objetivos e possa ser um modelo de previsão para o que será o desenvolvimento de aplicações

para a Web nos próximos anos.

8.2 Trabalho Futuro

O diagrama de Gantt da Figura 8.1 representa o plano de trabalhos futuro, para a realização

desta dissertação.

49


Figura 8.1: Diagrama de Gantt do plano de trabalhos

Na primeira semana, que terá início no dia 22 de Fevereiro de 2015, será dado início à instala-

ção das frameworks que irão ser experimentadas, processo que se prolongará por duas semanas. Na

segunda semana e ate à semana 6, será dado início à experimentação das tecnologias/frameworks.

Nas semanas 5 e 6 irá ser feita a definição da arquitetura a ser proposta e, a partir da semana 7, será

dado início ao desenvolvimento da prova de conceito, processo que terá a duração de 7 semanas.

Nas semanas 12 e 13 será avaliado o desenvolvimento feito, até à data, na prova de conceito. Na

semana 14 será feita a análise aos resultados obtidos no desenvolvimento da prova de conceito e

as últimas três semanas serão usadas para a escrita da dissertação.

50


51


52

Referências

[Ado] CSS animations and transitions performance: looking inside the browser | Web Plat-form Team Blog. URL: http://blogs.adobe.com/webplatform/2014/03/18/css-animations-and-transitions-performance/.

[Ang] AngularJS: Developer Guide: Developer Guide. URL: https://docs.angularjs.org/guide.

[F+11] Yu Fan et al. Cascading style sheets. 2011.

[Fra13] B. Frain. Sass and Compass for Designers. Packt Publishing, 2013. URL: http://www.google.hr/books?id=shJEwk7y80oC.

[Goo13] Google. Supporting Multiple Screens | Android Developers, 2013. URL: http://developer.android.com/guide/practices/screens_support.html.

[HR1] Data-binding Revolutions with Object.observe() - HTML5 Rocks. URL: http://www.html5rocks.com/en/tutorials/es7/observe/.

[HR2] Offline - HTML5 Rocks. URL: http://www.html5rocks.com/de/features/offline.

[Htma] Custom Elements: defining new elements in HTML - HTML5 Rocks.URL: http://www.html5rocks.com/en/tutorials/webcomponents/customelements/.

[HTMb] HTML Standard. URL: https://html.spec.whatwg.org/multipage/embedded-content.html#the-source-element-when-used-with-the-picture-element.

[Htmc] HTML’s New Template Tag: standardizing client-side templating - HTML5 Rocks.URL: http://www.html5rocks.com/en/tutorials/webcomponents/template/.

[Htmd] Shadow DOM 101 - HTML5 Rocks. URL: http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/.

[LL] Zoran Lovrekovic e Tomislav Lovrekovic. Is html5 right technology for the develop-ment of business software applications?

[Man] Using Mocha JS, Chai JS and Sinon JS to Test your Frontend JavaS-cript Code | via @codeship. URL: http://blog.codeship.com/mocha-js-chai-sinon-frontend-javascript-code-testing-tutorial/.

53

http://blogs.adobe.com/webplatform/2014/03/18/css-animations-and-transitions-performance/

http://blogs.adobe.com/webplatform/2014/03/18/css-animations-and-transitions-performance/

https://docs.angularjs.org/guide

https://docs.angularjs.org/guide

http://www.google.hr/books?id=shJEwk7y80oC

http://www.google.hr/books?id=shJEwk7y80oC

http://developer.android.com/guide/practices/screens_support.html

http://developer.android.com/guide/practices/screens_support.html

http://www.html5rocks.com/en/tutorials/es7/observe/

http://www.html5rocks.com/en/tutorials/es7/observe/

http://www.html5rocks.com/de/features/offline

http://www.html5rocks.com/de/features/offline

http://www.html5rocks.com/en/tutorials/webcomponents/customelements/

http://www.html5rocks.com/en/tutorials/webcomponents/customelements/

https://html.spec.whatwg.org/multipage/embedded-content.html#the-source-element-when-used-with-the-picture-element



http://www.html5rocks.com/en/tutorials/webcomponents/template/

http://www.html5rocks.com/en/tutorials/webcomponents/template/

http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/

http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/

http://blog.codeship.com/mocha-js-chai-sinon-frontend-javascript-code-testing-tutorial/

http://blog.codeship.com/mocha-js-chai-sinon-frontend-javascript-code-testing-tutorial/

REFERÊNCIAS

[Mar10] Ethan Marcotte. Responsive Web Design, 2010. URL: http://alistapart.com/article/responsive-web-design, doi:10.11635/2319-9954/1/1/18.

[Mat] Introduction - Material design - Google design guidelines. URL: http://www.google.com/design/spec/material-design/introduction.html.

[Moc] Mocha - the fun, simple, flexible JavaScript test framework. URL: http://mochajs.org/.

[Osm12] Addy Osmani. Learning JavaScript Design Patterns. "O’Reilly Media, Inc.", 2012.

[Pet12] Jesper Petersson. Designing and implementing an architecture for single-page applica-tions in javascript and html5. 2012.

[PO] DSA PINA e LEMC OLIVEIRA. Ria-rich internet applications: Uma revisão dos prin-cipais expoentes da área.

[Pola] HTML Imports - Polymer. URL: https://www.polymer-project.org/platform/html-imports.html.

[Polb] Understanding Polymer - Polymer. URL: https://www.polymer-project.org/docs/start/everything.html.

[Sam13] Ana Isabel Sampaio. Responsive web design. 2013.

[Sas] Sass: Sass Basics. URL: http://sass-lang.com/guide.

[Sha] David Shapiro. Web Component Architecture & Development with AngularJS Buildingreusable UI components.

[Sin] Sinon.JS - Documentation. URL: http://sinonjs.org/docs/.

[Sit] Vendor-specific Properties - SitePoint. URL: http://www.sitepoint.com/web-foundations/vendor-specific-properties/.

[Sma] Declarative Programming And The Web | Smashing Magazine. URL: http://www.smashingmagazine.com/2014/07/30/declarative-programming/.

[W31] Web Animations 1.0. URL: http://www.w3.org/TR/web-animations/#use-cases.

[W3Ca] 5 Loading Web pages — HTML5. URL: http://www.w3.org/TR/html5/browsers.html#appcache.

[W3Cb] Service Workers. URL: http://www.w3.org/TR/service-workers/.

[W3S14] W3Schools.com. Browser Statistics, 2014. URL: http://www.w3schools.com/browsers/browsers_stats.asp.

[Web] Introduction to the template elements — WebComponents.org. URL: http://webcomponents.org/articles/introduction-to-template-element/.

54

http://alistapart.com/article/responsive-web-design

http://alistapart.com/article/responsive-web-design

http://www.google.com/design/spec/material-design/introduction.html

http://www.google.com/design/spec/material-design/introduction.html

http://mochajs.org/

http://mochajs.org/

https://www.polymer-project.org/platform/html-imports.html

https://www.polymer-project.org/platform/html-imports.html

https://www.polymer-project.org/docs/start/everything.html

https://www.polymer-project.org/docs/start/everything.html

http://sass-lang.com/guide

http://sinonjs.org/docs/

http://www.sitepoint.com/web-foundations/vendor-specific-properties/

http://www.sitepoint.com/web-foundations/vendor-specific-properties/

http://www.smashingmagazine.com/2014/07/30/declarative-programming/

http://www.smashingmagazine.com/2014/07/30/declarative-programming/

http://www.w3.org/TR/web-animations/#use-cases

http://www.w3.org/TR/web-animations/#use-cases

http://www.w3.org/TR/html5/browsers.html#appcache

http://www.w3.org/TR/html5/browsers.html#appcache

http://www.w3.org/TR/service-workers/

http://www.w3schools.com/browsers/browsers_stats.asp

http://www.w3schools.com/browsers/browsers_stats.asp

http://webcomponents.org/articles/introduction-to-template-element/

http://webcomponents.org/articles/introduction-to-template-element/

Arquitetura Front-end: Web Components, Single-Page...

Documents

Transcript of Arquitetura Front-end: Web Components, Single-Page...