Recursos Para Dispositivos móveis

SUMÁRIO

1 INTRODUÇÃO 3

2 RECURSOS PARA DISPOSITIVOS MÓVEIS 4

2.1 PERSISTÊNCIA 4

2.2 THREADS 6

2.3 SINCRONIZAÇÃO DE PROCESSOS 9

2.3.1 SEMÁFOROS 9

2.3.2 MONITORES 11

3 CONCLUSÃO 13

REFERÊNCIAS 14

1 INTRODUÇÃO

O portfólio a seguir visa demonstrar os programas e estudos que são utilizados para desenvolver aplicativos para dispositivos móveis.

2 RECURSOS PARA DISPOSITIVOS MÓVEIS

2.1 PERSISTÊNCIA

A capacidade de persistir dados ou armazenar informações é sem dúvida um dos recursos mais importantes em qualquer linguagem de programação. Armazenar dados para uma posterior recuperação é uma constante na maioria dos ambientes computacionais, seja para persistência simples de parâmetros de configurações de algum sistema ou persistência de informações digitadas pelo usuário para alimentar algum banco de dados.

No que diz respeito à persistência em ambientes computacionais, o complicador é quando esse mesmo ambiente tem recursos de armazenamento restrito e, ainda, uma arquitetura de hardware e software bem diferente da encontrada em desktops ou grandes servidores, como é o caso dos dispositivos móveis. Essas diferenças podem ser observadas tanto do ponto de vista do usuário (ergonomia de hardware e software), quanto do ponto de vista do desenvolvedor (ferramentas de software, APIs e recursos). Os telefones celulares conseguiram alcançar uma popularidade quase tão grande quanto a observada na utilização de computadores pessoais a partir da década de 80. Mas, assim como todos os dispositivos móveis, eles também trazem consigo algumas dificuldades, como, problemas relacionados à ergonomia do teclado, uma interface visual simples porém limitada e a dependência de baterias que requerem recarga constante.

O Java 2 Micro Edition (J2ME) foi desenvolvido para contemplar toda a diversidade computacional existente nos dispositivos móveis. A tecnologia J2ME conseguiu abstrair conceitos e técnicas para homogeneizar o desenvolvimento em dispositivos móveis de forma completamente transparente. O perfil de informação de dispositivos móveis, conhecido como MIDP (Mobile Information Device Profile) surgiu como solução para diferenciar alguns dispositivos que apesar de possuirem características semelhantes, ainda assim são tecnologicamente diferentes. O perfil MIDP contempla os aparelhos celulares e é o responsável pela definição das APIs necessárias para a persistência de dados.

O conjunto de classes responsáveis por armazenar e recuperar dados é conhecido como Record Management System (RMS) ou sistema de gerenciamento de registros. O RMS permite manter os dados persistentes entre várias chamadas de um MIDlet (aplicação baseada no MIDP). Segundo a especificação MIDP, deve haver, disponível no dispositivo, pelo menos 8 kbytes de memória não-volátil (ROM) para que os aplicativos persistam dados. Exemplos de memória não-volátil seriam ROM, flash e etc. Em teoria, todo o espaço livre na memória ROM, ou flash de um dispositivo móvel, estaria disponível aos aplicativos para persistirem seus dados.

A unidade básica de dados mantida pelo RMS é conhecida como RecordStore ou repositório de registro (RR). Um RR pode ser comparado a uma tabela ou entidade no modelo relacional e é identificado por um nome de até 32 caracteres. Cada registro é composto por um identificador único e um array de bytes, onde os dados do registro serão armazenados. Um RR mantém em sua estrutura um conjunto de registros que podem ter tamanhos variáveis.

Um MIDlet é um aplicativo executado em um dispositivo móvel. Para isso, ele precisa ser empacotado em um arquivo Java (JAR). Um MIDlet pode, ainda, ser empacotado junto com outros MIDlets em um mesmo arquivo JAR, formando um conjunto. Tanto um MIDlet quanto um conjunto de MIDlets, formam uma aplicação J2ME única e completa. Cada conjunto de MIDlets ou um MIDlet, pode criar e manter diversos RRs, podendo, inclusive, compartilhá-los entre si, com o detalhe de que os nomes atribuídos aos RRs precisam ser únicos. A versão 1.0 do MIDP não permitia o compartilhamento de RRs entre MIDlets empacotados em diferentes arquivos JAR. A versão 2.0 do MIDP corrigiu essa limitação, permitindo assim o compartilhamento de um RR por todas os MIDlets instalados no dispositivo.

As APIs do RMS não fornecem recurso para travamento de registros. A implementação de um RR garante que a operação de persistência será realizada de forma indivisível e síncrona evitando eventuais inconsistências no caso de acessos múltiplos. Se for necessário que um MIDlet utilize múltiplas threads para acessar um RR, é necessário toda uma atenção para manter a consistência dos dados. Também, é responsabilidade da implementação no dispositivo fazer todo o possível para garantir a integridade e a consistência dos RRs durante operações normais ao seu uso como reinicialização, troca de baterias e etc.

Durante a desinstalação de um MIDlet do dispositivo, os armazéns de dados pertencentes a ele são removidos automaticamente.

Qualquer operação de inserção, atualização e exclusão de registros em um RR provocam a atualização automática do seu número de versão e da data em que ocorreu a mudança. O número da versão de um RR pode servir como referencial, por exemplo, para algoritmos de replicação. É uma maneira interessante de detectar quantas vezes um RR foi modificado. Esses dois valores, o número da versão e a data da atualização, podem ser recuperados através do uso dos métodos getVersion() e getLastModified() respectivamente. A Tabela 1 lista mais algumas funcionalidades da classe RecordStore.

A Listagem 1 contém um exemplo simples que cria um RR, preenche-o com dois registros e a seguir obtém e apresenta algumas informações sobre o RR. A Figura 1 apresenta a mesma aplicação sendo executada no emulador.

2.2 THREADS

Um thread é um fluxo único de controle sequencial dentro de um programa. Um thread não é um programa, mas executa dentro de um programa, como demonstra a figura abaixo:

O projeto fica mais interessante quando temos mais de um thread