了解Android联系人的架构 [英] Understanding architecture of Android contacts

查看:226
本文介绍了了解Android联系人的架构的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个Android应用,该应用需要知道何时添加/更新/删除联系人.

I am developing an Android app which needs to know when a contact is added/updated/deleted.

因此,我阅读了几篇文章.我了解,每当联系人更改时,我们都可以通过Content观察器得到通知,但是我们无法获取已添加/更新/删除的联系人.因此,我已经阅读了官方API,并准备了如何捕获特定联系人的设计.

So I read several posts for it. I understand that we can get notified through Content observers whenever a contacts gets changed, but we can't get which contacts have been added/updated/deleted. So I have read the official APIs and prepared my design how to capture that particular contact.

所以我一开始的想法

  1. 我们将存储所有联系人ID,已删除的标记和版本
  2. 每当联系人更改时,我都会从Android系统中获取表格的行数和行数.
  3. 如果我的行数少于系统行数,则联系人已被删除.
  4. 如果我的行数大于系统行数,则已添加联系人.
  5. 如果不是这种情况,则其中一个联系人版本已更改.

我还了解到,如果用户删除了联系人,Android不会删除该联系人,但会将已删除标志设置为0.因此,在这些情况下,行数将是相同的.

I have also learned that Android doesn't delete the contact if it is deleted by user, but it sets 0 on deleted flag. So in these cases the row count will be same.

Android还会根据官方文档中的说明多次更改联系人的行ID.因此,我们如何像查找uri一样唯一地标识它们,如果不是,那么我们还必须为此设置观察者.

Android also changes the row ID of a contact many times as stated in the official docs. So how can we uniquely identify them like lookup uri and if not then we have to put observer for that also.

所以我想知道以上是否正确?如果添加了联系人,则是否将其添加到光标的最后一行,这意味着如果我检查系统数据库的最后一行是否有联系人,它将为我添加或不添加联系人.

So I want to know whether the above is correct? And in the case a contact is added will it be added to the last row of cursor or not means if I check the last row of system database for contacts will it give me the contact added or not.

推荐答案

让我尽可能多地解释一下.基本上,您的政策看起来不错,但实际上比您想象的要复杂.

Let me explain as much as I could. Basically your policy looks pretty good, but actually it is bit more complex than you thought.

在Android上,联系人可以与多个 原始联系人,该联系人可以从许多数据提供者(例如Google,Facebook,Skype等)提供.例如,如果您本地联系人中的一位朋友也正在使用Skype,则 ContactContracts.RawContacts ,但是当您查询

On Android, a contact can be associated with several raw contacts, which may be provided from many data providers, such as Google, Facebook, Skype and so on. For example, if one of your friends in your local contacts is also using Skype, there are two raw contacts existing separately in ContactContracts.RawContacts, but they will be aggregated automatically and show up just as one contact when you query to ContactsContract.Contacts.

这也是为什么很难唯一地标识联系人的原因,因为您可以随时随地拆分或加入他们. LOOKUP_KEY在这种情况下不是很方便.

That is also why it's hard to identify a contact uniquely, because you can split or join them anytime you want. LOOKUP_KEY isn't very handy for this case.

除Google以外的许多应用仅提供单向同步,即从服务到联系人的同步,因此它们是只读的.在这种情况下,将不会使用Deleted标志,而仅在其同步过程中将其删除.因此,您不能简单地依靠该标志.

Many apps except Google only provide a one-way sync, i.e. only from service to contacts, so they are read-only. In this case, the deleted flag will not be used and simply deleted during their synchronization process. Thus, you can not simply rely on the flag.

尽管没有一个很好的简单解决方案,但是如果您观察的是特定的RawContacts而不是Contacts,我想实现所需的目标会容易得多.希望这有助于您的理解.

Though there isn't a good simple solution, I guess it's much easier to achieve what you want, if you observe for a specific RawContacts, not Contacts. Hope this helps your understanding.

这篇关于了解Android联系人的架构的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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