F IGURA 13: O PROTOCOLO HTTP, RESPONSÁVEL PELA COMUNICAÇÃO ENTRE O BROWSER DO UTILIZADOR E O SERVIDOR WEB

O W3C define HTML como uma linguagem de publicação de conteúdo, como texto, imagem, vídeo e áudio, entre outros, na web.

Abreu entende HTML como uma linguagem que permite a construção de páginas, através de conjuntos de elementos, vulgarmente conhecidos por tags, utilizados para descrever apresentar uma página web (Abreu, 2012).

Ao longo dos anos o HTML foi evoluindo e foram lançadas várias versões. Contudo, não existiam padrões e cada um criava á sua maneira. De forma a evitar que a web fosse construída em base proprietária, com formatos incompatíveis e limitados, surgiu em 1994 o World Wide Web Consortium (W3C).

Em 1997, o W3C lança a versão 3.2 do HTML, criando assim um standard, fazendo com que cada browser reconheça as páginas HTML da mesma forma, deixando de ser necessário criar uma página diferente para cada um e desta forma reduzir custos e finalmente tornar o HTML interoperável. Ainda em 1997, o W3C anunciou o HTML 4.0 (W3C, 1997). Com o lançamento da versão 4.0 surgiram alguns erros, corrigidos alguns meses depois, aquando o lançamento do HTML 4.01. Esta versão trouxe algumas melhorias: otimização da acessibilidade, reconhecimento de scripts, melhor controlo da estrutura de tabelas, melhor indexação aos motores de busca, suporte a objetos, entre outras novidades. Por fim, surgiu em 2000 o XHTML (Extensible HyperText Markup Language), juntando o padrão do HTML com a extensibilidade do XML (eXtensible Markup Language).

32

Contudo, o grande marco do HTML ocorreu em 2008 com o início do HTML 5, que promete revolucionar o mundo da Internet.

2.2.2- A nova versão: HTML5

Nos dias de hoje é fundamental estar sempre ligado à Internet, por questões profissionais ou de entretenimento. Desde 2010 o número de acessos à web através de dispositivos móveis duplicou, havendo cada vez mais utilizadores a ligarem-se através de smartphones ou tablets, em qualquer lado (Vedor, 2012).

O HTML 4.01 apesar de garantir uma quase interoperabilidade, não era suficiente e perfeito. Possuía várias fragilidades que neste tipo de dispositivos são cruciais: Os programadores criavam as páginas sem grande cuidado, com estruturas complexas e muitas das vezes recorriam a plug-ins que não tinham suporte em dispositivos móveis para incorporar ficheiros multimédia, como por exemplo o Adobe Flash, Apple QuickTime e o Microsoft Silverlight.

Segundo Pilgrim, o HTML 5 é a próxima geração de HTML, substituindo os ultrapassados HTML 4.01 e XHTML 1.0 e 1.1 (Pilgrim, 2010). É também uma tecnologia que introduz novos recursos que são necessários para criar aplicações web modernas. Na opinião do mesmo autor, durante anos os programadores de páginas web utilizaram recursos que nunca tinham sido aprovados ou documentados, tornando assim essas páginas suscetíveis à incompatibilidade quando processadas por diferentes browsers.

McDaniel afirma que o HTML 5 é baseado nas mesmas tecnologias, mas possui ferramentas poderosas de forma a criar a próxima geração de sítios, com o auxílio das CSS3 e do JavaScript, de forma a construir sites mais interativos e com movimento (McDaniel, 2011).

Após o lançamento da versão 4.01 do HTML, o W3C começou a preparar uma versão baseada em XML e HTML, que iria constituir o XHTML 2.0. Ao mesmo tempo, o grupo WHATWG (Web Hypertext Application Technology Working Group), que não concordava com o rumo que o W3C queria dar ao HTML, começou a preparar aquilo que hoje conhecemos como HTML 5. Em meados de 2008 o W3C acabou por ceder e

33

unir forças com o projeto proposto pelo WHATWG e desde aí ambos os grupos têm trabalhado em conjunto no standard que promete revolucionar a web.

