Utilizando acelerômetro para estabelecer conexões bluetooth seguras

Pesquisadores ingleses desenvolveram uma técnica para se estabelecer conexões bluetooth seguras utilizando o acelerômetro encontrado em alguns aparelhos celulares. A técnica consiste em chacoalhar os aparelhos que desejam se conectar de forma igual, os dados produzidos pelos acelerômetros são comparados e caso sigam o mesmo padrão a conexão é estabelecida.

Um vídeo demonstrando a técnica pode ser visto em:

http://www.youtube.com/watch?v=ktJC0S4_X58

Mais informações podem ser encontradas em:

http://technology.newscientist.com/article/dn12912
http://eis.comp.lancs.ac.uk/fileadmin/eis/publication/2007-ShakeImp.pdf

De volta a ativa... com novidades!

Passado algum tempo sem postar devido a falta de tempo por conta de projetos na faculdade e pessoais, resolvi finalmente reativar o blog. Mesmo não estando presente no blog, neste tempo que fiquei ausente continuei trabalhando com a Series60, mais precisamente com OpenGL ES e PythonS60 (em um futuro próximo irei postar informações interessantes sobre os dois).

O retorno do blog coincide com o anúncio do tão esperado Nokia 5800 XpressMusic. Como anúnciado pelos mais variados sites de notícias, ontem, quinta-feira (02/10/2008) a Nokia entrou na briga com a Apple (fabricante do iPhone) ao anunciar o lançamento de seu serviço digital de músicas, o "Comes with music" (que chega para competir com o iTunes) e o smartphone Nokia 5800 XpressMusic (que de certa forma será um concorrente ao iPhone). Por enquanto não irei me pronunciar a respeito destes lançamentos, irei esperar sua chegada ao mercado e alguns reviews para ter uma opnição mais concreta, mas acredito que esteja surgindo um novo segmento de trabalho da Nokia.

Nokia 5800 XpressMusic

A parte do lançamento do Nokia 5800 foi anunciado a nova versão da Series60. Isto sim foi o que mais chamou a atenção. O Series60 5º edição é baseado no Symbian OS 9.4, que possui melhoras em seu gerenciamento de memória, devido principalmente a utilização da paginação de memória (introduzida no Symbian 9.3). Um ponto a enfatizar é a interface com usuário, aparentemente optimizada para resoluções maiores e entrada de dados através de toque, o que me leva a deduzir que uma série de smartphones touchscreen estão para serem lançados brevemente.

Outro destaque ficou por conta da introdução da biblioteca Open C++, finalmente vemos um suporte as APIs padrões do C++ como STL e Boost. Fica a questão, seria este o primeiro passo para padronização do Symbian C++? Bem... veremos :).

Por fim, vale lembrar que o Nokia 5800 XpressMusic não é o primeiro dispositivo touchscreen da Nokia, que já trabalha a algum tempo com internet tablets touch-screen, apesar destes representarem outro segmento de mercado. Me parece que a Nokia demorou um pouco a entrar no mercado de smartphone touchscreens, diferente de outras empresas como LG, HTC, etc. Resta agora esperar e ver como o mercado irá reagir.

Recuperando um ponteiro para class Document

Muitas vezes quando utilizamos o padrão Model-View-Controller (que espero falar aqui no futuro) , precisamos acessar dados contidos na nossa classe Document.

Para fazer isto precisamos de um ponteiro que aponte para o objeto desta classe. Podemos recuperar esta referência através de um método da classe CEikAppUi chamado Document(). Este método retorna um ponteiro genérico do tipo CEikDocument. Para poder utilizar os métodos da nossa classe document precisaremos da um cast da classe base CEikDocument para a nossa classe CMeuDocumento (por exemplo).

Para ilustrar melhor a relação entre as classes aqui está um diagrama de classes. Para a nossa classe Document temos:

Não está explicíto, mas por estas classes começarem com a letra C, sabemos que são derivadas de CBase.

Recuperando a referência da nossa classe Document dentro de AppUi

Classes AppUi são em geral derivadas de CAknAppUi (caso não implemente views) ou CAknViewAppUi (caso a aplicação trabalhe com views). Na relação de hierarquia elas herdam o método Document() de CEikAppUi. Considerando que você precise do ponteiro para Document dentro de sua classe AppUi, basta apenas chamar o método Document(), dando o devido cast.



Exemplo:

// Cast para da classe base para a classe filho.
CMeuDocumento* documento = static_cast(Document());
// Chamando um método qualquer.
documento->MinhaFuncao();

Recuperando a referência para a nossa classe document dentro do container

