Ernani, eu fiz uma implementação usando os dois e o maior problema que tive foi que, como o SyncAdapter já roda em uma Thread exclusiva, lançar outra Thread (já que o RS é assíncrono) não somente não faz sentido, como também dificulta na hora do debug.
-- Além disso, o método #onPerformSync(Account, Bundle, String, ContentProviderClient, SyncResult) tem uma variável de controle, a SyncResult. Essa variável informa o SyncManager se ocorreu alguma falha na sincronização e influencia na política de back-off (tentar novamente).
Pra esperar todas as Requests do RS retornarem, para manter o SyncResult consistente, vc teria que fazer controle de concorrência, coisa que o RS não implementa (embora eu tenha aberto algumas issues no projeto sobre isso) e teria que fazer tudo na unha...
Simplesmente não compensa.
O que eu fiz, foi "espelhar" uma API que fosse compatível com os objetos Request e RequestListener do RS, mas que executasse o trabalho de forma síncrona. Me evitou ter que reescrever várias linhas de código, ficou mais fácil debugar e mais organizado também... :)
You received this message because you are subscribed to the Google Groups "Android Brasil - Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to androidbrasil-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
0 comentários:
Postar um comentário