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

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…

autonomous driving robots frequently use cameras for object and road detection. after detecting such elements in an image it must be able to locate them in the real world, or else the image serves no purpose. that’s the ipm: a means of associating points in an image to points in the car coordinate system. to do obtain it, one only has to understand the transformations that occur when points are projected in an image and undo all those steps, for each point of the image, thus obtaining the real coordinates of each pixel.

a little geometry:

the first transformation to consider is the one relative to the mechanics of the camera, the way it was constructed. correction of these values comprehends the calibration of the focal distance and the alignment of the lens relative to the projective plane, the image sensor. this requires finding 4 unknowns, that are used in this way:

the left part contains the corrected points and the right part the original point coordinates in the real world, multiplied by a matrix. this matrix describes a change in scale as well as a translation. this operation gives us an image that is equivalent to the one obtained if we were using a pinhole camera.

the camera is now perfect, but the lens is still uncorrected. usually lenses produce radial distortion in the projection. this distortion is quite intense if using fisheye lenses. that’s actually the case in the considered robot. due to mechanical constraints, the camera is quite close to the road, and using a normal lens would yield a fairly small field of view. on top of that, some might consider that in practice it is hard to have the lens perfectly parallel to the image sensor, which is a requirement for an undistorted projection. these two problems are solved with 5 new parameters, as corrected by the first few terms of a taylor expansion around the center of the lens [bradski, kaehler]:

after these two transformations we say that the camera is calibrated for the intrinsic parameters. at this point, if we know the position of the camera relative to the floor, elementary geometry allows us to solve the position of each point. usually, though, it’s hard to mount a camera with a specific angle to the floor, at a fixed height. to find these parameters we need to solve for the perspective transformation. this transformation basically will allow us to obtain a bird’s eye view of whatever the camera is capturing. this transform is given by the following operation [bevilacqua, gherardi, carozza]:

on the left we have the corrected image point, on the right the matrix that describes its rotations and translations, and the uncorrected image point. these rotations and translations are the unknowns, called the extrinsic parameters. once we have a bird’s eye view of the scene we can infer distances between points. we just need to locate one point, so we’ll be able to define a fixed coordinate for all points.

a little code:

when you don’t know these parameters, because cameras don’t have a datasheet stating the angle between the lens and the sensor, or how much the lens distorts the image, you can obtain them capturing know objects with identifiable points. chessboards are a good example. fortunately i had to do very little with this math introduction to calibrate the image, because opencv solved most of these problems with just a few function calls. anyway, i didn’t know that until i studied image projection, and it eventually came handy to know the inner works.

so, opencv provides me: a way of detecting chessboard corners, those referred easily identifiable points; given a series of chessboards, the intrinsic parameters; given four image points and their corrected projection, the extrinsic parameters.

detecting chessboard corners is a call away from cvFindChessboardCorners(). this accepts an image and returns a list of points. this list of points can be used, along with the image that produced them, to call cvFindCornerSubPix(), and get subpixel accuracy on those same points.

given a series of captures of different images from chessboards, which will produce a series of lists of points, opencv provides cvCalibrateCamera2(), that calculates the rotations and translations of the chessboard between captures, thus fixing all 9 intrinsic parameters. it should be noted that, for better results, at least 10 chessboard captures should be done. using cvUndistort2() one is able to see the result of correcting an image for the intrinsic parameters. this is easily evaluated for fisheye lenses, since after the calibration no visible distortion should be noticed. straight lines should remain straight [devernay, faugeras]. cvUndistortPoints() corrects a sparse set of points instead of a whole image.

once calibrated for the intrinsic parameters, we can find all 8 extrinsic parameters (the matrix is normalized so that ) using 4 collinear points (their ideal and distorted positions). one can do this laying a chessboard on the road and detecting the outermost corners. we know that these form a rectangle, so we can fix 4 coordinates that form a rectangle where those corners should be projected. opencv allows us to do this using cvGetPerspectiveTransform(). the result can be observed with a call to cvWarpPerspective(), which yields the referred bird’s eye view (or the result of any other calculated perspective transform). cvPerspectiveTransform() corrects a sparse set of points instead of a whole image.

so, since we now have a bird’s eye view, we only need to locate two points in the image and indicate their real coordinates. this will allow us to both find the relation between distances in pixels and distances in the real world and also fix the location of all the points.

conclusion:

this is pretty much an overview what i’ve been doing, and is greatly based on “learning opencv: computer vision with the opencv library“, from o’reilly media. further steps include making use of this map to abstract algorithms such as “lane detection”, “car positioning”, to work at a car coordinate level, instead of image coordinates. this will not only make it easier for the programmer to produce algorithms but will also facilitate porting solutions to other architectures, and different camera mounts.