Classes derivadas de CCoeControl possuem um atributo membro iCoeEnv, que é um ponteiro do tipo CCoeEnv. Esta classe possui um método AppUi() que retorna um ponteiro do tipo CCoeAppUi, iremos utilizar este ponteiro para chamar o método Document() de CEikAppUi. Como vemos no diagrama de classes ao lado, CCoeAppUi não possui o método Document() implementado (ele está implementado em CEikAppUi , filha de CCoeAppUi), tereremos então quer dar um cast para a classe AppUi de nossa aplicação para poder acessar este método.

Exemplo:

// Conversão do tipo CCoeAppUi para CMeuAppUi.
CMeuAppUi* appUi = static_cast(iCoeEnv->AppUi());
// Conversão do tipo CEikDocument para CMeuDocumento.
CMeuDocumento* documento = static_cast(appUi->Document());
// Chamando um método qualquer.
documento->MinhaFuncao();

Referências

Developing Series 60 Applications: A Guide for Symbian OS C++ Developers (cap. 4)

Utilizando classes Singleton no SymbianOS

Sigleton é um padrão de projeto definido no Livro Design Patterns: Elements of Reusable Object-Oriented Software. Este padrão diz que para uma determinada classe apenas uma única instância deve existir por todo o programa.

Em C++ padrão a forma mais simples de se criar uma classe Singleton é utilizar um ponteiro estático e um método estático. Em SymbianOS isto funciona para EXE mas não para DLL*. Pois este ponteiro estático é considerado como um Writable Static Data (variável global que existe durante toda a vida do processo), e isto não é permitido para DLLs.

Para fazer a criação de singletons temos duas possibilidades, utilizar a classe base CCoeStatic , ou utilizar Thread Local Storage (TLS). Até o momento nunca utilizei TLS então irei focar na utilização da classe CCoeStatic. A principal desvantagem na utilização de CCoeStatic é que você não pode utiliza-lo em aplicações baseadas em console (sem User Interface).

A lógica utilizada será bem parecida com o singleton em C++ padrão, a diferença é que não iremos utilizar um ponteiro estático. Iremos precisar criar um UID único para a classe (único dentro da aplicação), ele será utilizado para identificar de qual classe iremos obter a instância, caso esteja trabalhando com várias classes Singleton.

Arquivo: ExemploSingleton.h

/*
* Exemplo de criação de classes Singleton utilizando CCoeStatic.
* Autor: Leonardo Soares e Silva
*/

#include // Cabeçalho de CCoeStatic.

class CExemploSingleton : public CCoeStatic
{
public:
/* Retorna uma instância desta classe.
* Na primeira vez que este método for chamado ele fará a criação da instância.
* Em chamadas subsequentes será retornada esta instância.
*/
static CExemploSingleton* InstanceL();
~CExemploSingleton();
private:
/* Construtor precisa ser privado para evitar que outras classes a instancie diretamente.*/
CExemploSingleton();
/* Construtor de segunda-fase caso precise realizar alguma operação que possa abandonar */
void ConstructL();
};

Arquivo: ExemploSingleton.cpp

#include "ExemploSingleton.h"

/* UID definido para a classe CExemploSingleton.
* Este UID precisa ser único para esta classe dentro da aplicação.
*/
const TUid KUidClasseSingleton = { 1 };

/* Construção da classe.
* Passamos para CCoeStatic a UID da classe e prioridade de destruição da instância.
*/
CExemploSingleton::CExemploSingleton() : CCoeStatic( KUidClasseSingleton, EDefaultDestructionPriority )
{

}

CExemploSingleton::~CExemploSingleton()
{
// Não implementado.
}

CExemploSingleton* CExemploSingleton::InstanceL()
{
CExemploSingleton* instancia = static_cast
( CCoeEnv::Static( KUidClasseSingleton ) );
/* Somente entrará neste if na primeira chamada a InstanceL();
* Chamadas subsequentes a este método retornarâo esta instância.
*/
if( !instancia )
{
instancia = new (ELeave) CExemploSingleton();
/* Adiciona o ponteiro ao CleanupStack para garatir que está referência não será perdida caso ConstructL abandone.*/
CleanupStack::PushL( instancia );
/* Chamada ao construtor de segunda-fase */
instacia->ConstructL();
/* Após chamar métodos que possam abandonar , liberar da pilha */
CleanupStack::Pop( instancia );
}

return instancia;
}

void CExemploSingleton::ConstructL();
{
// Não implementado
}

O código por si só é bastante fácil de compreender. Como disse anteriormente basta fazer chamadas ao método InstanceL() para receber a referência da classe Singleton. Na primeira chamada será alocado o ponteiro e nas outras será apenas retornado a instância. Algo que vale ressaltar é a construção da classe:

CExemploSingleton::CExemploSingleton() : CCoeStatic( KUidClasseSingleton, EDefaultDestructionPriority )
{

}

