Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DE SANTA CATARINA CURSO DE CIÊNCIAS DA COMPUTAÇÃO
Elenice Colle Manganelli Juliano Romani
PROTOCOLOS DE SINCRONIZAÇÃO DE DADOS EM AMBIENTES WIRELESS: UM ESTUDO DE
CASO
Trabalho de Conclusão de Curso submetido à Universidade Federal de Santa Catarina como parte dos requisitos para a obtenção do grau de Bacharel em Ciências da Computação.
Orientador: Mário Antônio Ribeiro Dantas
Florianópolis-SC, fevereiro de 2004.
ii
PROTOCOLOS DE SINCRONIZAÇÃO DE DADOS EM AMBIENTES WIRELESS: UM ESTUDO DE
CASO
Elenice Colle Manganelli
Juliano Romani
________________________________
José Mazzucco Jr. Coordenador do Curso
Banca Examinadora:
________________________________
Prof. Mário Antônio Ribeiro Dantas Orientador
________________________________
Prof. Rosvelter J. Coelho da Costa
______________________________
Prof. Roberto Willrich
iii
“Se prepara, meu amigo, que você está indo pro inferno.”
Julio Felipe Szeremeta
iv
AGRADECIMENTOS
Agradecemos ao professores que nos apoiaram, as nossas famílias que agüentaram a
gente, e a 992, a Pior Turma de Todos os Tempos.
v
RESUMO
Atualmente, tem se verificado um grande crescimento na utilização da
computação móvel. Um dos fatores que podem explicar essa tendência é o
desenvolvimento de novos recursos computacionais, com uma maior capacidade de
processamento e armazenamento nos dispositivos móveis, bem como o aumento das
taxas de transmissão em redes wireless. Uma importante característica na sincronização
dos dispositivos móveis é o protocolo de sincronização de dados utilizado. Porém,
algumas considerações precisam ser analisadas na escolha, tais como: memória
disponível no dispositivo, a rede que vai ser utilizada (a taxa de transmissão, etc.). O
problema fundamental é encontrar um protocolo de sincronização de dados que atenda
aos problemas identificados. Neste trabalho é apresentada uma análise comparativa de
diferentes protocolos de sincronização de dados, baseando-se em um estudo de caso
experimental feito em uma plataforma convencional. Os resultados indicam algumas
soluções para o desenvolvimento na plataforma PalmOS e uma análise comparativa dos
protocolos HotSync e SyncML.
vi
ABSTRACT
Currently, it has verified a great growth in the use of the mobile computation.
One of the factors that can explain this trend is the development of new computational
resources, with a bigger capacity of processing and storage in the mobile devices, as
well as the increase of the taxes of transmission in wireless networks. An important
characteristic in the synchronization of the mobile devices is the used data
synchronization protocol . However, some considerations need is analyzed in the
choice, such as: available memory of the device, the network that go to be used (the tax
of transmission, etc.). The basic problem is to find a data synchronization protocol that
takes care of to the identified problems. In this work an analysis of different data
synchronization protocols is presented, being based on a study of made experimental
case in a conventional platform. The results indicate solutions for the development in
the PalmOS platform and an comparative analysis of the protocols HotSync and
SyncML.
vii
SUMÁRIO
CAPÍTULO I
1. INTRODUÇÃO......................................................................................................... 01
CAPÍTULO II
2. COMPUTAÇÃO MÓVEL........................................................................................ 03
2.1. Evolução da Computação Móvel ..................................................................... 03
2.2. Computadores Móveis ..................................................................................... 06
2.3. Computadores Fixos ........................................................................................ 07
2.4. Tecnologias sem Fio ........................................................................................ 07
2.4.1. Bluetooth.................................................................................................. 07
2.4.2. LANs sem Fio.......................................................................................... 08
2.4.3. Tecnologia Celular .................................................................................. 09
2.4.3.1.GSM ............................................................................................. 09
2.4.3.2.EDGE ............................................................................................ 10
2.4.3.3.GPRS ............................................................................................. 11
2.4.3.4.CDMA ........................................................................................... 12
2.5. Características da Computação Móvel............................................................. 13
2.5.1. Mobilidade ............................................................................................... 14
viii
2.5.2. Portabilidade ............................................................................................ 15
2.5.2.1. Pouca Bateria................................................................................ 16
2.5.2.2. Falta de Segurança na Informação................................................ 16
2.5.2.3. Pequena Interface com o Usuário................................................. 16
2.5.2.4. Pouca capacidade de armazenamento........................................... 17
2.5.3. Adaptação ................................................................................................ 17
2.5.4. Desconexão .............................................................................................. 17
2.6. Modelos Computacionais Móveis.................................................................... 19
2.6.1. Modelo Cliente/Servidor.......................................................................... 19
2.6.1.1. Modelo Cliente/Agente/Servidor .................................................. 20
2.6.1.2. Modelo Cliente/Interceptador/Servidor ........................................ 21
2.6.2. Modelo Peer-to-Peer ................................................................................ 22
2.6.3. Modelo de Agentes Móveis ..................................................................... 22
CAPÍTULO III
3. BANCO DE DADOS MÓVEIS................................................................................ 24
3.1. Características dos Banco de Dados Móveis ................................................... 25
3.1.1. Caching ................................................................................................... 25
3.1.2. Replicação .............................................................................................. 26
3.1.3. Difusão de dados .................................................................................... 27
ix
3.2. Transações Móveis .......................................................................................... 27
3.2.1. Propriedades das Transações Móveis ..................................................... 28
3.2.1.1. Atomicidade ................................................................................ 28
3.2.1.2. Consistência................................................................................. 29
3.2.1.3. Isolamento ................................................................................... 30
3.2.1.4. Durabilidade ................................................................................ 31
3.3. Modelos de Transações Móveis ........................................................................ 31
3.4. Processamento de Consultas.............................................................................. 33
3.5. Recuperação de Falhas ...................................................................................... 34
3.5.1. Localização................................................................................................ 36
3.5.2. Desconexão................................................................................................ 36
3.5.3. Energia....................................................................................................... 36
3.5.4. Rede........................................................................................................... 37
3.5.5. Falhas......................................................................................................... 37
3.5.6. Estratégias de Recuperação ....................................................................... 37
CAPÍTULO IV
4. TECNOLOGIAS DE SINCRONIZAÇÃO ............................................................... 41
4.1. Tipos de Sincronização ................................................................................... 41
4.1.1. One-Way................................................................................................. 41
x
4.1.2. Two-Way................................................................................................ 42
4.2. Protocolos de Sincronização ........................................................................... 42
4.2.1. Hotsync ................................................................................................... 44
4.2.2. Intellisync ............................................................................................... 45
4.2.3. SyncML .................................................................................................. 46
4.2.4. CPISync.................................................................................................. 50
CAPÍTULO V
5. AMBIENTE EXPERIMENTAL E RESULTADOS OBTIDOS .............................. 51
5.1. Descrição do Ambiente Utilizado................................................................... 51
5.2. Iniciando o Desenvolvimento na Plataforma PalmOS..................................... 52
5.2.1. PDB......................................................................................................... 53
5.2.2. PRC e Runtime ....................................................................................... 59
5.2.3. Conduit ................................................................................................... 60
5.2.4. Ferramentas de Desenvolvimento .......................................................... 62
5.3. Protótipo Desenvolvido ................................................................................... 64
5.3.1. O Programa Cliente................................................................................. 66
5.3.2. Descrição do Banco de Dados do Cliente .............................................. 68
5.3.3. O Módulo Conduit.................................................................................. 69
xi
5.4. Protocolos de Sincronização Investigados ........................................................ 69
CAPÍTULO VI
6. CONCLUSÕES E TRABALHOS FUTUROS .................................................... 73
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................... 76
ANEXOS ...................................................................................................................... 80
xii
ÍNDICE DE FIGURAS
FIGURA 1 – Dispositivos Móveis .................................................................................. 6
FIGURA 2 – Rede Fixa ................................................................................................... 7
FIGURA 3 – Estados de uma Operação de Desconexão............................................... 19
FIGURA 4 – Modelo Cliente/Servidor ......................................................................... 20
FIGURA 5 – Modelo Cliente/Agente/Servidor............................................................. 21
FIGURA 6 – Modelo Cliente/Interceptador/Servidor ................................................... 22
FIGURA 7 – HandOff – Estratégia de Recuperação..................................................... 39
FIGURA 8 – O Pentágono da Sincronização em Ambientes Móveis........................... 43
FIGURA 9 – Servidor Intellisync.................................................................................. 46
FIGURA 10 – Servidor SyncML .................................................................................. 47
FIGURA 11 – Interface do Cliente................................................................................ 65
FIGURA 12 – Estrutura do Sistema.............................................................................. 67
FIGURA 13 – Volume de Dados HotSync e SyncML (Slow)...................................... 70
FIGURA 14 – Volume de Dados HotSync e SyncML (Fast e Normal) ....................... 71
xiii
ÍNDICE DE TABELAS
TABELA 1 – Distribuição dos Blocos no PDB ............................................................ 54
TABELA 2 – Descrição do Header............................................................................... 54
TABELA 3 – Lista de Entradas de Registros................................................................ 56
TABELA 4 – Entradas de Registros ............................................................................. 56
TABELA 5 – Atributos dos Registros........................................................................... 57
TABELA 6 – Estrutura da Category ............................................................................. 58
TABELA 7 – Ferramentas de desenvolvimento para PalmOS ..................................... 63
TABELA 8 – Propriedades dos Protocolos de Sincronização de Dados Estudados..... 73
1
CAPÍTULO I
1. INTRODUÇÃO
Atualmente, com a ploriferação dos dispositivos móveis, os usuários são
providos de acesso a dados em qualquer lugar que estejam. Os sistemas que
fornecem esse acesso aos dados necessitam de novas tecnologias para gerenciar
e sincronizar dados, solucionando possíveis conflitos, verificando mudanças e
propagando as atualizações nos diversos dispositivos da sincronização.
Os protocolos de sincronização de dados para dispositivos móveis são
cuidadosamente criados para cobrir todos os problemas enfrentados. No caso
especial dos PDAs, que geralmente comunicam-se via serial, usb ou via wireless
com baixa largura de banda, possuem poder de processamento limitado, pouca
memória e pouca bateria espera-se que sempre estejam prontos para processar ou
transferir um grande volume de dados. Com esta visão levantada, existe a
necessidade que os protocolos de sincronização sejam eficientes o suficiente
para suprir as necessidades requeridas.
Este trabalho compreende o estudo e a experimentação dos protocolos de
sincronização de dados encontrados atualmente no mercado. Nossa pesquisa
também envolveu o desenvolvimento de um protótipo experimental de
sincronização de dados visando encontrar as dificuldades e facilidades de se
trabalhar com a computação móvel. A arquitetura empregada no experimento
incorporou ambientes de hardware convencionais e de baixo custo.
2
O objetivo principal deste trabalho é fornecer subsídios necessários para
o avanço da pesquisa científica, fornecendo as dificuldades e facilidades da
computação móvel e uma análise da performance dos protocolos de
sincronização de dados.
O trabalho é organizado como segue. O capítulo 2 fornece uma visão
geral sobre computação móvel, falando da evolução, das tecnologias sem fio,
das principais características e dos modelos de computação móvel. O capítulo 3
compreende a caracterização dos bancos de dados móveis, as transações móveis
e seus modelos, o processamento de consultas e a recuperação de falhas. No
capítulo 4 encontram-se as tecnologias de sincronização e os protocolos de
sincronização de dados estudados. O capítulo 5 expõe o ambiente experimental e
o protótipo desenvolvido. O capítulo 6 finaliza a pesquisa com as conclusões e a
perspectiva de trabalhos futuros.
3
CAPÍTULO II
2. COMPUTAÇÃO MÓVEL
A computação móvel tornou-se uma realidade na vida das pessoas com o
aparecimento de duas tecnologias: o aparecimento de computadores portáteis poderosos
e o desenvolvimento de redes rápidas e mais confiáveis (BARBARÁ,1999).
O ambiente da computação móvel não requer mais que os usuários mantenham
uma posição fixa na rede, permitindo assim uma grande mobilidade dos usuários.
O principal desafio da computação móvel é conseguir garantir o funcionamento
igualado aos dos computadores fixos, já que diversas restrições surgem com a
mobilidade, ou seja, é necessário ter um sistema de computadores distribuídos com
serviços comparáveis aos dos computadores fixos mas que permita mobilidade
(MATEUS & LOUREIRO, 1998).
2.1. Evolução da Computação Móvel
A evolução da computação móvel pode ser analisada através da evolução
tecnológica segundo Mateus & Loureiro (1998) até 1995 :
• 1820: Hans Christian Oersted descobre que a corrente elétrica produz
campo magnético; André Marie Ampère quantifica essa descoberta na lei de
Ampère;
4
• 1830: Joseph Henry descobre que a variação do campo magnético induz
corrente elétrica, mas quem publica o resultado é Michael Faraday, que
descobriu independentemente o mesmo resultado;
• 1864: James Clark Maxwell modifica a lei de Ampère e de Faraday e
desenvolve quatro operações sobre campos magnéticos;
• 1876: Alaxender Graham Bell inventa o telefone;
• 1896: Guglielmo Marconi inventa o telégrafo sem fio;
• 1907: Início do serviço de radiodifusão;
• 1914: Início da 1ª Guerra Mudial. Desenvolvimento rápido das
comunicações;
• 1921 : Radiodifusão entra em operação nos Estados Unidos;
• 1928: A Polícia de Detroit introduz um sistema de radiodifusão para
acionamento de carros;
• 1933: Quatro canais são autorizados para utilização na faixa de 30 – 40
MHz;
• 1935: A FM (Modulação em Freqüência) surge com alternativa para a AM
(Modulação em Amplitude) diminuindo o problema de ruídos;
• 1939: Grande avanço da comunicação via rádio com o advento da Segunda
Guerra Mundial;
• 1945: AT & T Bell Labs inicia experimentos na utilização de freqüências
mais altas objetivando melhorias nos serviços móveis;
• 1947: AT & T lança o IMTS (Improved Mobile Telephone Service), um
sistema onde apenas uma torre atendia uma grande área ou cidade. Em
seguida a AT & T Bell Labs propõe o conceito de celular;
5
• Anos 50: A faixa de transmissão é reduzida pela metade, onde sistemas
requeriam uma elevada banda de transmissão. Os primeiros sistemas de
paging começam a surgir;
• Anos 60: Um novo receptor de FM abre espaço para um maior número de
canais de comunicação com o mesmo espectro. Surgem aqui os primeiros
aparelhos portáteis;
• Anos 70: Um espectro de freqüência é alocado para os sistemas celulares.
Em 1979 é lançada a primeira rede celular no mundo, no Japão;
• 1983: O sistema celular evoluiu para os padrões atuais, sendo lançada a
primeira rede celular americana. Outros sistemas similares entram em
operação no mundo;
• 1991: Validação inicial nos Estados Unidos dos padrões TDMA e CDMA
de tecnologia celular;
• 1992: Introdução do sistema celular GSM (Groupe Spéciale Mobile);
• 1994: Introdução do sistema CPDC (Cellular Digital Packet Data). Início
dos serviços PCS (Personal Communication Services) CDMA e TDMA;
• 1995: Início dos projetos para cobertura terrestre de satélites de baixa
órbitra.
De acordo com PASTORE (2000) o número de usuários móveis excedeu 468
milhões em 2000, um número maior do que os usuários que utilizavam a internet, que
era 365 milhões.
6
2.2. Computadores Móveis
Computadores Móveis ou dispositivos móveis (PDAs, handhelds, Laptops,
celulares) possuem algumas vantagens com relação aos computadores fixos: são leves,
pequenos, pessoais, acessíveis, etc.
Mas por outro lado, as vantagens encontradas nos computadores móveis
acarretam um estreitamento de recursos, percebível facilmente aos abituados a utilizar a
computação fixa (DENARDI, 2003).
Os elementos móveis possuem geralmente pouca memória RAM, processadores
mais lentos, memória de armazenamento pequena e interface com o usuário limitada,
alguns exemplos de dispositivos móveis podem ser vistos na Figura 1.
FIGURA 1. Dispositivos Móveis. Fonte: MOB2003
7
2.3. Computadores Fixos
Os computadores fixos ou dispositivos fixos fazem parte de uma rede fixa cuja
localização e conectividade não mudam. Algumas das estações conectadas na rede fixa
podem servir como estações base de recursos, essas estações são também conhecidas
como servidores (ITO, 2001). Um exemplo de uma rede fixa pode ser vista na Figura 2.
FIGURA 2. Rede Fixa.
2.4. Tecnologias sem Fio
2.4.1. Bluetooth
A tecnologia wireless Bluetooth, segundo Dantas (2002), é um padrão de fato e
uma especificação para enlaces entre dispositivos móveis, usando ondas de rádio de
curto alcance. O Bluetooh Special Interest Group (SIG) é um grupo industrial formado
8
por empresas lideres em telecomunicações, computação e rede que estão dirigindo o
desenvolvimento da tecnologia e trazendo esta realidade para o mercado.
A proposta da tecnologia Bluetooth é habilitar os usuários para a conexão de
uma grande variedade de dispositivos de computação e telecomunicações de maneira
simples e fácil, sem a necessidade de cabos. Como a tecnologia é baseada em enlace via
rádio, é fácil a transmissão rápida e segura de voz e dados na rede. A operação do
Bluetooth é efetuada em uma banda de freqüência entre 2.402 e 2.480 GHz que está
globalmente disponível e tem compatibilidade mundial, sendo portanto um padrão
global para conectividade wireless. A tecnologia Bluetooth é muito resistente às
intempéries e dificuldades eletromagnéticas, o q garente que as interferências são
pequenas.
2.4.2. LANs sem Fio
Segundo GETIEEE802, o padrão de redes locais sem fio (802.11) define o
protocolo e a compatibilidade de interconexão de equipamentos de comunicação de
dados via ar, radio ou infravermelho em uma rede local (LAN) usando o "carrier sense
multiple access protocol with collision avoidance"(CSMA/CA) como mecanismo de
compartilhamento do meio. O controle de acesso ao meio (MAC) suporta operações
abaixo do controle do ponto de acesso assim como entre estações independentes. O
protocolo inclui autenticação, associação e reassociação de serviços, um procedimento
opcional de cifragem e descifragem, gerenciamento de energia. O padrão inclui a
definição de base de informação gerenciável (MIB) usando Abstract Syntax Notation 1
9
(ASN.1) e especifica o protocolo MAC formalmente, usando o Specification and
Description Language (SDL).
A camada física da implementação infravermelha suporta 1Mbit/s de taxa de
dados com uma extensão opcional de 2Mbit/s. A camada física da implementação do
rádio especifica também frequency-hopping spread spectrum (FHSS) suportando
1Mbit/s e um opcional 2Mbit/s de taxa de transferência ou direct sequence spread
spectrum (DSSS) suportando 1 e 2Mbit/s de taxa de transferência.
2.4.3. Tecnologia Celular
Algumas tecnologias celular serão descritas a seguir, segundo 3GAM (2003) :
• GSM
• EDGE
• GPRS
2.4.3.1. GSM
O Sistema Global de comunicações Móveis (GSM) é uma tecnologia sem fio de
segunda geração (2G) que provê serviços de qualidade de voz e de dados comutados por
circuito em uma ampla gama de faixas de espectro, que incluem 450, 850, 900, 1800 e
1900 MHz. GSM é uma tecnologia digital ou "PCS". Provê uma evolução sem
dificuldades e com bom custo-benefício para a terceira geração (3G). Estima-se que
10
GSM irá representar entre 80 e 85% dos clientes de próxima geração mundialmente,
segundo UMTS Fórum.
Em junho de 2003, GSM estava disponível via 665 redes em mais de 179 países.
É a tecnologia sem fio de uso predominante em termos mundiais, com mais de 880
milhões de clientes no continente americano, Ásia e Europa, o que representa 72% de
todos os clientes de tecnologia sem fio.
O GSM permite a vários usuários compartilharem um único canal de rádio
através de uma técnica denominada multiplexação por divisão de tempo (TDM), em que
um canal é dividido em seis intervalos de tempo. Designa-se para cada chamador um
intervalo de tempo específico de transmissão, que permite a vários chamadores
compartilhar um único canal simultaneamente sem interferência dos outros. Este
desenho viabiliza o uso eficiente do espectro e proporciona sete vezes mais capacidade
do que a analógica ou "AMPS", uma tecnologia de primeira geração (1G). GSM
também utiliza uma técnica chamada "salto de freqüências" que minimiza a
interferência proveniente de fontes externas e torna praticamente impossível o acesso
indevido a comunicações alheias.
2.4.3.2. EDGE
A EDGE (Taxas de Dados Ampliadas para a Evolução GSM) é uma tecnologia
de terceira geração (3G) de transmissão de dados e acesso à Internet de alta velocidade
que transmite dados em velocidade de até 473 kbps e taxa média entre 80 e 130 kbps.
As taxas médias são rápidas o suficiente para permitir um amplo leque de serviços de
11
dados avançados, incluindo streaming de som e imagem, acesso rápido à Internet e
download de arquivos pesados. A EDGE também suporta serviços "push-to-talk."
A EDGE às vezes é chamada de GPRS ampliada (E-GPRS; de Enhanced GPRS)
porque aumenta em três ou quatro vezes a capacidade e o throughput de dados da
GPRS. Assim como a GPRS, a EDGE é um serviço baseado em pacotes que oferece aos
clientes uma conexão permanente para transmissão de dados.
Assim como a conexão de banda larga por cabo e DSL, a EDGE oferece
conexão permanente à Internet, eliminando a necessidade de se conectar cada vez que
for usar, e os clientes podem receber serviços "pushed", tais como alertas da Bolsa. A
EDGE também permite que os clientes mantenham uma transmissão de dados enquanto
estão atendendo a uma ligação telefônica. Isto é totalmente único em tecnologias GSM.
2.4.3.3. GPRS
O Padrão de Transmissão de Rádio por Pacote (GPRS) é uma solução
espectralmente eficiente de dados móveis para novos serviços de dados mais rápidos e
roaming internacional. Como tecnologia de dados sem fio, GPRS oferece velocidades
máximas de dados de 115 kbps e um throughput médio de 30 a 40 kbps. GPRS é
freqüentemente chamada de tecnologia "2.5G" porque é a primeira etapa que uma
operadora GSM empreende quando inicia a transição à terceira geração (3G).
GPRS é uma tecnologia baseada em pacotes, o que significa que os dados são
divididos em pacotes e transmitidos em surtos breves via uma rede IP. Este desenho é
muito mais eficiente do que as redes comutadas por circuito e propicia uma redução dos
custos operativos da rede. O desenho de pacotes favorece os usuários principalmente de
duas maneiras: em primeiro lugar, GPRS provê uma conexão permanente de dados e
12
assim os usuários não precisam entrar no sistema cada vez que querem ter acesso a
serviços de dados. Em segundo lugar, os usuários só pagam pelos dados e não pagam
pelo tempo de permanência no ar em que se faz a conexão e nem pelo tempo de carregar
dados.
GPRS está baseada na plataforma GSM. GPRS está baseada em IP, padrão
universal utilizado na Internet, não num padrão unicamente de tecnologia sem fio que
requer equipamento proprietário. Ao utilizar uma tecnologia aberta e totalmente
padronizada, GPRS é ideal para o fornecimento de acesso sem fio a outras redes
baseadas em IP, como LANs corporativas e ISPs. Outra vantagem da base IP de GPRS
é que as operadoras e seus parceiros podem desenvolver e lançar serviços de dados
avançados muito mais rapidamente e a menor custo, fatores atribuídos à ampla
disponibilidade de "know-how IP" e equipamento pronto para usar.
Como a tecnologia sem fio de transmissão de dados por pacote mais amplamente
utilizada no mundo, GPRS se apóia na base de assinantes GSM, que já orça pelo bilhão,
e 665 redes GSM em mais de 179 países. Como GSM, GPRS suporta seamless roaming,
e portanto os usuários continuam tendo acesso a seus serviços de dados quando viajam.
Em junho de 2003, 162 operadoras em 70 países já haviam lançado GPRS. Mais 33
operadoras em outros 17 países estão em diferentes etapas de implantação.
2.4.3.4. CDMA
De acordo com CDG , o padrão CDMA (Code Division Multiple Access) é uma
tecnologia "spread spectrum", permitindo muitos usuarios ocuparem a mesma alocação
de tempo e freqüência em uma determinada banda/espaço. Como o próprio nome diz,
13
CDMA designa códigos únicos para cada comunicação para diferenciar de outras do
mesmo spectrum. Num mundo de recursos de spectrum finitos, CDMA habilita muito
mais pessoas para compartilhar as ondas emitidas ao mesmo tempo do que tecnologias
alternativas. O CDMA2000 representa a familia de tecnologia 3G que inclui
CDMA2000 1X e CDMA2000 1xEV:
• CDMA2000 1X pode dobrar a capacidade de voz da rede cdmaOne e entregar
pacotes de dados a uma velocidade máxima de 307kbps em ambientes móveis.
• CDMA2000 1xEV inclui:
1. CDMA2000 1xEV-DO: entrega pacotes de dados a uma velocidade
máxima de 2.4Mbps e suporta aplicações como transferencia de MP3 e
video conferencia.
2. CDMA2000 1xEV-DV: provê a integração de voz e tranmissão de
pacotes de dados e serviços multimídia simultaneamente em velocidades
de até 3.09Mbps.
3. 1xEV-DO e 1xEV-DV as duas são compatíveis com CDMA2000 1X e
cdmaOne.
2.5. Características da Computação Móvel
Computadores móveis requerem acesso a redes sem fio, embora possa às vezes
se unir fisicamente à uma rede fixa com uma conexão melhor e mais barata
permanecendo estacionários em reuniões em cima de uma mesa por exemplo.
14
Em uma comunicação sem fio é muito mais difícil conseguir uma comunicação
perfeita, pois existem muitos obstáculos que podem interferir no sinal, introduzindo
assim ruídos e ecos. As conexões sem fio possuem qualidade mais baixa que as
conexões fixas, pois possuem baixa largura de banda, taxas de erros elevadas e
desconexões mais freqüentes. Esses fatores podem aumentar a latência nos
retransmissores, atraso no intervalo de retransmissão, erro no processamento do
protocolo de controle e curtas desconexões (FORMAN & ZAHORJAN, 1994).
2.5.1. Mobilidade
Entende-se por mobilidade a capacidade que um dispositivo possui de se mover
pela rede. Nos deparamos com vários problemas provenientes da mobilidade.
Algumas das principais conseqüências da mobilidade são abordadas por SILVA
& ENDLER (2000):
• A inexistência de uma topoligia fixa de rede faz com que os algoritmos
existentes precisem ser reprojetados;
• A carga distribuída em uma rede com elementos móveis pode variar muito mais
rapidamente que em uma rede fixa;
• A localização de um elemento móvel na rede implica em um aumento no custo
de cada comunicação;
• Estruturas de dados e algoritmos são necessários para manter a localização dos
clientes móveis atualizada;
• A largura de banda, a latência da comunicação e a confiabilidade dos elementos
móveis podem variar muito;
15
• O número de serviços disponíveis de um elemento móvel podem variar de um
local para outro.
A mobilidade entre as células pode acarretar em interferência ou interrupção da
comunicação, assim como largura de banda reduzida podendo ocasionar várias
restrições na qualidade da transmissão dos dados (SONG. et al, 1999).
2.5.2. Portabilidade
Dentre todas as vantagens que um dispositivo móvel possui, ele ainda não atende
aos desejos de seus usuários, pois para eles ele deveria ser pequeno, pesar pouco, ser
durável, resistente à água e ter uma bateria de vida longa. Alguns problemas são
solucionados, mas outros não, como a bateria por exemplo, já que o dispositivo deve ser
leve.
Segundo FORMAN & ZAHORJAN (1994) quatro problemas ainda são
enfrentados devido à portabilidade do dispositivo, são eles:
• Pouca Bateria;
• Pouca Segurança da Informação;
• Pequena Interface com o Usuário e;
• Pouca Capacidade de Armazenamento.
16
2.5.2.1. Pouca Bateria
A bateria é a única fonte de energia para o dispositivo móvel e é também o que
mais pesa para ele. Uma solução que vem sendo estudada é o consumo menor de
energia das funções executadas pelo dispositivo. Vários fabricantes vêm desenvolvendo
projetos na arquitetura dos dispositivos para que consumam menos bateria. A bateria
pode ser conservada não somente pela arquitetura, mas também por um software mais
eficiente.
2.5.2.2. Falta de Segurança na Informação
Os computadores portáteis possuem riscos de danos físicos, de acesso
desautorizado, de perda e de roubo, isto pode acarretar na perca de privacidade, pela
violação de dados pessoais bem como a perca total dos dados. Esses riscos podem ser
reduzidos quando o dispositivo serve apenas como intermediador da comunicação e
atualização dos dados armazenados que ficam em um servidor fixo e seguro. E para
impedir a divulgação não autorizada da informação contida em um dispositivo roubado
ou perdido, os dados armazenados no disco ou em cartões de memória são
criptografados. Só que para isso ter efeito, os usuários não podem deixar sessões
autenticadas abertas. Em redes wireless sistemas de replicação resolvem o problema de
backup em computadores remotos, conservando a informação segura.
2.5.2.3. Pequena Interface com o Usuário
O tamanho de um dispositivo portátil limita muito a interface com o usuário, as
tecnologias de janelas dos softwares atuais é inadequada devido ao tamanho da tela.
17
Barras de tarefas ou títulos ocupam muito espaço na tela e por isso são consideradas
desnecessárias. Várias maneiras de aumentar a interface ou pelo menos dar a impressão
que ela foi aumentada estão sendo estudadas.
Técnicas de reconhecimento da escrita e da fala são englobadas ao dispositivo
com o intuito de diminuir o tamanho e aumentar a durabilidade.
2.5.2.4. Pouca Capacidade de Armazenamento
A capacidade de armazenamento em um dispositivo móvel é limitada por
exigências físicas de tamanho e bateria. Embora os computadores em rede de hoje
possuam paginação remota, confiar na rede não é muito aconselhável para um
dispositivo móvel susceptível a desconexões regulares.
2.5.3. Adaptação
Todas as circunstâncias de um usuário móvel mudam constantemente devido a
sua locomoção no ambiente, para que as unidades móveis funcionem com sucesso é
necessário que estas unidades sejam adaptativas. STAYANARAYANAN (1996) define
uma faixa de estratégias para adaptação delimitada por dois extremos, Laissez-Faire e
Application-Transparent.
2.5.4. Desconexão
Os sistemas computadorizados de hoje dependem muito da rede a qual estão
ligados, podendo até parar de funcionar caso ocorram falhas na rede. A falha na rede é
de um interesse muito maior na computação móvel já que a comunicação sem fio é
18
muito susceptível a desconexão. Considera-se então o melhor computador móvel aquele
que tolera as desconexões à rede (FORMAN & ZAHORJAN, 1994).
Segundo PITOURA & SAMARAS (1998), as operações de desconexão
envolvem três estados distintos, como visto na Figura 3:
• Hoarding: carregamento de itens na unidade móvel. Os dados podem ser
replicados ou movidos a um cachê local, podendo ficar inacessíveis a outros
membros da rede;
• Operações Locais: período em que o dispositivo está desconectado da rede fixa
podendo realizar operações apenas dos dados que possue em memória, isso
ocorre após o hoarding. Caso os dados necessários não estejam disponíveis, é
criada uma fila para execução de operações futuras que ocorrerão na próxima
conexão à rede;
• Reconciliação: durante a reconexão os dados são atualizados na unidade fixa
conforme as informações provenientes dos dispositivos conectados.
Uma situação de atualização concorrente entra em funcionamento e deve ser
tratada por uma semântica correta para que não ocorra inconsistência nos dados
atualizados.
19
FIGURA 3 – Estados de uma operação de desconexão. Fonte: (PITOURA & SAMARAS, 1998).
Na comunicação sem fio as desconexões podem ser caracterizadas de formas
diferentes. As desconexões podem ser voluntárias ou forçadas. Nas desconexões
voluntárias o usuário ou dispositivo é quem desliga a conexão com o propósito de
diminuir o custo da tarifa, o consumo de energia ou a largura de banda. Na desconexão
forçada o usuário não pretendia desligar a conexão, mas ela acontece espontaneamente
por motivo de cobertura na área ou falta de sinal no local em que se encontra (MATEUS
& LOUREIRO, 1998).
2.6. Modelos Computacionais Móveis
2.6.1. Modelo Cliente/Servidor
Segundo SATYANARAYANAN (1996), são chamadas de aplicações clientes
àqueles sistemas computacionais que solicitam serviços para uma aplicação que está
Hoarding
Reintegração Operações locais
20
sendo executada em outro lugar ou sistema operacional. Parte da comunicação é feita
por cabos fixos e na parte restante a comunicação é estabelecida por sinais de rádio, ou
seja, sem fio algum (Figura 4).
FIGURA 4 – Modelo Cliente/Servidor. Fonte: CUNHA (2003).
O dispositivo móvel faz o papel de cliente, enquanto o dispositivo fixo trabalha
como servidor. Podem existir vários servidores com funcionalidades distintas, dando
maior disponibilidade dos dados aos clientes.
Para MATEUS & LOUREIRO (1998) o modelo tradicional Cliente/Servidor não
atende a todos os requisitos necessários da computação móvel, por isso duas extensões
do modelo são discutidas a seguir: o Modelo Cliente/Agente/Servidor e o modelo
Cliente/Interceptador/Servidor.
2.6.1.1. Modelo Cliente/Agente/Servidor
Este é um modelo onde existem três partes: o cliente, que representa o
computador móvel, o servidor que é a estação na rede fixa e o agente que fica na rede
fixa e age em função do cliente (Figura 5). O agente simula a presença do cliente na
Aplicação cliente
Aplicação servidora
Unidade fixaUnidade móvel
Enlace sem fio
Rede fixaRede sem fio
21
rede fixa aliviando o impacto das falhas na comunicação, ele provê facilidades para
enfileirar mensagens a serem trocadas com o cliente móvel. O tempo de resposta entre
operações remotas pode diminuir, já que a carga de trabalho do servidor é menor.
Alguns problemas são encontrados nesse modelo; a necessidade de mudança do
cliente para comunicação com o agente e não mais com o servidor é um deles, outro
pode ser levantado no sentido de otimização, já que o agente otimiza a transmissão de
dados para o cliente móvel e não no sentido contrário.
FIGURA 5 – Modelo Cliente/Agente/Servidor. Fonte: CUNHA (2003).
2.6.1.2. Modelo Cliente/Interceptador/Servidor
Nesse modelo existem dois agentes, um fica na parte da rede fixa e outro na
parte móvel (Figura 6). Esses dois novos elementos são chamados de interceptadores ao
invés de agentes. O interceptador do lado do cliente intercepta chamadas do cliente e
junto com o outro interceptador executa otimizações para reduzir a comunicação no
lado sem fio e tentar manter a computação do cliente móvel sem interrupções.
Aplicação cliente
Aplicação servidora
Enlace sem fio
Unidade fixaUnidade móvelAgente
Rede fixa Rede sem fio
22
FIGURA 6 – Modelo Cliente/Interceptador/Servidor. Fonte: CUNHA (2003).
2.6.2. Modelo Peer-to-Peer
Neste modelo não existe distinção entre estações clientes e estações servidoras,
todas podem desempenhar tanto um papel como o outro. Esse modelo na computação
móvel faz com que os computadores tornem-se parceiros idênticos numa computação
distribuída (MATEUS & LOUREIRO, 1998).
2.6.3. Modelo de Agentes Móveis
Esse modelo trata a questão da mobilidade mais naturalmente podendo executar
um trabalho desconectado. Os agentes, descritos por PITOURA & SAMARAS (1998),
têm a capacidade de executar funções remotamente, sendo constituídos por instruções,
dados e um estado próprio. Além disso, possuem alguns aspectos que tornam viáveis a
execução de transações em ambientes móveis, tais como:
• Os agentes são tratados como objetos, quando ele é tranferido todo o objeto é
movido;
Aplicação cliente
Aplicação servidora
Enlace sem fio
Unidade fixaUnidade móvel
InterceptadorInterceptador
Rede fixa Rede sem fio
23
• O agente móvel não precisa ser executado de modo síncrono;
• Os agentes móveis ou objetos locais comunicam-se e trocam informações entre
si;
• Os agentes móveis podem executar operações mesmo estando desconectados;
• Tarefas em paralelo podem ser executadas por agentes distintos em diferentes
servidores.
24
CAPÍTULO III
3. BANCO DE DADOS MÓVEIS
A computação móvel está sendo utilizada nas mais diversas áreas de negócio,
incluindo a área de vendas, de empresas imobiliárias, empresas aéreas, de controle de
informação de trânsito e várias outras, principalmente nas grandes cidades.
Para que a mobilidade tenha efeito vantajoso existe a necessidade da utilização
de banco de dados para controle e armazenamento da informação. Um SGBD (Sistema
Gerenciador de Banco de Dados) tem como objetivo propiciar um ambiente conveniente
e eficiente para recuperação e armazenamento da informação (SILBERSCHATZ et al,
1999).
As aplicações que rodam em clientes móveis se conectam freqüentemente a
repositórios de dados remotos carregando somente as informações necessárias. Para isso
é necessário que o banco de dados tenha a capacidade de carregar as informações do
repositório e trabalhar com essa informação mesmo estando desconectado ou fora do
alcance do repositório. As informações atualizadas no cliente móvel enquanto ele estava
desconectado serão atualizadas na sua próxima conexão (BADRINATH & PHATAK,
1995).
25
3.1. Características dos Bancos de Dados Móveis
3.1.1. Caching
O mecanismo de caching é utilizado para otimizar o tempo de resposta nas
consultas da computação móvel e dar suporte quando a unidade móvel estiver
desconcetada.
Para que o mecanismo de caching atinja um bom resultado é necessário que estejam
definidas as estruturas de dados e as estratégias de gerenciamento do caching
consideradas as características de cada aplicação e o padrão de acesso aos dados
(FERREIRA & FINGER, 2000).
As operações sobre os dados podem ser divididas em três categorias segundo
DENARDI (2003):
• Dados somente para consulta: os dados não podem ser atualizados localmente e
conseqüentemente eles não são reintegrados em uma futura conexão ao banco de
dados remoto.
• Dados não concorrentes: atualizações locais podem ser feitas, mas os dados
replicados ficam bloqueados no servidor, evitando atualizações conflitantes.
• Dados concorrentes: os dados replicados podem ser alterados tanto no servidor
como no cache. Para que não ocorram conflitos o cache deve armazenar
informações sobre atualizações ocorridas para tomada de decisões.
26
3.1.2.Replicação
O sistema mantém cópias idênticas das relações inteiras ou partes dela que são
chamadas de réplicas e podem ser armazenadas em diversos pontos da rede.
Como na computação móvel as conexões podem ser raras, fracas e sem aviso
prévio, o computador móvel tem a necessidade de armazenar uma cópia local dos dados
necessários a fim de diminuir o custo com novas consultas e facilitar o trabalho em
modo desconectado (LUBINSKI & HEUER, 2000).
A replicação de dados é um dos problemas-chave em sistemas de computação
móvel. Um tratamento aplicável de replicação precisa de soluções novas que os
protocolos de replicação existentes não oferecem. Os sistemas atualmente em uso em
ambientes móveis sobrecarregam o usuário com a manutenção e consistência dos dados
replicados (LUBINSKI & HEUER, 2000).
Alguns requisitos precisam ser atingidos nas técnicas de replicação de dados,
segundo LUBINSKI & HEUER (2000):
• Alta disponibilidade de dados no dispositivo móvel, com o intuito de atingir
custos baixos e uma consistência de dados aceitável;
• Uso de informação de contexto semântico sobre o usuário, atributos da aplicação
e dos dados
27
3.1.3.Difusão de Dados
A difusão de dados, segundo BARBARÁ (1999), é a entrega de informações de um
conjunto de provedores para um grande número de clientes. Este processo de entrega de
informação é caracterizado pela assimetria nas comunicações. A largura de banda é
maior no sentido servidor-cliente do que no sentido cliente-servidor. Quando um
servidor recebe um pedido de dados ele localiza-o e retorna para o cliente os dados, este
modelo é chamado de pull-based. Quando a entrega dos dados é feita repetidamente
pelo servidor a um conjunto de clientes está se usando o modelo push-based. Neste
modelo o grande problema enfrentado é a decisão sobre quais itens de dados devem ser
disseminados.
3.2. Transações Móveis
Transação é uma coleção de operações que desempenham uma função lógica dentro
de uma aplicação do sistema de banco de dados. Cada transação é uma unidade de
atomicidade e consistência. As transações não devem violar nenhuma regra de
consistência no banco de dados. Portanto, o banco de dados que estava consistente antes
do início da transação deve permanecer consistente após o término da transação. No
entanto, durante a execução de uma transação, há a necessidade de aceitar
inconsistências temporárias. Estas inconsistências, embora necessárias, podem gerar
problemas caso ocorra uma falha (SILBERSCHATZ et al, 1999).
28
3.2.1. Propriedades das Transações Móveis
Para garantir que uma transação seja confiável e consistente e assegurar a
integridade dos dados, o sistema de banco de dados deve manter as propriedades de
atomicidade, consistência, isolamento e durabilidade que serão apresentadas a seguir.
3.2.1.1. Atomicidade
A transação deve ser atômica, ou seja, ela deve ser executada por completo, ou será
totalmente desfeita (SILBERSCHATZ et al, 1999). No caso de ocorrer qualquer
interrupção na execução da transação, é de responsabilidade do sistema gerenciador de
banco de dados determinar o que deve ser feito com a mesma ao se recuperar a falha. O
sistema de banco de dados mantém registrado os valores dos dados antes do início da
transação e só apaga essa cópia quando a transação for considerada confirmada. Caso
contrário, estes valores poderão ser restabelecidos.
Comumente, há dois tipos de falhas. O primeiro é quando uma falha ocorre por
erros nos dados de entrada, impasses ou alguma razão que impediria de concluir sua
tarefa com sucesso. No caso desta falha o aborto da transação pode ser executado pela
própria transação ou ainda pelo sistema gerenciador de banco de dados (SGBD),
caracterizando a recuperação de transações. O segundo tipo está ligado a quedas no
sistema, falhas de processadores, interrupções no canal de comunicação e assim por
diante. Este tipo de falha é involuntário à transação. A principal diferença entre esta
falha e a anterior, é que esta pode estar com dados ainda em memória volátil, o que
provocaria a perda dos dados.
29
3.2.1.2. Consistência
A consistência de uma transação é o banco de dados estar em um estado consistente
antes do início da transação a após o término da mesma continuar consistente.
Segundo ÖZSU & VALDURIEZ (2001), existe uma classificação quanto aos dados
sujos (valores de dados atualizados por uma transação mas ainda não confirmados), em
quatro graus de consistência:
• Transação com consistência de grau 3:
1ª consideração – a transação não sobrescreve dados sujos de outras
transações;
2ª consideração – a transação não consolida nenhuma gravação até concluir
todas as gravações, ou seja, até o final da transação completa;
3ª consideração – a transação não lê dados sujos de outras transações;
4ª consideração – outras transações não sujam quaisquer dados lidos por
esta transação até que esta seja executada por completo.
• Transação com consistência de grau 2: deve verificar as três primeiras
considerações acima citadas no grau 3.
• Transação com consistência de grau 1: deve verificar as duas primeiras
considerações citadas no grau 3.
• Transação com consistência de grau 0: deve verificar a primeira consideração
citada no grau 3.
Com estes graus de consistência é possível projetar aplicativos mais flexíveis e que
possam utilizar transações que operem em níveis diferentes.
30
3.2.1.3. Isolamento
O isolamento de uma transação garante que nenhuma outra transação visualize seus
resultados antes desta estar completa. O isolamento é um dos fatores mais importantes
para a manutenção da consistência entre as transações.
Considerando os graus de consistência vistos anteriormente, verifica-se que quanto
maior o grau de consistência maior deve ser o grau de isolamento. O isolamento das
transações permite que haja execução concorrente, ou seja, mais que uma transação
sendo executada simultaneamente.
Os níveis de isolamento são definidos segundo seu fenômeno (ÖSZU &
VALDURIEZ, 2001):
• Dados sujos: dados com valores já modificados por uma transação, mas não
efetivados ainda.
• Leitura não repetível ou leitura vaga: uma transação lê o valor de um item de
dados. Logo após outra transação elimina este item de dado e efetiva a
transação. Quando a primeira transação volta a ler o mesmo item e não o
encontra acaba gerando dois valores de leitura dentro de uma mesma transação.
• Fantasma: uma transação pesquisa em certos itens de dados, seguindo um
critério para a pesquisa, mas outra transação insere novas tuplas após essa
pesquisa. No momento em que a primeira transação pesquisa novemente haverá
mais dados que serão diferentes dos recuperados.
31
3.2.1.4. Durabilidade
Esta propriedade da transação garante que, uma vez executada e consolidada a
transação, seus resultados se tornem permanentes no banco de dados. Com isso, está
assegurado a permanência destes dados no banco, mesmo se ocorrerem falhas no
sistema.
3.3. Modelos de Transações Móveis
Segundo DUNHAM & KUMAR (1998) no passado pesquisadores tem
endereçado os problemas de processamento de informação móvel e nós classificamos os
aproximadores como reestruturação das transações ACID para processamento de
informação móvel e desenvolver um novo modelo de transação. Serão mostrados alguns
modelos de transações móveis.
Transação Kangaroo: é o primeiro e o único em redes móveis que inclui
movimento em sua estratégia de execução. O modelo é construido assumindo um multi
banco de dados onde o gerenciamento da transação é sempre desempenhado pela
estação base. Como a unidade móvel se movimenta, então o gerenciamento da transação
também se move. Cada transação é divida em subtransações que são executadas
independentemente do sistema de banco de dados da rede fixa.
Reporting e Co-transação: a origem das transações é representada em termos
de reporting, que pode compartilhar seu resultado parcial com a transação de origem a
qualquer hora e pode realizar a operação commint independentemente, e co-transações,
que é uma classe especial da transação de reporting, na qual pode ser forçada a esperar
por outras transações, depois de entregar seu resultado pode continuar a executar outras
32
operações. Essas duas transações podem ser executadas tranto na estação base como na
unidade móvel.
Clustering: assume um sistema totalmente distribuido, e é designado para
manter a consistência do banco de dados. O banco de dados é divido em cluster, e um
segundo nível de consistência dos dados é definido e mantido. Nesse modelo, uma
transação móvel é decomposta em um conjunto de transações fracas e completas. As
operações de leitura e escrita também são classificadas como fracas e completas. As
operações fracas são permitidas para acessar enquanto desconectadas. A transação pode
acessar ou atualizar dados na unidade móvel e pode se tornar inconsistente com os
dados da rede fixa.
Semantics Based: assume o processamento de uma transação móvel como um
problema de conexão e concorrência, podendo ter longos atrasos no processamento de
dados, bem como, desconexões. Essa abordagem utiliza a organização dos objetos para
dividir grandes e complexos objetos em pequenos fragmentos. O servidor do banco de
dados disponibiliza os fragmentos a pedido de uma unidade móvel. Para completar a
transação, a unidade móvel retorna os fragmentos para o servidor.
MDSTPM: é assumido que um Multidatabase Transaction Processing Manager
(MDSTPM) em cada unidade móvel. Cada componente do sistema de banco de dados é
responsável pelo gerenciamento das transações locais. Para facilitar a execução de
transações globais, uma camada de software adicional pode ser implementada,
permitindo o gerenciamento e coordenação de transações através dos múltiplos
componentes do sistema de gerenciamento (YEO & ZASLAVSKY, 1994).
33
3.4. Processamento de Consultas
Para se realizar uma consulta móvel, dependendo do caso, é necessário se ter a
localização exata da unidade. Podemos utilizar o GPS para consulta da localização, ou
através de uma triangulação das antenas que captam o sinal.
Como NASSU & FINGER (2000) disseram, quando um usuário faz uma
consulta diversos fatores contribuem no tempo de resposta do sistema, tais como:
• O tempo de transmissão de dados pode ser alto. A baixa taxa de transmissão dos
meios sem fio, a baixa confiabilidade, que pode gerar retransmissões freqüentes,
influem nesse tempo.
• A execução da consulta ao banco de dados pode ser demorada, principalmente
no caso em que as cidades são grandes, com grande número de ruas e
informações. O grande uso de forma concorrente também pode retardar o tempo
de resposta do banco de dados.
• O usuário pode estar desconectado da rede, por vontade própria ou não. O tempo
de desconexão pode ser longo e a resposta pode demorar mais para chegar ao
usuário que a solicitou.
A localização dos dados no processamento das consultas pode incluir dados
transientes, que trocam de valores de acordo com o processamento das consultas, e
dados contínuos, que são continuamente atualizados durante o movimento da unidade
móvel.
Em computação móvel, uma unidade móvel esta em constantes mudanças de
lugar. A localização depende dos dados existentes e o conjunto de dados e seus valores
são ligados com uma localização particular, onde respostas para consultas dependem de
34
onde são originadas. Então dependendo do lugar da consulta eu teria um resultado
diferente de uma consulta realizada em outro lugar.
Vários fatores são responsáveis pela posição do usuário após a consulta:
• Velocidade
• Aceleração
• Tipo de movimento, como uniforme, uniformimente variado, etc
• Direção
• Sentido
• Trajetória
• Tempo de processamento de consulta, demora na transmissão de dados,
desconexões ou quedas de sinal.
3.5. Recuperação de Falhas
É um processo responsável a preservar a consistência do banco de dados após
falhas do sistema, de transações ou de meios de comunicação.
Em sistemas distribuídos a recuperação de falhas é baseada em pontos de
recuperação, conhecidos como checkpoints. No caso de falhas e desconexões, a
aplicação usa o último checkpoint, salvo para reiniciar sua execução (PITOURA &
SAMARAS, 1998).
A unidade móvel deve estar sempre informada sobre qual célula se encontra e
quando o sistema entrará em modo de desconexão, pois ela é responsável por gerar um
checkpoint caso mude de célula ou haja uma desconexão. Um checkpoint global
consiste de um conjunto de checkpoints locais. Os estados globais são armazenados e
usados pelo protocolo para recuperar falhas das aplicações. Um estado global inclui o
35
estado de cada processo que faz parte da aplicação distribuída e possivelmente algumas
mensagens. Para uma recuperação correta, o protocolo pode salvar um estado
consistente global.
De acordo com (NEVES & FUCHS, 1997), os protocolos checkpoint são
classificados em duas categorias:
• Protocolos coordenados: a criação dos checkpoints é realizada em modo
conectado, para garantir a consistência e recuperabilidade do checkpoint global.
O protocolo requer o envio de mensagens para diferentes unidades móveis, para
que ocorra a sincronização no processo de checkpoint, e as vezes pode ocorrer
problema de desconexão.
• Protocolos não coordenados: permitem a criação de checkpoints independentes,
sem a necessidade de comunicação, desse modo, o processo pode continuar
durante as desconexões. No entanto, mensagens precisam ser trocadas durante a
recuperação para localizar o checkpoint global, exigindo a coleta de informações
sobre outras unidades móveis.
Devido às características como mobilidade, baixa largura de banda e
desconexões, protocolos coordenados e não coordenados são considerados inadequados
para o ambiente móvel (PITOURA & SAMARAS, 1998).
NEVES & FUCHS (1997) propõem um novo tipo de protocolo que armazena o
estado global sem troca de mensagens. Durante a execução da aplicação, o protocolo
mantém o estado global em um local fixo para recuperar falhas permanentes, falhas de
hardware, e outro em unidades móveis para recuperar falhas temporárias, falhas de
software.
36
Algumas características de um esquema de checkpoint em um ambiente móvel
são analisadas a seguir.
3.5.1. Localização
Para que exista a comunicação entre a rede fixa e a unidade móvel, é necessário
saber a localização exata desta última. A localização de uma unidade móvel dentro de
uma rede fixa não é constante devido a sua mobilidade. Uma unidade móvel precisa ser
localizada para depois determinar seu checkpoint. O protocolo pode também manter a
trilha dos lugares onde o estado do processo foi salvo.
3.5.2. Desconexão
Uma unidade móvel é dita desconectada quando esta fora da faixa de
transmissão dos emissores. Durante a desconexão, todas as informações armazenadas
em sites remotos não estão acessíveis às unidades móveis. Desta forma, uma unidade
móvel fica impossibilitada de enviar ou receber mensagens.
3.5.3. Energia
Devido às restrições oferecidas pelo tempo das baterias utilizadas pelos dispositivos
móveis o consumo das mesmas deve ser reduzido. O protocolo checkpoint tem a função
de reduzir a quantidade de informações que são adicionadas para as mensagens e evitar
o envio de mensagens extras, realizando o menos número possível de acessos ao
servidor.
37
3.5.4. Rede
A diversidade de tecnologias utilizadas em redes wireless faz com que as
características da rede não sejam constantes, tais como, custos, velocidade e latência. O
protocolo checkpoint deverá se adaptar as características da rede onde está atuando.
3.5.5. Falhas
Unidades móveis podem apresentar falhas de software, que são gerenciadas por soft
checkpoints e são armazenados localmente na unidade móvel, e de hardware, que são
gerenciadas por hard checkpoints e são armazenados na rede fixa. O protocolo
checkpoint deve fornecer mecanismos para tolerar os tipos de falhas que possam a vir
ocorrer com as unidades móveis.
3.5.6. Estratégias de Recuperação
Uma estratégia de recuperação essencialmente tem dois componentes, segundo
KRISHNA (1996): uma estratégia de state-saving e uma de handoff.
• State-saving – as estratégias apresentadas aqui são baseadas no tradicional
checkpointing e técnicas de message-logging. Nessas estratégias o host
periodicamente salva o estado em um lugar seguro. Então, numa falha do host, a
execução pode ser recomeçada do último checkpoint salvo. Duas estratégias de
recuperação salvando o estado do processo serão discutidas aqui:
o No Logging: o estado do processo pode ser alterado, tanto na recepção
de mensagem de outro host, ou tanto na entrada de dados pelo usuário.
As mensagens ou as entradas de dados que alteram o estado são
38
chamados eventos de escrita. Num acesso No Logging o estado de um
dipositivo móvel é salvo num servidor toda vez que ocorre um evento de
escrita no dispositivo móvel. Depois de uma falha, quando o dispositivo
móvel reinicializa, o dispositivo manda uma mensagem pro servidor, que
então transfere o último estado para o dispositivo móvel. O dispositivo
móvel então lê o ultimo estado e recomeça a operação. É importante
salientar que a necessidade de uma freqüente transmissão do estado o
link sem fio é um fator limitante para esse esquema.
o Logging: o dispositivo móvel verifca seu estado periodicamente. As
mensagens e entradas de dados que modificam o estado do dispositivo
móvel são armazenadas. Caso uma mensagem seja recebida de outro
usuário, a estação base primeiro a loga, e depois a envia para o
dispositivo móvel, para ser executada. Em uma entrada de dados pelo
usuário, o dispositivo primeiro envia uma cópia para a estação base para
logging e depois do reconhecimento do dispositivo móvel, processa a
entrada e envia uma resposta ao usuário. Este procedimento garante que
as mensagens ou entradas do usuário não sejam perdidas devido às falhas
que possam ocorrer.
• Handoff – um grande problema para a recuperação de dados é a mobilidade de
estações móveis de célula, não sendo possível à definição exata de sua
localização. A figura 7 representa a execução de um handoff. Os dispositivos
móveis 1 e 2 executam algoritmo distribuído.
39
FIGURA7 - Handoff – Estratégia de Recuperação
Na execução de um handoff, a estação base 2 armazena o checkpoint e as
mensagens de log do dispositivo móvel 2. Durante a execução, o dispositivo
móvel 2 se desloca para a célula da estação 3, e depois para a célula da estação
4. O processo de handoff ocorre entre os limites das estações 2 e 3, e entre as
estações 3 e 4. Se uma falha ocorrer entre o dispositivo móvel 2 até sua chegada
na estação 4, as informações poderão ser recuperadas devido ao seu
armazenamento na estação 2. Caso este processo não seja realizado, isto é, as
informações não sejam armazenadas, a estação base onde se encontra o
dispositivo móvel deverá identificar onde o checkpoint foi salvo. Este
procedimento poderá ser baseado em uma transferência durante o processo de
handoff sobre o estado do dispositivo móvel.
Existem três modos de transferir informações durante o handoff: pessimistic,
lazy, trickle.
Estação Base 4
Estação Base 3
Estação Base 2
Estação Base 1
Estação Base 5
Disp Móvel 1
Disp Móvel 2
Disp Móvel 2
Disp Móvel 2
Rede Fixa
40
Pessimistic: em um deslocamento de um dispositivo móvel de uma célula para
outra, o checkpoint é transferido durante o handoff. Caso a estratégia de logging
esteja sendo usada, a mensagem de log é transferida juntamente para a nova
célula da estação base. Uma vez recebido o checkpoint ou o log, a estação base
envia um reconhecimento para a estação anterior e esta cancela as informações,
desde que a unidade móvel não esteja mais em sua célula. A principal
desvantagem ;e que esta aproximação requer que um grande volume de dados
seja transferido durante o handoff.
Lazy: durante o handoff não há transferência de log e checkpoint. A estratégia
cria uma lista de estações base de células visitadas por um dispositivo móvel que
pode utilizar as estratégias de logging e not-logging descritas anteriormente. A
desvantagem desta estratégia é o armazenamento de checkpoints e logs em
diferentes estações base.
Tricle: garante que logs e checkpoint correspondentes a um dispositivo móvel,
estejam sempre na estação base mais próxima. Durante o handoff, uma
mensagem é enviada para a estação precedente para transferir qualquer log ou
checkpoint que tenha sido armazenado em um dispositivo móvel. Semelhante à
estratégia Lazy, a estação base corrente envia uma mensagem de controle para a
nova célula da estação base, identificando a localização da célula do dispositivo
móvel, que grava a autenticação do dispositivo móvel precedente.
41
CAPÍTULO IV
4. TECNOLOGIAS DE SINCRONIZAÇÃO
Para BADRINATH & PHATAK (2001) a sincronização em ambientes
móveis pode ser definida como o ato de estabelecer equivalência entre duas coleções de
dados, entre cliente e servidor, após a ocorrência de alteração nos registros
armazenados. Depois de sincronização de dados cada elemento de dados em uma
coleção é mapeado por um elemento de dados em outra, sendo que seus dados são
equivalentes, entretanto não necessariamente idênticos.
4.1. Tipos de Sincronização
4.1.1. One-Way
A sincronização One-Way compreende a transferência de atualizações de dados
em sentido único (PALAZZO & PULIOFITO, 2000). Após um dispositivo estabelecer
conexão com outro ele indica todas as alterações realizadas localmente. Após a
transmissão, os dados são aplicados no banco de dados do receptor. O dispositivo
receptor não recebe nenhuma mensagem de aceite ou erro na efetivação das requisições
ao banco de dados.
O plano One-Way pode ser aplicado de duas formas: no sentido cliente/servidor
ou ao contrário.
42
a) One-Way Cliente/Servidor
Nesse tipo de sincronização o cliente é responsável por inicia-la e submeter todas
as modificações ao servidor, mas o servidor não retorna o resultado final das ações
realizadas no banco de dados.
b) One-Way Servidor/Cliente
O servidor que inicia a transmissão, que conecta-se com o cliente e submete
todos os dados atualizados no banco de dados consolidado . Após terminar a
transferência, o cliente possui a versão atualizada de todos registros do banco de dados
do servidor. O servidor não captura nenhuma alteração feita pelo cliente.
4.1.2. Two-Way
A transmissão das modificações ocorre nos dois sentidos, tanto do cliente como
do servidor. A sincronização é iniciada pelo cliente. O servidor identifica e trata os
conflitos existentes retornando ao cliente os dados corretos. No final, o cliente e o
servidor possuem os mesmos dados.
4.2. Protocolos de Sincronização
Um protocolo de sincronização define o fluxo de trabalho para a comunicação
durante uma seção de sincronização de dados quando o dispositivo móvel é conectado à
rede fixa. Para BREITBART, KOMONDOOR, RASTOGI (1999), deve dar suporte a
identificação de registros, comandos de protocolo comuns para sincronização de dados
local e de rede, e poder apoiar a identificação e resolução de conflitos de sincronização.
43
Atualmente diversos fabricantes oferecem uma variedade de produtos de
sincronização de dados. Cada protocolo funciona apenas para transportes específicos
implementados para alguns dispositivos. A proliferação de tecnologias de sincronização
complica as tarefas de usuários, fabricantes de dispositivos, provedores de serviços e
desenvolvedores de aplicações. A falta de um protocolo de sincronização de dados
comum impede o crescimento do uso de dispositivos móveis, restringindo a habilidade
de usuários para ter acesso dados e limitando a entrega de operações realizadas sobre
dados móveis. Todos os protocolos tendem a alcançar o pentágono, Figura 8, mas
nenhum protocolo estudado alcança tal objetivo.
FIGURA 8 – O Pentágono da Sincronização em Ambientes Móveis
A sincronização entre dispositivos móveis é determinada por uma variedade de
fatores, incluindo a latência da sincronização, a quantidade de bateria utilizada, o custo
monetário envolvido (conexão a rede, tempo, etc.), a robustez e a confiabilidade da
rotina de sincronização. Um bom protocolo de sincronização é aquele que tende a estas
direções.
Os dispositivos móveis são limitados na comunicação devido às ligações de rede
que os conectam, possuem poderes computacionais limitados, memória e bateria
Volume de dados transmitido
Tamanho da rede
Memória Ponto central de falha
Computação
44
limitadas. Os vértices do Pentágono, Figura 8, representam a escalabilidade da
sincronização em dispositivos móveis. A computação e a comunicação têm ligação
direta com a latência e utilização da bateria. A memória dos dispositivos móveis é
limitada e nenhum protocolo que consumir muita memória será apropriado. Ao mesmo
tempo, nós desejamos desenvolver protocolos que permitam que um grande número
dispositivos na rede sincronizem entre si, que sejam robustos e preferivelmente peer-to-
peer em vez do centralizado, mantendo-se na linha com a natureza de redes ad-hoc .
Aplicações que reconciliam e solucionam mudanças em dados entre duas fontes
distintas são amplamente utilizadas por empresas de geração de softwares para sistemas
móveis. Porém, o mercado de sincronização atual consiste em soluções proprietárias
múltiplas, que não satisfazem todo o espectro de funcionalidades e o suporte requerido
aos dispositivos pela maioria das organizações. Muitas organizações não estão dispostas
a desenvolver múltiplos canais e a implementar várias soluções de sincronização para
permitir o acesso de múltiplos dispositivos a um único banco de dados devido à
complexidade e o custo de manutenção requerido.
4.2.1. Hotsync
Dispositivos Palm rodam na plataforma Palm Operating System que fornece o
protocolo HotSync para sincronizar os bancos de dados do Palm com o do micro
Desktop. O HotSync (PALMOS) opera em dois modos, dependendo do histórico de
sincronização do dispositivo com o micro computador em particular.
O FastSync ocorre quando o dispositivo sincroniza com o mesmo micro
computador que sincronizou pela última vez. Neste caso o dispositivo sincroniza
processando os registros baseados nas flags de status de cada registro que dizem se este
45
foi modificado, criado ou apagado. O FastSync é a melhor opção quando a
sincronização ocorre somente entre dois dispositivos, sendo que o dispositivo poderá
recordar flags de status somente de um micro computador.
O Slowsync ocorre quando a condição principal do Fastsync não é encontrada.
Neste caso o dispositivo transfere a base de dados inteira ao PC a ser trabalhado pela
comparação. Enquanto o espaço de armazenamento do dispositivo se torna maior e as
bases de dados se tornam maiores, a introdução da latência crescente envolvida em
transferir a base de dados inteira do PDA ao PC para a sincronização subseqüente torna-
se cada vez mais importante.
Mas pode-se dizer que com o avanço de tecnologias mais rápidas de conexão
dos dispositivos móveis com os PCs e as redes sem fio cada vez mais rápidas a latência
do slowsync se transforma um assunto tratável.
4.2.2. Intellisync
O Intellisync (PUMATECH), produto fabricado pela Pumatech, faz sempre a
sincronização do tipo Fastsync, utilizando um servidor central com o qual os
dispositivos móveis sincronizam sempre. Isto significa que todos os dispositivos
sincronizados têm que manter as flags de status das atualizações com respeito somente
ao usuário central, permitindo um Fastsync todas as vezes. A Figura 9 mostra uma rede
típica da companhia usando a arquitetura de Intellisync.
46
FIGURA 9 – Servidor Intellisync
Esta arquitetura não é projetada para o caso geral onde um dispositivo pode
sincronizar com outros dispositivo em uma rede do tipo peer-to-peer. No geral, uma
arquitetura distribuída baseada na sincronização do tipo peer-to-peer fornece o
desempenho muito melhor da rede, nos termos de robustez e escalabilidade, do que uma
rede centralizada.
4.2.3. SyncML
SyncML , segundo SYNCML (2002) é uma iniciativa da indústria aberta suportada
por muitas companhias, incluindo Ericsson, IBM, Lótus, Matsushita, Motorola, Nokia,
OpenWare e Starfish.
Pode ser considerada como uma linguagem padrão para sincronizar diferentes
dispositivos e aplicações sobre qualquer rede. Com o SyncML qualquer tipo de
informação pode ser sincronizada para manter a informação consistente e atualizada,
não importando a localização do dispositivo e da rede.
47
O protocolo possui as seguintes características:
• Opera efecientemente sobre redes wireless e com fios.
• Suporta uma variedade de protocolos de transporte, como HTTP, WSP, OBEX,
redes TCP/IP, SMTP, POP3, IMAP, e protocolos proprietários.
• Acesso a dados de uma variedade de aplicações.
A figura 10 mostra o SyncML framework. Este framework ajuda na análise de
implementação de um modelo de sistema associado com a implementação do SyncML.
Os blocos maiores desse framework é a representação do protocolo SyncML, conceitual
adaptador SyncML e a interface SyncML. O protocolo de sincronização de dados
SyncML está fora do framework SyncML para manter o framework de fácil
implementação e atividade conjunta.
FIGURA 10 – Servidor SyncML
48
A aplicação “A” descreve um serviço de rede que provê serviço de sincronização de
dados para a aplicação “B”. Vamos assumir que a aplicação “B” deseja se sincronizar
com a aplicação “A”. O serviço e o dispositivo são conectados sobre um protocolo de
transporte em comum, como HTTP. A aplicação “A” implementa o processo “Sync
Engine” utilizando o protocolo de sincronização de dados manifestando o acesso cliente
para o “Sync Server” – um recurso de rede. O “Sync Server Agent” se comunica entre
as aplicações cliente e o “Sync Engine” para gerenciar o acesso a rede e para e de as
comunicações. Invocando as funções definidas na interface SyncML para executar essas
capacidades. A interface SyncML não é nada mais que uma aplicação para o “SyncML
Adapter”. “SyncML Adapter” é um processo conceitual que pode ser considerado como
ponto de entrada e saída para a aplicação “A”.
Usando a representação de protocolo, SyncML é um protocolo de sincronização que
define como inicializar, sincronizar e encerrar a sincronização incluindo a troca de
dados entre os dispositivos sincronizados. SyncML é programado considerando ele
como um protocolo de sincronização comum, tendo cuidado nos casos onde os serviços
de rede e os dispositivos de armazenamento de dados que estão começando a ser
sincronizados estão em formatos diferentes ou sendo usados por diferentes programas.
Há sete tipos diferentes de sincronização definidas pelo SyncML, dependendo de como
a sincronização é inicializada pelo cliente eu servidor e a transferência de informação
entre eles.
1. Two-Way Sync: Este tipo de sincronização é o mais normal e largamente usado
onde o servidor e o cliente trocam somente os dados modificados no final.
Cliente é sempre esperado para começar a sincronização mandando as
modificações primeiro.
49
2. Slow Sync: Este tipo de sincronização como ser considerada como uma forma
de sincronização two-way com uma exceção de que o cliente envia o banco de
dados inteiro ao invés de somente as modificações, pedindo ao servidor para
preparar a analise da sincronização para os dados entre cliente e o servidor. O
servidor retorna sempre as modificações requeridas pelo cliente.
3. One-Way Sync from Client only: Somente durante este tipo de sincronização, o
cliente envia todas as modificações para o servidor, mas não espera nenhuma
modificação do servidor.
4. Refresh Sync from Client only: Este é um tipo especial de One-Way Sync from
Client , onde o cliente exporta todos os dados do banco de dados para o servidor.
O servidor é esperado repor os dados existentes com o banco de dados recebido
do cliente.
5. One-Way Sync from Server only: Este tipo de sincronização envia todos os
dados modificados do servidor para o cliente e não espera qualquer modificação
do cliente.
6. Refresh Sync from Server only: Este é um tipo especial de sincronização One-
Way Sync from Server, onde o servidor esporta todos os dados do banca de
dados para o cliente. O cliente é esperado repor os dados existentes com o banco
de dados recebido do servidor.
7. Server Alertd Sync: O servidor alerta o cliente para preparar uma sincronização.
Ele também diz ao cliente qual dos tipos de sincronização acima a ser usada
entre eles.
50
SyncML tenta conseguir potencialidades do Fastsync, requerendo que todos os
dispositivos da rede possuam flags de status para cada registro. Isso pode causar uma
demanda de memória muito grande. Onde a complexidade aumenta conforme o número
de dispositivos em rede. Isso não é sustentável em redes com vários dispositivos.
4.2.4. CPISync
Há muitas instâncias de sincronização de dados onde há necessidade de
sincronizar dados semelhantes em dispositivos diferentes. O CPISync, segundo
Trachtenberg, Starobinbki, e Agarwal (2001,2002), que é uma abreviação de
“Characteristc Polynominal Interpolation Syncronization”, faz a complexidade do
tempo da sincronização quase independente do tamanho do conjunto de dados a ser
sincronizado, e somente dependente do número de diferenças entre os dois conjuntos de
dados. Este é um contraste marcante em relação ao Slowsync que utiliza uma
transferência de dados inteira entre os hosts enquanto sincronizando os dados, fazendo a
sincronização dos dados um tempo linear em relação ao numero de registros no banco
de dados.
CPISync é baseado em uma solução recente para um conjunto de problemas de
reconcialização por Minsky, Trachtenberg e Zippel (2000) é escalável com o número
de dispositivos na rede e o tamanho do banco de dados a ser sincronizado. Esta solução
envolve mais recurso computacional comparado ao Slowsync, este recurso
computacional pode ser distribuído assimetricamente entre os hosts. Isto significa que
em casos onde os hosts tem capacidades computacionais diferentes (ex. PDA e PC), o
CPISync pode transferir mais dos recursos computacionais para o pc, permitindo uma
rápida execução do CPISync comparado a uma aproximação simétrica.
51
5. AMBIENTE EXPERIMENTAL E RESULTADOS OBTIDOS
Nosso ambiente experimental é composto por um cliente móvel representado por
um Palm M100 e um servidor fixo, um Atlon XP 1.4 GHz. A seguir descreveremos
todo o ambiente utilizado, as ferramentas de desenvolvimento utilizadas para
desenvolver o protótipo de sincronização e a análise comparativa dos protocolos de
sincronização de dados estudados.
5.1. Descrição do Ambiente Utilizado
Para nosso experimento utilizamos um cliente móvel que faz operações de
consulta e atualizações em um banco de dados consolidado pertencente a um servidor.
Por motivos burocráticos não foi possível conseguir dispositivos recentes a
tempo para nosso experimento, possuíamos apenas um dispositivo portátil, um Palm
M100, para fazer o papel de cliente.
Utilizamos um computador Atlon XP 1.4 GHz, rodando Windows XP como
servidor e um Palm M100 funcionando como cliente móvel. O PalmOS Emulator
(POSE) também foi utilizado funcionando como clientes móveis inexistentes.
A utilização do Emulador não é recomendada só para suprir a falta de um
dispositivo, mas sim para testar aplicações antes de serem instaladas nos dispositivos
físicos. No Emulador as aplicações rodam mais rápido e pode-se evitar um Hard Reset
caso a aplicação desenvolvida possua algum erro.
52
5.2. Iniciando o Desenvolvimento na Plataforma PalmOS
Quando iniciamos nosso projeto, a previsão que havia era a de conseguir
trabalhar com dois dispositivos portáteis adquiridos pela universidade, só que por vários
motivos não conseguimos os dispositivos a tempo. Tínhamos em mãos um Palm M100
e algumas idéias formuladas.
As principais dúvidas que surgiram foram a de “Como começar a desenvolver?”
e “Que ferramenta utilizar?”. Algumas dúvidas foram sendo esclarecidas ao longo de
todo o estudo desenvolvido e serão apresentadas a seguir.
A primeira coisa que tivemos que ter como pré-requisito antes do
desenvolvimento foi a de se habituar com o dispositivo que tínhamos disponível, o Palm
M100.
Após conhecer bem o Palm que iríamos trabalhar descobrimos a existência do
Emulador do PalmOS , o Palm OS Emulator (POSE). Assim poderíamos desenvolver
algum aplicativo e testá-lo no emulador. O emulador simula o funcionamento de
diversos modelos diferentes do Palm. Para simular cada modelo é necessário carregar a
ROM específica no emulador.
O emulador é uma ferramenta muito importante para desenvolvedores Palm, é
altamente recomendável que, antes de colocar a aplicação funcionar no Palm, teste-se
ela no emulador.
A maioria dos projetos para Palm envolvem dois tipos de programas:
53
- Aplicativo executado no Palm
Esse é o programa que será executado no Palm, desenvolvido com a ferramenta
de programação escolhida. Os caminhos para escolher a melhor ferramenta serão
descritos mais tarde.
- Conduit
O Conduit é uma DLL responsável pela troca de dados entre Palm e o Desktop
nos dois sentidos.
Atualmente existe uma variedade menor de ferramentas disponíveis para
produção dessas DLLs, comparada ao número de ferramentas disponíveis para o
desenvolvimento de aplicativos para o Palm.
Alguns conceitos sobre o desenvolvimento na plataforma PalmOS são descritos
a seguir.
5.2.1. PDB
O Palm Database (PDB) é o formato padrão que o PalmOS utiliza para
armazenamento de dados, em forma de registros. Apresentaremos aqui o modo como
são armazenados os dados dentro do PDB, as estruturas internas e os conceitos
envolvidos na sua utilização.
54
O formato PDB é composto de blocos com tamanho variável, exceto o Header
que contém sempre 72 bytes. Cada bloco representa um conjunto de informações dentro
do Banco de Dados. Veja a disposição dos blocos abaixo:
TABELA 1- Distribuição dos Blocos no PDB
Header do Banco de Dados (Tamanho Fixo 72 bytes) Lista de Entradas de Registros (Tamanho variável)
AppInfo Block (Opcional, Tamanho Variável) SortInfo Block (Opcional, Tamanho Variável)
Entradas de Registros (Tamanho Variável)
Detalhamento dos Blocos
Header
No Header, são gravadas informações que identificam o Banco de Dados no
PalmOS e estão detalhadas as localizações dos blocos de informações dentro do Banco
de Dados. A estrutura apresentada abaixo, detalha cada parte do Header, começando
pela posição 1, como o primeiro byte do Bloco.
TABELA 2 – Descrição do Header
Posição Tamanho Conteúdo 1 a 32 32 Nome genérico do Banco de Dados. Exemplo:
"Banco_Generico". Os bytes que não forem usados após o nome devem ser preenchidos com ZERO. Este nome aparece na Lista "Info", de Bancos de Dados Instalados no Palm.
33 a 34 2 Flags do Banco de Dados. 16 Bits contendo detalhes sobre características do Banco de Dados no PalmOS.
0x0002 – Somente para Leitura
0x0004 – AppInfoBlock Modificada
0x0008 – Se Setado, o HotSync fará o Backup do
55
Banco de Dados
0x0010 – OK para instalar sobre uma cópia já existente no Palm
0x0020 – Força RESET do Palm após instalar
0x0040 – Não permite envio do Banco via Infravermelho (Beaming)
35 a 36 2 Versão do Banco de Dados, informada pelo desenvolvedor.
37 a 40 4 Data de Criação do Banco de Dados. 41 a 44 4 Data de Modificação do Banco de Dados. 45 a 48 4 Data do Último Backup. 49 a 52 4 Número de Modificações no Banco de Dados. 53 a 56 4 Posição absoluta a partir do início do Header do
Banco de Dados, identificando a localização do AppInfo Block. Se não houver AppInfo Block no Arquivo, os quatro bytes são preenchidos com Zero.
57 a 60 4 Posição absoluta a partir do início do Header do Banco de Dados, identificando a localização do SortInfo Block. Se não houver SortInfo Block no Arquivo, os quatro bytes são preenchidos com Zero.
61 a 64 4 PDB Type. Quatro caracteres identificando o tipo do Banco de Dados. Esta informação mais o Identificador do Criador do Arquivo, é a forma mais comum de abrir o Banco de Dados utilizando as funções da API do PalmOS.
65 a 68 4 Creator ID. Identificador único do criador do Banco de Dados.
69 a 72 4 Unique ID Seed. Raramente utilizado, serve para armazenar um número de identificador único para o PDB. Somente 3 bytes são utilizados, sendo que o quarto byte serve apenas para alinhamento dos bytes. Normalmente contém Zeros, pois não há documentação disponível para sua utilização.
Lista de Entradas de Registros (Record List)
A Record List funciona como um índice seqüencial, ou relação de todos os
registros gravados no Banco de Dados. Contém entradas informando a Posição Absoluta
56
(em bytes) dos registros a partir do Início do Header. A primeira entrada corresponde ao
primeiro registro do Banco de Dados, e assim por diante. Cada Entrada de Registro tem
8 bytes. Veja o detalhamento abaixo:
TABELA 3 – Lista de Entradas de Registros
Posição Tamanho Conteúdo 1 a 4 4 Posição Absoluta (em bytes) a partir do início do
Header onde começa a próxima Record List (Como dissemos logo acima, raro, porém possível). Normalmente contém Zeros.
5 a 6 2 Número de Entradas de Registros na Record List (Consequentemente, número de registros no Banco de Dados). Observação importante: se o Banco de Dados estiver vazio, as duas próximas posições (7 a 8) devem ser preenchidas com Zeros, indicando final do Banco de Dados.
7 8 Primeira Entrada de Registro com tamanho de 8 bytes. Os registros são identificados seqüencialmente a partir do primeiro até o último.
Entradas de Registros
TABELA 4 – Entradas de Registros
Posição Tamanho Conteúdo 1 a 4 4 Posição Absoluta (em bytes) a partir do início do
Header onde começa o Registro no Banco de Dados.
5 1 Atributos do Registro (Vide Tabela abaixo). 6 a 8 3 Identificador único do Registro (Unique ID). Este
identificador é estabelecido automaticamente pelo PalmOS quando o registro é criado. É possível alterar o valor do Unique ID, porém não há garantias que esse número seja preservado no próximo HotSync.
57
Atributos do Registro
TABELA 5 –Atributos do Registro
Bit Significado 0,1,2,3 Identificam a Categoria à qual o Registro pertence
(Vide AppInfo abaixo sobre Categorias) 4 Registro marcado como Secret (Privado) 5 Registro marcado como Busy (Ocupado pelo
Sistema Operacional) 6 Registro marcado como Dirty (Modificado
recentemente) 7 Registro marcado como Deleted (Apagado, porém
não removido ainda).
Dentro do Sistema, podemos comparar os bits através de operações de AND
lógico e identificar os atributos do registro
AppInfo Block
O AppInfo Block é uma área que pode ser utilizada dentro de um Banco de Dados
para guardar qualquer tipo de informação que o desenvolvedor achar necessário. No
formato PDB não há definições de campos, tipos de dados, etc. Para suprir essa
dificuldade, é comum utilizar o AppInfo Block para gravar infomações a estrutura de
campos. Isso fica a critério do desenvolvedor, não há nenhuma API do PalmOS para tal
finalidade.
Outra característica do AppInfo Block é que nele é gravado o conjunto de
Categorias de um Banco de Dados. Categorias (Categories no PalmOS) são
classificações que aplicadas aos registros de um Banco de Dados. Cada registro pode ser
associado à uma Categoria e o PalmOS dispõe de rotinas que permitem filtrar a busca
de registros por categoria. Um exemplo típico do uso de Categorias é a aplicação
58
Address do Palm. Nesta aplicação, é possível classificar os registros como Business,
Personal, QuickList, etc. São permitidas 16 Categorias por Banco de Dados, sendo que
normalmente a primeira da lista é criada com o nome "Unfiled", para indicar que o
registro não foi classificado em nenhuma categoria (default).
Estrutura da Category Data dentro do AppInfo Block
TABELA 6 – Estrutura da Category
Posição Tamanho Conteúdo 1 2 16 bits indicando qual das 16 categorias foi
renomeada. É um controle para a aplicação de HotSync que houve mudança nas Categorias.
3 256 Array de 16 strings terminadas em Zero (NULL terminated), com 16 bytes cada string, representando o nome de cada uma das 16 categorias do Banco de Dados. Se forem classificadas menos do que 16 categorias, deve-se inicializar as outras com Zero.
259 16 Array de 16 bytes representando o código de identificação de cada Categoria (ID). Normalmente é inicializado com valores de 1 a 16.
275 1 Último código de categoria utilizado (ID). 276 1 Um byte não utilizado (Somente para
alinhamento de bytes dentro da estrutura).
O PalmOS dispõe de rotinas de inicialização da Category Data em sua API, porém,
se o arquivo PDB for gerado com uma ferramenta específica, deve se ficar atento para
gerar a estrutura das categorias na ordem correta.
Dentro do AppInfo Block, logo após o bloco de categorias, podem ser colocados os
dados específicos da aplicação.
59
SortInfo Block
O SortInfo Block é uma área dentro do PDB destinada a aplicações específicas.
Não tem fomato predefinido, nem tamanho. Sua localização é dada pela posição
absoluta dentro do Banco de Dados, através do campo específico no Header do PDB. A
maioria das aplicações não usa o SortInfo Block.
Entradas de Registros
Os registros que foram apontados na Record List são colocados logo após o último
bloco de dados específicos da aplicação (AppInfo/SortInfo) se houver. Como já
dissemos os registros não tem formato, nem padrão de gravação, tamanho, etc (são
conhecidos como Raw Data). A única consistência é que a posição absoluta (em bytes)
do registro dentro do PDB seja indicada na sua entrada correspondente na Record List.
5.2.2. PRC e Runtime
PRC é a extensão do aplicativo desenvolvido para rodar no Palm. Em linguagem
simplificada, é equivalente ao “.EXE” ao qual estamos acostumados.
Algumas ferramentas simplesmente geram um PRC, após o processo de
compilação.
60
Outras ferramentas trabalham com run-time, ou seja, em modo interpretado.
Geralmente o run-time é instalado no Palm durante o processo de instalação da própria
ferramenta. Nem sempre o arquivo gerado fica visível, mas o importante é que ele é
transportado para o Palm durante o próximo HotSync, juntando-se ao run-time da
ferramenta. Ao ser executado, o run-time aciona o aplicativo, interpretando os
comandos e executando-o.
Dependendo da ferramenta utilizada não há como optar em desenvolver o próprio
Conduit e pode-se ficar sujeito a trabalhar com o Conduit nativo da ferramenta, e toda
troca de dados estará sujeita às regras da ferramenta. Com isso, perde-se muita
flexibilidade.
5.2.3. Conduit
O Conduit, que é uma DLL ativada durante o processo de sincronização. O
Conduit tem a capacidade de importar, exportar e sincronizar dados entre o dispositivo
móvel e o desktop. Ele pode utilizar o tipo de transferência que achar mais conveniente,
escolhendo entre one-way e two-way. Com ele podemos atualizar nosso banco de dados
móveis com o servidor e vice-versa.
Tipos de Conduit
- Conduit de Instalação: este conduit tem como finalidade instalar aplicações na
memória principal do dispositivo móvel ou em seu cartão de expansão. Geralmente este
61
conduit é ativado durante o processo de sincronização. Os aplicativos provenientes do
servidor são instalados no dispositivo móvel sem que este solicite.
- Conduit de Backup: este conduit faz uma cópia fiel dos dados localizados na unidade
móvel para o micro servidor.
- Conduit de Sincronização: sincroniza dados entre unidades móveis ou fixas. O
programador do conduit é quem indica o que irá ocorrer. Dados podem ser copiados ou
atualizados no desktop e vice-versa.
Em nosso experimento utilizamos um conduit de sincronização que
descreveremos mais tarde.
A DLL desenvolvida para a sincronização, chamada de Conduit, pode ser feita
através de algumas ferramentas:
• Delphi
• Visual C++
• Java e Visual Basic
A escolha da ferramenta vai depender necessariamente da habilidade com a
linguagem. Optamos por desenvolver nosso Conduit em Delphi, pois já temos
conhecimento nessa linguagem a algum tempo.
62
5.2.4. Ferramentas de Desenvolvimento
Existem diversas ferramentas para desenvolvimento de aplicações para
dispositivos móveis. As ferramentas não ficam distribuídas em melhores ou piores, mas
sim em as mais adequadas ao projeto específico. Para escolher a ferramenta levamos em
consideração alguns pontos relevantes:
- Tamanho e Performance do aplicativo X Facilidade e Rapidez de
desenvolvimento
É claro que os aplicativos desenvolvidos em liguagem C terão um tamanho bem
menor do que os demais e a performance poderá ser bem diferenciada. Entretanto, o
desenvolvimento em C requer tempo e habilidade por nós já esquecida. A flexibilidade
da linguagem C nos dá um poder muito grande, como por exemplo acessar todas as
funções do PalmOS. Mas a dificuldade em desenvolver é bem maior comparado a das
ferramentas "RAD" , o que implica no fator TEMPO, que é tão importante na hora de
dimensionar o prazo de um projeto.
Ficou claro que quanto maior a facilidade e rapidez de desenvolvimento, maior a
possibilidade de termos um aplicativo bem dimensionado, ou um aplicativo não tão
grande porém sujeito a trabalhar com run-time.
- Run-time
Avaliar o espaço ocupado e se a empresa cobra um custo por run-time.
63
- Preço dos Aplicativos
Avaliar o preço do aplicativo, ficar também atento à licença de uso por tempo
determinado, além da política de upgrades.
Podemos separar as ferramentas de desenvolvimento em categorias, onde os
principais termos de comparação são FLEXIBILIDADE x FACILIDADE/RAPIDEZ de
desenvolvimento.
Na categoria FÁCIL e RÁPIDO, porém pouco flexível, e ainda sujeito à run-time
presente no Palm, ficaram, entre outros, o Satelite Forms, o CASL Tools e o Pendragon
Forms. São ferramentas para desenvolvedores bem acostumados a desenvolver sistemas
em Delphi, VB e semelhantes.
Na categoria FLEXÍVEL e LEVE, porém com uma curva lenta de aprendizado,
com o pré-requisito de muito conhecimento em linguagem C, estão o CodeWarrior e o
GCC.
O CodeWarrior é o ambiente oficial de desenvolvimento para o PalmOS e
permite criar aplicações em ANSI C e C++ no Windows 95/98/NT e Macintosh.
O seguinte quadro comparativo foi criado para avaliação das ferramentas
encontradas:
Tabela 7 – Ferramentas de desenvolvimento para PalmOS
Ferramenta Runtime Flexibilidade Curva de Aprendizado Conduit próprio CodeWarrior Não Grande Lenta Não GCC (PRC Não Grande Lenta Não
64
Tools) Satelite Forms
Sim Média/Grande Rápida Sim
Pendragon Forms
Sim Pequena Rápida Sim
CASL Tools Sim Média Rápida Sim PDA Toolbox
Não Pequena Rápida Sim
Falchnet Não Grande Lenta Não PocketStudio Não Média Média Não
Como foi citado anteriormente, algumas ferramentas têm seus próprios
Conduits. Outras, entretanto, como exemplo o CodeWarrior, cujos aplicativos são PRCs
e manipulam PDBs, devem ser complementadas com a aplicação Conduit.
5.3. Protótipo Desenvolvido
Para verificar as funcionalidades de consulta e sincronização de dados através do
Palm, criamos uma aplicação com um cadastro de clientes e um módulo para consulta
de endereço através do cep. A Figura 11 mostra a tela inicial da aplicação. Este sistema
permite que usuários móveis compartilhem dados de clientes provenientes de um banco
de dados consolidado, podendo também incluir, excluir e editar dados do servidor.
65
FIGURA 11 - Interface do Cliente
As réplicas dos dados provenientes do servidor ficam na memória RAM do
dispositivo móvel, permitindo que o usuário trabalhe com estas réplicas em modo
desconectado. A sincronização é feita assim que o cliente achar necessário.
O sistema como um todo pode ser visto da seguinte maneira:
- Aplicação Cliente: permite que o usuário faça consultas, inserções, atualizações
e exclusões do banco de dados.
66
- Banco de Dados do Cliente: armazena as réplicas de dados provenientes do
banco de dados consolidado ou de própria criação do cliente móvel.
- Protocolo de Sincronização: responsável por fazer a conexão dos dispositivos e
transferência dos dados. Para este sistema utilizamos o protocolo HotSync e testamos a
funcionalidade de outros protocolos de sincronização disponíveis no mercado mas que
não englobaram o sistema.
- Gerenciador de Sincronização: responsável por ativar os conduits disponíveis
para sincronização.
- Banco de Dados Consolidado: base de dados fixa localizada no servidor.
5.3.1. O Programa Cliente
Nossa aplicação cliente tem por finalidade prover o acesso e gerenciar os dados
disponíveis na unidade móvel. Tudo o que é feito sobre os dados locais repercutem nos
dados localizados no servidor.
O usuário móvel tem acesso a todos os dados da base de Clientes localizada no
servidor, podendo alterar as informações, incluir um novo cliente ou excluí-lo da base
de dados, através da sincronização. Outra opção ao usuário é a consulta de endereço via
cep, que foi englobada à nossa aplicação para verificação de consultas via cliente.
A aplicação como um todo pode ser vista na Figura 12.
67
FIGURA 12 – Estrutura do Sistema
Para a programação da interface utilizamos inicialmente a ferramenta Satellite
Forms Enterprise Edition versão 4.1.0. Desenvolvida pela Pumatech desde 1997 e
lançada em 2001, a Satellite Forms é uma ferramenta RAD, de fácil aprendizado e pode
gerar sistemas para a plataforma PalmOS ou Pocket PC 2002/2003. Possui conduit
próprio, mas não dá muita flexibilidade ao programador.
Aplicações feitas em Satellite Forms necessitam do run-time da aplicação
instalado no dispositivo para funcionar .
Em nosso experimento não utilizamos o conduit próprio da ferramenta,
desenvolvemos nosso próprio conduit. No momento da sincronização foi detectado que
o componente utilizado para desenvolver o conduit não é compatível com os dados
provenientes da Satellite Forms. A partir daí não conseguimos mais trabalhar com a
ferramenta, já que ela não possuía os requisitos necessários para o nosso
68
desenvolvimento. Decidimos assim optar por outra ferramenta, a PocketStudio
Professional.
Desenvolvida pela Pocket-Technologies desde 1999 e lançada em 2001, a
PocketStudio possui um compilador que gera aplicações nativas PalmOS sem a
necessidade de run-time. Nos primeiros momentos não nos adaptamos bem a esta
ferramenta, já que o desenvolvimento com a Satellite Forms era muito mais produtivo e
fácil, mas ao longo do desenvolvimento fomos nos adaptando e conseguimos concluir a
aplicação.
5.3.2. Descrição do Banco de Dados do Cliente
Em nossa aplicação foram definidos dois banco de dados, um para
gerenciamento dos dados dos clientes, o Cliente-DB e outro para consulta de cep no
servidor, o Cep-DB.
Esses dois bancos de dados possuem a mesma estrutura do banco de dados do
servidor, a principal diferença é que os banco de dados do cliente possuem todos os
dados classificados como do tipo string, eles são convertidos para o formato que está no
servidor apenas na hora da sincronização, enquanto no servidor os atributos dos dados
são bem definidos.
69
5.3.3 O Módulo Conduit
O Conduit construído em nosso experimento foi projetado com a linguagem
Borland Delphi 5.0.
Para que o conduit fizesse parte do processo de sincronização era necessário que
ele fosse inserido na lista de eventos a serem sincronizados. Utilizamos o CDK (Conduit
Development Kit) para essa inserção. Cada DLL inserida através do CDK deve possuir
um creatorID que faz ligação com a respectiva aplicação instalada no palmtop.
5.4. Protocolos de Sincronização Investigados
Dentre os protocolos estudados, conseguimos testar apenas 2, o HotSync e o
SyncML. Apesar de tentarmos encontrar os outros protocolos estudados, não
encontramos nada de concreto sobre o CPISync e pouca coisa sobre o Intellisync. Havia
uma versão de teste do cliente Intellisync, mas o servidor de sincronização não
encontrava-se disponível para download.
Nossos testes foram feitos utilizando os protocolos Hotsync e SyncML. O
servidor de sincronização foi instalado em um computador Atlon XP 1.4 GHz e o
cliente de sincronização foi instalado no emulador POSE. Utilizamos um banco de
dados contendo informação de aproximadamente 1800 clientes, totalizando 128 Kb de
dados.
Alguns pontos relevantes foram levantados na análise:
70
Volume de Dados Transmitido
O SyncML transmitiu um volume de dados consideravelmente maior que o
HotSync para a mesma quantidade de dados transmitida, como pode ser visto na Figura
13. Já na Figura14, o SyncML transmitiu um volume menor de dados no modo normal ,
equivalente ao modo Fast do HotSync, isso se deve ao fato de que o HotSync tranfere
ao registro todo que foi modificado e o SyncML transfere apenas os dados do registro
que foram midificados. Considerando-se ambientes wireless, esta característica é muito
importante, já que a comunicação pode ser fraca.
050000
100000
150000200000250000300000350000
400000450000500000
bytes transferidos
slow sync hotsyncslow sync syncml
FIGURA 13 – Volume de Dados HotSync e SyncML (Slow)
71
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
bytes transferidos
fast sync hotsyncnormal sync syncml
FIGURA 14 - Volume de Dados HotSync e SyncML (Fast e Normal)
Processamento Envolvido
Não foi possível levantar essa característica já que estávamos utilizando o
emulador.
Tamanho da Rede
Essa característica indica se com o aumento da rede o protocolo continua
funcionando normalmente. Nesta categoria o FastSync torna-se mais fraco, pois
sincroniza apenas dois nodos na rede. O SyncML é inadequado para grandes redes
porque cada dispositivo tem que manter a informação de sincronização para todos os
outros dispositivos da rede.
72
Memória
Na utilização dos protocolos estudados verificou-se que o SyncML é o que
consome mais memória do dispositivo e do servidor para fazer a sincronização. Dados
concretos não podem ser levantados devido à utilização do emulador. Dispositivos com
pouca memória não são indicados para sincronizar via SyncML.
73
CAPÍTULO VI
6. CONCLUSÕES E TRABALHOS FUTUROS
Nos últimos anos ocorreu um crescimento substancial das tecnologias que
empregam computação móvel. Com este trabalho conseguimos mostrar como é
trabalhar com computação móvel, os problemas enfrentados e que atitudes tomar.
Mostramos um problema clássico de sincronização entre banco de dados e os protocolos
empregados no experimento.
Existem diversos protocolos de sincronização no mercado, mas muitos deles não
estão disponíveis para um estudo aprofundado. A decisão a ser tomada de que protocolo
utilizar depende muito dos recursos disponíveis pelo usuário, principalmente no que se
refere ao hardware disponível.
Dentre os protocolos estudados, chegou-se a seguinte tabela comparativa:
TABELA 8 – Propriedades dos Protocolos de Sincronização de Dados Estudados
Protocolo de Sincronização
de Dados
Volume de Dados
Transmitidos
Número de dispositivos na
rede
Memória utilizada
Ponto central de
falha
Processamento utilizado
HotSync modo FastSync
Normal
Apenas 2 Normal Sim Normal
HotSync modo SlowSync
Alto Vários Normal Sim Normal
74
SyncML modo Normal
Baixo Apenas 2 Alto Sim Normal
SyncML modo Slow
Normal Vários, mas torna-se muito complexo
Muito alto, dependendo do número de dispositivos utilizado
Sim Alto
O assunto escolhido para este trabalho tem evidente tendência de crescimento futuro. Os
PDAs estão cada vez menores e com maior desempenho, trazendo consigo novos
problemas a serem enfrentados e os protocolos existentes não atendem a tudo que
precisam.
Com base no levantamento bibliográfico feito neste trabalho foi possível
observar as diversas abordagens de pesquisa com relação à computação móvel
permitiram um estudo amplo para atender diversos tipos de necessidades. Percebemos
que há pouca coisa que nos fala sobre os protocolos de sincronização. Na maioria
encontrada, nenhum documento toma um aprofundamento no assunto relevante o
suficiente.
O estudo que ocorreu para o desenvolvimento deste trabalho nos trouxe um bom
entendimento das deficiências e facilidades que a computação móvel nos traz. A
implementação prática de um protótipo de sincronização contribuiu para o
aprimoramento de métodos propostos na literatura e a descoberta de novos desafios para
incentivar a continuidade deste e de outros trabalhos científicos.
75
Em termos de trabalhos futuros, uma boa análise a ser feita é a da criação de um
protocolo que alcance todas as necessidades da sincronização, podendo funcionar em
redes maiores, consumindo pouca memória dos dispositivos, transmitindo um grande
volume de dados em um tempo curto, etc., características estas que a maioria no
mercado não tem.
76
REFERÊNCIAS BIBLIOGRÁFICAS
3GAM – 3G AMERICAS:: Unifying the Americas through Wireless Tecnology.
http://www.3gamericas.org
BADRINATH, B. R.; PHATAK, S. H. Bounded Locking for Optimistic
Concurrency Control. Department of Computer Science, University Rutgers,
Piscatway, 1995.
BARBARÁ, D. Mobile Computing and Database: A Survey. IEEE Transactions on
Knowledge and Data Engineering, p.1-14, 1999.
BREITBART, Y.; KOMONDOOR, R.; RASTOGI, R.; et al. Update Propagation
Protocols for Replicated Databases. ACM SIGMOD International Conference
on Management of Data, p.97-108, 1999.
CDG – CDMA Development Group
http://www.cdg.org
CUNHA, D. P. da. Um Estudo das Estratégias de Replicação e Reconciliação de
Banco de Dados Móveis em um Ambiente Wireless. Dissertação de Mestrado
em Ciência da Computação, UFSC, 2003
DANTAS, M. Tecnologias de Redes de Comunicação e Computadores. Rio de
Janeiro: Axcel Books, 2002.
DENARDI, M.A. Um Estudo Comparativo de Mecanismos de Controle de
Concorrência de Gerenciamento de Dados em Ambientes de Computação
Móvel. Dissertação de Mestrado em Ciência da Computação, UFSC, 2003.
77
DUNHAM, M.; KUMAR, V. Defining Location Data Dependency, Transaction
Mobility and Commitment. Relatório Técnico 98-CSE-1, fevereiro, 1998, p. 1-
22.
FERREIRA, E. J.; FINGER, M. Controle de Concorrência e Distribuição de Dados:
a teoria clássica, suas limitações e extensões modernas. Escola de Computação
2000.
FORMAN, G. H.; ZAHORJAN, J. The Challenges of Mobile Computing. IEEE
Computer, 27(6):38-47, Abril, 1994.
GETIEEE802 - IEEE Standards “Get IEEE 802”(TM) Wireless (IEEE 802.11).
http://standards.ieee.org/getieee802/802.11.html
ITO, G. Bancos de Dados Móveis: Uma Análise de Soluções Propostas para
Gerenciamento de Dados. Dissertação de Mestrado em Ciência da Computação,
UFSC, 2001.
KRISHNA, P.. Performance Issues in Mobile Wireless Networks. Dissertação –
Texas University, Agosto 1996.
LUBINSKI, A.; HEUER, A. Configured Replication for Mobile Applications.
Workshop Grundlagen von Datenbanken, p.1-13, 2000.
MATEUS, G.; LOUREIRO, A. Introdução a Computação Móvel. Rio de Janeiro:
NCE/UFRJ, 11ª Escola de Computação, 1998.
MINSKY, Y. ; TRACHTENBERG, A. and ZIPPEL, R., Set Reconciliation with
Nearly Optimal Communication Complexity. Tech. Rep. TR2000-1813,
Cornell University, 2000.
MOB2003 – MICROSOFT
http://www.microsoft.com/mobile/images/devices.gif
78
NASSU, E. A.; FINGER, M. O Significado de “Aqui”em Sistemas Transacionais
Móveis. I Workshop SIDAM (Sistemas de Informação Distribuída de Agentes
Móveis), outubro, 2000, p. 55-63.
NEVES, N.; FUCHS, W. K. Adaptive Recovery for Mobile Enviroments.
Communications of the ACM, v.1, n.40, janeiro, 1997, p. 69-74.
ÖZSU, M.; VALDURIEZ, P. Principles of Distributed Database Systems. New
Jersey: Prentice Hall, 2ª ed., 1999.
PALAZZO, S.; PULIOFITO, A.; SCARPA, M. Design and Evaluation of a
Replicated Database for Mobile Systems. Wireless Networks 6, p.131-133,
2000.
PALMOS
http://palmos.com/dev/support/docs/palmos/ReferenceTOC.html
PASTORE, M. Wireless Aims Widespread Appeal. Cyberlatas 2000; cyber
atlas.internet.com/markets/wireless/article/0,,10094_587701,00.html.
PITOURA, E.; SAMARAS, G. Data Management for Mobile Computing. Kluwer
Academic Publishers, 1998.
PUMATECH
http://www.pumatech.com
SILBERSCHATZ, A.; KORTH H.; SUDARSHAN S. Sistemas de Banco de Dados.
Makron Books, São Paulo, 1999.
SILVA, F. J. S. e; ENDLER, M. Requisitos e Arquiteturas de Software para
Computação Móvel. I Workshop SIDAM (Sistemas de Informação Distribuída
de Agentes Móveis), outubro 2000.
79
SONG Siang Wun et al. SIDAM – Sistemas de Informação Distribuídos para
Agentes Móveis. Departamento de Ciência da Computação, IME São Paulo e
Departamento de Ciência da Computação e Estatística ICM São Carlos, São
Paulo, Junho, 1999.
SATYANARAYANAN, M. Fundamental Challenges in Mobile Computing. ACM
Symposium on Principles of Distributed Computing, Filadélfia, p.1-7, 1996.
SYNCML
http://www.syncml.org/downloads.html
TRACHTENBERG, A. ; STAROBINBKI, D. and AGARWAL, S. Fast PDA
Synchronization Using Characteristic Polynomial Interpolation. Tech. Rep.
TR2001-03, Boston University, 2001.
TRACHTENBERG, A. ; STAROBINBKI, D. and AGARWAL, S. Fast PDA
Synchronization Using Characteristic Polynomial Interpolation. Proceedings
of the IEEE Infocom, 2002.
UMST FORUM
http://www.umst-forum.org
YEO, L. H.; ZASLAVSKY, UM. Submission of Transactions from Móbile
Workstations in a Cooperative Multidatabase Processing Enviroment.
Proceedings of Distributed Computing Systems, p. 372-379, junho, 1994.
80
PROTOCOLOS DE SINCRONIZAÇÃO EM AMBIENTES WIRELESS: UM ESTUDO DE CASO
Elenice Colle Manganelli
Juliano Romani {juliano}{elenice}@inf.ufsc.br
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
UNIVERSIDADE FEDERAL DE SANTA CATARINA RESUMO
Atualmente, tem se verificado um grande crescimento na utilização da computação móvel. Um dos fatores que podem explicar essa tendência é o desenvolvimento de novos recursos computacionais, como uma maior capacidade de processamento e armazenamento nos dispositivos móveis, bem como o aumento das taxas de transmissão em redes wireless. Uma importante característica na sincronização dos dispositivos móveis é o protocolo de sincronização utilizado. Porém, algumas considerações precisam ser analisadas na escolha, tais como: memória disponível do dispositivo, a rede que vai ser utilizada, a taxa de transmissão, etc.. O problema fundamental é encontrar um protocolo que atenda aos problemas identificados. Neste trabalho é apresentada uma análise de diferentes protocolos de sincronização, baseando-se em um estudo de caso experimental feito em uma plataforma convencional. Os resultados indicam soluções para o desenvolvimento na plataforma PalmOS e uma análise dos protocolos HotSync e SyncML.
ABSTRACT
Currently, it has verified a great growth in the use of the mobile computation. One of the factors that can explain this trend is the development of new computational resources, as a bigger capacity of processing and storage in the mobile devices, as well as the increase of the taxes of transmission in wireless networks. An important characteristic in the synchronization of the mobile devices is the used synchronization protocol . However, some considerations need is analyzed in the choice, such as: available memory of the device, the network that go to be used, the tax of transmission, etc.. The basic problem is to find a protocol that takes care of to the identified problems. In this work an analysis of different synchronization protocols is presented, being based on a study of made experimental case in a conventional platform. The results indicate solutions for the development in the PalmOS platform and an analysis of the protocols HotSync and SyncML.
COMPUTAÇÃO MÓVEL
A computação móvel tornou-se uma realidade na vida das pessoas com
o aparecimento de duas tecnologias: o aparecimento de computadores portáteis poderosos e o desenvolvimento de redes
1
rápidas e mais confiáveis (BARBARÁ,1999).
O ambiente da computação móvel não requer mais que os usuários mantenham uma posição fixa na rede, permitindo assim uma grande mobilidade dos usuários.
O principal desafio da computação móvel é conseguir garantir o funcionamento igualado aos dos computadores fixos, já que diversas restrições surgem com a mobilidade, ou seja, é necessário ter um sistema de computadores distribuídos com serviços comparáveis aos dos computadores fixos mas que permita mobilidade (MATEUS & LOUREIRO, 1998).
Características da Computação Móvel
Computadores móveis requerem acesso a redes sem fio, embora possa às vezes se unir fisicamente à uma rede fixa com uma conexão melhor e mais barata permanecendo estacionários em reuniões em cima de uma mesa por exemplo.
Em uma comunicação sem fio é muito mais difícil conseguir uma comunicação perfeita, pois existem muitos obstáculos que podem interferir no sinal, introduzindo assim ruídos e ecos. As conexões sem fio possuem qualidade mais baixa que as conexões fixas, pois possuem baixa largura de banda, taxas de erros elevadas e desconexões mais freqüentes. Esses fatores podem aumentar a latência nos retransmissores, atraso no intervalo de retransmissão, erro no processamento do protocolo de controle e curtas desconexões (FORMAN & ZAHORJAN, 1994).
BANCO DE DADOS MÓVEIS
Para que a mobilidade tenha efeito vantajoso existe a necessidade da utilização de banco de dados para controle e armazenamento da informação. Um SGBD (Sistema Gerenciador de Banco de Dados) tem como objetivo propiciar um ambiente conveniente e eficiente para recuperação e armazenamento da informação (SILBERSCHATZ et al, 1999).
As aplicações que rodam em clientes móveis se conectam freqüentemente a repositórios de dados remotos carregando somente as informações necessárias. Para isso é necessário que o banco de dados tenha a capacidade de carregar as informações do repositório e trabalhar com essa informação mesmo estando desconectado ou fora do alcance do repositório. As informações atualizadas no cliente móvel enquanto ele estava desconectado serão atualizadas na sua próxima conexão (BADRINATH & PHATAK, 1995).
TECNOLOGIAS DE SINCRONIZAÇÃO
Para BADRINATH & PHATAK (2001) a sincronização em ambientes móveis pode ser definida como o ato de estabelecer equivalência entre duas coleções de dados, entre cliente e servidor, após a ocorrência de alteração nos registros armazenados. Depois de sincronização de dados cada elemento de dados em uma coleção é mapeado por um elemento de dados em outra, sendo que seus dados são equivalentes, entretanto não necessariamente idênticos.
2
Hotsync Dispositivos Palm rodam na plataforma Palm Operating System que fornece o protocolo HotSync para sincronizar os bancos de dados do Palm com o do micro Desktop. O HotSync (PALMOS) opera em dois modos, dependendo do histórico de sincronização do dispositivo com o micro computador em particular.
O FastSync ocorre quando o dispositivo sincroniza com o mesmo micro computador que sincronizou pela última vez. Neste caso o dispositivo sincroniza processando os registros baseados nas flags de status de cada registro que dizem se este foi modificado, criado ou apagado. O FastSync é a melhor opção quando a sincronização ocorre somente entre dois dispositivos, sendo que o dispositivo poderá recordar flags de status somente de um micro computador.
O Slowsync ocorre quando a condição principal do Fastsync não é encontrada. Neste caso o dispositivo transfere a base de dados inteira ao PC a ser trabalhado pela comparação. Enquanto o espaço de armazenamento do dispositivo se torna maior grande e as bases de dados se tornam maiores, a introdução da latência crescente envolvida em transferir a base de dados inteira do PDA ao PC para a sincronização subseqüente torna-se cada vez mais importante.
Mas pode-se dizer que com o avanço de tecnologias mais rápidas de conexão dos dispositivos móveis com os PCs e as redes sem fio cada vez mais rápidas a latência do slowsync se transforma um assunto tratável.
Intellisync
O Intellisync (PUMATECH), produto fabricado pela Pumatech, faz sempre a sincronização do tipo Fastsync, utilizando um servidor central com o qual os dispositivos móveis sincronizam sempre. Isto significa que todos os dispositivos sincronizados têm que manter as flags de status das atualizações com respeito somente ao usuário central, permitindo um Fastsync todas as vezes. Esta arquitetura não é projetada para o caso geral onde um dispositivo pode sincronizar com outros dispositivo em uma rede do peer-to-peer. No geral, uma arquitetura distribuída baseada na sincronização do peer-to-peer fornece o desempenho muito melhor da rede, nos termos de robustez e escalabilidade, do que uma rede centralizada.
SyncML SyncML , segundo SYNCML (2002) é uma iniciativa da indústria aberta suportada por muitas companhias, incluindo Ericsson, IBM, Lótus, Matsushita, Motorola, Nokia, OpenWare e Starfish.
Pode ser considerada como uma linguagem padrão para sincronizar diferente dispositivos e aplicações sobre qualquer rede. Com o SyncML qualquer tipo de informação pode ser sincronizada para manter a informação consistente e atualizada, não importando a localização do dispositivo e da rede.
O protocolo possui as seguintes características:
• Opera efecientemente sobre redes wireless e com fios.
• Suporta uma variedade de protocolos de transporte, como HTTP, WSP, OBEX, redes
3
TCP/IP, SMTP, POP3, IMAP, e protocolos proprietários.
• Acesso a dados de uma variedade de aplicações.
Este framework ajuda na analise de implementação de um modelo de sistema associado com a implementação do SyncML. Os blocos maiores desse framework é a representação do protocolo SyncML, conceitual adaptador SyncML e a interface SyncML. O protocolo de sincronização de dados SyncML está fora do framework SyncML para manter o framework de fácil implementação e atividade conjunta.
A aplicação “A” descreve um serviço de rede que provê serviço de sincronização de dados para a aplicação “B”. Vamos assumir que a aplicação “B” deseja se sincronizar com a aplicação “A”. O serviço e o dispositivo são conectados sobre um protocolo de transporte em comum, como HTTP. A aplicação “A” implementa o processo “Sync Engine” utilizando o protocolo de sincronização de dados manifestando o acesso cliente para o “Sync Server” – um recurso de rede. O “Sync Server Agent” se comunica entre as aplicações cliente e o “Sync Engine” para gerenciar o acesso a rede e para e de as comunicações. Invocando as funções definidas na interface SyncML para executar essas capacidades. A interface SyncML não é nada mais que uma aplicação para o “SyncML Adapter”. “SyncML Adapter” é um processo conceitual que pode ser considerado como ponto de entrada e saída para a aplicação “A”.
Usando a representação de protocolo, SyncML é um protocolo de sincronização que define como inicializar, sincronizar e encerrar a
sincronização incluindo a troca de dados entre os dispositivos sincronizados. SyncML é programado considerando ele como um protocolo de sincronização comum, tendo cuidado nos casos onde os serviços de rede e os dispositivos de armazenamento de dados que estão começando a ser sincronizados estão em formatos diferentes ou sendo usados por diferentes programas. Há sete tipos diferentes de sincronização definidas pelo SyncML, dependendo de como a sincronização é inicializada pelo cliente eu servidor e a transferência de informação entre eles.
8. Two-Way Sync
9. Slow Sync
10. One-Way Sync from Client only
11. Refresh Sync from Client only
12. One-Way Sync from Server only
13. Refresh Sync from Server only
14. Server Alertd Sync
SyncML tenta conseguir potencialidades do Fastsync, requerendo que todos os dispositivos da rede possuam flags de status para cada registro. Isso pode causar uma demanda de memória muito grande. Onde a complexidade aumenta conforme o número de dispositivos em rede. Isso não é sustentável em redes com vários dispositivos.
CPISync
Há muitas instâncias de sincronização de dados onde há necessidade de sincronizar dados semelhantes em dispositivos diferentes. O CPISync, segundo Trachtenberg, Starobinbki, e Agarwal (2001,2002), que é uma abreviação de “Characteristc Polynominal Interpolation
4
Syncronization”, faz a complexidade do tempo da sincronização quase independente do tamanho do conjunto de dados a ser sincronizado, e somente dependente do número de diferenças entre os dois conjuntos de dados. Este é um contraste marcante em relação ao Slowsync que utiliza uma transferência de dados inteira entre os hosts enquanto sincronizando os dados, fazendo a sincronização dos dados um tempo linear em relação ao numero de registros no banco de dados.
CPISync é baseado em uma solução recente para um conjunto de problemas de reconcialização por Minsky, Trachtenberg e Zippel (2000) é escalável com o número de dispositivos na rede e o tamanho do banco de dados a ser sincronizado. Esta solução envolve mais recurso computacional comparado ao Slowsync, este recurso computacional pode ser distribuído assimetricamente entre os hosts. Isto significa que em casos onde os hosts tem capacidades computacionais diferentes (ex. PDA e PC), o CPISync pode transferir mais dos recursos computacionais para o pc, permitindo uma rápida execução do CPISync comparado a uma aproximação simétrica.
AMBIENTE EXPERIMENTAL E RESULTADOS OBTIDOS
Para nosso experimento utilizamos um cliente móvel que faz operações de consulta e atualizações em um banco de dados consolidado pertencente a um servidor.
Por motivos burocráticos não foi possível conseguir dispositivos recentes a tempo para nosso experimento, possuíamos apenas um dispositivo
portátil, um Palm M100, para fazer o papel de cliente.
Utilizamos um computador desktop rodando Windows como servidor e um Palm M100 funcionando como cliente móvel. O PalmOS Emulator (POSE) também foi utilizado funcionando como clientes móveis inexistentes.
A utilização do Emulador não é recomendada só para suprir a falta de um dispositivo, mas sim para testar aplicações antes de serem instaladas nos dispositivos físicos. No Emulador as aplicações rodam mais rápido e pode-se evitar um Hard Reset caso a aplicação desenvolvida possua algum erro.
Iniciando o Desenvolvimento na Plataforma PalmOS
Quando iniciamos nosso projeto, a previsão que havia era a de conseguir trabalhar com dois dispositivos portáteis adquiridos pela universidade, só que por vários motivos não conseguimos os dispositivos a tempo. Tínhamos em mãos um Palm M100 e algumas idéias formuladas.
As principais dúvidas que surgiram foram a de “Como começar a desenvolver?” e “Que ferramenta utilizar?”. Algumas dúvidas foram sendo esclarecidas ao longo de todo o estudo desenvolvido e serão apresentadas a seguir.
Protótipo Desenvolvido
Para verificar as funcionalidades de consulta e sincronização de dados através do Palm, criamos uma aplicação com um cadastro de clientes e um módulo para consulta de endereço
5
através do cep. A Figura 2 mostra a tela inicial da aplicação. Este sistema permite que usuários móveis compartilhem dados de clientes provenientes de um banco de dados consolidado, podendo também incluir, excluir e editar dados do servidor.
FIGURA 2 - Interface do Cliente
As réplicas dos dados provenientes do servidor ficam na memória RAM do dispositivo móvel, permitindo que o usuário trabalhe com estas réplicas em modo desconectado. A sincronização é feita assim que o cliente achar necessário.
O sistema como um todo pode ser visto da seguinte maneira:
- Aplicação Cliente: permite que o usuário faça consultas, inserções, atualizações e exclusões do banco de dados.
- Banco de Dados do Cliente: armazena as réplicas de dados provenientes do banco de dados consolidado ou de própria criação do cliente móvel.
- Protocolo de Sincronização: responsável por fazer a conexão dos
dispositivos e transferência dos dados. Para este sistema utilizamos o protocolo HotSync e testamos a funcionalidade de outros protocolos de sincronização disponíveis no mercado mas que não englobaram o sistema.
- Gerenciador de Sincronização: responsável por ativas os conduits disponíveis para sincronização.
- Banco de Dados Consolidado: base de dados fixa localizada no servidor.
O Programa Cliente
Nossa aplicação cliente tem por finalidade prover o acesso e gerenciar os dados disponíveis na unidade móvel. Tudo o que é feito sobre os dados locais repercutem nos dados localizados no servidor.
O usuário móvel tem acesso a todos os dados da base de Clientes localizada no servidor, podendo alterar as informações, incluir um novo cliente ou excluí-lo da base de dados, através da sincronização. Outra opção ao usuário é a consulta de endereço via cep, que foi englobada à nossa aplicação para verificação de consultas via cliente.
Protocolos de Sincronização Investigados
Dentre os protocolos estudados, conseguimos testar apenas 2, o HotSync e o
SyncML. Apesar de tentarmos encontrar os outros protocolos estudados, não encontramos nada de concreto sobre o CPISync e pouca coisa
6
sobre o Intellisync. Havia uma versão de teste do cliente Intellisync, mas o servidor de sincronização não encontrava-se disponível para download.
Nossos testes foram feitos utilizando os protocolos Hotsync e SyncML. O servidor de sincronização foi instalado em um computador Pentium 200MHz e o cliente de sincronização foi instalado no emulador POSE. Utilizamos um banco de dados contendo informação de aproximadamente 1800 clientes, totalizando 128 Kb de dados.
Alguns pontos relevantes foram levantados na análise:
Volume de Dados Transmitido
O SyncML transmitiu um volume de bytes consideravelmente maior que o HotSync para o mesmo volume de dados, como pode ser visto na Figura 3 e a 4. Sendo necessário para isso maior processamento e maior tempo de conexão. Considerando-se ambientes wireless, esta característica é muito importante, já que a comunicação pode ser fraca.
Processamento Envolvido
Não foi possível levantar essa característica já que estávamos utilizando o emulador.
050000
100000
150000200000250000300000350000
400000450000500000
bytes transferidos
slow sync hotsyncslow sync syncml
FIGURA 3 – Volume de Dados HotSync e SyncML (Slow)
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
bytes transferidos
fast sync hotsyncnormal sync syncml
FIGURA 4 - Volume de Dados HotSync e SyncML (Fast e Normal)
Tamanho da Rede
Essa característica indica se com o aumento da rede o protocolo continua funcionando normalmente. Nesta categoria o FastSync torna-se mais fraco, pois sincroniza apenas dois nodos na rede. O SyncML é inadequado para grandes redes porque cada dispositivo tem que manter a informação de sincronização para todos os outros dispositivos da rede.
7
Memória
Na utilização dos protocolos estudados verificou-se que o SyncML é o que consome mais memória do dispositivo e do servidor para fazer a sincronização. Dados concretos não podem ser levantados devido à utilização do emulador. Dispositivos com pouca memória não são indicados para sincronizar via SyncML.
Nos últimos anos ocorreu um crescimento substancial das tecnologias que empregam computação móvel. Com este trabalho conseguimos mostrar como é trabalhar com computação móvel, os problemas enfrentados e que atitudes tomar. Mostramos um problema clássico de sincronização entre banco de dados e os protocolos empregados no experimento.
Existem diversos protocolos de sincronização no mercado, mas muitos deles não estão disponíveis para um estudo aprofundado. A decisão a ser tomada de que protocolo utilizar depende muito dos recursos disponíveis pelo usuário, principalmente no que se refere ao hardware disponível.
O assunto escolhido para este trabalho tem evidente tendência de crescimento futuro. Os PDAs estão cada vez menores e com maior desempenho, trazendo consigo novos problemas a serem enfrentados e os protocolos existentes não atendem a tudo que precisam.
Com base no levantamento bibliográfico feito neste trabalho foi possível observar as diversas abordagens de pesquisa com relação à computação móvel permitiram um estudo amplo para atender diversos
tipos de necessidades. Percebemos que há pouca coisa que nos fala sobre os protocolos de sincronização. Na maioria encontrada, nenhum documento toma um aprofundamento no assunto relevante o suficiente.
O estudo que ocorreu para o desenvolvimento deste trabalho nos trouxe um bom entendimento das deficiências e facilidades que a computação móvel nos traz. A implementação prática de um protótipo de sincronização contribuiu para o aprimoramento de métodos propostos na literatura e a descoberta de novos desafios para incentivar a continuidade deste e de outros trabalhos científicos.
REFERÊNCIAS BIBLIOGRÁFICAS
BADRINATH, B. R.; PHATAK, S. H.
Bounded Locking for Optimistic Concurrency Control. Department of Computer Science, University Rutgers, Piscatway, 1995.
BARBARÁ, D. Mobile Computing and Database: A Survey. IEEE Transactions on Knowledge and Data Engineering, p.1-14, 1999.
BREITBART, Y.; KOMONDOOR, R.; RASTOGI, R.; et al. Update Propagation Protocols for Replicated Databases. ACM SIGMOD International Conference on Management of Data, p.97-108, 1999.
DANTAS, M. Tecnologias de Redes de Comunicação e Computadores. Rio de Janeiro: Axcel Books, 2002.
FORMAN, G. H.; ZAHORJAN, J. The Challenges of Mobile
8
Computing. IEEE Computer, 27(6):38-47, Abril, 1994.
MATEUS, G.; LOUREIRO, A. Introdução a Computação Móvel. Rio de Janeiro: NCE/UFRJ, 11ª Escola de Computação, 1998.
MINSKY, Y. ; TRACHTENBERG, A. and ZIPPEL, R., Set Reconciliation with Nearly Optimal Communication Complexity. Tech. Rep. TR2000-1813, Cornell University, 2000.
PALMOS http://palmos.com/dev/support/do
cs/palmos/ReferenceTOC.html PITOURA, E.; SAMARAS, G. Data
Management for Mobile Computing. Kluwer Academic Publishers, 1998.
PUMATECH http://www.pumatech.com
SILBERSCHATZ, A.; KORTH H.; SUDARSHAN S. Sistemas de Banco de Dados. Makron Books, São Paulo, 1999.
SYNCML http://www.syncml.org/download
s.html TRACHTENBERG, A. ;
STAROBINBKI, D. and AGARWAL, S. Fast PDA Synchronization Using Characteristic Polynomial Interpolation. Tech. Rep. TR2001-03, Boston University, 2001.
TRACHTENBERG, A. ; STAROBINBKI, D. and AGARWAL, S. Fast PDA Synchronization Using Characteristic Polynomial Interpolation. Proceedings of the IEEE Infocom, 2002.
1
Código Fonte Programa Cliente program Cliente(Cmd: Word; CmdPBP: Pointer; LaunchFlags: Word): LongWord; {$CREATOR 'appl'} uses PalmOS, Cliente_rc, Cliente_evn, TableList in 'TableList.pas', PSIO in 'PSIO.pas', ClienteUI in 'ClienteUI.pas', ClienteList in 'ClienteList.pas', ClienteDB in 'ClienteDB.pas', CepDB in 'CepDB.pas', CepUI in 'CepUI.pas', CepList in 'CepList.pas'; function CheckROMVersion(RequiredVersion: UInt32): Boolean; var RomVersion: UInt32; begin FtrGet(sysFtrCreator, sysFtrNumROMVersion, RomVersion); Result := RomVersion >= RequiredVersion; end; function StartApplication: Boolean; begin Result := CheckROMVersion($3503000); // PalmOS version if not Result then begin FrmCustomAlert(AlertIncompatible, '3.5', nil, nil); Exit; end; ClienteDB.Open; CepDB.Open; FrmGotoForm(Pesquisa); end; procedure StopApplication; begin FrmCloseAllForms; CepDB.Close; ClienteDB.Close; end;
2
begin if Cmd = sysAppLaunchCmdNormalLaunch then if StartApplication then begin EventLoop; StopApplication; end; end. Unit CepDB; interface uses PalmOS, PSDatabase, PSUtils; const DatabaseName = 'Cep-DB'; DatabaseType = Rsc('STANDARD'); // Record Fields CepruaIdx=0; CepcidadeIdx=1; CepbairroIdx=2; CepcepIdx=3; CepufIdx=4; var FieldDefs: array [0..4] of TFieldDef = ( (DataType: ftString), // rua (DataType: ftString), // cidade (DataType: ftString), // bairro (DataType: ftString), // cep (DataType: ftString) // uf ); Database : TDatabase; function Open : Boolean; function Close : Boolean; procedure NewRecord; procedure Next; procedure Prior; procedure First; procedure Last;
3
function Bof : Boolean; function Eof : Boolean; implementation function Open : Boolean; begin Result := PSDatabase.Open(Database, DatabaseName, dmModeReadWrite); if not Result then begin Result := PSDatabase.CreateDatabase(DatabaseName, Creator, DatabaseType); if Result then Result := PSDatabase.Open(Database, DatabaseName, dmModeReadWrite); end; if not Result then begin ShowSystemError(PSDatabase.LastError); Exit; end; if Result then PSDatabase.SetFieldDefs(Database, FieldDefs[0], SizeOf(FieldDefs) div
SizeOf(FieldDefs[0])); end; function Close : Boolean; begin Result := PSDatabase.Close(Database); end; procedure NewRecord; // Create record with default values begin PSDatabase.Append(Database); PSDatabase.Post(Database); end; procedure Next; begin if (not Eof) then PSDatabase.Next(Database); end; procedure Prior; begin if (not Bof) then PSDatabase.Prior(Database);
4
end; procedure First; begin PSDatabase.First(Database); end; procedure Last; begin PSDatabase.Last(Database); end; function Bof : Boolean; begin Result := PSDatabase.Bof(Database); end; function Eof : Boolean; begin Result := PSDatabase.Eof(Database); end; end. Unit CepList; interface uses PalmOS, PSDatabase, PSTable, TableList, Cliente_rc, CepDb, CepUI; var CEPLista : TTableList; implementation const ColPos : array[0..5] of Integer = (0, 8, 18, 28, 38, 50);
5
procedure TableCallBack(tableP: Pointer; row, column: Int16; var bounds: RectangleType);
begin PSDatabase.MoveTo(CepDb.Database, TblGetItemInt(TableP, Row, Column)); // Draw fields in table row TableList.DrawTruncChars(FieldStringPtr(CepDb.Database, CepcepIdx), Bounds, 3,
160); { TableList.DrawTruncChars(FieldStringPtr(CepDb.Database, CepruaIdx), Bounds,
ColPos[1], ColPos[2]); TableList.DrawTruncChars(FieldStringPtr(CepDb.Database, CepbairroIdx), Bounds,
ColPos[2], ColPos[3]); TableList.DrawTruncChars(FieldStringPtr(CepDb.Database, CepcidadeIdx), Bounds,
ColPos[3], ColPos[4]); TableList.DrawTruncChars(FieldStringPtr(CepDb.Database, CepufIdx), Bounds,
ColPos[4], ColPos[5]); } end; initialization CEPLista.TableID := ListaCEP; CEPLista.TableDrawItemFunc := TableCallBack; CEPLista.Database := @CepDb.Database; CEPLista.TopVisibleRecord := 0; CEPLista.RepeatButtonUp := CepUp; CEPLista.RepeatButtonDown := CepDown; CEPLista.CompareFunction := TableList.Child; // Not child table - use default
function end. Unit CepUI; interface uses PalmOS, PSIO, PSDatabase, CepDB, Cliente_rc; procedure ReadData; procedure WriteData; var
6
DeleteRec : Boolean; implementation // Read data from database and put on screen procedure ReadData; begin DeleteRec := False; PSDatabase.Edit(CepDb.Database); PSIO.ReadToUIField(CepDb.Database, CepDb.CepruaIdx, Field2); PSIO.ReadToUIField(CepDb.Database, CepDb.CepcidadeIdx, Field4); PSIO.ReadToUIField(CepDb.Database, CepDb.CepbairroIdx, Field3); PSIO.ReadToUIField(CepDb.Database, CepDb.CepcepIdx, Field1); PSIO.ReadToUIField(CepDb.Database, CepDb.CepufIdx, Field5); end; // Write data from screen into database procedure WriteData; begin if DeleteRec then begin PSDatabase.Cancel(CepDb.Database); PSDatabase.Delete(CepDb.Database); exit; end; PSIO.WriteFromUIField(CepDb.Database, CepDb.CepruaIdx, Field2); PSIO.WriteFromUIField(CepDb.Database, CepDb.CepcidadeIdx, Field4); PSIO.WriteFromUIField(CepDb.Database, CepDb.CepbairroIdx, Field3); PSIO.WriteFromUIField(CepDb.Database, CepDb.CepcepIdx, Field1); PSIO.WriteFromUIField(CepDb.Database, CepDb.CepufIdx, Field5); PSDatabase.Post(CepDb.Database); end; initialization end. Unit ClienteDB; interface uses PalmOS, PSDatabase, PSUtils; const DatabaseName = 'Cliente-DB';
7
DatabaseType = Rsc('STANDARD'); // Record Fields Clientecd_clienteIdx=0; Clientenm_cliIdx=1; Clientelog_cliIdx=2; Clientecomp_cliIdx=3; Clientebairro_cliIdx=4; Clientecid_cliIdx=5; Clienteuf_cliIdx=6; var FieldDefs: array [0..6] of TFieldDef = ( (DataType: ftString), // cd_cliente (DataType: ftString), // nm_cli (DataType: ftString), // log_cli (DataType: ftString), // comp_cli (DataType: ftString), // bairro_cli (DataType: ftString), // cid_cli (DataType: ftString) // uf_cli ); Database : TDatabase; function Open : Boolean; function Close : Boolean; procedure NewRecord; implementation function Open : Boolean; begin Result := PSDatabase.Open(Database, DatabaseName, dmModeReadWrite); if not Result then begin Result := PSDatabase.CreateDatabase(DatabaseName, Creator, DatabaseType); if Result then Result := PSDatabase.Open(Database, DatabaseName, dmModeReadWrite); end; if not Result then begin ShowSystemError(PSDatabase.LastError); Exit; end;
8
if Result then PSDatabase.SetFieldDefs(Database, FieldDefs[0], SizeOf(FieldDefs) div
SizeOf(FieldDefs[0])); end; function Close : Boolean; begin Result := PSDatabase.Close(Database); end; procedure NewRecord; // Create record with default values begin PSDatabase.Append(Database); PSDatabase.Post(Database); end; end. Unit ClienteUI; interface uses PalmOS, PSIO, PSDatabase, ClienteDB, Cliente_rc; procedure ReadData; procedure WriteData; var DeleteRec : Boolean; implementation // Read data from database and put on screen procedure ReadData; begin DeleteRec := False; PSDatabase.Edit(ClienteDB.Database); PSIO.ReadToUIField(ClienteDB.Database, ClienteDB.Clientecd_clienteIdx,
ClienteEditFieldcd_cliente); PSIO.ReadToUIField(ClienteDB.Database, ClienteDB.Clientenm_cliIdx,
ClienteEditFieldnm_cli); PSIO.ReadToUIField(ClienteDB.Database, ClienteDB.Clientelog_cliIdx,
ClienteEditFieldlog_cli);
9
PSIO.ReadToUIField(ClienteDB.Database, ClienteDB.Clientecomp_cliIdx, ClienteEditFieldcomp_cli);
PSIO.ReadToUIField(ClienteDB.Database, ClienteDB.Clientebairro_cliIdx, ClienteEditFieldbairro_cli);
PSIO.ReadToUIField(ClienteDB.Database, ClienteDB.Clientecid_cliIdx, ClienteEditFieldcid_cli);
PSIO.ReadToUIField(ClienteDB.Database, ClienteDB.Clienteuf_cliIdx, ClienteEditFielduf_cli);
end; // Write data from screen into database procedure WriteData; begin if DeleteRec then begin PSDatabase.Cancel(ClienteDB.Database); PSDatabase.Delete(ClienteDB.Database); exit; end; PSIO.WriteFromUIField(ClienteDB.Database, ClienteDB.Clientecd_clienteIdx,
ClienteEditFieldcd_cliente); PSIO.WriteFromUIField(ClienteDB.Database, ClienteDB.Clientenm_cliIdx,
ClienteEditFieldnm_cli); PSIO.WriteFromUIField(ClienteDB.Database, ClienteDB.Clientelog_cliIdx,
ClienteEditFieldlog_cli); PSIO.WriteFromUIField(ClienteDB.Database, ClienteDB.Clientecomp_cliIdx,
ClienteEditFieldcomp_cli); PSIO.WriteFromUIField(ClienteDB.Database, ClienteDB.Clientebairro_cliIdx,
ClienteEditFieldbairro_cli); PSIO.WriteFromUIField(ClienteDB.Database, ClienteDB.Clientecid_cliIdx,
ClienteEditFieldcid_cli); PSIO.WriteFromUIField(ClienteDB.Database, ClienteDB.Clienteuf_cliIdx,
ClienteEditFielduf_cli); PSDatabase.Post(ClienteDB.Database); end; initialization end. // ---------------------------------------------------------------------------- // // Palm OS 5.0 declarations, Copyright (c) 2000-2002 Pocket Technologies, Inc. // // ---------------------------------------------------------------------------- unit PalmOS;
10
interface uses PalmTypes, CoreTraps, // libraries LibTraps, // system publics Rect, ErrorBase, AlarmMgr, Bitmap, Chars, ConnectionMgr, ConsoleMgr, Crc,
DataMgr, LocaleMgr, DateTime, DLServer, Encrypt, ExgMgr, ExgLib, FeatureMgr, FileStream, FloatMgr, Font, Graffiti, Helper, HelperServiceClass, ImcUtils, IntlMgr, KeyMgr, Localize, MemoryMgr, ModemMgr, PalmLocale, NotifyMgr, Password, PenMgr,
PceNativeCall_, SerialLinkMgr, SerialMgrOld, StringMgr, TimeMgr, Window, SysEvent, SysEvtMgr, SystemResources, SysUtils, TextMgr, TextServicesMgr, IrLib, // UI publics AboutBox, AttentionMgr, Clipboard, Control, Day, FatalAlert, Find_, FontSelect_, Field, GraffitiReference, GraffitiShift, UIControls, Keyboard, List, PrivateRecords, ScrollBar, SelDay, SelTime, SelTimeZone, Table, UIColor, UIResources, Form, Progress, Launcher, Event_, Category, Menu_, // hardware Hal, HwrMiscFlags, M68KHwr, // others SystemMgr, AppLaunchCmd, PhoneLookup, NetMgr, NetBitUtils, OverlayMgr,
Preferences, SoundMgr, InsPoint, SerialMgr, INetMgr, // libraries AddressSortLib, ExgLocalLib, FSLib, Lz77Mgr, TelephonyMgrTypes,
TelephonyMgr, TelephonyMgrUI, SmsLib, UDAMgr, ExpansionMgr, VFSMgr, PdiConst, PdiLib,
SlotDrvrLib, CPMLibCommon, CPMLib68KInterface, SslLib, SslLibAsn1, SslLibMac; implementation end. Unit PSIO; // DB Table Example v1.0 // Created by Clayton Powell // Evolutionary Systems - www.evolutionary.net
11
interface uses PalmOS, PSTypes, PSString, PSSlider, PSCheckbox, PSDatabase, PSField, PSButton, PSList; const BufSize = longDateStrLength + 1 + timeStringLength + 1; var PSIODecimalPlaces : UInt8 = 2; type TSelectorContext = record SelectorTriggerID : TSelectorTrigger; DateTime : DateTimeType; Buffer : array[0..BufSize] of char; end; procedure ReadToUIField(var Database : TDatabase; FieldIndex: Int16; Field: TField); procedure WriteFromUIField(var Database : TDatabase; FieldIndex: Int16; Field:
TField); procedure ReadToUISelector(var Database : TDatabase; FieldIndex: Int16; var
SelectorContext: TSelectorContext); procedure EditUISelector(var Database : TDatabase; FieldIndex: Int16; var
SelectorContext: TSelectorContext); procedure WriteFromUISelector(var Database : TDatabase; FieldIndex: Int16; var
SelectorContext: TSelectorContext); procedure ReadToUISlider(var Database : TDatabase; FieldIndex: Int16; Slider:
TSlider); procedure WriteFromUISlider(var Database : TDatabase; FieldIndex: Int16; Slider:
TSlider); procedure ReadToUICheckbox(var Database : TDatabase; FieldIndex: Int16;
Checkbox: TCheckbox); procedure WriteFromUICheckbox(var Database : TDatabase; FieldIndex: Int16;
Checkbox: TCheckbox); procedure ReadToUIDropList(var Database : TDatabase; FieldIndex: Int16; List: TList;
PopupTrigger: TPopupTrigger); procedure WriteFromUIDropList(var Database : TDatabase; FieldIndex: Int16; List:
TList; PopupTrigger: TPopupTrigger); implementation
12
const PSIOReadErrorAlert = AutoID; PSIOEditErrorAlert = AutoID; PSIOWriteErrorAlert = AutoID; PSIOErrorAlert = AutoID; resource ALERT PSIOReadErrorAlert ERROR BEGIN TITLE 'PSIO Read Error' MESSAGE 'The DB field of type ^1 cannot be put into a UI ^2' BUTTONS 'OK' END; ALERT PSIOEditErrorAlert ERROR BEGIN TITLE 'PSIO Edit Error' MESSAGE 'Cannot edit a UI ^2 of type ^1' BUTTONS 'OK' END; ALERT PSIOWriteErrorAlert ERROR BEGIN TITLE 'PSIO Write Error' MESSAGE 'Cannot write a UI ^2 to a DB field of type ^1' BUTTONS 'OK' END; ALERT PSIOErrorAlert ERROR BEGIN TITLE 'PSIO Error' MESSAGE '^1' BUTTONS 'OK' END; procedure FormatFloat(dst: PChar; f: Double; Decimals: UInt8); var w, i, Len, Offset : Int32; D : Double; buf : Array[0..maxStrIToALen] of char; begin dst[0] := #0; D := f; if D < 0 then begin D := -D; // Deal with negative numbers
13
StrCat(dst, '-'); end; for i := 1 to Decimals do D := D * 10; // Deal with decimal places w := round(D); // Get whole number portion of float if (w = $7FFFFFFF) then // Overflow begin FlpFToA(f, dst); // Use default draw proc exit; end; StrIToA(buf, w); // Convert whole number to string Len := StrLen(buf); if Len <= Decimals then StrCat(dst, '0') // zero before decimal point else StrNCat(dst, buf, StrLen(dst)+Len-Decimals+1); if Decimals > 0 then StrCat(dst, '.') // add decimal point else exit; // We're done! for i := 1 to Decimals - Len do // Fill missing zeroes after decimal point StrCat(dst, '0'); Offset := Len-decimals; if Offset < 0 then Offset := 0; StrCat(dst, @buf[Offset]); end; procedure FormatDate(var Date: DateType; var DateTime: DateTimeType; Buffer:
PChar); begin Buffer[0] := #0; DateTime.Year := 0; if Date.Bits = 0 then // Not set yet exit; DateTime.Year := 1904 + (Date.Bits shr 9); DateTime.Month := (Date.Bits and $01E0) shr 5; DateTime.Day := Date.Bits and $001F; DateToAscii(DateTime.Month, DateTime.Day, DateTime.Year, dfDMYLong,
Buffer); end;
14
procedure FormatTime(var Time : TimeType; var DateTime: DateTimeType; Buffer:
PChar); begin Buffer[0] := #0; DateTime.Hour := Time.Hours; DateTime.Minute := Time.Minutes; TimeToAscii(DateTime.Hour, DateTime.Minute, tfColonAMPM, Buffer); end; procedure FormatDateTime(var DateTime: DateTimeType; Buffer: PChar); var P : PChar; begin Buffer[0] := #0; if TimDateTimeToSeconds(@DateTime) = 0 then // Not set yet exit; DateToAscii(DateTime.Month, DateTime.Day, DateTime.Year, dfDMYLong,
Buffer); StrCat(Buffer, ' '); P := @Buffer[StrLen(Buffer)]; TimeToAscii(DateTime.Hour, DateTime.Minute, tfColonAMPM, P); end; procedure DropListSetSelection(ListID: UInt16; PopupTriggerID: UInt16; Selection :
Int16); var List : ListPtr; begin List := PSList.Ptr(ListID); LstSetSelection(List, Selection); LstMakeItemVisible(List, Selection); LstDrawList(List); CtlSetLabel(PSButton.Ptr(PopupTriggerID), LstGetSelectionText(List, Selection)); end; // Read data from database and put into Field on screen procedure ReadToUIField(var Database : TDatabase; FieldIndex: Int16; Field: TField); var Buffer : array[0..BufSize] of char; Date : DateType; Time : TimeType; DateTime : DateTimeType; begin case Database.FieldDefs^[FieldIndex].DataType of ftBoolean : begin if PSDatabase.FieldBoolean(Database, FieldIndex) then PSField.SetText(Field, 'True')
15
else PSField.SetText(Field, 'False'); end; ftInt8 : begin StrIToA(Buffer, PSDatabase.FieldInt8(Database, FieldIndex)); PSField.SetText(Field, Buffer); end; ftInt16 : begin StrIToA(Buffer, PSDatabase.FieldInt16(Database, FieldIndex)); PSField.SetText(Field, Buffer); end; ftInt32 : begin StrIToA(Buffer, PSDatabase.FieldInt32(Database, FieldIndex)); PSField.SetText(Field, Buffer); end; ftUInt8 : begin StrIToA(Buffer, PSDatabase.FieldUInt8(Database, FieldIndex)); PSField.SetText(Field, Buffer); end; ftUInt16 : begin StrIToA(Buffer, PSDatabase.FieldUInt16(Database, FieldIndex)); PSField.SetText(Field, Buffer); end; ftUInt32 : begin StrIToA(Buffer, PSDatabase.FieldUInt32(Database, FieldIndex)); PSField.SetText(Field, Buffer); end; ftSingle : begin FormatFloat(Buffer, PSDatabase.FieldSingle(Database, FieldIndex),
PSIODecimalPlaces); PSField.SetText(Field, Buffer); end; ftDouble : begin FormatFloat(Buffer, PSDatabase.FieldDouble(Database, FieldIndex),
PSIODecimalPlaces); PSField.SetText(Field, Buffer); end; ftDate : begin PSDatabase.FieldDate(Database, FieldIndex, Date);
16
FormatDate(Date, DateTime, Buffer); PSField.SetText(Field, Buffer); end; ftTime : begin PSDatabase.FieldTime(Database, FieldIndex, Time); FormatTime(Time, DateTime, Buffer); PSField.SetText(Field, Buffer); end; ftDateTime : begin PSDatabase.FieldDateTime(Database, FieldIndex, DateTime); FormatDateTime(DateTime, Buffer); PSField.SetText(Field, Buffer); end; ftString : begin PSField.SetText(Field, PSDatabase.FieldStringPtr(Database, FieldIndex)); end; ftBinary : FrmCustomAlert(PSIOReadErrorAlert, 'Binary', 'Field', ''); else FrmCustomAlert(PSIOErrorAlert, 'Unknown DB field datatype.', '', ''); end; end; // Read data from database and put into Field on screen procedure WriteFromUIField(var Database : TDatabase; FieldIndex: Int16; Field:
TField); var Buffer : array[0..BufSize] of char; P : PChar; Size : UInt32; begin case Database.FieldDefs^[FieldIndex].DataType of ftBoolean : begin PSField.Text(Field, Buffer, sizeof(Buffer)); if (Buffer[0] = 'T') or (Buffer[0] = 't') then PSDatabase.SetFieldBoolean(Database, FieldIndex, True) else PSDatabase.SetFieldBoolean(Database, FieldIndex, False); end; ftInt8 : begin PSField.Text(Field, Buffer, sizeof(Buffer)); PSDatabase.SetFieldInt8(Database, FieldIndex, StrAToI(Buffer)); end; ftInt16 : begin
17
PSField.Text(Field, Buffer, sizeof(Buffer)); PSDatabase.SetFieldInt16(Database, FieldIndex, StrAToI(Buffer)); end; ftInt32 : begin PSField.Text(Field, Buffer, sizeof(Buffer)); PSDatabase.SetFieldInt32(Database, FieldIndex, StrAToI(Buffer)); end; ftUInt8 : begin PSField.Text(Field, Buffer, sizeof(Buffer)); PSDatabase.SetFieldUInt8(Database, FieldIndex, StrAToI(Buffer)); end; ftUInt16 : begin PSField.Text(Field, Buffer, sizeof(Buffer)); PSDatabase.SetFieldUInt16(Database, FieldIndex, StrAToI(Buffer)); end; ftUInt32 : begin PSField.Text(Field, Buffer, sizeof(Buffer)); PSDatabase.SetFieldUInt32(Database, FieldIndex, StrAToI(Buffer)); end; ftSingle : begin PSField.Text(Field, Buffer, sizeof(Buffer)); PSDatabase.SetFieldSingle(Database, FieldIndex, FlpAToF(Buffer)); end; ftDouble : begin PSField.Text(Field, Buffer, sizeof(Buffer)); PSDatabase.SetFieldDouble(Database, FieldIndex, FlpAToF(Buffer)); end; ftDate : FrmCustomAlert(PSIOWriteErrorAlert, 'Date', 'Field', ''); ftTime : FrmCustomAlert(PSIOWriteErrorAlert, 'Time', 'Field', ''); ftDateTime : FrmCustomAlert(PSIOWriteErrorAlert, 'DateTime', 'Field', ''); ftString : begin Size := TextLength(Field) + 1; P := MemPtrNew(Size); Text(Field, P, Size); PSDatabase.SetFieldString(Database, FieldIndex, P); MemPtrFree(P); end; ftBinary : FrmCustomAlert(PSIOWriteErrorAlert, 'Binary', 'Field', ''); else FrmCustomAlert(PSIOErrorAlert, 'Unknown DB field datatype.', '', '');
18
end; end; procedure ReadToUISelector(var Database : TDatabase; FieldIndex: Int16; var
SelectorContext: TSelectorContext); var Date : DateType; Time : TimeType; P : PChar; begin case Database.FieldDefs^[FieldIndex].DataType of ftBoolean : FrmCustomAlert(PSIOReadErrorAlert, 'Boolean', 'Selector', ''); ftInt8 : FrmCustomAlert(PSIOReadErrorAlert, 'Int8', 'Selector', ''); ftInt16 : FrmCustomAlert(PSIOReadErrorAlert, 'Int16', 'Selector', ''); ftInt32 : FrmCustomAlert(PSIOReadErrorAlert, 'Int32', 'Selector', ''); ftUInt8 : FrmCustomAlert(PSIOReadErrorAlert, 'UInt8', 'Selector', ''); ftUInt16 : FrmCustomAlert(PSIOReadErrorAlert, 'UInt16', 'Selector', ''); ftUInt32 : FrmCustomAlert(PSIOReadErrorAlert, 'UInt32', 'Selector', ''); ftSingle : FrmCustomAlert(PSIOReadErrorAlert, 'Single', 'Selector', ''); ftDouble : FrmCustomAlert(PSIOReadErrorAlert, 'Double', 'Selector', ''); ftDate : begin PSDatabase.FieldDate(Database, FieldIndex, Date); FormatDate(Date, SelectorContext.DateTime, SelectorContext.Buffer); PSButton.SetCaption(SelectorContext.SelectorTriggerID, SelectorContext.Buffer); end; ftTime : begin PSDatabase.FieldTime(Database, FieldIndex, Time); FormatTime(Time, SelectorContext.DateTime, SelectorContext.Buffer); PSButton.SetCaption(SelectorContext.SelectorTriggerID, SelectorContext.Buffer); end; ftDateTime : begin PSDatabase.FieldDateTime(Database, FieldIndex, SelectorContext.DateTime); FormatDateTime(SelectorContext.DateTime, SelectorContext.Buffer); PSButton.SetCaption(SelectorContext.SelectorTriggerID, SelectorContext.Buffer); end; ftString : FrmCustomAlert(PSIOReadErrorAlert, 'String', 'Selector', ''); ftBinary : FrmCustomAlert(PSIOReadErrorAlert, 'Binary', 'Selector', ''); else FrmCustomAlert(PSIOErrorAlert, 'Unknown DB field datatype.', '', ''); end; end; procedure EditUISelector(var Database : TDatabase; FieldIndex: Int16; var
SelectorContext: TSelectorContext); var
19
NewDT : DateTimeType; P : PChar; begin case Database.FieldDefs^[FieldIndex].DataType of ftBoolean : FrmCustomAlert(PSIOEditErrorAlert, 'Boolean', 'Selector', ''); ftInt8 : FrmCustomAlert(PSIOEditErrorAlert, 'Int8', 'Selector', ''); ftInt16 : FrmCustomAlert(PSIOEditErrorAlert, 'Int16', 'Selector', ''); ftInt32 : FrmCustomAlert(PSIOEditErrorAlert, 'Int32', 'Selector', ''); ftUInt8 : FrmCustomAlert(PSIOEditErrorAlert, 'UInt8', 'Selector', ''); ftUInt16 : FrmCustomAlert(PSIOEditErrorAlert, 'UInt16', 'Selector', ''); ftUInt32 : FrmCustomAlert(PSIOEditErrorAlert, 'UInt32', 'Selector', ''); ftSingle : FrmCustomAlert(PSIOEditErrorAlert, 'Single', 'Selector', ''); ftDouble : FrmCustomAlert(PSIOEditErrorAlert, 'Double', 'Selector', ''); ftDate : begin NewDT := SelectorContext.DateTime; if NewDT.Year = 0 then // Not set yet TimSecondsToDateTime(TimGetSeconds, @NewDT); // Default to current date if not SelectDay(selectDayByDay, NewDT.Month, NewDT.Day, NewDT.Year,
'Select Date') then exit; SelectorContext.DateTime := NewDT; DateToAscii(SelectorContext.DateTime.Month, SelectorContext.DateTime.Day,
SelectorContext.DateTime.Year, dfDMYLong, SelectorContext.Buffer); PSButton.SetCaption(SelectorContext.SelectorTriggerID, SelectorContext.Buffer); end; ftTime : begin NewDT := SelectorContext.DateTime; if not SelectOneTime(NewDT.Hour, NewDT.Minute, 'Select Time') then exit; SelectorContext.DateTime := NewDT; TimeToAscii(SelectorContext.DateTime.Hour, SelectorContext.DateTime.Minute,
tfColonAMPM, SelectorContext.Buffer); PSButton.SetCaption(SelectorContext.SelectorTriggerID, SelectorContext.Buffer); end; ftDateTime : begin NewDT := SelectorContext.DateTime; if TimDateTimeToSeconds(@NewDT) = 0 then // Not set yet TimSecondsToDateTime(TimGetSeconds, @NewDT); // Default to current
date/time
20
if not SelectDay(selectDayByDay, NewDT.Month, NewDT.Day, NewDT.Year, 'Select Date') then
exit; if not SelectOneTime(NewDT.Hour, NewDT.Minute, 'Select Time') then exit; SelectorContext.DateTime := NewDT; FormatDateTime(SelectorContext.DateTime, SelectorContext.Buffer); PSButton.SetCaption(SelectorContext.SelectorTriggerID, SelectorContext.Buffer); end; ftString : FrmCustomAlert(PSIOEditErrorAlert, 'String', 'Selector', ''); ftBinary : FrmCustomAlert(PSIOEditErrorAlert, 'Binary', 'Selector', ''); else FrmCustomAlert(PSIOErrorAlert, 'Unknown DB field datatype.', '', ''); end; end; procedure WriteFromUISelector(var Database : TDatabase; FieldIndex: Int16; var
SelectorContext: TSelectorContext); var Date : DateType; Time : TimeType; begin case Database.FieldDefs^[FieldIndex].DataType of ftBoolean : FrmCustomAlert(PSIOWriteErrorAlert, 'Boolean', 'Selector', ''); ftInt8 : FrmCustomAlert(PSIOWriteErrorAlert, 'Int8', 'Selector', ''); ftInt16 : FrmCustomAlert(PSIOWriteErrorAlert, 'Int16', 'Selector', ''); ftInt32 : FrmCustomAlert(PSIOWriteErrorAlert, 'Int32', 'Selector', ''); ftUInt8 : FrmCustomAlert(PSIOWriteErrorAlert, 'UInt8', 'Selector', ''); ftUInt16 : FrmCustomAlert(PSIOWriteErrorAlert, 'UInt16', 'Selector', ''); ftUInt32 : FrmCustomAlert(PSIOWriteErrorAlert, 'UInt32', 'Selector', ''); ftSingle : FrmCustomAlert(PSIOWriteErrorAlert, 'Single', 'Selector', ''); ftDouble : FrmCustomAlert(PSIOWriteErrorAlert, 'Double', 'Selector', ''); ftDate : begin if SelectorContext.DateTime.Year = 0 then Date.Bits := 0 else Date.Bits := ((SelectorContext.DateTime.Year-1904) shl 9) or (SelectorContext.DateTime.Month shl 5) or SelectorContext.DateTime.Day; PSDatabase.SetFieldDate(Database, FieldIndex, Date); end; ftTime : begin Time.Hours := SelectorContext.DateTime.Hour; Time.Minutes := SelectorContext.DateTime.Minute;
21
PSDatabase.SetFieldTime(Database, FieldIndex, Time); end; ftDateTime : begin PSDatabase.SetFieldDateTime(Database, FieldIndex, SelectorContext.DateTime); end; ftString : FrmCustomAlert(PSIOWriteErrorAlert, 'String', 'Selector', ''); ftBinary : FrmCustomAlert(PSIOWriteErrorAlert, 'Binary', 'Selector', ''); else FrmCustomAlert(PSIOErrorAlert, 'Unknown DB field datatype.', '', ''); end; end; procedure ReadToUISlider(var Database : TDatabase; FieldIndex: Int16; Slider:
TSlider); begin case Database.FieldDefs^[FieldIndex].DataType of ftBoolean : FrmCustomAlert(PSIOReadErrorAlert, 'Boolean', 'Slider', ''); ftInt8 : PSSlider.SetValue(Slider, PSDatabase.FieldInt8(Database, FieldIndex)); ftInt16 : PSSlider.SetValue(Slider, PSDatabase.FieldInt16(Database, FieldIndex)); ftInt32 : PSSlider.SetValue(Slider, PSDatabase.FieldInt32(Database, FieldIndex)); ftUInt8 : PSSlider.SetValue(Slider, PSDatabase.FieldUInt8(Database, FieldIndex)); ftUInt16 : PSSlider.SetValue(Slider, PSDatabase.FieldUInt16(Database, FieldIndex)); ftUInt32 : PSSlider.SetValue(Slider, PSDatabase.FieldUInt32(Database, FieldIndex)); ftSingle : PSSlider.SetValue(Slider, Round(PSDatabase.FieldSingle(Database,
FieldIndex))); ftDouble : PSSlider.SetValue(Slider, Round(PSDatabase.FieldSingle(Database,
FieldIndex))); ftDate : FrmCustomAlert(PSIOReadErrorAlert, 'Date', 'Slider', ''); ftTime : FrmCustomAlert(PSIOReadErrorAlert, 'Time', 'Slider', ''); ftDateTime : FrmCustomAlert(PSIOReadErrorAlert, 'DateTime', 'Slider', ''); ftString : PSSlider.SetValue(Slider, StrAToI(PSDatabase.FieldStringPtr(Database,
FieldIndex))); ftBinary : FrmCustomAlert(PSIOReadErrorAlert, 'Binary', 'Slider', ''); else FrmCustomAlert(PSIOErrorAlert, 'Unknown DB field datatype.', '', ''); end; end; procedure WriteFromUISlider(var Database : TDatabase; FieldIndex: Int16; Slider:
TSlider); var Buffer : array[0..BufSize] of char;
22
begin case Database.FieldDefs^[FieldIndex].DataType of ftBoolean : FrmCustomAlert(PSIOWriteErrorAlert, 'Boolean', 'Slider', ''); ftInt8 : PSDatabase.SetFieldInt8(Database, FieldIndex, PSSlider.Value(Slider)); ftInt16 : PSDatabase.SetFieldInt16(Database, FieldIndex, PSSlider.Value(Slider)); ftInt32 : PSDatabase.SetFieldInt32(Database, FieldIndex, PSSlider.Value(Slider)); ftUInt8 : PSDatabase.SetFieldUInt8(Database, FieldIndex, PSSlider.Value(Slider)); ftUInt16 : PSDatabase.SetFieldUInt16(Database, FieldIndex, PSSlider.Value(Slider)); ftUInt32 : PSDatabase.SetFieldUInt32(Database, FieldIndex, PSSlider.Value(Slider)); ftSingle : FrmCustomAlert(PSIOWriteErrorAlert, 'Single', 'Slider', ''); ftDouble : FrmCustomAlert(PSIOWriteErrorAlert, 'Double', 'Slider', ''); ftDate : FrmCustomAlert(PSIOWriteErrorAlert, 'Date', 'Slider', ''); ftTime : FrmCustomAlert(PSIOWriteErrorAlert, 'Time', 'Slider', ''); ftDateTime : FrmCustomAlert(PSIOWriteErrorAlert, 'DateTime', 'Slider', ''); ftString : begin StrIToA(Buffer, PSSlider.Value(Slider)); PSDatabase.SetFieldString(Database, FieldIndex, Buffer); end; ftBinary : FrmCustomAlert(PSIOWriteErrorAlert, 'Binary', 'Slider', ''); else FrmCustomAlert(PSIOErrorAlert, 'Unknown DB field datatype.', '', ''); end; end; procedure ReadToUICheckbox(var Database : TDatabase; FieldIndex: Int16;
Checkbox: TCheckbox); var Buffer : array[0..BufSize] of char; begin case Database.FieldDefs^[FieldIndex].DataType of ftBoolean : PSCheckbox.SetChecked(Checkbox, PSDatabase.FieldBoolean(Database,
FieldIndex)); ftInt8 : PSCheckbox.SetChecked(Checkbox, PSDatabase.FieldInt8(Database,
FieldIndex)<>0); ftInt16 : PSCheckbox.SetChecked(Checkbox, PSDatabase.FieldInt16(Database,
FieldIndex)<>0); ftInt32 : PSCheckbox.SetChecked(Checkbox, PSDatabase.FieldInt32(Database,
FieldIndex)<>0); ftUInt8 : PSCheckbox.SetChecked(Checkbox, PSDatabase.FieldUInt8(Database,
FieldIndex)<>0); ftUInt16 : PSCheckbox.SetChecked(Checkbox, PSDatabase.FieldUInt16(Database,
FieldIndex)<>0); ftUInt32 : PSCheckbox.SetChecked(Checkbox, PSDatabase.FieldUInt32(Database,
FieldIndex)<>0);
23
ftSingle : FrmCustomAlert(PSIOReadErrorAlert, 'Single', 'Checkbox', ''); ftDouble : FrmCustomAlert(PSIOReadErrorAlert, 'Double', 'Checkbox', ''); ftDate : FrmCustomAlert(PSIOReadErrorAlert, 'Date', 'Checkbox', ''); ftTime : FrmCustomAlert(PSIOReadErrorAlert, 'Time', 'Checkbox', ''); ftDateTime : FrmCustomAlert(PSIOReadErrorAlert, 'DateTime', 'Checkbox', ''); ftString : begin if PSDatabase.FieldStringPtr(Database, FieldIndex)[0] = 'T' then PSCheckbox.SetChecked(Checkbox, True) else PSCheckbox.SetChecked(Checkbox, False); end; ftBinary : FrmCustomAlert(PSIOReadErrorAlert, 'Binary', 'Slider', ''); else FrmCustomAlert(PSIOErrorAlert, 'Unknown DB field datatype.', '', ''); end; end; procedure WriteFromUICheckbox(var Database : TDatabase; FieldIndex: Int16;
Checkbox: TCheckbox); var Buffer : array[0..BufSize] of char; begin case Database.FieldDefs^[FieldIndex].DataType of ftBoolean : PSDatabase.SetFieldBoolean(Database, FieldIndex,
PSCheckbox.Checked(Checkbox)); ftInt8 : PSDatabase.SetFieldInt8(Database, FieldIndex,
Int8(PSCheckbox.Checked(Checkbox))); ftInt16 : PSDatabase.SetFieldInt16(Database, FieldIndex,
Int16(PSCheckbox.Checked(Checkbox))); ftInt32 : PSDatabase.SetFieldInt32(Database, FieldIndex,
Int32(PSCheckbox.Checked(Checkbox))); ftUInt8 : PSDatabase.SetFieldUInt8(Database, FieldIndex,
UInt8(PSCheckbox.Checked(Checkbox))); ftUInt16 : PSDatabase.SetFieldUInt16(Database, FieldIndex,
UInt16(PSCheckbox.Checked(Checkbox))); ftUInt32 : PSDatabase.SetFieldUInt32(Database, FieldIndex,
UInt32(PSCheckbox.Checked(Checkbox))); ftSingle : FrmCustomAlert(PSIOWriteErrorAlert, 'Single', 'Checkbox', ''); ftDouble : FrmCustomAlert(PSIOWriteErrorAlert, 'Double', 'Checkbox', ''); ftDate : FrmCustomAlert(PSIOWriteErrorAlert, 'Date', 'Checkbox', ''); ftTime : FrmCustomAlert(PSIOWriteErrorAlert, 'Time', 'Checkbox', ''); ftDateTime : FrmCustomAlert(PSIOWriteErrorAlert, 'DateTime', 'Checkbox', ''); ftString : begin if PSCheckbox.Checked(Checkbox) then
24
PSDatabase.SetFieldString(Database, FieldIndex, 'True') else PSDatabase.SetFieldString(Database, FieldIndex, 'False'); end; ftBinary : FrmCustomAlert(PSIOWriteErrorAlert, 'Binary', 'Checkbox', ''); else FrmCustomAlert(PSIOErrorAlert, 'Unknown DB field datatype.', '', ''); end; end; procedure ReadToUIDropList(var Database : TDatabase; FieldIndex: Int16; List: TList;
PopupTrigger: TPopupTrigger); begin case Database.FieldDefs^[FieldIndex].DataType of ftBoolean : DropListSetSelection(List, PopupTrigger,
Integer(PSDatabase.FieldBoolean(Database, FieldIndex))); ftInt8 : DropListSetSelection(List, PopupTrigger, PSDatabase.FieldInt8(Database,
FieldIndex)); ftInt16 : DropListSetSelection(List, PopupTrigger, PSDatabase.FieldInt16(Database,
FieldIndex)); ftInt32 : DropListSetSelection(List, PopupTrigger, PSDatabase.FieldInt32(Database,
FieldIndex)); ftUInt8 : DropListSetSelection(List, PopupTrigger, PSDatabase.FieldUInt8(Database,
FieldIndex)); ftUInt16 : DropListSetSelection(List, PopupTrigger,
PSDatabase.FieldUInt16(Database, FieldIndex)); ftUInt32 : DropListSetSelection(List, PopupTrigger,
PSDatabase.FieldUInt32(Database, FieldIndex)); ftSingle : FrmCustomAlert(PSIOReadErrorAlert, 'Single', 'DropList', ''); ftDouble : FrmCustomAlert(PSIOReadErrorAlert, 'Double', 'DropList', ''); ftDate : FrmCustomAlert(PSIOReadErrorAlert, 'Date', 'DropList', ''); ftTime : FrmCustomAlert(PSIOReadErrorAlert, 'Time', 'DropList', ''); ftDateTime : FrmCustomAlert(PSIOReadErrorAlert, 'DateTime', 'DropList', ''); ftString : DropListSetSelection(List, PopupTrigger,
StrAToI(PSDatabase.FieldStringPtr(Database, FieldIndex))); ftBinary : FrmCustomAlert(PSIOReadErrorAlert, 'Binary', 'DropList', ''); else FrmCustomAlert(PSIOErrorAlert, 'Unknown DB field datatype.', '', ''); end; end; procedure WriteFromUIDropList(var Database : TDatabase; FieldIndex: Int16; List:
TList; PopupTrigger: TPopupTrigger); var Buffer : array[0..BufSize] of char;
25
begin case Database.FieldDefs^[FieldIndex].DataType of ftBoolean : PSDatabase.SetFieldBoolean(Database, FieldIndex,
Boolean(PSList.SelectionIndex(List))); ftInt8 : PSDatabase.SetFieldInt8(Database, FieldIndex, PSList.SelectionIndex(List)); ftInt16 : PSDatabase.SetFieldInt16(Database, FieldIndex,
PSList.SelectionIndex(List)); ftInt32 : PSDatabase.SetFieldInt32(Database, FieldIndex,
PSList.SelectionIndex(List)); ftUInt8 : PSDatabase.SetFieldUInt8(Database, FieldIndex,
PSList.SelectionIndex(List)); ftUInt16 : PSDatabase.SetFieldUInt16(Database, FieldIndex,
PSList.SelectionIndex(List)); ftUInt32 : PSDatabase.SetFieldUInt32(Database, FieldIndex,
PSList.SelectionIndex(List)); ftSingle : FrmCustomAlert(PSIOWriteErrorAlert, 'Single', 'DropList', ''); ftDouble : FrmCustomAlert(PSIOWriteErrorAlert, 'Double', 'DropList', ''); ftDate : FrmCustomAlert(PSIOWriteErrorAlert, 'Date', 'DropList', ''); ftTime : FrmCustomAlert(PSIOWriteErrorAlert, 'Time', 'DropList', ''); ftDateTime : FrmCustomAlert(PSIOWriteErrorAlert, 'DateTime', 'DropList', ''); ftString : begin StrIToA(Buffer, PSList.SelectionIndex(List)); PSDatabase.SetFieldString(Database, FieldIndex, Buffer); end; ftBinary : FrmCustomAlert(PSIOWriteErrorAlert, 'Binary', 'DropList', ''); else FrmCustomAlert(PSIOErrorAlert, 'Unknown DB field datatype.', '', ''); end; end; end. Unit TableList; // DB Table Example v1.0 // Created by Clayton Powell // Evolutionary Solutions - www.evolutionary.net interface uses PalmOS, PSDatabase, PSTable; type IntString = Array[0..maxStrIToALen] of char;
26
DateTimeString = Array[0..longDateStrLength+timeStringLength+1] of char; DateString = Array[0..longDateStrLength+1] of char; TimeString = Array[0..timeStringLength+1] of char; TTableList = record TableID : UInt16; Database : ^TDatabase; CompareFunction : TCompare; // For Detail table - True if child of Master table RepeatButtonUp, RepeatButtonDown : UInt16; TopVisibleRecord: Integer; // number of first record shown in table AllowScrollUp, AllowScrollDown: Boolean; // Allow scroll in each direction? TableDrawItemFunc : TableDrawItemFuncType; end; function Child(var Database: TDatabase; CustomParam: Pointer): Boolean; procedure OpenTable(var aTableList: TTableList); procedure LoadTable(var aTableList: TTableList); procedure DrawTable(var aTableList: TTableList); procedure RefreshTable(var aTableList: TTableList); procedure ScrollUp(var aTableList: TTableList); procedure ScrollDown(var aTableList: TTableList); procedure DrawTruncInt32(Value : Int32; var bounds: RectangleType; Left, Right:
Int16); procedure DrawTruncUInt32Hex(Value : UInt32; var bounds: RectangleType; Left,
Right: Int16); procedure DrawTruncUInt32(Value : UInt32; var bounds: RectangleType; Left, Right:
Int16); procedure DrawTruncDateTime(var DT : DateTimeType; var bounds: RectangleType;
Left, Right: Int16); procedure DrawTruncDate(var DT : DateTimeType; var bounds: RectangleType; Left,
Right: Int16); procedure DrawTruncTime(var DT : DateTimeType; var bounds: RectangleType; Left,
Right: Int16); procedure DrawTruncChars(S : PChar; var bounds: RectangleType; Left, Right: Int16); procedure DrawChar(S : PChar; var bounds: RectangleType; Left, Right: Int16); implementation procedure DrawTruncInt32(Value : Int32; var bounds: RectangleType; Left, Right:
Int16); var S : IntString; begin StrIToA(S, Value);
27
WinDrawTruncChars(S, StrLen(S), Bounds.topLeft.x+Left, Bounds.topLeft.y, Right-Left-5);
end; procedure DrawTruncUInt32Hex(Value : UInt32; var bounds: RectangleType; Left,
Right: Int16); var S : IntString; begin StrIToH(S, Value); WinDrawTruncChars(S, StrLen(S), Bounds.topLeft.x+Left, Bounds.topLeft.y, Right-
Left-5); end; procedure DrawTruncUInt32(Value : UInt32; var bounds: RectangleType; Left, Right:
Int16); var S : IntString; begin StrIToA(S, Value); WinDrawTruncChars(S, StrLen(S), Bounds.topLeft.x+Left, Bounds.topLeft.y, Right-
Left-5); end; procedure DrawTruncDateTime(var DT : DateTimeType; var bounds: RectangleType;
Left, Right: Int16); var S : DateTimeString; P : PChar; begin P := S; DateToAscii(dt.Month, dt.Day, dt.Year, dfDMYLong, P); StrCat(P, ' '); P := P + StrLen(S); TimeToAscii(dt.Hour, dt.Minute, tfColonAMPM, P); WinDrawTruncChars(S, StrLen(S), Bounds.topLeft.x+Left, Bounds.topLeft.y, Right-
Left-5); end; procedure DrawTruncTime(var DT : DateTimeType; var bounds: RectangleType; Left,
Right: Int16); var S : TimeString; begin TimeToAscii(dt.Hour, dt.Minute, tfColonAMPM, S); WinDrawTruncChars(S, StrLen(S), Bounds.topLeft.x+Left, Bounds.topLeft.y, Right-
Left-5); end;
28
procedure DrawTruncDate(var DT : DateTimeType; var bounds: RectangleType; Left,
Right: Int16); var S : DateString; begin DateToAscii(dt.Month, dt.Day, dt.Year, dfDMYLong, S); WinDrawTruncChars(S, StrLen(S), Bounds.topLeft.x+Left, Bounds.topLeft.y, Right-
Left-5); end; procedure DrawTruncChars(S : PChar; var bounds: RectangleType; Left, Right: Int16); begin WinDrawTruncChars(S, StrLen(S), Bounds.topLeft.x+Left, Bounds.topLeft.y, Right-
Left-5); end; procedure DrawChar(S : PChar; var bounds: RectangleType; Left, Right: Int16); begin WinDrawTruncChars(S, 1, Bounds.topLeft.x+Left, Bounds.topLeft.y, Right-Left); end; procedure UpdateScrollButtons(var aTableList: TTableList); var ScrollUp, ScrollDown: Integer; Form : FormPtr; begin Form := FrmGetActiveForm; ScrollUp := FrmGetObjectIndex(Form, aTableList.RepeatButtonUp); ScrollDown := FrmGetObjectIndex(Form, aTableList.RepeatButtonDown); FrmUpdateScrollers(Form, ScrollUp, ScrollDown, aTableList.AllowScrollUp,
aTableList.AllowScrollDown); end; procedure LoadTable(var aTableList: TTableList); var i: Integer; Table: TablePtr; RowCount : Integer; begin RowCount := PSTable.RowCount(aTableList.TableID); Table := PSTable.Ptr(aTableList.TableID); for i := 0 to RowCount-1 do // Clear table begin TblSetRowUsable(Table, i, False);
29
TblMarkRowInvalid(Table, i); end; // Position DB to top visible record PSDatabase.MoveTo(aTableList.Database^, aTableList.TopVisibleRecord); PSDatabase.Prior(aTableList.Database^); PSDatabase.FindNext(aTableList.Database^, aTableList.CompareFunction, nil); if PSDatabase.EOF(aTableList.Database^) then // Not valid so go to top of list PSDatabase.FindFirst(aTableList.Database^, aTableList.CompareFunction, nil); aTableList.TopVisibleRecord := PSDatabase.RecNo(aTableList.Database^); // Test if we can scroll up by seeing if a previous record exists aTableList.AllowScrollUp := False; if not PSDatabase.BOF(aTableList.Database^) then begin PSDatabase.FindPrior(aTableList.Database^, aTableList.CompareFunction, nil); if not PSDatabase.BOF(aTableList.Database^) then aTableList.AllowScrollUp := True; PSDatabase.FindNext(aTableList.Database^, aTableList.CompareFunction, nil); end; // Now load each table record until end of DB or table full i := 0; while not PSDatabase.EOF(aTableList.Database^) do begin TblSetItemStyle(Table, i, 0, customTableItem); TblSetItemInt(Table, i, 0, PSDatabase.RecNo(aTableList.Database^)); // Store rec
num for later rendering in callback TblSetRowUsable(Table, i, True); Inc(i); if i >= RowCount then break; // Table full PSDatabase.FindNext(aTableList.Database^, aTableList.CompareFunction, nil); end; // Test if we can scroll down by seeing if a next record exists aTableList.AllowScrollDown := False; if not PSDatabase.EOF(aTableList.Database^) then PSDatabase.FindNext(aTableList.Database^, aTableList.CompareFunction, nil); if not PSDatabase.EOF(aTableList.Database^) then aTableList.AllowScrollDown := True; UpdateScrollButtons(aTableList); end; procedure DrawTable(var aTableList: TTableList);
30
begin TblRedrawTable(PSTable.Ptr(aTableList.TableID)); end; procedure RefreshTable(var aTableList: TTableList); begin aTableList.TopVisibleRecord := 0; LoadTable(aTableList); DrawTable(aTableList); end; procedure ScrollUp(var aTableList : TTableList); begin if not aTableList.AllowScrollUp then begin SndPlaySystemSound(sndError); exit; end; PSDatabase.MoveTo(aTableList.Database^, aTableList.TopVisibleRecord); PSDatabase.FindPrior(aTableList.Database^, aTableList.CompareFunction, nil); aTableList.TopVisibleRecord := PSDatabase.RecNo(aTableList.Database^); LoadTable(aTableList); DrawTable(aTableList); end; procedure ScrollDown(var aTableList : TTableList); begin if not aTableList.AllowScrollDown then begin SndPlaySystemSound(sndError); exit; end; PSDatabase.MoveTo(aTableList.Database^, aTableList.TopVisibleRecord); PSDatabase.FindNext(aTableList.Database^, aTableList.CompareFunction, nil); aTableList.TopVisibleRecord := PSDatabase.RecNo(aTableList.Database^); LoadTable(aTableList); DrawTable(aTableList); end; // Default to all records as child of master for non detail tables function Child(var Database: TDatabase; CustomParam: Pointer): Boolean; begin Result := True; end;
31
procedure OpenTable(var aTableList: TTableList); var Table: TablePtr; begin // Load table and draw form Table := PSTable.Ptr(aTableList.TableID); TblSetCustomDrawProcedure(Table, 0, aTableList.TableDrawItemFunc); TblSetColumnUsable(Table, 0, True); end; end. ibrary PConduit; { Important note about DLL memory management: ShareMem must be the first unit in your library's USES clause AND your project's (select Project-View Source) USES clause if your DLL exports any procedures or functions that pass strings as parameters or function results. This applies to all strings passed to and from your DLL--even those that are nested in records and classes. ShareMem is the interface unit to the BORLNDMM.DLL shared memory manager, which must be deployed along with your DLL. To avoid using BORLNDMM.DLL, pass string information using PChar or ShortString parameters. } uses SysUtils, Classes, Forms, UConduit in 'UConduit.pas' {DataModule1: TDataModule}; begin DataModule1 := TDataModule1.Create(Application); end. interface uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, TabdPalmConduit, Db, TabdConduitSync, DBTables; type TDataModule1 = class(TDataModule) TabdConduit: TTabdConduit;
32
TPalmCliente: TTabdConduitDb; TabCliente: TTable; TPalmCep: TTabdConduitDb; TabCep: TTable; qry_aux: TQuery; procedure TabdConduitOpenConduit(var Error: Integer); private procedure SincClienteNoDesktop; procedure IncluiClienteNoPalm; procedure EncontraEndereco; procedure IncluiCepNoPalm(cep:TStringList); public { Public declarations } end; var DataModule1: TDataModule1; implementation {$R *.DFM} procedure TDataModule1.SincClienteNoDesktop; type TRegistro = record Codigo: LongInt; Nome: string; Rua: string; Comp: string; Bairro: string; Cidade: string; Estado: string; end; var Registro: TRegistro; begin TPalmCliente.Open; TabCliente.open; try //encontrar registros modificados no palm while not TPalmCliente.Eof do begin //o registro está apagado? if (TPalmCliente.Attributes and sraRecAttrDeleted) > 0 then begin if TabCliente.FindKey([TPalmCliente.RecordId]) then
33
TabCliente.Delete; TPalmCliente.Next; end else //o registro não foi modificado? if (TPalmCliente.Attributes and sraRecAttrDirty) = 0 then begin TPalmCliente.Next; end else //o registro foi alterado.. begin //obtendo os valores dos campos da tabela do Palm Registro.Codigo := StrtoInt(Trim(TPalmCliente.Fields[0].ArrayValue[0])); Registro.Nome := VartoStr(Trim(TPalmCliente.Fields[1].ArrayValue[0])); Registro.Rua := VartoStr(Trim(TPalmCliente.Fields[2].ArrayValue[0])); Registro.Comp := VartoStr(Trim(TPalmCliente.Fields[3].ArrayValue[0])); Registro.Bairro := VartoStr(Trim(TPalmCliente.Fields[4].ArrayValue[0])); Registro.Cidade := VartoStr(Trim(TPalmCliente.Fields[5].ArrayValue[0])); Registro.Estado := VartoStr(Trim(TPalmCliente.Fields[6].ArrayValue[0])); //encontramos o registro na tabela local if TabCliente.FindKey([TPalmCliente.RecordId]) then TabCliente.Edit else TabCliente.Insert; with TabCliente do begin //gravamos as informações obtidas no banco local FieldByName('Num_Registro').AsInteger := TPalmCliente.RecordId; FieldByName('Cd_cliente').AsInteger := Registro.Codigo; FieldByName('Nm_cliente').AsString := Registro.Nome; FieldByName('Log_Cliente').AsString := Registro.Rua; FieldByName('Comp_Cli').AsString := Registro.Comp; FieldByName('Bairro_Cli').AsString := Registro.Bairro; FieldByName('Cid_Cli').AsString := Registro.Cidade; FieldByName('Uf_cli').AsString := Registro.Estado; FieldByName('Apagado').AsBoolean := False; FieldByName('Modificado').AsBoolean := False; FieldByName('Criado').AsBoolean := False; Post; end; //processar eventos pendentes TabdConduit.YieldCycles(1); TPalmCliente.Next; end;
34
end; //verificar se registros foram criados, modificados ou apagados no banco local TabCliente.First; while not TabCliente.Eof do begin //registro criado? if (TabCliente.FieldByName('Criado').AsBoolean) then IncluiClienteNoPalm; //registro modificado? if (TabCliente.FieldByName('Modificado').AsBoolean) then begin with TPalmCliente do try //ver se o registro está no palm Find(TPalmCliente.FieldByName('Num_Registro').AsInteger); Edit; FieldByName('Cd_Cliente').AsString :=
TabCliente.FieldByName('Cd_cliente').AsString; FieldByName('Nm_Cli').AsString :=
TabCliente.FieldByName('Nm_Cliente').AsString; FieldByName('Log_Cli').AsString :=
TabCliente.FieldByName('Log_cliente').AsString; FieldByName('Comp_Cli').AsString :=
TabCliente.FieldByName('Comp_cli').AsString; FieldByName('Bairro_Cli').AsString :=
TabCliente.FieldByName('Bairro_cli').AsString; FieldByName('Cid_Cli').AsString :=
TabCliente.FieldByName('Cid_cli').AsString; FieldByName('Uf_Cli').AsString :=
TabCliente.FieldByName('Uf_cli').AsString; Post; except //incluir no Palm se não encontrou IncluiClienteNoPalm; end; //zerar todos os flags TabCliente.Edit; TabCliente.FieldByName('Modificado').AsBoolean := False; TabCliente.FieldByName('Apagado').AsBoolean := False; TabCliente.Post; end; //registro apagado? if (TabCliente.FieldByName('Apagado').AsBoolean) then begin with TPalmCliente do
35
try //procura o registro no palm Find(TabCliente.FieldbyName('Num_Registro').AsInteger); Delete; //apaga também no banco local TabCliente.Delete; Continue; except //se não encontrar no palm, apaga somente no banco local TabCliente.Delete; Continue; end; end; Application.ProcessMessages; TabCliente.Next; end; finally //remover todos os arquivos apagados no palm TPalmCliente.PurgeDeletedRecords; //resetar todas as flags TPalmCliente.ResetSyncFlags; //fechar as tabelas.. TPalmCliente.Close; TabCliente.Close; end; end; procedure TDataModule1.IncluiClienteNoPalm; begin //incluir novo cliente no palm with TPalmCliente do begin Append; FieldByName('Cd_Cliente').AsString :=
TabCliente.FieldByName('Cd_cliente').AsString; FieldByName('Nm_Cli').AsString :=
TabCliente.FieldByName('Nm_Cliente').AsString; FieldByName('Log_Cli').AsString :=
TabCliente.FieldByName('Log_cliente').AsString; FieldByName('Comp_Cli').AsString :=
TabCliente.FieldByName('Comp_cli').AsString; FieldByName('Bairro_Cli').AsString :=
TabCliente.FieldByName('Bairro_cli').AsString; FieldByName('Cid_Cli').AsString := TabCliente.FieldByName('Cid_cli').AsString;
36
FieldByName('Uf_Cli').AsString := TabCliente.FieldByName('Uf_cli').AsString; Post; //pegar o id criado pelo palm Last; TabCliente.Edit; TabCliente.FieldByName('Num_Registro').AsInteger := RecordId; TabCliente.FieldByName('Criado').AsBoolean := False; TabCliente.FieldByName('Modificado').AsBoolean := False; TabCliente.FieldByName('Apagado').AsBoolean := False; TabCliente.Post; end; end; procedure TDataModule1.TabdConduitOpenConduit(var Error: Integer); begin Error := 0; //sincronizar as tabelas... SincClienteNoDesktop; EncontraEndereco; end; procedure TDataModule1.EncontraEndereco; type TRegistro = record logradouro: string; cidade: string; bairro: string; cep: string; uf: string; end; var Registro: TRegistro; Ceps_Busca : TSTringList; begin Ceps_Busca := TSTringList.Create; TPalmCep.Open; TabCep.open; //encontrar registros modificados no palm try TPalmCep.First; while not TPalmCep.Eof do begin //o registro não foi modificado desde a ultima consulta if (TPalmCep.Attributes and sraRecAttrDirty) = 0 then begin TPalmCep.Next;
37
end else if (TPalmCliente.Attributes and sraRecAttrDeleted) > 0 then begin TPalmCep.Next; end else begin //obtendo os valores dos campos da tabela do Palm Ceps_Busca.add(VartoStr(Trim(TPalmCep.Fields[3].ArrayValue[0]))); TPalmCep.Delete; TabdConduit.YieldCycles(1); TPalmCep.Next; end; end; finally IncluiCepNoPalm(Ceps_Busca); //remover todos os arquivos apagados no palm TPalmCep.PurgeDeletedRecords; //resetar todas as flags TPalmCep.ResetSyncFlags; //fechar as tabelas.. TPalmCep.Close; TabCep.Close; end; end; procedure TDataModule1.IncluiCepNoPalm(cep:TStringList); var i:integer; begin for i:=0 to (cep.Count -1) do begin with Qry_aux do begin Close; Sql.Clear; Sql.Add('Select * from ceps where cep8_log = ' + #39 + Trim(cep[i]) + #39); try open except on e: edatabaseerror do
38
begin //faça o tratamento// end; end; if RecordCount > 0 then begin TPalmCep.Append; TPalmCep.FieldByName('Rua').AsString := FieldByName('Nome_log').AsString; TPalmCep.FieldByName('Cidade').AsString :=
FieldByName('Local_Log').AsString; TPalmCep.FieldByName('Bairro').AsString := FieldByName
('Bair8_Log').AsString; TPalmCep.FieldByName('Cep').AsString := FieldByName('cep8_Log').AsSTring; TPalmCep.FieldByName('Uf').AsString := FieldByName('Uf_Log').AsString; TPalmCep.Post; end; end; end; end; end.
