Análise Comparativa das Tecnologias

De uma forma sucinta, apresenta-se a Tabela 1 onde se reúnem as características mais relevantes para a selecção da tecnologia de base que melhor se adequa ao propósito deste trabalho.

Parâmetro Código Aplicação disponí- vel17 Código Fonte Plataformas suportadas

Conexão GUI Geração códigos

Informação do cliente

Active Print Sim Não Alguns modelos

Nokia e

Siemens18

Http ou https

Browser Site Não

ARToolKitPlus - Plata- forma PDA’s e telemóveis com câmaras Local - Aplicação -

Colorcode Não - Qualquer

dispositivo com câmara

(CCD/CMOS)

- - - -

PaperClick Não - Vários19 Http Browser - -

PrintAccess Sim Não Apenas Nokia 6630 ou 6681 Http Browser Site, limitado Não Semacode Sim Só Serires 60 Equipamentos com Java Mobile Edition e Symbian.

Http Browser Site e aplicação

Não

SpotCodes Sim Não Equipamentos com Java Mobile Edition e Symbian.

Bluetooth Browser Site Keywords fixas20

Tripcode Sim Sim Equipamentos com Java Mobile Edition e Symbian.21 Bluetooth Própria aplica- ção Aplicação Implementar no servidor

VisualCodes Sim Sim Nokias Séries 60 (Symbian v6.1 e v7.0s) Local ou bluetooth Própria aplica- ção Site Implementar no cliente e no servidor Tabela 1 – Resumo das características dos códigos visuais

17 _{As aplicações foram testadas com um Nokia 6600.} 18

Alguns modelos Séries 60: Nokia 3650, 3660, 6600, 6630, 6670, 6680, 7610, 7650 e Siemens SX1.

19 _{Vários modelos de dispositivos com câmara e, através de uma gateway específica, também possível com PC’s e telemóveis sem câmara.} 20 _{Apenas suporta algumas keywords fixas no URL codificado que, em run—time, são substituídas: “%USER%”, “%NUMCLICKS%”, “%CRC%”,}

“%MODEL%”, “%BRAND%”.

21

Em relação à estrutura da tabela apresentada, a coluna "Aplicação disponível" pretende indicar se os autores/representantes do código visual em causa disponibilizavam uma aplicação para leitura de códigos visuais. Em "Código Fonte" indica se, para além da aplicação, existia também o respectivo código fonte, cujas excepções são o caso da disponibilização de uma plataforma de desenvolvimento e, um outro caso, de apenas ser disponibilizado o código-fonte para um modelo particular de dispositivos. Na coluna "Plataformas suportadas" é efectuada referência às plataformas sobre as quais essa aplicação funcionaria. Em "Conexão" é mencionado o tipo de conexão que era utilizado para comunicar com o servidor ou a indicação "local" quando não havia necessidade de comunicação. Em "GUI" é indicado se a

interface

gráfica era própria da aplicação ou se utilizava recursos terceiros, como seja o

browser

do dispositivo. Na coluna "Geração de códigos" indica se existia possibilidade de gerar novos códigos, nesses casos, referindo onde poderiam ser gerados. Finalmente, em "Informação de cliente" indica-se se era possível, com essa aplicação leitora, obter informação sobre o cliente que estava a efectuar o pedido de conexão ao servidor.

As principais ilações da pesquisa e das experiências efectuadas sobre os vários tipos de códigos encontrados, e sintetizadas na Tabela 1, são as seguintes:

• Para o desenvolvimento de aplicações baseadas na tecnologia de códigos visuais, casos como os Colorcodes e os PaperClick não propiciam a sua aplicação em novos projectos por não existirem aplicações de teste, código-fonte, nem API’s disponíveis.

• A aplicação disponibilizada para ler códigos visuais Active Print é pertinente, uma vez que lê as duas normas mais comuns:

QR

e

Datamatrix

. No entanto, apenas proporcionam uma única aplicação (Glass), que implementa uma única funcionalidade, e é apenas executável em plataformas Symbian (mais concretamente nos modelos Séries 60 da Nokia). De forma idêntica, para ler

Datamatrix

, os códigos PrintAccess possuem uma aplicação de teste fechada (sem código fonte) e compatível somente com dois modelos da Nokia, o que limita o acesso à experiência por parte de um grupo alargado de pessoas que detêm outros dispositivos muito distintos dos apresentados.

• Os Semacodes, percursores dos códigos visuais e provavelmente os mais difundidos, permitem codificar qualquer tipo de URL representado num

