Jump to content

Recommended Posts

Posted

Boa noite,

Estou a desenvolver uma aplicação para Android que recolhe informação sobre várias actividades do utilizador e armazena localmente numa base de dados (SQLite). Esta informação deve ser enviada para um servidor para posteriormente ser tratada, contudo encontro-me com algumas dúvidas relativamente ao desenvolvimento deste procedimento.

Estou a pensar em ter um BroadcastReceiver que detecta a ligação à rede WI-FI e a ideia é então depois enviar os dados que estão localmente armazenados para o servidor. Porém vejo aqui problemas como: quando detecto que existe ligação à internet e então começo a enviar os dados, se o utilizador desligar de repente o WI-FI pode causar problemas a transmitir a informação ao servidor (transmissão ficar a meio).

Qual a melhor forma de realizar este procedimento? Existe algum mecanismo de failover no SDK do Android?

Cumprimentos.

Posted (edited)

Bom dia,

Qual a melhor forma de realizar este procedimento?

Não há problema nenhum, este problema já foi resolvido à muito tempo com a implementação destas noções (ou conceitos) :

1- A aplicação deve gerenciar o offline/online, dito de outra maneira os dados devem ser armazenados em local na base de dados (por exemplo SQLite) e depois sincronizados no Cloud Computing (o modelo de cliente/servidor esta fora de moda :-) ) sincronizados, quando houver rede Internet (4G/LTE, 3G, Wifi, ...) .

2- Do lado do Cloud os serviços devem respeitar o que se chama a Idempotência as funções ou operações são idempotentes :

Em matemática e ciência da computação, a idempotência é a propriedade que algumas operações têm de poderem ser aplicadas várias vezes sem que o valor do resultado se altere após a aplicação inicial. (Fonte : Wikipédia, a enciclopédia livre.)

3- A transmissão não fica a meio por que à tolerância a falhas ou seja resiliência com um mecanismo ou envia todo (commit ) ou não envia nada (rollback). Para respeitar a integridade do sistema. O que a aplicação tem que fazer é verificar se a operação do lado do servidor é feito corretamente com um ACK de resposta. Para não começar outra vez a enviar dados e consumir a largura de banda.

Qual é a tecnologia que você utiliza do lado servidor ? Java EE Servlet , GlassFish, JETTY, Tomcat , PHP, .Net ? Ou utiliza algum Cloud , Jelastic, CloudBees, OpenShift, Google App Engine, Win Azure Mobile Services, Amazone EC2, ... ?

Como você sabe certamente Java EE 8 vai ser um serviço Cloud PaaS.

Existe algum mecanismo de failover no SDK do Android?

A aplicação corre (Run) na "Dalvik Virtual Machine" e não no SDK Android que serve para o Desenvolvimento.

De qualquer forma a solução esta nos mecanismos disponibilizados no JAVA e utilização de IF else, Exceptions e todo o que java permite para evitar falhas no sistema.

Cordialmente

Ernest Duarte

Edited by Ernest Duarte
Posted (edited)

Eu estou a utilizar um servidor JBoss e tenho um serviço de REST implementado através de RestEasy com JAX. É requisito ter esta arquitetura, daí não me estar a basear numa abordagem com a Cloud.

O que estava a querer saber, e não percebi na tua resposta, é precisamente como é que implemento um mecanismo de commit/rollback para esta situação.

Cumprimentos

Edited by PuPax
Posted

Bom dia,

O ponto 3- permite verificar que os dados armazenados de maneira persistente no lado do servidor respeite a integridade dos dados com o commit / rollback.

A solução ao facto de o utilizador desligar a rede de repente, está em primeiro logar do lado do servidor (e não do lado do mobile). O servidor é que deve garantir o respeito da integridade dos dados enviados.

Os sistemas móveis por natureza têm conexões intermitentes. É uma realidade que deve ser resolvido no lado do servidor, já que o mobile neste caso não pode fazer nada a não ser continuar em modo Offline.

E para isto que serve o ponto 1- aplicação deve gerenciar o offline/online

Do lado servidor o commit / rollback :

-> Os dados são enviados do cliente para o servidor dentro de entidades no formato por exemplo JSON ou XML.

O servidor verifica a integridade dos dados : Se essa entidade chegar completa do lado servidor deve ser armazenada de maneira persistente.

Do lado do servidor deve sempre armazenar os dados de cada entidade de cada uma das etapas, por exemplo no caso os envios se fazem em múltiplos envios de dados o que é o caso dos formulários de comercio Internet.

Do lado do cliente como ouve uma interrupção na conexão ele pode memorizar esse evento e tentar enviar outra vez quando tiver rede Internet. Como à Idempotência (vista no ponto 2-) então não desfaz o que já está feito do lado do servidor.

Exemplo :

Suponha que há diferentes formulários de dados para enviar em diferentes etapas:

Passo 1: Entidade 1: formulário que pede o nome e idade e sexo etc...

ENVIAR

Passo 2: Entidade 2 : formulário que pede o endereço (num, rua, vila, país) etc...

ENVIAR

Passo 3: Entidade 3: formulário que pede o cartão digital azul etc...

ENVIAR

Isto forma um tipo de transacção.

A cada passo do lado do servidor a aplicação deve salvar entidades de maneira persistente (commit intermediários).

Quando todos passos estão concluídos faz um commit final.

Se houver um problema na rede, por exemplo o utilizador desligar de repente então à duas possibilidades ou se faz um rollback (desfaz-se todo) ou se continua no passo seguinte quando o rede volta a funcionar no caso de uma sessão persistente.

De qualquer forma se deve de respeitar a integridade dos dados e a consistência dos dados. E fazer que haja uma sincronia entre os dados do lado cliente e do servidor.

Cordialmente

Ernest Duarte

  • Vote 2

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.