O W3C definiu como quatro princípios chave de conceção do HTML 5 a compatibilidade, a utilidade, a interoperabilidade e o acesso universal (W3C, 2007):

 Compatibilidade: Existem alguns elementos que estavam presentes em versões anteriores do HTML, que agora deixam de ser utilizados. Uma aplicação deverá ser capaz de ser processada da melhor forma possível em browsers mais antigos. Além disso, evolução não é revolução. Existem já várias funcionalidades que não necessitam de ser recriadas, evitando-se assim reinventar a roda.

 Utilidade: Uma aplicação web deverá ser utilizada da melhor forma para todos os fins pretendidos. O grupo de trabalho do HTML 5 pretende enfrentar e eliminar definitivamente os erros de versões transatas e assegurar que os recursos funcionem com o modelo de segurança da web.

 Interoperabilidade: Outra vontade relacionada com o HTML 5 é permitir que possa ser processado em todos os browsers mais utilizados. Deverá ser uma linguagem reconhecida pela simplicidade de cada recurso e permitir que os erros sejam tratados, reduzindo assim o risco de problemas da aplicação.

 Acesso universal: Este princípio está, em parte, relacionado com o anterior. Uma aplicação web deverá ser capaz de trabalhar em diferentes plataformas, dispositivos e meios de comunicação, independentemente de sistemas operativos, resoluções de tela e diferentes arquiteturas. Deverá também permitir a publicação em todos os idiomas e permitir que pessoas com algum tipo de capacidade reduzidas, independentemente da habilidade ou capacidades físicas, consigam também usá-lo.

O HTML 5 inclui também recursos que não são diretamente controlados pelo WHATWG ou pelo W3C, como por exemplo a API de Geolocalização. Esta API está a ser desenvolvida pelo GWG (Geolocation Working Group) e, por ser parte da evolução

34

da web moderna, é associado ao HTML 5, fornecendo-lhe recursos imprescindíveis para uma maior experiência por parte do utilizador.

Por ser uma tecnologia ainda em desenvolvimento, a lista de recursos definidos no HTML 5 está sempre a ser alterada, quer seja para adicionar ou melhorar recursos já existentes, sempre com o objetivo de simplificar. Os principais recursos que o HTML 5 nos oferece:

Semântica: Oferece uma forma mais simples para a construção de um layout

semântico. É possível construir um layout de uma página sem recurso às antigas tags <div>, anteriormente usado para delimitar secções de uma página, utilizando novos elementos estruturais como o <header>, <nav> ou <footer>, que criam uma área destinada, respetivamente, para o cabeçalho, área de hiperligações e rodapé;

Formulários mais ricos: uma das principais vulnerabilidades de um sítio são os

campos de introdução de dados por parte do utilizador. No HTML 4, é necessário validar esses dados no lado do servidor e, para proporcionar uma melhor experiência ao utilizador, também do lado do cliente, que poderia ser conseguido recorrendo ao JS.

Na versão 5 do HTML, estes formulários foram revistos e é possível restringir os campos para formatos de valores específicos, como números de telefone, intervalos de valor ou até mesmo um formato definido pelo próprio utilizador, dispensando desta forma a verificação através do JS;

Os formulários HTML passaram a ter também alguns novos tipos de campos de formulário, como os sliders e data, e também atributos como o placeholder e o autofocus, responsáveis por pré-definir um valor padrão num determinado campo e selecionar automaticamente um deles quando a página é carregada.

Novo suporte para elementos de vídeo e áudio: há algum tempo atrás, a

multimédia tinha a sua presença na Internet quase que restrita a formatos mais leves, como o MIDI ou os GIFs animados. Com a evolução da largura de banda, começou a ser possível suportar-se formatos mais pesados e consequentemente com maior

35

qualidade, como o MP3 ou AVI. Contudo, para os incorporar nas páginas web era necessário recorrer à instalação de plugins de terceiros no cliente, como por exemplo o Adobe Flash ou o Microsoft Silverlight.

Em 2007, Anne Van Kesteren comunicou ao WHATWG que a empresa Opera se encontrava a desenvolver um novo mecanismo de vídeo, que primava pela simplicidade e era idêntico ao antigo elemento (Kesteren, 2007).

Abreu comenta que o termo “vídeo” é, na maior parte das pessoas, automaticamente associado, pela maior parte das pessoas, a ficheiros nos formatos AVI ou MP4, quando na realidade estas designações apenas identificam o formato do contentor (Abreu, 2012). Um contentor pode conter vários elementos no seu interior, como clips de vídeo e áudio, título, informações sobre o episódio, entre outros, e limita- se a gerir a organização desses elementos. O armazenamento destas faixas de vídeo e áudio dentro dos contentores é possível devido àquilo a que chamamos “codificação”, com recurso a codecs para a codificação e posterior descodificação dos mesmos. Abreu afirma ainda que atualmente a especificação do HTML 5 não impõe restrições em relação aos codecs que devem ser suportados nos browsers, sendo que o Mozilla Firefox, Google Chrome e Opera suportam o codec de vídeo Theora e o codec de áudio Vorbis, em contentores Ogg.

