Post on 22-Jun-2020
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
Problemas da Web Atual
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
Problemas da Web Atual
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
Problemas da Web Atual
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
Problemas da Web Atual
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
Problemas da Web Atual
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
Responsive Web Design
• 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
Responsive Web Design
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
Responsive Web Design
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
Responsive Web Design
• 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
Responsive Web Design
• 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
Responsive Web Design
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
Responsive Web Design
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
Single-Page Applications
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
Single-Page Applications
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
Single-Page Applications
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
Single-Page Applications
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
Single-Page Applications
• 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
Single-Page Applications
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
Single-Page Applications
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
Single-Page Applications
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
Single-Page Applications
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
Proposta de Trabalho
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
Proposta de Trabalho
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
Proposta de Trabalho
• 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
Conclusões e Trabalho Futuro
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
Conclusões e Trabalho Futuro
51
Conclusões e Trabalho Futuro
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
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