the project code is not public per se, but i’m free to disclose any requested parts.

sobre as t-shirts, a ideia surgiu-me ao acordar, claro, talvez porque durante o sono estive a arrumar os acontecimentos dos últimos dias em aveiro, onde foi depositada muita atenção nas minhas cores.

sobre o telemóvel, tenho uma história mais longa. há já algum tempo que procurava um telemóvel que me permitisse uma maior e melhor sincronização de calendários, contactos, e-mail e redes sociais como bónus. apesar de ter surgido muito antes, esta ideia tornou-se mais forte com o aparecimento de um android acessível no mercado português, o htc magic. acontece que, picuinhas como sou, não o comprei. o que se passava na altura, e ainda agora, é que todos os telemóveis da htc tinham um compromisso: ou era o ecrã, ou a memória, ou o processador, esquecendo o preço. enfim… não gosto de compromissos! graças ao empurrão na pesquisa dei para olhar para outros mercados, como o alguns symbian da nokia, e mesmo o iphone. quanto aos symbian, apesar da instalação no mercado, dei-os como mortos, lentos, e mesmo com bugs. quanto aos iphone é fácil esquecer a paixão, pois o preço nunca se justifica.

a febre passou até que um dia, por engano, tropecei no samsung wave. engraçado o preço ter sido a primeira coisa a reparar, 340€ na vodafone. até seria caro, dependendo do que tinha dentro. mas até fui ver o que tinha dentro. não descobri senão um ecrã maravilhoso, um processador potente, e uma autonomia razoável. vi logo que seria um bom negócio, e já lá vai mais de um mês e muitas reviews. depois de muita espera na vodafone acabei por comprar na expansys, que fez um excelente serviço aos melhores preços.

o maior medo era o bada, o novo sistema operativo da samsung. olhando para os vídeos a interface notava-se muito fluida, e com todas as funcionalidades básicas. o defeito é a escassez de aplicações. dei por mim a ser desencorajado por colegas com android, e perguntei quantas aplicações já tinham descarregado, ao que me responderam centenas. perguntei se eram úteis, e disseram que sim, liam códigos de barras no supermercado. perguntei quantas vezes fizeram isso: uma. é verdade, uma. o telemóvel para mim, apesar de necessitar de funcionalidades avançadas, não necessita de acasalar com outros, nem exprimir o quanto sou pobre. precisa de fazer o que disse inicialmente: sincronizar e comunicar.

acontece que este telemóvel faz isso na perfeição. há já muito tempo, na perspectiva de comprar um telemóvel novo, ou ser assaltado e perder o cartão, comecei a organizar os contactos no google contacts, com fotos, datas de nascimento, a história toda. uma das primeiras coisas que fiz com o novo wave foi sincronizar a conta do google et voilá, os contactos estavam no meu telemóvel, foto e tudo, o que não acontece em muitos clientes activesync. configurei a conta do facebook e seleccionei uma série de contactos para importar. a maioria deles ficou associado com os do google, mas outros tive de associar manualmente. a associação automática é feita, parece-me, por campos de contacto comuns entre as pessoas, como o e-mail ou o número de telefone. para as pessoas que não têm estas informações no facebook é impossível adivinhar, e associar pelo nome seria até indesejável. infelizmente o telefone faz uma certa distinção entre os contactos das contas de sincronização, o cartão sim e o telefone, não sendo possível a cópia entre o primeiro e os dois últimos e vice versa.

tive há dias a oportunidade de mexer num motorola droid. achei extremamente esquisito que o android não forneça um mecanismo para terminar aplicações. por um lado faz sentido, só as termina quando for preciso (mas ao menos deixa o utilizador escolher?), por outro não faz sentido nenhum, pois as aplicações ficam em segundo plano a consumir recursos… oops, não! não ficam! ficam em memória, mas não lhe é concedido processamento! quer dizer, eu carrego uma página web mas entretanto gostava de verificar uma mensagem que recebi, quando volto à aplicação é que a página continua a carregar! isto não acontece com o wave. o wave tem verdadeiro multitasking, neste exemplo a página continua a carregar e, quando volto ao browser, tenho tudo arrumadinho para consulta. infelizmente, e na única situação que me apercebi de lentidão, um evento em segundo plano que encrava ligeiramente a fluidez são os avisos de nova mensagem, novo e-mail, etc. talvez um problema do escalonador, talvez uma necessidade enorme de processador.

sobre a câmara, o resultado não está propriamente à vista, mas estou satisfeito. é fácil encontrar exemplos de vídeos e fotos na net, mas sempre tendo em conta que são “apontar e disparar”, nada cuidado. apesar de tirar boas fotos e óptimo vídeo, acredito que a fotografia é muito mais do que perfeição de imagens. apesar de uns milhares de euros fornecerem um potencial enorme em termos comerciais, a fotografia amadora é mais acerca de captar momentos, e exprimir sensações, que está muito além de resoluções, sensibilidades, tempos de exposição… mesmo assim existem algumas possibilidades de manipulação destes parâmetros, nomeadamente a exposição, alguns efeitos de pós processamento, etc.

