na crista da onda: anfíbio

depois do fracasso e do sucesso parcial do desenvolvimento para bada, procurei descobrir como seria desenvolver um widget para o telemóvel. surpresa! os widgets não passam de páginas web! apesar de já ter confessado não gostar de programação por eventos, por algum motivo, javascript e html são coisas totalmente diferentes, para mim. talvez por associar scripting tão potente a linguagem de marcação de forma tão simples. não sei, mas gosto!

uma coisa que dava jeito era poder ter no ecrã principal atalhos para aplicações. más notícias. para a maioria, não é possível. a samsung implementa uma api bondi, mas esta permite o acesso a escassas aplicações. claro que a samsung tem acesso a todas, com widgets até para aceder à aplicação da loja, que nem sequer consta na documentação. para as aplicações que interessa não deixam aceder…

além de aceder ao telemóvel, também seria interessante o acesso directo à web. é muito fácil criar pequenos atalhos no ecrã, estilo bookmarks. tive a ideia de ir mais longe, procurando poupar espaço comparativamente a essa solução. um pequeno widget do estilo da google, que vem no telemóvel, mas com botões configuráveis, e potencialmente ilimitados. surge o All Terrain Search:

a ideia é simples. uma caixa de texto e botões. se existir texto nessa caixa, o botão faz uma pesquisa no site. se a caixa estiver em branco, o botão redirecciona para a homepage. 4 botões não são lá grande coisa, portanto um scroll permite ver mais 4, e mais 4, e mais 4, tantos quanto inserir.

a ideia foi estruturar o código de maneira a que fosse simples adicionar novos motores. numa pasta individual colocam-se os ícones dos motores. qualquer que seja o tamanho da imagem, será sempre apresentada a 84×84 pixels. é recomendável redimensionar antes, uma vez que o rendering do browser estraga um pouco a qualidade das imagens.

as imagens são depois usadas num ficheiro javascript, onde o utilizador deve mexer para configurar a seu gosto. a lista de motores não passa de um array de variáveis com 3 propriedades: a homepage, a string para pesquisa e a localização da imagem. se o tamanho do array exceder o número de motores visíveis de uma vez, as restantes serão acedidas por scoll.

não queria usar um botão adicional e desperdiçar espaço, queria que um drag vertical no widget mudasse a lista de motores. o drag horizontal também seria interessante, mas esse será sempre apanhado primeiro pelo home screen, para mudar entre ecrãs. o scroll foi a maior perda de tempo. a samsung tem uma má implementação dos eventos touch no seu browser. a única coisa que me permitiu gerir com eficiência foi o evento onmousewheel, lançado aquando de arrastamentos do dedo. não funcionando como num computador, no entanto, o Event associado não tem a propriedade wheelDelta, que normalmente devolve a extensão/direcção do scroll. não consigo sequer saber se o scroll é para baixo ou para cima, só sei que houve scroll. ainda para mais, um arrastamento contínuo lança diversos eventos, o que provoca scrolls a mais, acidentais.

para solucionar os dois problemas, o scroll não faz bem scroll, mas faz cycle entre as páginas de motores. para evitar o lançamento consecutivo de vários scroll, quando capturo um primeiro deixo de ouvir o evento para só ouvir um quinto de segundo mais tarde:

scroll = function(e) { /* more like cycle through */
	page = (page + 1) % Math.ceil(engines.length / visibleEngines);

	/* disable scroll for a fifth of a sec */
	document.onmousewheel = null;
	setTimeout('document.onmousewheel = scroll', 200);

	changePage(page);
}