如何使用CALLER_IS_SYNCADAPTER正确 [英] How to use CALLER_IS_SYNCADAPTER properly

查看:930
本文介绍了如何使用CALLER_IS_SYNCADAPTER正确的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

不知何故,我不明白的查询参数CALLER_IS_SYNCADAPTER的工作理念。它的默认值是假的,如果设置,脏标志不会被自动设置。那么什么是真正的意思吗?从我的理解,在接触的结果设置dirty标志为1。经过同步适配器每次更改完成这项工作,使用插入/更新/与CALLER_IS_SYNCADAPTER删除插入/更新和删除的记录应该有一个肮脏的标志0 ,是这样吗?

somehow I don't understand the working concept of the query parameter CALLER_IS_SYNCADAPTER. Its default value is false, if set, the DIRTY flag is not automatically set. So what does it actually mean? Out from my understanding, each change on a contact results in setting the dirty flag to 1. After a sync adapter finished the job, using insert/update/delete with the CALLER_IS_SYNCADAPTER the inserted/updated and deleted records should have a dirty flag of 0, is that right?

但是,如果我调用与可选的参数查询,但条目保持与标志1.

However if I invoke queries with that optional parameter, the entries remain with the flag 1.

有没有别的东西,我需要做的,或者是我的理解它是如何应该工作错了吗?或者是有什么要告诉同步已成功完成设置标志系统?

Is there something else I have to do, or is my understanding how it should work wrong? Or is there something to tell the system the sync has been finished successfully to set the flags?

没有任何人有一个样品或一些建议进一步阅读?

Does anybody have a sample or some advices for further reading?

推荐答案

CALLER_IS_SYNCADAPTER并不一定会影响什么是存储在数据库行中,它取决于执行的命令。它不应该对查询的效果。不从装置上的用户应用程序使用它。

CALLER_IS_SYNCADAPTER doesn't necessarily affect what's stored in the database row, it depends on the command performed. It shouldn't have an effect on queries. Do not use it from a user application on the device.

现在......为什么会存在?

Now... Why does it exist?

这是为了帮助有NotifyChange()/ ContentObservers / ContentResolver的/ Syncadapter整合。有两个用例,用于改变在数据库中的行。

It is provided to help with notifyChange() / ContentObservers / ContentResolver / Syncadapter integration. There are two use cases for changing a row in the database.

  1. 本地用户编辑从应用程序。
  2. 变化来自于网络(通过SyncAdapter)

无论哪种变化要求用户界面进行更新,如果它的屏幕上。因此 ContentResolver.notifyChange(URI URI,ContentObserver观测,布尔syncToNetwork)被调用。这将更新ContentObservers并告诉他们去获取从ContentProvider的数据库的最新数据。在呼叫最后一个参数是您的线索。

Either change requires the UI to update, if it's onscreen. Therefore ContentResolver.notifyChange(Uri uri, ContentObserver observer, boolean syncToNetwork) gets called. This updates ContentObservers and tells them to go fetch the newest data from the ContentProvider DB. That last parameter in the call is your clue.

ContentResolver的本身就是一个ContentObserver。当它看到数据库的变化,则它认为启动你的SyncAdapter给变更推到网络上。这是伟大的情况下1。在第二种情况下,它是多余的。这种变化来的的网络,没有任何理由可言启动同步到更改发回。

ContentResolver itself is a ContentObserver. When it sees the database change, it considers starting up your SyncAdapter to push the change up to the network. This is great in case 1. In case 2, it's redundant. The change came from the network, there's no reason at all to start up a sync to send the change back.

Calendar.CALLER_IS_SYNCADAPTER是update()方法的SyncAdapter执行中使用的提示。如果这是真的,ContentProvider的设置 syncToNetwork 为假,确保多余的第二个同步不执行

Calendar.CALLER_IS_SYNCADAPTER is a cue used within the update() performed by the SyncAdapter. When it's true, ContentProvider sets syncToNetwork as false, ensuring a redundant second sync is not performed

第二个例子是作为veljko提及。为从服务器上删除的事情最彻底的方法是设置删除标志,然后执行同步。当CALLER_IS_SYNCADAPTER标志是假的(用户应用程序)调用删除()设置标志。当标志为真(同步发生),一个呼叫删除()将删除到服务器并从所述本地数据库中的行。只有一个delete()的调用,该标志允许的ContentProvider知道它应该哪个任务做的。

A second example is as veljko mentioned. The cleanest way to delete a thing from the server is to set the delete flag, and then perform a sync. When the CALLER_IS_SYNCADAPTER flag is false (user app) a call to delete() sets the flag. When the flag is true (sync is happening), a call to delete() pushes the deletion up to the server and removes the row from the local DB. There's only one delete() call, this flag allows the ContentProvider to know which task it's supposed to do.

这篇关于如何使用CALLER_IS_SYNCADAPTER正确的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