quanto à autonomia, claro que não é telemóvel para durar uma semana, mas isso também depende do uso que se lhe dá. isto é, durante a noite, em rede 2G e sem outras conectividades ligadas, a bateria desce cerca de 5%. feitas as contas, se o deixar assim, dura 6 dias, o que vai além de muitos telemóveis sem motivo para consumir mais. esta bateria aguenta seguramente dois dias cada um com duas horas de mensagens de texto, 10 minutos de conversação, meia hora de wi-fi, 15 minutos de need for speed: shift. talvez mais.

no final de contas não me arrependo do investimento. ao fim de tanto tempo foi o único telemóvel que me captou a atenção em termos de qualidade/características/preço e, até agora, ficou à altura. também não foi só a mim que captou a atenção. este telemóvel ainda não chegou a todos os mercados e já esgotou em muitas lojas. é fácil também encontrar pela internet muitos fóruns e conversas dedicadas ao telemóvel e ao sistema operativo; a actividade no gsmarena não deixa dúvidas; e o objectivo da samsung em duplicar a quota no próximo ano parece-me já ter estado muito mais longe.

ninguém me tira da cabeça o my brute, tamanhas as conversas que tive de aturar durante os almoços… quem é que voltaria a um site onde via o seu boneco levar porrada todos os dias? eu continuo a apostar que mais de metade dos adversários eram aleatórios do sistema, feitos só para levar na boca e deixar as pessoas felizes, para que voltassem.

mas e o preço a pagar pela lucidez?

i think it’s funny that most people think they should be worried after watching this. so what is the problem with privacy? we’re all entitled to it; we have rights over it; the right to ignore it, if that suits us!

no one likes being told that the government listens to our conversations or that car plates will have tracking chips in the future. why? because it invades our privacy. i don’t like it either! why? because i have no choice!

people worry, for example, about the outcomes of using free wifi from google, because of the facilitated ability it will give the company to collect “personal” data. i don’t care that google, or any other company, for that matter, collects my data. why? because:

• my web browsing data is not private. it has never been. but if that worries me i just hide my ass or use encryption. most people seem to worry about admins reading their mail, but gnupg is a great working tool; use it.
• my routes are not private, they have never been; cute girls can stalk me all they want, nothing i can do about it. although, if i’m carrying a wifi equiped device and don’t want the service providers to know about my roaming activity, i can just turn the device off. simple as that.
• though i usually leave the “collect data to provide feedback box” unchecked, i believe regular usage information can help service providers enhance their service, and i think it is good to know that your presence somehow has an effect in the ecosystem.
• i have other options, there’s always an alternative service.
• i get advertisements all the time, but i block them because they just don’t make sense. but imagine being around lunch time in a random street and get an ad about a delicious hamburger just the next street, hell *that* would be great!

of course this last argument has a problem. two problems, actually. the first problem is that most people don’t have the right tools to decide their actions, but that is an education problem, it’s the world we’ve grown up in. it started with television.

the second problem is far more complicated, and the only reason i’m pissed at google. google makes money placing ads. google places ads on the internet. google wants people to go to the internet. so google sells people a phone that can put them on the internet anywhere at anytime. google nexus is a great phone, it is the best phone ever. for a couple of weeks before the launch i seriously considered buying one, and i was really fond of the idea that google would change the market. but they didn’t, all they did was give the consumer the ability to choose if they want the phone locked or unlocked, that’s not new, not even in the states.

my problem with this scheme is that google makes money twice: selling the phone, then placing ads in it. i think google is a large enough company to really change the market and give the user two completely new options: pay for the phone, stay private; or take a free phone, let us make money out of how you use it.

you saw the video, there’s nothing wrong about google. google didn’t invade your privacy, google is just a tool. if you know there’s no way of using that tool against you then there’s nothing to be afraid of. take advantage, use it wisely!

and, seriously, see what kind of stuff the guy in the video wants to hide. that does not apply to you, you hope!

• manufacturer: this has to be apple, sony, toshiba or asus, mixed order
• screen: 14.1″ proved itself ideal. also considering 13.3″. pixel size from 1366×768, definitely led backlit (or better?)
• processor: something 2010 intel
• storage: ssd!! when does it mass ship?
• graphics: something a bit more than “hd capable”, preferably dedicated
• price: up to 1100€, please?

everything else is relevant, but not major. welcome things like apple mbp’s unibody, 7 hour battery, light sensors, illuminated keyboard…