首先接着上一篇，為什麼谷歌設計聯系人顯示的時候姓名和電話不一起顯示？
這裡我們先到谷歌官方看聯系人的介紹：
The Contacts Provider is an Android content provider component. It maintains three types of data about a person, each of which corresponds to a table offered by the provider, as illustrated in figurel.
聯系人資料是通過contentprovider來提供對外資料通路的。聯系人内容提供者包含了聯系人的三種類型資料，每一個 對應于内容提供者的一張表，關系如下圖1所示：
The three tables are commonly referred to by the names of their contract classes. The classes define constants for content URIs, column names, and column values used by the tables:
上面三張表通常被contact類名所引用，下面的這些表使用了一些類，而這些類定義了uris常量，列名以及列對應的值。
<dl></dl>
<dt></dt>
<dd>Rows representing different people, based on aggregations of raw contact rows.</dd>
<dd>Rows containing a summary of a person's data, specific to a user account and type.</dd>
<dd>Rows containing the details for raw contact, such as email addresses or phone numbers.</dd>
<dd>主要就是這三張表了。</dd>
<dd> </dd>
<dd>下面來看看contactprovider對外提供方問方式： </dd>
<dd></dd>
那麼通路這些資料是通過封裝好的query，delete update，insert等方法，而這些方法具有局限性，
<dd>比如查詢：</dd>
那麼這裡就有一個問題，就是一次隻能查一張表，不能進行聯合查詢，因為使用resolver的預設方法中，它是将裡面的内容填到sql語句對應的條件中，這種做法的好處是可以友善使用，其中封裝對一些特殊字元的處理，但是問題是在相關的條件中沒有聯合查詢如外連接配接 内連接配接這些，是以導緻了在使用contentprovider通路系統資料就會有一次隻能通路一個表的結果。
那麼系統提供一個範例，那就是可以先查詢Raw.contact這個表，顯示聯系人的姓名，當點選這個聯系人再根據聯系人_id，通過data這個表獲得聯系人的其他資訊。是以在很多廠商通訊錄app在設計上就規避了這種風險，顯示的時候，先顯示姓名，通過多一步的操作來完成聯系人詳細資訊的展示。
那麼假設如果産品經理要求你顯示的時候就如同下面這樣，該怎麼辦？
做還是不做？？
要做的話 要怎麼做？