Datamatrix

. No entanto, a aplicação descodificadora deste tipo de códigos,

Semacode Reader

, embora seja bastante flexível em termos de funcionalidades (pois abre o

browser

do dispositivo para aceder aos conteúdos do URL codificado), não permite recolher informação sobre o dispositivo cliente.

• O ARToolKitPlus é bastante flexível pois disponibiliza uma plataforma para o desenvolvimento de aplicações no campo do reconhecimento visual. Contudo, é necessário desenvolver o próprio mecanismo de reconhecimento que, em determinadas situações, poderá não ser justificável. Exige, ainda, que sejam disponibilizadas bibliotecas específicas, de forma a ajudar o programador a ocultar muitas das particularidades desse tipo de processamento.

• Os Spotcodes permitem obter dados que identifiquem os clientes (características do dispositivo móvel) através da codificação de algumas palavras-reservadas no próprio código visual aquando da sua geração. Não disponibilizam, no entanto, código-fonte e apenas permitem a geração de um número limitado de novas

tags

, tendo essas que ser geradas no

site

da empresa detentora da sua versão comercial, após um registo. Esta situação poderá causar alguma resistência, dificuldades ou mesmo entropia aos potenciais utilizadores de um protótipo independente.

• Os Tripcodes disponibilizam o código-fonte, quer das aplicações servidor (MobileSense e MobileEye) quer para o leitor das

tags

(TripReader) a instalar nos dispositivos clientes. O protocolo de comunicação utilizado é

bluetooth

obrigando, por um lado, a uma limitação do raio de acção mas, por outro, não implicando custos financeiros a potenciais utilizadores. É desenvolvido em linguagem Java, logo potencialmente suportado por qualquer dispositivo que implemente o ambiente Java para dispositivos móveis (KVM). Para além destes factos, disponibilizam também mecanismos (

scripts

) para ajudar na implementação de uma aplicação que gere novos

tripcodes

.

• Os VisualCodes permitem uma considerável panóplia de funcionalidades, com cinco aplicações distintas. Disponibilizam o código-fonte e estão mais evoluídos em relação à maioria dos restantes tipos de códigos, pois suportam também a utilização, por parte das aplicações de descodificação, de parâmetros adicionais como a distância do dispositivo ao código e a inclinação do mesmo. Como desvantagem, as aplicações apenas são suportadas em ambientes

Symbian

.

É, ainda, importante estabelecer algumas considerações acerca da instalação das várias aplicações em análise:

• Para instalar o

Glass.sis

, aplicação para teste dos códigos Active Print, pode efectuar-se o

download

do

site

ou solicitar directamente por SMS. Contudo, após instalação, é necessário

utilizar a conexão

internet

do dispositivo (GPRS, WAP, etc.) para obter uma

key

(chave de acesso) dos autores e, assim, validar a versão

trial

(experimental).

• Para instalar a aplicação de leitura dos PrintAccess é necessário aceder, pelo dispositivo móvel, ao URL fornecido;

• Para os Semacodes, procede-se ao simples

download

do

site

, para posterior instalação através do PC no dispositivo móvel (assumindo que o

download

não é efectuado directamente pelo dispositivo);

• Tanto os Spotcodes, como os Tripcodes ou os Visualcodes permitem o

download

do

site

, directamente para telemóvel ou por ficheiro de instalação. Os Spotcodes possibilitam ainda a solicitação por SMS da aplicação cliente (leitor de códigos) e os Tripcodes disponibilizam a parte “servidor”, a qual, após

download

, deverá ser configurada e recompilada.

Finalmente, quanto à conexão, poderia ser possível utilizar

bluetooth

, nos leitores de códigos que utilizem

http

para comunicar, desde que a arquitectura da solução inclua um equipamento tradutor dos pedidos (TCP/IP sobre

bluetooth

). Por exemplo, com a

bridge

Bluegiga22_{, esse tipo de tradução}

seria possível desde que cumulativamente:

• Se possua um Nokia Series60 (exemplos: Modelos 3650, 6600 ou 7650); • Se possua um

browser

no dispositivo (por exemplo Opera) e não a versão

default

“Serviços”;

• Se efectue a instalação da aplicação “Bluegiga Office Agent” (officeAgent.sis); e, • Se altere a conexão

default

do

browser

para a “bt access”.

Esta análise seria fulcral na selecção da tecnologia de suporte ao protótipo a desenvolver e estará devidamente descrita na secção 3.1.3.

No documento A adopção de códigos visuais como modelo de interacção (páginas 31-35)