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);
}

ao longo do episódio de south park emitido em 25 de março de 2009, stan tenta devolver uma misturadora que o pai comprou com um plano de pagamentos. como a loja não trata da dívida gerada com o plano, stan tem que se dirigir junto da companhia financeira responsável para obter a devolução.

acontece que o economista não pode devolver o dinheiro. o que ele faz é simplesmente convencer pessoas sem dinheiro a comprar uma misturadora, empacota as dívidas numa grande, e são os investidores em wall street que tratam delas.

uma vez em wall street, stan descobre que ainda não pode recuperar o seu dinheiro pois os investidores separaram o grande pacote em valores que pudessem vender aos bancos. no entanto os bancos também não podem fazer a devolução pois, uma vez que muita gente foi aos bancos à procura do retorno das misturadoras, o governo teve de comprar os valores aos bancos, para que não falissem.

então stan dirige-se ao departamento do tesouro. ali explica a situação, e dizem-lhe de imediato que não há problema, apenas precisam de consultar as tabelas para ver o valor que que lhe devem devolver. de regresso de uma sala, ensanguentados, os funcionários anunciam o valor de investimento no total de 90 trilhões de dólares (biliões, no nosso sistema).

entretanto surge uma emergência com uma companhia de serguros prestes a falir, e os funcionários têm de ir lá dentro verificar os gráficos para ver o que fazer. stan entra e espreita: solta-se uma galinha decapitada, onde cair é a jogada mais prudente:

metáfora: galinhas
realidade: polvos

humm… doesn’t seem that different, to me!

desta vez custou um pouco mais começar, pois foi preciso ler um pouco sobre controlos e containers. no fundo não há muita diferença relativamente a outros toolkits gráficos. comparando com gtk, que foi o último que usei, para o bada também tenho duas hipóteses: posso programar e colocar os controlos todos no sítio com código, ou posso desenhar no ide e depois, no código, pedir para que sejam colocados no sítio e obter o handle. nada de especial.

o problema que há com este modo de programação do bada, para mim, é que as callbacks para os módulos geradores de eventos não são passadas explicitamente. o que é passado é uma classe que implemente (herde, em c++) uma interface IModuleEventListener. além disto não podemos definir argumentos para passar a essas funções. resultado: torna-se complicado gerir a partilha de recursos a serem utilizados na rotina de atendimento. o que é que eu fiz? o módulo principal herda tudo… felizmente não há colisões, mas neste caso não vi que fizesse sentido criar módulos diferentes. uma vez que vou tratar de eventos wifi, e da interface, bem como os genéricos das aplicações, isto é a classe criada:

class WifiSmith :
	public Osp::App::Application,
	public Osp::System::IScreenEventListener,
	public Osp::Ui::IActionEventListener,
	public Osp::Net::Wifi::IWifiManagerEventListener,
	public Osp::Ui::IItemEventListener
{

em vez de dar uma caixa de texto e um botão “do the magic” achei que seria mais interessante (e até mais simples) limitar-me a pegar no wi-fi, obter uma lista das redes disponíveis e listá-las. isto foi muito fácil de fazer. ao construir o manifest.xml no site, tive de adicionar privilégio WIFI. isto permite fazer todas as operações com o módulo wi-fi, excepto Connect(). para ligar é necessário permissões WIFI_MANAGER. infelizemente, só parceiros da samsung podem pertencer a este grupo, pois é necessário um nível de acesso SYSTEM. uma parvoíce, a meu ver. qualquer que seja a parte da api, não vejo motivo para que alguém que pague (ou receba?) tenha acesso e os outros não. no entanto esta limitação apenas impede publicação na loja; o grupo pode ser adicionado manualmente no ficheiro xml, mas a aplicação será certamente rejeitada na loja:

<Privileges>
	<Privilege>
		<Name>WIFI</Name>
	</Privilege>
	<Privilege>
		<Name>WIFI_MANAGER</Name>
	</Privilege>
</Privileges>

para compilar com permissões especiais é preciso, com frequência, adicionar uma biblioteca para linkagem, neste caso FNet. verdade para o simulador, para o telemóvel parece-me estar tudo na mesma biblioteca, FOsp.

a interface da aplicação é muito simples. dois botões em baixo, um “refresh” e outro “back”. gosto das aplicações que têm botão de saída no ecrã, não gosto de usar o físico. no editor visual: as duas SOFTKEY activas e uma List que ocupa todo o ecrã. a List permite scroll se os elementos excederem o espaço reservado. a SlidableList serve para listas grandes, e alocação dinâmica dos elementos que interessam ver num dado momento apenas. no início desenho esta estrutura, associo as callbacks, e inicializo as variáveis necessárias:

bool
WifiSmith::OnAppInitializing(AppRegistry& appRegistry)
{
	// draw the form
	MainForm *pMainForm = new MainForm();
	pMainForm->Construct(L"IDF_FORM1");
	Frame *pFrame = GetAppFrame()->GetFrame();
	pFrame->AddControl(*pMainForm);
	pFrame->SetCurrentForm(*pMainForm);
	pMainForm->SetSoftkeyActionId(SOFTKEY_1, SOFTKEY_1);
	pMainForm->AddSoftkeyActionListener(SOFTKEY_1, *this); // register back button event
	pMainForm->SetSoftkeyActionId(SOFTKEY_0, SOFTKEY_0);
	pMainForm->AddSoftkeyActionListener(SOFTKEY_0, *this); // register refresh button event
	pMainForm->RequestRedraw();

	// set the wifimanager
	pWifiManager.Construct(*this);

	// get the essid list control
	pEssidListControl = (List*)pMainForm->GetControl("IDC_LIST1");
	pEssidListControl->AddItemEventListener(*this);

	return true;
}

que no fim liberto:

bool
WifiSmith::OnAppTerminating(AppRegistry& appRegistry, bool forcedTermination)
{
	// decided to use dynamic allocation for the WifiManager and the list of WifiBssInfo (networks)
	delete pEssidListControl;

	return true;
}

sair da aplicação faz-se chamando o método Application::Terminate(). este método parece só estar acessível no módulo principal. tentei mesmo Application::GetInstance()->Terminate() noutros módulos, mas nem assim consegui compilar. azelhice minha, talvez. a cada refresh limpa-se e volta-se a preencher a lista de redes disponíveis:

void
WifiSmith::OnWifiActivated(result r)
{
	pWifiManager.Scan();
}

 // SOFTKEYs
void
WifiSmith::OnActionPerformed(const Osp::Ui::Control &source, int actionId)
{
	// SOFTKEY_0 is just the actionId I associated with it on line 42, it's not really the key.
	if(actionId == SOFTKEY_0) // refresh
	{
		RefreshList();
	}
	else
	{
		Application::Terminate();
	}
}

void
WifiSmith::RefreshList()
{
	// clear the essid list
	pEssidListControl->RemoveAllItems();
	pEssidListControl->RequestRedraw();

	// turn on wifi, if off
	if(!pWifiManager.IsActivated())
	{
		MessageBox vMessageBox;
		vMessageBox.Construct("Action required!", "WiFi needs to be ON for scanning! Turn on?", MSGBOX_STYLE_YESNO, 0);
		int modalResult;
		vMessageBox.ShowAndWait(modalResult);

		if(modalResult == MSGBOX_RESULT_YES)
		{
			pWifiManager.Activate();
		}
		else
		{
			Application::Terminate();
		}
	}
	else
	{
		// get the available networks
		OnWifiActivated(E_SUCCESS);
	}
}

quando o wi-fi está desligado é na função refresh que pergunto ao utilizador se pretende activar, com uma MessageBox. se não o fizer, a aplicação termina. faria sentido chamar a RefreshList() na inicialização. no entanto há um problema de concorrência. enquanto a aplicação está a arrancar é mostrada uma “imagem splash”. por algum motivo a aplicação bloqueia nesse splash se tentar abrir uma MessageBox algures na função OnAppInitializing(). provavelmente funcionaria na função OnForeground(), mas nesse caso tinha de controlar o estado da aplicação com uma nova variável, pois a função OnForeground() é chamada sempre que se volta ao foreground, e não apenas da primeira vez. continuo a achar que o problema é do sistema operativo, algo diferente devia acontecer.

findo o Scan(), preenche-se novamente a lista:

void
WifiSmith::OnWifiScanCompletedN(const Osp::Base::Collection::IList *pWifiBssInfoList, result r)
{
	pNetworkList.RemoveAll();
	pNetworkList.AddItems(*pWifiBssInfoList);

	for(int r = 0; r < pNetworkList.GetCount(); r++)
	{
		WifiBssInfo *currentBssInfo = (WifiBssInfo*)pNetworkList.GetAt(r);
		pEssidListControl->AddItem(&currentBssInfo->GetSsid(), null, null, null, r);
	}
	pEssidListControl->RequestRedraw(true);
}

para quem não viu até aqui, é fácil perceber que não há muito tratamento de erros. esta função, por exemplo, indica com a variável r se o Scan() teve ou não sucesso. no entanto pouca diferença faz para o código que escrevi. mais, por motivos de eficiência, o mecanismo de controlo de excepções do c++ foi completamente ignorado pela samsung, não existem excepções no bada. o compilador até me avisou que, na linha 111, estou a passar um endereço de uma variável temporária. como nunca me deu problemas, não senti necessidade de copiar os nomes para uma lista.

depois de listadas as redes, é possível ver a listagem no telemóvel. clicando em qualquer rede, tenta-se ligar:

void
WifiSmith::OnItemStateChanged(const Osp::Ui::Control &source, int index, int itemId, Osp::Ui::ItemStatus status)
{
	WifiBssInfo *pWifiBssInfo = (WifiBssInfo*)pNetworkList.GetAt(itemId);
	const WifiSecurityInfo *pWifiSecurityInfo = pWifiBssInfo->GetSecurityInfo();

	// if open and no encryption, go right ahead!
	if(pWifiSecurityInfo->GetAuthenticationType() == WIFI_AUTHENTICATION_OPEN
			&& pWifiSecurityInfo->GetEncryptionType() == WIFI_ENCRYPTION_NONE)
	{
		pWifiManager.Connect(*pWifiBssInfo);
	}
}

lembre-se que, na linha 111, dei um itemId a cada elemento da List igual ao índice dessa rede na lista de redes. no fim da tentativa de ligação à rede, posso informar o utilizador:

void
WifiSmith::OnWifiConnected(const Osp::Base::String &ssid, result r)
{
	MessageBox vMessageBox;
	int modalResult;

	if(r == E_SUCCESS)
	{
		vMessageBox.Construct("Connected:", ssid, MSGBOX_STYLE_OK, 0);
	}
	else
	{
		vMessageBox.Construct("Unable to connect:", ssid, MSGBOX_STYLE_OK, 0);
	}

	vMessageBox.ShowAndWait(modalResult);
}

por vários motivos, neste código só me ligo a redes abertas. o primeiro é o facto de ainda não ter tratado disso. o segundo é que, quando fui a testar o caso dos routers thomson, por exemplo, acabei por descobrir que a resolução das chaves é um tanto ou quanto probabilística, e nem sequer funcionou para alguns casos que testei. o terceiro motivo é o facto de subscrever um aditivo internet, como faz todo o sentido, com este telemóvel, e até porque não frequento sítios atulhados de redes vulneráveis.

no entanto acrescentar esta funcionalidade, para mim, faz-se do seguinte modo: começa-se por criar uma classe que recebe um WifiBssInfo e, com essa informação (provavelmente só ssi e bssid), identifica o tipo de router com que está a lidar e devolve, de acordo, a chave a utilizar. pode ainda disponibilizar um método booleano do tipo CanSolve() o que permitirá, no tempo da listagem, mostrar apenas as redes com que é possível lidar. por último, uma vez que alguns algoritmos devolvem mais que uma chave, a função OnWifiConnected() deve implementar uma máquina de estados que permita tentar a chave seguinte para a mesma rede, caso a ligação tenha falhado, e até que não existam mais chaves. nada mais!

algumas capturas:

(uau, this sucks! é preciso mesmo clicar nas imagens, parece que os thumbnails do wordpress cortam a imagem…)

o primeiro passo foi obter o ide/sdk. nada a assinalar, trata-se do eclipse. o problema é que as tralhas da samsung exigem windows, e logo aqui desmoralizo fortemente. felizmente não estou sozinho, há mais quem gostasse de desenvolver para bada em linux, vamos confiar nos rumores que tendem a nosso favor! é um pouco estranho ter de esperar, uma vez que o próprio bada é baseado em linux, e o eclipse é até dos poucos ambientes decentes para este sistema operativo.

ligeiramente relutante, lá avancei à descoberta da documentação. o primeiro projecto seria colmatar a falha da loja: não existe uma lanterna. melhor, existe, mas usa o ecrã para iluminar, com um led tão bom do outro lado, junto à câmara.

depressa relembro como não sou grande fã de programação por eventos. o que vale é que c++ permite herança múltipla, e então é mais fácil atulhar a classe principal de métodos para atender eventos desde a bateria ao flash. a minha ideia de aplicação seria que o próprio programa fosse o botão de flash. isto é, ligar o flash seria tão simples como ligar o programa, que saía de imediato. desligar seria iniciar novamente a aplicação. um toggle!

neste caso de utilização não precisava de mais do que criar um objecto de acesso à câmara, que me dá controlo sobre o flash. se o IsFlashOn(), SetFlash(false), senão SetFlash(true). o IsFlashOn() funciona, o problema é que o SetFlash(true) liga o flash, mas não inicia a iluminação, per se. a iluminação é feita apenas ao utilizar a câmara, provavelmente desde que se inicia a focagem até à captura. talvez por este motivo não tenha aparecido a aplicação na loja…

além desta característica do sistema, tive outro problema. se não libertar a câmara quando a aplicação terminar, azar, tenho de reiniciar o telemóvel! nas funções que o ide cria automaticamente têm o cuidado de dizer na rotina OnAppTerminating(), em comentário, que se deve libertar a memória e os recursos. pergunto-me se o sistema operativo limpa a memória não libertada pelo programador???, caso contrário seria muito problemático deixar qualquer pessoa programar para o bada!

sobre este aspecto, parece que demora muito tempo até que uma aplicação seja admitida na loja. talvez seja esse o motivo para ainda não haver muitas aplicações (sinceramente não estou a ver lugar para muitas mais úteis…). por um lado é bom saber que as aplicações à disposição foram vistas e revistas, por outro deve ser altamente desmotivante para o programador…

podia considerar-me preguiçoso por não despender esse tempo com mais frequência? os amigos com quem hoje estou diariamente ficarão um dia esses contactos esporádicos. não são amizades maiores ou menores, melhores ou piores, mas têm papéis diferentes. relações desiguais que marcam fases da vida. os cheiros, olhares, sorrisos, vozes, que me permitem reviver o passado e ansiar o futuro.

eu acho que a viagem no tempo é um tema de conversa muito interessante, mas não suporto que se fale dela em termos científicos, muito menos em tom de leis. a primeira:

não se pode voltar atrás no tempo, as fórmulas não o permitem. é um mecanismo que a natureza tem de se proteger!

parece razoável: como é que se lidava com alterações no passado que criassem paradoxos no presente? boa pergunta, mas não ter resposta prova a impossibilidade? há milhares de anos era “impossível dar a volta ao mundo”, pois “o mundo era plano”. hoje é impossível voltar atrás no tempo, mas porquê?

se voltasses atrás no tempo e morresses, o que é que acontecia agora, que estás a falar comigo?

não sei, mas isto não prova que não é possível, só prova ignorância. eu não sei explicar o que acontece no meu cérebro que me permita escrever, no entanto escrevo. mas sei que o cérebro tem um papel no processo, já é qualquer coisa. para defender a resolução deste paradoxo gosto da física quântica, que afirma a existência de ramificações de universos num grande multiverso. isto é, se eu voltar atrás no tempo e morrer, estou a criar uma bifurcação. numa delas estou aqui, a escrever. noutra não estou, e outras coisas totalmente diferentes acontecem.

viajar para o futuro é possível, e está provado. os sistemas de gps precisam de ajustes devido ao facto de estarem afastados da terra. segundo einstein, o tempo passa mais devagar perto de objectos de grande massa.

bem, duas brincadeiras. claro que é possível viajar no tempo para o futuro. estou a fazê-lo neste preciso momento. não me sinto parado no tempo. corpos de grande massa: sim, se estiver ao pé de uma menina gorda o tempo parece passar mais devagar do que se estiver ao pé de uma menina elegante. =) relatividade de einstein. sabia umas coisas, o homem!

