Telephony.Sms.Inbox.PERSON使用不推荐的Contacts.People._ID

Question

Bounty奖励--奖金将颁发给从填充的Telephony.Sms.Inbox.PERSON值获得的答案，仅使用ContractsContact表给相关联的Contact。

我正在以我的应用程序中标准的方式读取SMS消息：

    final String[] projection = {Telephony.Sms.Inbox.BODY,
            Telephony.Sms.Inbox.ADDRESS,
            Telephony.Sms.Inbox.READ,
            Telephony.Sms.Inbox.DATE,
            Telephony.Sms.Inbox.PERSON};

    final Cursor cursor = ctx.getContentResolver().query(Telephony.Sms.Inbox.CONTENT_URI,
            projection, null, null, Telephony.Sms.Inbox.DEFAULT_SORT_ORDER);

填充后，从索引Telephony.Sms.Inbox.PERSON返回的id与不推荐的Contacts.People._ID的id相关，可以用以下方式查询进一步的联系人信息：

    final String[] projection = {Contacts.People.DISPLAY_NAME};
    final String[] selectionArgs = {contactId};

    final Cursor cursor = ctx.getContentResolver().query(Contacts.People.CONTENT_URI,
            projection, Contacts.People._ID + " = ?", selectionArgs, null);

为什么相对较新的电话API会使用不推荐的表而不是ContactsContract

Telephony.Sms.Inbox.PERSON文档声明：

类型:整数(引用内容中的项://联系人/人员)

我试过没成功(但不奇怪？)若要在任何ContactsContract id字段中找到到id的映射，只需使用不推荐的API来解析需要快速执行的查询。

这类查询包括通过特定联系人搜索消息，而我只有名称。联系人可能有多个号码，这些数字可能不符合Telephony.Sms.Inbox.ADDRESS条目的格式。

使用解决办法和Telephony.Sms.Inbox.ADDRESS和ContactsContract.PhoneLookup并不是世界末日，从数字到联系人，但我仍然觉得--我一定是遗漏了什么东西--

下面是我为“Joe”获取消息的过程。

1)查询ContactsContract表，以确认设备上存在一个名为Joe的联系人--如果联系人实际上被列为'Joe ‘，则得到一个接近匹配的联系人。

2)使用已确认的名称，我以下列方式查询不推荐的Contact.People表以获取联系人的所有关联in：

    final String selection = Contacts.People.DISPLAY_NAME + " LIKE ?";

    final String[] projection = {Contacts.People.DISPLAY_NAME,
            Contacts.People._ID};

    final String[] selectionArgs = {contactName};

    final Cursor cursor = ctx.getContentResolver().query(Contacts.People.CONTENT_URI,
            projection, selection, selectionArgs, null);

3)使用不推荐的联系人ids列表，我按如下方式查询消息表：

    final String[] referredArgs = new String[contactIdArray.size()];
    for (int i = 0; i < contactIdArray.size(); i++) {
        referredArgs[i] = contactIdArray.get(i);
    }

    final String referredSelection = Telephony.Sms.Inbox.PERSON + " IN "
            + "(" + TextUtils.join(",", referredArgs) + ")";

    final String[] projection = {Telephony.Sms.Inbox.BODY,
            Telephony.Sms.Inbox.ADDRESS,
            Telephony.Sms.Inbox.READ,
            Telephony.Sms.Inbox.DATE,
            Telephony.Sms.Inbox.PERSON};

    final Cursor cursor = ctx.getContentResolver().query(Telephony.Sms.Inbox.CONTENT_URI,
            projection, referredSelection, null, Telephony.Sms.Inbox.DEFAULT_SORT_ORDER);

我希望有人会告诉我，我在这里的房子周围，有一个更明显的解决方案使用当前的API。我不认为使用ContactsContract.PhoneLookup来迭代整个消息表是一种优化的解决方案。

提前谢谢。

Answer 1

我不会使用Telephony.Sms.Inbox.PERSON字段，如果我是您，肯定不会查询不推荐的People apis。People apis已经被废弃了这么长时间了，您不能指望我们的所有设备都能正确地支持它。

首先你需要明白的是，短信和联系人之间没有一对一的联系。短信可以来自一个非接触的电话号码，一个单一的联系人，多个联系人，一个联系人和非联系人的混合物，阿尔法数字ids，甚至其他更罕见的选择。

接下来，您应该仔细阅读股票代码，以及它如何处理从SMS集合中获得的正确的“收件人ID”，其中有一个名为canonical-addresses (或canonical-address)的集合，用作电话号码(或以逗号分隔的电话列表)和收件人id之间的映射。代码在启动时执行一个查询，将整个表缓存在内存中，然后使用它在电话和收件人ids之间映射。

这是映射类

Answer 2

为什么相对较新的Telephony会使用不推荐的表，而不是ContactsContract？

你所指的并不新鲜。在Telephony.java中，您可以看到它依赖于现有的content://sms提供程序：

    public static final class Inbox implements BaseColumns, TextBasedSmsColumns {
        /**
         * The {@code content://} style URL for this table.
         */
        public static final Uri CONTENT_URI = Uri.parse("content://sms/inbox");

它已经是在甜甜圈里 (可能在此之前，但我没有检查)。

Kitkat是一种改变SMS应用的能力。的新鲜事。

Answer 3

已经五年了，而且还很重要。如果只需要同步文本消息，则仍然需要无休止地执行phoneLookup和挂起联系人表上的回调。