Passamos através do contrutor para CCoeStatic dois argumentos. Uma das definições do construtor de CCoeStatic é:

CCoeStatic(TUid aUid, TInt aDestructionPriority, TScope aScope=EThread);

Onde:

aUid = Uid da classe singleton.
aDestructionPriority = Define com que prioridade a instância será destruída. Quanto maior este valor , mais cedo o objeto será destruído. Valores positivos fazem com que o objeto seja destruído antes de CCoeAppUi enquanto valores negativos fazem com que o objeto seja destruído após CCoeAppUi.
aScope = Define para quem o objeto estará acessível. Por definição é para o Thread da aplicação.

---
* = A partir da versão 8.1 passou a ser suportado.

Tipos básicos em Symbian

Opa, antes de começar a falar sobre tipos de variáveis em SymbianOS preciso explicar o porquê estou ausente do blog. Primeiro por que estava de férias e no tempo livre estava engajado em um projeto pessoal de desenvolvimento de um pequeno jogo clone do snake da Nokia (concluído, depois posto o source, funciona legal no emulador mas não funcionou no meu N95 e não tive tempo de verificar o porquê até por que não poderei depura-lo on-device já que minha versão do Carbide é a express), segundo que com as aulas começando e com retorno do projeto fiquei sem tempo de postar mas vou tentar sempre que possível postar algo interessante aqui.

Ok, vamos ao que interessa...

Se você não conhece os tipos básicos utilizados em SymbianOS considere a leitura do artigo Tipos Básicos no Nokia Wiki. Estas mudanças TInt, TUint, TReal, etc são apenas typedefs dos tipos padrões de C/C++ mas devem ser utilizados pois é assim que o compilador irá interpretá-los. O que gostaria de dizer neste post se refere mais a eficiência na programação.

Tipos Inteiros

Sintaxe:

typedef signed int TInt;

O SymbianOS permite que programadores utilizem tipos inteiros de 8, 16, 32 ou 64 bits, porém segundo o próprio site www.symbian.com é recomendável a utilização do tipo TInt sempre que possível. Isto pode ser explicado por motivos simples, o SymbianOS trabalha em cima da arquitetura ARM e nessa arquitetura o tamanho da palavra é de 32bits. Quando você utiliza inteiros (TInt16 e TInt32) com tamanho menor que esta palavra ela terá que ser então "modificada" para o tamanho da palavra que a arquitetura utiliza

Nota: TInt8 na verdade é um typedef do tipo char e TInt32 é um typedef do tipo long int.

Por isso a utilização de inteiros com tamanhos definidos deve ser utilizada quando a precisão no tamanho dos dados é necessária, em outros casos aconselha-se utilizar TInt.

Tipos flutuantes

O uso de tipos flutuantes deve ser evitado sempre que possível pois a maioria dos dispositivos em que o SymbianOS trabalha não dá suporte a operações de ponto flutuantes em hardware, ficando assim sua performance comprometida seriamente.


Gerência de memória e recursos

Bem, seria meio redundante eu postar os mesmos artigos que já postei na Nokia Wiki aqui. Então para evitar isto e para criar o costume de se utilizar a Wiki resolvi fazer algumas referências aqui a artigos encontrados lá. Como o sistema de busca dele não é um dos melhores às vezes você não encontra tudo que procura, talvez isso possa ajudar.

O post de hoje será em relação a gerência de memória e recursos. Quando se programa para um dispositivo que possui tantos recursos limitados como um celular é preciso ter cuidado para não disperdiçar nada. A um tempo atrás os celulares eram reduzidos apenas a capacidade de realizar e receber chamadas. Hoje celulares como o N93, N95, N800 apresentam recursos como aceleração 3D e processadores mais robustos como o ARM11 que opera a 300MHZ mas mesmo assim ainda são muito limitados.

Começando por este artigo onde é arbodado os conceitos básicos de stack , heap, exceções (abandonos ou leaves em Symbian), pilha de limpeza entre outros. Gostaria de dar ênfase para a construção em duas fases e para pilha de limpeza.

Pilha de limpeza e Construção em duas fases são melhores abordados nesses links.

Para finalizar, algumas regras na gestão de recursos que procuram minimizar estes desperdícios podem ser encontras neste link

Códigos de erros

Ao ocorrer um erro durante a execução de uma aplicação é exibido o porquê deste erro ter acontecido. Podemos chamar isto de "Códigos de erros" e conhecê-los é importante para solucioná-los. Escrevi este artigo para o Nokia Wiki PT comentando sobre cada um dos erros e como corrigí-los e apesar de ainda incompleto cobre os erros mais comuns, caso conheça mais erros não esqueça de contribuir! ;)

Link para o artigo aqui!

Caso queira verificar a lista completa de erros ela pode ser encontrada na documentação do SDK do Symbian, link aqui!