Segundo Peter Lubbers, os novos elementos de áudio e vídeo permitem adicionar novas opções multimédia sem a necessidade de plug-ins externos, proporcionando assim aos programadores uma API comum, integrada e programável, que pode ser utilizada para criar aplicações mais atraentes (Lubbers, Salim, & Albers, 2011).

Nas versões anteriores do HTML, a solução para incorporar vídeos ou áudio em páginas web passava pela utilização do elemento <object>. Contudo, devido às diversas incompatibilidades entre os browsers, esse elemento requeria o elemento <embed>. Durante anos essa foi a solução, contudo não era a melhor, pois implicava muitas das vezes duplicar parâmetros e usar comandos demasiado complexos e confusos. O HTML5 veio assim simplificar esses dois elementos, fornecendo os elementos <vídeo> e <audio>, com valências mais simplistas.

36 API de Geolocalização: Apesar de não ser uma API diretamente controlada e

desenvolvida pelos grupos de trabalho do HTML 5, faz parte da evolução da web moderna, disponibilizando recursos capazes de proporcionar uma experiência mais rica ao utilizador.

Existem várias estratégias de marketing, que tentam cativar os utilizadores a adquiri determinados serviços ou produtos. Uma estratégia que está a crescer a um ritmo elevado, recorre à geolocalização, permitindo desta forma que os anúncios sejam contextualizados e cheguem a pessoas que realmente poderão necessitar deles. “Muitos sites oferecem anúncios específicos de acordo com o dia, a hora, a localização geográfica do utilizador, etc.“ (Rita & Oliveira, 2006). Um bom exemplo é quando um utilizador efetua uma pesquisa num motor de busca, utilizando a expressão “restaurante” e nos resultados surgem em primeiro lugar, os restaurantes que são da sua região. A posição geográfica do utilizador é determinada e representada através de um par de coordenadas: a latitude e a longitude.

A API de geolocalização do HTML 5 requer autorização do utilizador para obter as suas coordenadas de localização e permite não só determinar a posição atual do utilizador como também verificar, em intervalos regulares, se essa posição se altera, utilizando o método watchPosition.

Canvas: Até agora, para representar gráficos mais avançados era necessária a

utilização de plug-ins, como o Adobe Flash ou o Microsoft Silverlight. O HTML5, mais uma vez inovou e procurou simplificar o processo, adicionando o elemento <canvas>.

Originalmente criado pela Apple, em 2004, para o MAC OS X e posteriormente para o Safari, o canvas foi adotado pela especificação desta tecnologia. Chuck Hudson diz que o coração do canvas é formado por dois componentes (Hudson & Leadbetter, 2011): o canvas do HTML e o JS, para executar operações. Tal como acontece com um pintor, a tela fica em branco até que ele decida começar a utilizar os pincéis e as ferramentas disponíveis para criar a sua obra de arte. Da mesma forma, o JS fornece-nos as ferramentas necessárias para criar uma panóplia de projetos com o canvas.

Remy Sharp afirma que esta é uma das maiores partes da especificação do HTML5, tendo até sido escrito num documento à parte dela, não deixando no entanto de fazer parte da mesma (Lawson & Sharp, 2010). Já Steve Fulton acredita que o canvas seja o elemento mais interessante do HTML5 e define-o como um bitmap de modo

37

imediato (immediate mode) que cria uma superfície retangular, por omissão com 300 pixéis de largura e 150 pixéis de altura, que pode ser manipulada com recurso a JS (Fulton & Fulton, 2011). Abreu afirma que immediate mode se refere à forma como os pixéis são renderizados nesta superfície, sendo neste caso necessário criar o código JS dos elementos gráficos aos quais se pretende fazer o rendering (Abreu, 2012). Uma característica deste elemento é não possuir “memória”, obrigando a fazer novamente o rendering dos elementos sempre que seja necessário atualizá-lo. O facto deste elemento recorrer a um bitmap immediate mode, torna-o muito diferente do Flash, Silverligh e SVG, que operam em retained mode. Este modo, em vez de fazer o rendering diretamente, atualiza o estado interno da biblioteca gráfica, ou seja, ao contrário do immediate mode, é mantida uma lista dos objetos presentes na superfície e esses objetos possuem propriedades capazes de influenciar o seu comportamento (ex: coordenadas X e Y, tamanho, cor, etc.). Este modo de bitmap afasta o programador de operações de baixo nível, mas proporciona-lhe menos controlo sobre o processamento final na superfície (Gu & He, 2012).

