Comunicação com o Servidor

Quanto a comunicação com o servidor da aplicação, o padrão utilizado foi o protocolo REST, por ser muito comum em aplicações móveis. Foram encontradas algumas API, tais como RESTDroid1

e Retrofit2

, que tinham como propósito encapsular as requisições, simplificando as chamadas aos web services REST.

Tais APIs foram encontradas e estudadas, entretanto, por serem insatisfatórias, for- mam descartadas. Estas foram consideradas insatisfatória por não apresentarem uma vasta documentação nem uma fácil customização, tendo sido desenvolvido como solução a criação de três classes: WebServiceImpl, JSONProcessor, HttpClientSingleton. Estas re- alizam o envio e o recebimento das requisições entre o dispositivo móvel e o servidor de aplicação, conforme apresentado da Figura 8.

Figura 8: Módulo Comunicação com o Servidor

A Figura 8 apresenta as classes que compõem o sistema de envio e de recebimento das requisições entre o dispositivo móvel e o servidor de aplicação. O processo é inicializado quando utilizado alguns dos métodos existente na classe OffLineManager, presente no mó- dulo Utils, que tem como objetivo encaminhar a requisição para a classe WebServiceImpl, cuja função é realizar a requisição junto ao servidor de aplicação.

A classe WebServiceImpl, que consiste na implementação da interface WebService, contempla uma série de métodos existentes que já estão predefinidos, tais como: get,

1

https://github.com/PCreations/RESTDroid

2

post, put e delete. Se houver a necessidade, o desenvolvedor poderá realizar uma nova implementação da classe que se adeque a sua realidade, basta que realize uma nova imple- mentação da interface WebService e dos seus métodos ali contidos. Pode ser modificado também o protocolo a ser utilizado nas trocas de mensagens entre o servidor de aplicação e o dispositivo móvel.

A classe HttpClientSingleton apresenta diversos atributos, que define desde o tempo de espera do serviço (timeout) até o tempo de espera do socket, adota como padrão de projeto o singleton, que consiste em manter uma única instância da classe durante todo o uso do aplicativo. Caso seja necessário modificar o timeout basta modificar os valores dos atributos presentes na classe. Já a classe JSONProcessor tem como atribuição realizar a serialização dos objetos e a de serialização do JSON para os objetos persistêntes.

3.2.3

Persistência

Quanto a Persistência, inicialmente foi realizado um estudo com o intuito de encon- trar alguma API que apresentasse características como: a realização da persistência de forma não intrusiva; a capacidade de realizar as operações básicas, como criar, remover, atualizar e buscar; realizar a criação das tabelas e do banco de dados quando inicializado; e, principalmente, que apresentasse licença permitindo total liberdade para realizar as modificações necessárias.

No estudo foram encontradas algumas API, tais como h4Android3_{, OrmLite}4_{, Sugar}

ORM5

e o andOrm6

, que apresentavam todas essas características ou parte delas, sendo então realizado um estudo mais detalhado nestas APIs, com a finalidade de analisar e comprovar se tudo o que era prometido seria de fato cumprindo.

A API selecionada foi o h4Android, que tem como características a persistência mape- amento objeto relacional, relacionamento entre as classes, a criação das tabelas do banco de dados e as operações básicas de criação, remoção, atualização, busca e não seja intru- siva. Porém, apesar desta apresentar grande parte dos objetivos almejados, ainda assim foi necessário realizar algumas modificações no h4Android para que trabalhasse conforme o planejado e fosse incorporado ao framework.

Foram realizadas as seguinte modificações:

3 https://code.google.com/p/h4android/wiki/h4Android 4 http://ormlite.com/ 5 http://satyan.github.io/sugar/ 6 https://github.com/jonatasdaniel/andorm

• Implementação do insert em cascata das classes mapeadas; • Implementação do update em cascata das classes mapeadas;

• Implementação do findAll em cascata das classes mapeadas, que consiste na consulta de todos os dados da Classe em questão;

• Implementação do find, sendo possível informar quais os atributos devem ser con- siderados no momento da busca, realizando esta em cascata nas classes mapeadas, em que todas as entidades das classes serão retornadas;

• O método updateAll foi desenvolvido, uma vez que o mesmo não apresentava im- plementação padrão do h4Android. A sua utilização também ocorrerá na forma de cascata nas classes mapeadas;

• Criação da interface, denominada PersistDB, que se faz necessária para a persis- tência dos dados, sendo necessária para a definição da chave primária de todas as classes mapeadas.

A Figura 9 exemplifica as classes que são responsáveis pela persistência do framework.

Figura 9: Módulo de Persistência

A classe OffLineManager, responsável por delegar as requisições da aplicação, irá delegar a função de persistência para classe PersistenceManager, que apresenta os métodos necessários para a realização das operações básicas de persistências dos dados no SQLite, utilizando o mapeamento objeto relacional, padrão esse adotado pelo framework.

Todos os métodos existentes na classe PersistenceManager estão presentes na interface IPersistenceManager, podendo ser reimplementada pelo desenvolvedor caso a mesma não apresente as operações conforme desejado. Referente a classe PersistenceManager, esta

tem como herança a classe SQLiteDatabase que provê a comunicação de acesso a base de dados SQLite.

3.2.4

Sincronização

Quanto a sincronização, o framework adota como padrão a sincronização automática e assíncrona. Durante o uso do aplicativo, ao realizar uma operação, o framework em background verificará se há algum dado que necessite ser sincronizado junto ao servidor de aplicação, sendo constatado esta necessidade, serão carregados todos os dados presentes na tabela sincronização e será inicializado o processo. A sincronização é bilateral, podendo ser realizada do servidor de aplicação para o dispositivo móvel, durante as requisições REST ou durante a sicronização do dado alterado quando offline para o servidor.

A Figura 10 exemplifica as classes responsáveis pelo mecanismo padrão de persistência dos dados que irão ser sincronizados.

Figura 10: Classe responsável pelos dados a serem sincronizados

A classe OffLineManager, por ser a principal classe do framework, tem como respon- sabilidade delegar a realização de determinadas operações, uma delas é que seja realizada a sincronização dos dados, que invocará o método sync, sempre que for detectado conec- tividade, este está presente na classe SincronizacaoUtils, tendo como finalidade verificar se há algum registro que necessita ser sincronizado e atualizado na base de dados lo- cal do dispositivo. O serviço de Sincronização está intrisicamente ligado com o Módulo Persistência e com o Módulo Comunicação com o servidor.