Desenvolvimento

1.1 PERSISTNCIA EM APLICATIVOS PARA DISPOSITIVOS MVEIS COM

J2ME
A capacidade de persistir dados ou armazenar informaes
sem dvida um dos recursos mais importantes em qualquer linguagem de
programao. Armazenar dados para uma posterior recuperao uma
constante na maioria dos ambientes computacionais, seja para persistncia
simples de parmetros de configuraes de algum sistema ou persistncia de
informaes digitadas pelo usurio para alimentar algum banco de dados.
No que diz respeito persistncia 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 mveis. Essas diferenas podem ser observadas tanto do
ponto de vista do usurio (ergonomia de hardware e software), quanto do ponto
de vista do desenvolvedor (ferramentas de software, APIs e recursos). Os
telefones celulares conseguiram alcanar uma popularidade quase to grande
quanto a observada na utilizao de computadores pessoais a partir da dcada
de 80. Mas, assim como todos os dispositivos mveis, eles tambm trazem
consigo algumas dificuldades, como, problemas relacionados ergonomia do
teclado, uma interface visual simples porm limitada e a dependncia de
baterias que requerem recarga constante.

1.1.1 J2ME e perfil MIDP
O Java 2 Micro Edition (J2ME) foi desenvolvido para
contemplar toda a diversidade computacional existente nos dispositivos
mveis. A tecnologia J2ME conseguiu abstrair conceitos e tcnicas para
homogeneizar o desenvolvimento em dispositivos mveis de forma
completamente transparente. O perfil de informao de dispositivos mveis,
conhecido como MIDP (Mobile Information Device Profile) surgiu como soluo
para diferenciar alguns dispositivos que apesar de possurem caractersticas
semelhantes, ainda assim so tecnologicamente diferentes. O perfil MIDP
contempla os aparelhos celulares e o responsvel pela definio das APIs
necessrias para a persistncia de dados.
1.1.2 RMS
O conjunto de classes responsveis 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 vrias chamadas de um MIDlet (aplicao baseada no MIDP). Segundo a
especificao MIDP, deve haver, disponvel no dispositivo, pelo menos 8
kbytes de memria no-voltil (ROM) para que os aplicativos persistam dados.
Exemplos de memria no-voltil seriam ROM, flash e etc. Em teoria, todo o
espao livre na memria ROM, ou flash de um dispositivo mvel, estaria
disponvel aos aplicativos para persistirem seus dados.
A unidade bsica de dados mantida pelo RMS conhecida
como RecordStore ou repositrio 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 sero armazenados. Um RR mantm
em sua estrutura um conjunto de registros que podem ter tamanhos variveis.
Um MIDlet um aplicativo executado em um dispositivo mvel.
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 aplicao 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 atribudos aos RRs precisam ser
nicos. A verso 1.0 do MIDP no permitia o compartilhamento de RRs entre
MIDlets empacotados em diferentes arquivos JAR. A verso 2.0 do MIDP
corrigiu essa limitao, permitindo assim o compartilhamento de um RR por
todas os MIDlets instalados no dispositivo.
As APIs do RMS no fornecem recurso para travamento de
registros. A implementao de um RR garante que a operao de persistncia
ser realizada de forma indivisvel e sncrona evitando eventuais
inconsistncias no caso de acessos mltiplos. Se for necessrio que um MIDlet
utilize mltiplas threads para acessar um RR, necessrio toda uma ateno
para manter a consistncia dos dados. Tambm, responsabilidade da
implementao no dispositivo fazer todo o possvel para garantir a integridade
e a consistncia dos RRs durante operaes normais ao seu uso como
reinicializao, troca de baterias e etc.
Durante a desinstalao de um MIDlet do dispositivo, os
armazns de dados pertencentes a ele so removidos automaticamente.
1.1.3 Classe RecordStore
Qualquer operao de insero, atualizao e excluso de
registros em um RR provocam a atualizao automtica do seu nmero de
verso e da data em que ocorreu a mudana. O nmero da verso de um RR
pode servir como referencial, por exemplo, para algoritmos de replicao.
uma maneira interessante de detectar quantas vezes um RR foi modificado.
Esses dois valores, o nmero da verso e a data da atualizao, podem ser
recuperados atravs do uso dos mtodos getVersion() e getLastModified()
respectivamente.


1.2 THREAD
Para programas "normais" (single thread), tem um nico ponto de execuo dentro do
programa num momento particular, um thread semelhante: tem um incio, uma sequncia e
um fim, como um programa "normal". Tem um nico ponto de execuo no certo momento
dentro de um thread

Definio: thread um fluxo nico de controle sequencial
dentro de um programa.
A coisa fica mais interessante quando temos mais de um thread no mesmo programa
O browser um exemplo de uma aplicao multithreaded,
onde vrias coisas podem ocorrer ao mesmo tempo:
1.3 USABILIDADE DE INTERFACES PARA DISPOSITIVOS MVEIS
Um questionamento comum sobre as melhores prticas de
front-end / usabilidade para dispositivos mveis o quanto elas so especficas
ao contexto mobile, pois muitas delas no se distinguem das diretrizes que vm
sendo difundidas h 20 anos.
fato que grande parte das diretrizes so semelhantes, mas o
que muda a criticidade quando tratamos de mobile. Algumas recomendaes
tornam-se mais graves e imperdoveis quando no so seguidas no projeto de
interfaces para dispositivos mveis.
Como exemplo, podemos usar a questo da densidade informacional. Em aplicaes que sero
visualizadas em dispositivos mveis, os textos devem ser concisos, eliminando informaes
secundrias que podem ser irrelevantes.

1.4 ENGENHARIA SOCIAL

Engenharia social compreende a inaptido dos indivduos manterem-se atualizados com
diversas questes pertinentes a tecnologia da informao, alm de no estarem conscientes
do valor da informao que eles possuem e, portanto, no terem preocupao em proteger
essa informao conscientemente.
1.5 VULNERABILIDADE
Qualquer sistema que manipule dados est sujeito a alguma
vulnerabilidade. A conexo com a Internet representa uma das principais
formas de desestabilizao e roubo de informaes para qualquer Usurio
dentro de uma Organizao. Alm da Internet, h outras possibilidades de
acesso remoto que podem comprometer o sistema e a segurana de dados,
tais como bluetooth, infravermelho, etc. Toda essa possvel exposio dos
dados pode acarretar em invaso de rede e seus servidores, expondo
informaes confidenciais e violando a privacidade garantida por lei.