Lubbers refere que o canvas suporta as mesmas operações bidimensionais que os sistemas operacionais e estruturas mais modernas e que quem já tenha desenvolvido para esses sistemas não irá sentir dificuldades a adaptar-se (Lubbers et al., 2011). Por outro lado, quem nunca utilizou estes sistemas irá ficar agradavelmente surpreendido com o quão mais poderosa é esta tecnologia quando comparada ao que foi feito nas CSS, durante muitos anos, pelos programadores.

De acordo com Rob Hawkes não se desenha diretamente na API do Canvas, mas sim num contexto bidimensional que ele nos proporciona (Hawkes, 2011). Este contexto permite-nos executar incontáveis funcionalidades (Fulton & Fulton, 2011):

- Criar e modificar desenhos bidimensionais, textos e imagens bitmap; - Aplicar cores, rotações, opacidade e manipular pixéis;

- Criar diferentes tipos de linhas, curvas e caixas e exibir gráficos; - Criar e modificar animações avançadas;

- Deteção de colisões;

- Incorporar e manipular vídeo e áudio;

38

- Desenvolver gráficos de jogos animados. Apesar de ainda não haver um contexto tridimensional, existem já várias implementações, como o WebGL, mas nenhuma adotada pelo standard do HTML5 (Ferreira & Eis, 2011). Contudo, isso não impede os programadores de explorarem maneiras de utilizar técnicas 3D e criar aplicações multiplayer.

Com o recurso ao JS é possível criar animações complexas, incluindo fundos interativos para sítios, elementos de navegação, ferramentas gráficas, eventos de rato e teclado, captura de frames de um vídeo e até mesmo jogos com elevada interatividade.

Devido ao poder do elemento canvas e da globalidade do HTML5, a Apple descontinuou, em Abril de 2010, o Adobe Flash em dispositivos móveis e decidiu apostar no HTML5 (Jobs, 2010). Esta decisão deve-se principalmente a questões tecnológicas e facilidade de uso do HTML5. Em primeiro lugar, o HTML5 é um standard aberto e não depende de plugins de terceiros, como era o caso do Flash. Em segundo, o Flash não proporcionava uma “web completa” aos utilizadores de dispositivos Apple, porque 75% dos vídeos da web são em Flash. O terceiro contra da Apple prende-se com questões de segurança, confiabilidade e desempenho, enquanto o quarto fator aponta a um gasto excessivo de bateria dos dispositivos móveis. O quinto motivo refere-se ao facto de o Flash ter sido desenvolvido para computadores e para ser utilizado com um rato, não para ecrãs táteis. Por último, o Flash é multiplataforma e a Adobe não pode depender de terceiros para decidir quando distribuir as ferramentas aos programadores. Estes seis motivos fizeram com que a Apple pretendesse abandonar o passado e apostar no HTML5, uma tecnologia emergente e que vai dominar os dispositivos móveis. Em consequência, em Novembro de 2011 a Adobe descontinuou o desenvolvimento do Flash para browsers de dispositivos móveis, admitindo que o HTML5 é a melhor solução para eles (Winokur, 2011).

O elemento canvas trás, finalmente, uma forma nativa de desenhar nos browsers sem necessidade de recorrer a aplicações externas, é poderosa ao nível de desenvolvimento e adivinha-se que os programadores o testarão até aos seus limites (Lawson & Sharp, 2010).

Armazenamento de dados: Uma atividade fundamental para qualquer aplicação

web é a possibilidade de armazenamento de dados. Abreu afirma que, nas versões anteriores do HTML, a única forma capaz de armazenar pequenas quantidades de dados a partir de uma página HTML eram as cookies (Abreu, 2012). Os cookies podiam ser

39

utilizadas para guardar um valor, guardar nomes de utilizadores, preferências, datas de autenticação, entre muitas outras possibilidades. Elcio Ferreira desacredita-as, por terem uma interface complexa, envolvendo cálculos complexos com datas e controlo de nome de domínio e também porque estavam limitadas a apenas 4KB de informação (Ferreira & Eis, 2011). Remy Sharp também considera que os cookies não são a melhor opção, achando-as uma ”porcaria ou lixo”, pois têm uma série de problemas que fazem com que seja doloroso trabalhar com elas, preferindo procurar bibliotecas de JS capazes de as substituir (Lawson & Sharp, 2010).