para provar estas teorias, usam-se relógios atómicos. uns na terra, uns no espaço, outros ali pela atmosfera às voltas para um lado e para o outro. no fim juntam-se e todos mostram durações diferentes. o que eu sei sobre os relógios atómicos é que são muito precisos, regulares. o que eu sei também é que um relógio não sustenta a noção de tempo. isto é, porque é que se diz que o tempo contrai e dilata e não se diz que o relógio alterou o seu período? se calhar as diferentes condições de velocidade e de massa condicionam o funcionamento dos relógios, e não o tempo em si.

se circundares a terra à velocidade da luz durante 40 anos, quando aterrares passaram 10’000 anos na terra, ou coisa que o valha.

até pode ser, mas o facto de eu ter envelhecido apenas 40 anos não implica que o tempo tenha mudado. explica apenas que eu envelheci a uma taxa de 40 anos por 10’000. o que mudou, a meu ver, foi a minha percepção do tempo, e a velocidade dos meus mecanismos biológicos. se é essa a noção de tempo, então claro que é fácil viajar, mesmo para trás: qualquer envelhecimento reversível.

não tenho para mim que envelhecer mais rápido ou mais devagar em relação a outros seja viagem no tempo. viagem no tempo consiste em saltar entre momentos diferentes de um tempo a 3 dimensões, se é que existem! há tanta coisa escrita que nem me atrevo a citar (nem a ler!). acredito em viagens no tempo, claro, e que o homem conseguiria controlar, mas acho que a extinção chegará antes desse dia. sem a discussão e as teorias científicas não era possível avançar, mas deixo isso para os tolos. por enquanto, e com tantas incertezas, o tema ao café não passa de filosofia.