Com o aumento do uso dos dispositivos móveis por parte dos utilizadores, houve a neces- sidade de adaptar os websites aos vários tamanhos de ecrãs. Um website em que os seus elementos se adaptam aos diferentes tamanhos de ecrãs é designado de responsive. Exis- tem dois métodos que os developers podem utilizar para que um website seja responsive, nomeadamente: Responsive Web Design (RWD) e Adaptive Web Design (AWD).
Esta secção foi escrita com base nos seguintes artigos: [19] e [14]. Responsive Web Design (RWD)
Responsive Web Design (RWD)é uma abordagem para o web design de sites que oferece uma experiência de visualização e navegação optimizada com o mínimo de redimensio- namento e scrolling, que é aplicada a vários dispositivos. Um site RWD muda os seus elementos na página consoante o tamanho de ecrã, utilizando apenas um único layout. Essa mudança é feita usando grids fluidas e proporcionais, imagens flexíveis, e CSS3 media queries.
Um site RWD usa as três seguintes regras:
1. A grid fluida requer que os elementos estejam em unidades relativas, como percen- tagens, em vez de unidades absolutas como pixels ou pontos;
2. As imagens flexíveis requerem que as suas unidades sejam também relativas, para evitar que estas saiam fora dos seus elementos HTML.
3. A utilização de media queries permite que a página use diferentes estilos de CSS de acordo com as características do dispositivo, tipicamente esses estilos são mudados consoante a sua largura.
Adaptive Web Design (AWD)
Ao contrário do RWD, o AWD apresenta vários layouts de acordo com o tamanho do dispositivo. O layout utilizado depende do tamanho do ecrã detetado. Tipicamente, as
aplicações web que utilizam o método AWD possuem layouts específicos para telemóveis, tabletse desktops. Ao detectar-se o tipo de dispositivo utilizado é selecionado o layout responsável por esse mesmo tipo de dispositivo.
Comparação entre RWD e AWD
Apesar de ambos os métodos terem como objetivo de melhorar a interação do utilizador com qualquer tipo de dispositivo, ambos apresentam vantagens e desvantagens compara- tivamente.
1. RWD é mais difícil de implementar - necessita de um esforço maior por parte do developeruma vez que o método RWD apenas tem um layout com todo o CSS e or- ganização do website, tendo que fazer por exemplo, várias media queries de forma a assegurar que funciona corretamente em qualquer tamanho possível. Geralmente é mais fácil desenvolver alguns layouts específicos para o website do que desenvolver apenas um layout que funcione em qualquer tamanho de ecrã.
2. AWD é menos flexível - No design Adaptive existem vários layouts para alguns tamanhos de ecrã. Caso um novo dispositivo com um novo tamanho de ecrã apa- reça, e não exista um layout para esse tamanho, então será necessário fazer um novo layout. Ao contrário, o design Responsive é mais flexível e por isso caso haja um novo dispositivo com um novo tamanho de ecrã, o website irá adaptar-se a esse novo tamanho, tendo que provavelmente apenas modificar o CSS do layout.
3. Sites RWD carregam mais rapidamente - Os websites Adaptive necessitam de carregar todos os layouts que se encontram no servidor, enquanto que os websites Responsive apenas necessitam de carregar um layout. Logo, o tempo de carrega- mento de todos os layouts necessários para um website que usa o método Adaptive é tipicamente maior em relação aos websites Responsive. Esta situação poderá nem sempre ocorrer, dependendo do número de páginas de cada método. Por exem- plo, se existir um website RWD com cem páginas em comparação com um website Adaptivecom dez páginas, o carregamento de apenas um layout será provavelmente maior do que o carregamento de vários layouts.
2.1.5
Frameworks
Para o desenvolvimento de Single Page Applications existem várias frameworks, tais como, Backbone.js, AngularJs, Ember.js, Knockout.js. Apenas são abordadas as fra- meworks Backbone.js e AngularJs, pois são atualmente as frameworks mais populares. Nesta secção, é feita uma breve introdução sobre a arquitetura MVC, e a descrição das duas frameworks. Esta secção foi escrita com base nos seguintes artigos: [4], [24], [3], [9], [6], [27], [32], [7] e [18].
Arquitetura MVC
Model - View - Controller(MVC) é um padrão de arquitetura de software que faz a se- paração da camada de dados (Model) com a camada de apresentação (View), utilizando um componente (Controller) para fazer a ligação entre estas duas camadas, como mostra a figura 2.8.
Figura 2.8: Representação da relação entre Model, View, Controller
O Model contém a lógica do negócio e funções que manipulam os dados da aplicação. A View é responsável pela apresentação do aspeto da aplicação de acordo com o estado corrente do Model. Por último, o Controller aceita e intercepta os pedidos do utilizador para atualizar a apresentação da View ou para atualizar o estado do Model.
O uso da arquitetura MVC no desenvolvimento de aplicações, apresenta um conjunto de vantagens, nomeadamente:
• Reaproveitamento de código e regras; • Facilidade de manutenção;
• Camada de persistência independente;
• Facilidade na implementação de camadas de segurança; • Facilidade na atualização da interface da aplicação.
Esta arquitetura é também utilizada para o desenvolvimento de aplicações web, onde a página HTML representa a View, e o código que gera os dados dinâmicos para o HTML é o Controller. O Model tipicamente é responsável por representar os dados que se en- contram na base de dados. A grande das maiorias das frameworks desenvolvidas para criar SPA, basearam-se na arquitetura MVC. Contudo, existem frameworks que seguem a arquitetura MV*, uma vez que não apresentam um Controlller. Isto porque a lógica que
opera a aplicação está presente na View. Para além disto, este tipo de arquitetura apre- senta outros componentes, como por exemplo Collections e Routers, como é o caso da frameworkBackbone.js.
Backbone.js
Backbone.js é uma framework para desenvolver aplicações web dinâmicas sobre a ar- quitetura MV*. Esta framework permite representar dados do servidor como Models, garantindo suporte à validação, exclusão e gravação no servidor. O Model é apresen- tado ao utilizador através de uma View, e esta manipula o Model através de uma interface RESTful JSON. A View pode definir callbacks para eventos do Model, que podem ser eventos relacionados com a mudança de estado dos atributos do Model, e que através desses callbacks a View mantém o estado da sua representação sempre atualizado. Com esta abordagem obtém-se um código que não inspeciona e nem depende de todo o DOM da aplicação para atualizar manualmente o HTML, uma vez que as Views estarão sempre atualizadas de acordo com as mudanças verificadas nos Models.
O Backbone.js é conhecido pela sua leveza e robustez, e a sua única dependência é a biblioteca Underscore.js, que por sua vez é dependente da biblioteca jQuery para intera- ções com o DOM. A biblioteca Underscore.js define templates para as Views, contendo elementos HTML e variáveis de template com a seguinte sintaxe:
1 . <%= n o m e _ v a r i a v e l %>
As Views passam as informações dos dados para representar nos templates em formato JSON. Por sua vez, os templates são responsáveis por corresponder os dados às variáveis de template. Na figura 2.9 está representado um template de uma View, responsável por fazer a iteração dos dados recebidos a partir da respetiva View. No final é apresentado uma lista com a descrição contida nos dados iterados. Este processo corresponde à ren- derização de uma View.
Figura 2.9: Exemplo de um Template de uma View Os principais componentes e ações do Backbone.js são os seguintes:
1. Models e Views - permitem manter a lógica do negócio separada da interface do utilizador. As tarefas responsáveis pelos Models são: coordenar os dados e a lógica
do negócio; carregar e guardar dados a partir do servidor; e emitir eventos quando os dados mudam. Enquanto que as Views contêm listeners para modificações que ocorrem nos Models; lidam com os inputs e as interações do utilizador; e enviam inputscapturados para os Models.
Por exemplo, considerando uma aplicação para a gestão de funcionários que per- mite a visualização da lista e dos detalhes dos funcionários. Quando um utilizador clica em obter os detalhes de um funcionário, esse evento é capturado pela View que por sua vez inicializa o Model (que irá conter os dados do utilizador) e faz um pedido ao servidor. Após a resposta do servidor, o Model é atualizado com os novos valores do funcionário. A View deteta que houve uma mudança no Model, e faz a renderização com os detalhes do funcionário. A figura 2.10 representa um exemplo deste tipo de interações.
Figura 2.10: Interação entre os models e as views.
2. Collections - uma Collection é um conjunto de models, responsável por carregar e guardar novos models para o servidor, fornecendo funções auxiliares para a realiza- ção de agregações ou cálculos.
Continuando o exemplo anterior, um utilizador ao adicionar um funcionário à sua aplicação, a View responsável por isso, irá detetar esse input e inicializar um novo Modelpara adicionar na base de dados. Assim que os detalhes do Model sejam in- seridos, a View deteta que foi adicionado um novo funcionário e recebe uma coleção com os detalhes de todos os funcionários. A figura 2.11 representa esse exemplo.
3. Renderização de Views - cada View gere a renderização e a interação do utilizador dentro do próprio DOM. As Views refletem os dados que os Models contêm. Existem duas formas de uma View ser renderizada. A primeira é quando um utili- zador realiza uma ação e espera que a mesma View seja novamente renderizada. A segunda é no caso de quando um utilizador clica, por exemplo num link, e os dados obtidos do servidor são representados por outra View. A figura 2.12 representa estas duas formas de renderização.
Figura 2.12: Representação da Renderização de Views
4. Routing com URLs - Nas aplicações web queremos providenciar URLs linkables, marcáveise partilháveis dentro da própria aplicação. Usamos o Router para atuali- zar o URL do browser sempre que o utilizador atinja um novo “lugar” na aplicação, em que pode querer marcar ou partilhar. Por outro lado, o Router consegue dete- tar mudanças no URL e pode dizer à aplicação exatamente onde se encontra. Por exemplo, se um utilizador clicar num link e este contenha a hashtag books (#books), é verificado a que Router pertence o “#books”. Assim que é detetado, é renderizada uma nova view. A figura 2.13 representa esse exemplo.
AngularJs
AngularJs é uma framework para desenvolver aplicações web dinâmicas sobre a arquite- tura MVC. Uma aplicação desenvolvida por AngularJs é definida por Modules que podem depender uns dos outros. Permite adicionar às páginas HTML novos atributos ou tags e expressões designados de Directives. Os Controllers são responsáveis pelo comporta- mento da aplicação, que ajudam a estruturar e a testar o código JavaScript mais facil- mente. Por último, o código pode ser facilmente fatorizado em Services que podem ser chamados nos Controllers.
O AngularJs é composto principalmente por:
1. Expressões - A fim de criar Views numa aplicação, o AngularJs permite executar expressões diretamente dentro das páginas HTML. A figura 2.14 representa uma expressão muito básica da soma entre dois números, em que o resultado é compu- tado dentro de quatro chavetas (ligação de dados).
Figura 2.14: Expressoes
2. Directives - As Directives são elementos incorporados e definidos no HTML, de forma a que a manipulação do DOM seja mais transparente e/ou para adicionar novos comportamentos às tags existentes. Um exemplo de uma Directive é o “ng- repeat”, que é utilizada para fazer iterações sobre um array e renderiza um template para cada elemento do array. Na figura 2.15 a Directive “ng-repeat”, faz iterações sobre o array names, em que para cada iteração faz renderização de um nome.
Figura 2.15: Diretiva ng-repeat
3. Controllers - O Controller é responsável pelo comportamento da aplicação. São usados para inicializar e/ou adicionar comportamentos à variável “$scope” e per- mitem fazer a comunicação com a View. Os controllers nunca devem ter nada re- lacionado com o DOM. A Directive “ng-controller” é utilizada para definir em que
parte do documento HTML será utilizada. Na figura 2.16, é exemplificado como o “$scope”, permite fazer a ligação entre a View e o Controller, em que o objetivo é renderizar o primeiro e o último nome de uma pessoa. Para isso, o Controller é inicializado na <div>, e a variável “$scope” é definida dentro da função “myC- trl” do Controller. Esta função é responsável por atribuir os valores às variáveis “firstName” e “lastName”, que serão renderizadas na View.
Figura 2.16: Diretiva ng-controller
4. Modules - Os Modules são componentes que inicializam e encapsulam os Control- lers, Directives, Services e Routes e são definidos pela Directive “ng-app”. A figura 2.17 representa um exemplo de um Module. Para criar um novo Module utiliza- mos a chamada “var app = angular.module("myApp", [])”. O primeiro parâmetro corresponde ao nome do Module, e o segundo parâmetro é um array com as depen- dências de que este Module está dependente. Neste caso o array está vazio, logo o Module corrente não depende de outros Modules. Para que o Module conheça o Controllerutilizamos a chamada “module.controller(...)”.
5. Services - Os Services são: Singletons, ou seja, cada componente dependente de um serviço obtém uma referência para uma única instância gerado pela serviço; lazily instantiated, isto é, o AngularJs apenas faz uma instância de um serviço quando uma componente da aplicação depende disso. Os componentes podem ser utiliza- dos para partilhar informações entre Controllers, servir como comunicação com o servidor e também para ser a camada que contém a lógica do negócio.
6. Routers - Esta componente permite criar diferentes URLs para diferentes páginas numa aplicação. Providenciam URLs linkables, marcáveis e partilháveis dentro da própria aplicação. Um Router é especificado no URL depois do símbolo hashtag. Na figura 2.18 é apresentado um exemplo de dois Routers, uma para os utilizadores e o segundo para outros Routers que são redirecionados para a página de erro. Por exemplo, se o URL acedido for “http://domain/#users”, o AngularJs irá carregar a View “users.html” e o Controller “UsersCtrl”. Para qualquer outro URL irá ser carregada a View “error.html”.
Figura 2.18: Representação de duas routes
O AngularJs apresenta o conceito de biding bidirecional ilustrado na figura 2.19. Em primeiro lugar o template (código HMTL com marcadores e/ou diretivas adicionais) é compilado no browser, em que a sua compilação gera uma View. Quaisquer modificações na View são refletidas imediatamente no Model, e quaisquer modificações no Model são propagadas na View. O Model é a única fonte com os dados para o estado da aplicação, o que simplifica a programação do Model para os developers. A View é uma simples projeção instantânea do Model. Devido à View ser uma projeção do Model, o Controller é completamente separado da View. Isto faz com que os testes sejam mais rápidos e organizados porque é fácil testar o Controller de forma isolada sem a dependência da Viewe do DOM/browser.
Figura 2.19: Binding Bidirecional Backbone vs AngularJs
Estas duas frameworks têm muitos aspetos em comum: ambas são opensource, e tentam resolver o problema de desenvolver SPA usando o design MVC e MV*. Ambas apresen- tam os conceitos de Models, Views, Events e Routing.
Na tabela 2.1.5 é feita uma comparação entre as duas frameworks:
Backbone.js AngularJS
Comunidade Pequena Grande
Tamanho da Framework Mais Leve Mais Pesada
Templating Depende de Terceiros
(ex: Underscore.js)
Não tem dependências
Aprendizagem Mais Fácil Mais Difícil
Arquitetura MV* MVC
Performance Mais Rápida Mais Lenta
Ligação de Dados
(Data Biding) Não Usa Bidirecional
Bootstrap
O Bootstrap é uma framework open-source usada no front-end para ajudar os developers a desenvolverem aplicações web responsivas usando o método RWD. Para além de conter os vários elementos de CSS, o Bootstrap apresenta um diversidade de componentes em JavaScript (jQuery) que ajudam o developer a implementar uma grande variedade fun- cionalidades, como por exemplo: tootlip8, menu-dropdown, modal, carousel, slideshow, etc. . . Esta framework é muito popular entre os designers e por isso existem muitas biblio- tecas e plug-ins desenvolvidos para esta framework. A figura 2.20 apresenta a disposição de três colunas com diferentes tamanhos num desktop. Ao usar as classes da framework
as três colunas irão adaptar-se aos diferentes tamanhos de ecrã. A figura 2.21 apresenta a disposição das três colunas num dispositivo com a largura de “790 pixels”.
Figura 2.20: Disposição de três colunas num desktop
Figura 2.21: Disposição de três colunas num dispositivo móvel