Chuck Hudson escreve que alguns conjuntos de dados podem melhorar a experiência do utilizador se os cookies poderem ser armazenados e recuperados localmente, em vez de serem recuperados do servidor de cada vez que são utilizados (Hudson & Leadbetter, 2011). Com o HTML5 surgem duas novas formas de armazenamento local: Web Storage e Web SQL Databases.

O Web Storage, baseado no conceito dos cookies, permite o armazenamento de até 5Mb de informação por domínio e, ao contrário dos cookies, não são propagados para o servidor através de pedidos HTTP, funcionando localmente. Esta funcionalidade possui dois tipos de storage: localStorage e sessionStorage.

Elcio Ferreira e Abreu comparam estes dois tipos de Web Storage (Abreu, 2012; Ferreira & Eis, 2011) : enquanto o localStorage armazena localmente os dados sem um limite de tempo de vida e a sobreviver entre sessões, podendo ser recuperados numa outra página carregada a partir de outra janela, o sessionStorage apenas mantém esses dados durante a sessão na página atual, perdendo-se todos os dados armazenados quando a página é encerrada, sem a possibilidade de serem recuperados numa utilização futura. Ambos os tipos de armazenamento utilizam um objeto do tipo Storage, que se comporta como um dicionário, onde os dados são mantidos no formato chave/valor, sempre do tipo string. Caso se pretenda armazenar um valor que não seja do tipo string, é necessário seriá-lo numa string antes de o armazenar.

O Web SQL Databases é uma outra forma de armazenar dados no cliente mas, ao contrário do Web Storage, não se baseou nos cookies mas sim nas tradicionais bases de dados SQL. Remy Sharp analisa este tipo de armazenamento e afirma que é necessário saber utilizar a linguagem SQL, mais propriamente SQLite, pois é a ela que o Web Storage recorre para o armazenamento (Lawson & Sharp, 2010). Quanto aos limites de armazenamento, afirma que a documentação não é clara e que cada browser impõe os

40

seus limites sendo, por norma, 5Mb por domínio. Infelizmente esta forma de armazenamento ainda não é suportada por muitos dos browsers, sendo que atualmente apenas o Opera, o Chrome e o Safari a suportam (Deveria, 2013; Lawson & Sharp, 2010).

Estas duas novas formas de armazenamento prometem bastante e Hogan considera que são fáceis de usar, incrivelmente poderosas, e razoavelmente seguras (Hogan, 2011).

Existem muitas outras novidades no HTML5 que, por serem em tão elevado número e por não serem objeto do trabalho, não é possível abordar nesta dissertação. O HTML5 prometia e já provou que possui todas as funcionalidades para revolucionar o desenvolvimento de aplicações web, quer através das funcionalidades explicadas anteriormente, como o canvas ou o novo suporte para elementos áudio e vídeo, quer também pelas funcionalidades não abordadas, mas com igual importância, como a facilidade das interfaces drag and drop, aplicações offline ou da microdata.

As opiniões sobre esta tecnologia são, geralmente, positivas. Steve Jobs, fundador da Apple, apoia o HTML5, por permitir que os programadores web criem gráficos avançados, tipografia, animações e transições independentes de plug-ins externos, como não acontece com o Flash, da Adobe (Jobs, 2010); Para Dion Almaer (Almaer, 2010), co-fundador da Ajaxian.com, principal comunidade de Ajax, a revolução do Ajax foi um hack e, com os browsers HTML5, temos finalmente um fantástico runtime. John Harding, Engenheiro de Software do Google, afirma que na empresa estão entusiasmados com o esforço do HTML 5, principalmente com a tag <video>, que tornou possível a reprodução dos vídeos do Youtube através da interface em HTML5 (Harding, 2010).

2.3- Android

2.3.1- Introdução e estatísticas

Durante os últimos anos existiram várias tentativas para transformar o software de dispositivos móveis em open source (e.g. Maemo, Debian Mobile, Symbian OS).

41

Existiam também alguns SO closed source (e.g. BlackBerry OS, Microsoft Windows Mobile) mas nenhum se conseguiu assumir como perfeito. Apesar do Symbian OS dominar o mercado de SO para dispositivos móveis (Hall & Anderson, 2009), nunca foi visto como completo e o seu ambiente para desenvolvimento de aplicações era complexo. Em 2007, a forma como os smartphones eram vistos mudou, após o lançamento do iPhone. Desenvolvido pela Apple e com o sistema operativo iOS, dispunha de uma interface tátil baseada na orientação do dispositivo, tornando-se no primeiro SO móvel com uma grande comunidade de aficionados e transformou-se num