本文基于Android4.4.2浅析Contacts及相关模块的功能实现,以及数据库的操作。
本篇博文主要分析contacts,后续会分析contactsProvider。
联系人模块主要记录用户的联系人数据,方便用户快捷的操作和使用,主要包括本机联系人和Sim卡联系人。
本机联系人主要存储在手机内部存储空间,Android平台上是通过数据库进行存储,使用ContentProvider组件封装,提供复杂的字段用于表示联系人数据,并提供用户快捷的操作,比如增加,删除,修改,查询等等。
Sim卡联系人主要存储在Sim卡内部存储文件,包括adn、fdn、sdn。主要提供简单的字段用于表示联系人数据。并通过IccProvider提供的接口进行数据的增加、删除、修改、查询操作。
联系人Contacts应用主要包括3个部分:
1. Contacts主要响应用户的请求和交互,数据显示。
2. ContactsProvider继承自Android四大组件之一的ContentProvider组件,封装了对底层数据库contact2.db的添删改查。
3. SQLite在底层物理性地存储了联系人数据。
Contacts模块的主要7块功能:
简要说明:
* PeopleActivity类负责联系人列表的显示。
* PeopleActivity包含4个Fragment,每个Fragment包含一个ListView。
* 各个Fragment中ListView的Adapter(BaseAdapter的子类)负责将数据填充到ListView。
* 各个Fragment的Loader类(CursorLoader的子类)负责加载数据。
* 实现LoadertManager接口负责管理这些CursorLoader。
为什么使用Loader?
1. Loaders确保所有的cursor操作是异步的,从而排除了UI线程中堵塞的可能性。
2. 当通过LoaderManager来管理,Loaders还可以在activity实例中保持当前的cursor数据,也就是不需要重新查询(比如,当因为横竖屏切换需要重新启动activity时)。
3. 当数据改变时,Loaders可以自动检测底层数据的更新和重新检索。
数据加载流程概览:
流程具体分析:
先上图:
PeopleActivity
。 onCreate
方法: createViewsAndFragments(savedState);
mFavoritesFragment = new ContactTileListFragment();
mAllFragment = new DefaultContactBrowseListFragment();
mGroupsFragment = new GroupBrowseListFragment();
发现创建了3个Fragment,分别是 收藏联系人列表、所有联系人列表、群组列表。
DefaultContactBrowseListFragment
: DefaultContactBrowseListFragment
的祖父类是: ContactEntryListFragment
LoadManager
接口,实现了该接口3个重要的抽象方法:public Loader onCreateLoader(int id, Bundle args);//创建Loader
public void onLoadFinished(Loader loader, D data);//数据加载完毕后的回调方法
public void onLoaderReset(Loader loader);//数据重新加载
该类同时提供了重要的抽象方法:
protected abstract T createListAdapter();//创建适配器Adapter类。
这意味着,子类可以按需求创造自己的适配器Adapter类,完成各个子界面Listview的数据显示,如3.1节图1所示。
DefaultContactBrowseListFragment
类: onCreateView
之前,会执行父类的一些方法,顺序如下:onAttach()
setContext(activity);
setLoaderManager(super.getLoaderManager());
setLoaderManager
中设置当前的LoaderManager
实现类。
加载联系人列表数据的过程中,这个类是ProfileandContactsLoader
。
之后执行onCreate
方法。
DefaultContactBrowseListFragment
的onCreate(Bundle)
方法:mAdapter = createListAdapter();
发现在这里创建了ListAdapter
:
DefaultContactListAdapter adapter =
new DefaultContactListAdapter(getContext());
可以知道创建的ListAdapter类型是DefaultContactListAdapter
并返回到DefaultContactBrowseListFragment
类。
执行完onCreate
方法之后,
执行DefaultContactBrowseListFragment
的onCreateView
方法。
DefaultContactBrowseListFragment
的onCreateView
方法:mListView = (ListView)mView.findViewById(android.R.id.list);
mListView.setAdapter(mAdapter);
首先获取了ListView用以填充联系人数据,然后设置了适配器,但是此时适配器中的数据是空的,直到后面才会加载数据更新uI。
在onCreateView
方法执行完之后,在uI可见之前回调执行Activity
的onStart
方法。
DefaultContactBrowseListFragment
的onStart
方法:mContactsPrefs.registerChangeListener(mPreferencesChangeListener);
startLoading();
首先注册了一个ContentObserve
的子类监听数据变化。
然后执行startLoading
方法,目测这应当就是开始加载数据的方法了!
DefaultContactBrowseListFragment
的startLoading
方法:int partitionCount = mAdapter.getPartitionCount();
for (int i = 0; i < partitionCount; i++) {
……
Partition partition = mAdapter.getPartition(i);
startLoadingDirectoryPartition(i);
……}
Partition
这个类持有一个Cursor
对象,用来存储数据。
Adapter
持有的Partition
,Partition
类代表了当前需要加载的Directory
,可以理解为一个联系人集合,比如说本地联系人、Google联系人……这里我们假设只加载本地联系人数据,所以partitionCount=1。
从这里我们可以做出猜测:
联系人数据不是想象中的分页(每次N条联系人数据)加载,也不是说一次性全部加载,而是一个账户一个账户加载联系人数据,加载完毕一个账户就在uI刷新并显示数据。
DefaultContactBrowseListFragment
的startLoadingDirectoryPartition
方法:loadDirectoryPartition(partitionIndex, partition);
进入此方法:
getLoaderManager().restartLoader(partitionIndex, args, this);
这个方法是LoaderManager
实现类的方法,参照文档解释:
这个方法会新建/重启一个当前LoaderManager中的Loader,将回调方法注册给他,并开始加载数据。也就是说会回调LoaderManager的onCreateLoader()方法。
Starts a new or restarts an existing android.content.Loader in this manager, registers the callbacks to it, and (if the activity/fragment is currently started) starts loading it
进入LoadManager接口的实现类:LoaderManagerImpl 的restartLoader方法内部:
LoaderInfo info = mLoaders.get(id);
Create info=
createAndInstallLoader(id, args, (LoaderManager.LoaderCallbacks
ContactEntryListFragment
的onCreateLoader
方法,位于DefaultContactBrowseListFragment
的祖父类ContactEntryListFragment
中:CursorLoader loader = createCursorLoader(mContext);//创建Loader
mAdapter.configureLoader(loader, directoryId);//配置Loader
发现在此方法中,首先调用createCursorLoader
方法创建了Loader
。
然后通过configureLoader
方法配置Loader
的query
方法的查询参数,也就是配置SQL中select查询语句的参数。
这也同时意味着,ContactEntryListFragment
类的子类们可以重写createCursorLoader
方法以提供适合自身的Loader
,重写configureLoader
方法为Loader
配置合适的参数,适配各种自定义的查询获取数据。
createCursorLoader
方法在DefaultContactBrowseListFragment
类中实现:return new ProfileAndContactsLoader(context);
直接返回了DefaultContactBrowseListFragment
的数据加载器:ProfileAndContactsLoader
这就是DefaultContactBrowseListFragment
的Loader
实现类(数据加载器)。
ProfileAndContactsLoader
类是如何加载数据的呢? CursorLoader
,而CursorLoader
又继承自AsyncTaskLoader
LoadBackGround()
方法中: ContentResolver
的query
方法:Cursor cursor = getContext()
.getContentResolver()
.query(mUri, mProjection, mSelection,
mSelectionArgs, mSortOrder, mCancellationSignal);
cursor.registerContentObserver(mObserver);
通过这个Query
方法,实现了对联系人数据的查询,返回Cursor
数据。并绑定了数据监听器。
query(mUri, mProjection, mSelection,
mSelectionArgs, mSortOrder, mCancellationSignal)
的这些参数那里指定的呢?
configureLoader
方法在DefaultContactListAdapter
类中实现,实现了对query
参数的配置:
configureUri(loader, directoryId, filter);
loader.setProjection(getProjection(false));
configureSelection(loader, directoryId, filter);
loader.setSortOrder(sortOrder);
可以看到,配置了Loader
主要的几个参数:Uri
,Projection
,Selection
,SortOrder
。
这些参数用于最后和ContactsProvider
交互的方法Query
方法中……
ContactsProvider2
的uri
是:Uri:content://com.android.contacts/contacts?address_book_index_extras=true&directory=0
发现ContentProvider
的服务类似一个网站,uri
就是网址,而请求数据的方式类似使用Get
方式获取数据。
最后通过ContentProvider2
构建的查询语句是这样的:
SELECT
_id, display_name, agg_presence.mode AS contact_presence,
contacts_status_updates.status AS contact_status, photo_id, photo_thumb_uri, lookup,
is_user_profile
FROM view_contacts
LEFT OUTER JOIN agg_presence ON (_id = agg_presence.presence_contact_id) LEFT OUTER JOIN
status_updates contacts_status_updates ON
(status_update_id=contacts_status_updates.status_update_data_id)
可以发现最后通过ContactsProvider2
实现的查询,并不是直接查询相关的表(Contacts
表、rawcontacts
表,data
表……),而是直接查询view_contacts
视图,因为这样会有更加高的效率。
这也就意味着如果想给联系人数据库新增一个字段供界面使用,仅修改对应的表结构是不行,还要修改对应的视图才能得到想要的效果。
LoaderManager
的onLoadFinished
方法,完成对Ui界面的更新:onPartitionLoaded(loaderId, data);
接着进入onPartitionLoaded
方法:
mAdapter.changeCursor(partitionIndex, data);
进入这个changeCursor
方法:
mPartitions[partition].cursor = cursor;
notifyDataSetChanged();
发现在这里改变了Adapter
的数据集Cursor
,并发出通知数据已经改变,UI进行更新。
至此,默认联系人数据的显示分析到此结束。
其他Fragment
的数据填充基本仍然类似此流程,所不同的只是各自的Fragment
、Adapter
、CursorLoader
以及CursorLoader
配置的参数(uri,projection,selection,args,order……)有所不同。
可以参考下表:
Fragment | Adapter | CursorLoader |
---|---|---|
DefaultContactBrowseListFragment(默认联系人列表) | DefaultContactListAdapter | ProfileAndContactsLoader |
ContactTitleListFragment(收藏联系人列表) | ContactTileAdapter | ContactTileLoaderFactory StarredLoader |
ContactTitleFrequentFragment(常用联系人列表) | ContactTitleAdapter | ContactTileLoaderFactory |
FrequentLoader GroupBrowseListFragment(群组列表) | GroupBrowseLIstAdapter | GroupListLoader |
GroupDetailFragment(指定ID群组的联系人列表) | GroupMemberTileAdapter | GroupMemberLoader |
ContactDetailFragment(指定ID联系人信息) | ViewAdapter | ContactLoader |
关键类:
ContactDetailActivity
ContactDetailFragment
ContactLoaderFragment //不可见 负责加载联系人详细数据,集成LoadManager对象。
ContactLoader //联系人详细信息Loader。
ContactDetailLayoutController //布局控制类。
原理类似列表显示,如下简要说明:
* ContactLoaderFragment
类创建了一个实现LoaderManager.LoaderCallbacks
接口的对象,数据类型指定为Contacts
。负责创建、管理ContactLoader
。
* 得到当前用户选择的联系人URI
,配置对应的ContactLoader
。
* 后台数据查询分完毕后,回调LoadManager
的onLoadFinished()
方法,并将数据以Contacts
的数据类型返回,然后回调ContactDetailLoaderFragmentListener
的onDetailsLoaded()
方法。
* onDetailsLoaded()
方法中,新开一个线程,通过ContactDetailLayoutController
类的setContactData(Conatct)
设置数据,刷新ContactDetailFragment
。
联系人数据所属的账号不同,加载的UI也是不同的,比如Sim卡联系人一般只有name,phone num,但是本地账号联系人可能就会有email,address,website等信息……
联系人数据UI的加载是通过代码动态加载的,而不是xml文件写死的。
先进入新建联系人界面:
主界面PeopleActivity
中点击新建联系人Button,触发onOptionsItemSelected
方法中的
case R.id.menu_add_contact
分支:
执行startActivity(intent);
startActivity启动Intent,Intent的Action设置为android.intent.action.INSERT
找到匹配此Action的Activity:ContactEditorActivity
ContactEditorActivity
的布局文件:
ContactEditorActivity
的onCreate()
方法中找到布局:
setContentView(R.layout.contact_editor_activity);
在xml文件中找到这个布局:
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent">
<fragment class="com.android.contacts.editor.ContactEditorFragment"
android:id="@+id/contact_editor_fragment"
android:layout_width="match_parent"
android:layout_height="match_parent" />
FrameLayout>
只包含一个Fragment:ContactEditorFragment
。程序解析Xml文件到这里就会执行ContactEditorFragment
类。
ContactEditorFragment
的onCreateView
方法://展开布局
final View view
= inflater.inflate(R.layout.contact_editor_fragment, container, false);
//找到布局中的一个线性布局
//关键的布局是contact_editor_fragment中的一个iD为editors的线性布局!
mContent = (LinearLayout) view.findViewById(R.id.editors);
contact_editor_fragment
:<ScrollView xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:fillViewport="true"
android:fadingEdge="none"
android:background="@color/background_primary"
>
<LinearLayout android:id="@+id/editors"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical"
/>
ScrollView>
于是确认ContactEditorFragment
的根布局就是一个id为editors
的LinearLayout。
想到上一步的语句:
mContent = (LinearLayout) view.findViewById(R.id.editors);
所以关键就在于,接下来在代码中为mContent
这个线性布局动态添加地了什么UI,而这些UI才是真正显示的东西。
ContactEditorFragment
的onCreateView
方法执行完毕之后,会调用onActivityCreate()
方法:if (Intent.ACTION_INSERT.equals(mAction))
{
final Account account = mIntentExtras == null ? null : (Account)
mIntentExtbindEditorsForNewContactras.getParcelable(Intents.Insert.ACCOUNT);
final String dataSet = mIntentExtras == null ? null :
mIntentExtras.getString(Intents.Insert.DATA_SET);
if (account != null) {
// Account specified in Intent
createContact(new AccountWithDataSet(account.name, account.type, dataSet));}
上面代码首先取出了当前Account信息,数据信息。封装为一个AccountWithDataSet
对象,作为createContact
方法的参数。之前我们分析过,编辑界面和账户是高度相关的,所以对UI的动态操作必然和Account对象相关。进入createContact
方法。
ContactEditorFragment
中的createContact()
到底对界面干了什么!! createContact
方法中调用了bindEditorsForNewContact(account, accountType)
: ……
final RawContact rawContact = new RawContact();
if (newAccount != null) {
rawContact.setAccount(newAccount);
} else {
rawContact.setAccountToLocal();
}
final ValuesDelta valuesDelta = ValuesDelta.fromAfter(rawContact.getValues());
final RawContactDelta insert = new RawContactDelta(valuesDelta);
……
mState.add(insert);
bindEditors();
发现暂时还是没有对界面做什么事情,任然处于酝酿阶段……
首先使用传入的Accout对象创建一个RawContact
对象,然后使用RawContact
对象构建了一个RawContactDelta
对象insert
,接着就将insert
对象放入RawContactDeltaList
对象mState
中。
RawContact
类:raw contacts数据表内的一条数据,表示一个联系人某一特定帐户的信息。存储Data表中一些数据行(电话号码、Email、地址……)的集合及一些其他的信息。
他的存储结构为: HashMap
RawContactDelta
类:包含RawContact
对象(即一个联系人某一特定帐户的信息),并具有记录修改的功能。
RawContactDeltaList
类:内部的存储结构是ArrayList
,可以理解为 单个联系人所有账户的数据集合。
bindEditors()
法。 ……
mContent.removeAllViews();
……
final BaseRawContactEditorView editor;
……
editor = (RawContactEditorView) inflater.inflate(R.layout.raw_contact_editor_view,mContent, false);
//添加视图了……………………
mContent.addView(editor);
//为自定义视图BaseRawContactEditorView设置状态,必然是修改UI的操作!
editor.setState(rawContactDelta, type, mViewIdGenerator, isEditingUserProfile());
可以看到,mContent
这个LinearLayout添加的View是editor,而editor是一个自定义的视图BaseRawContactEditorView
,布局是R.layout.raw_contact_editor_view
。
<com.android.contacts.editor.RawContactEditorView
xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical"
android:paddingTop="@dimen/editor_padding_top">
<include
用户账户相关UI
layout="@layout/editor_account_header_with_dropdown" />
<LinearLayout
android:id="@+id/body"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical">
<LinearLayout
android:layout_height="wrap_content"
android:layout_width="match_parent"
android:orientation="horizontal"
android:paddingTop="8dip">
<LinearLayout
android:layout_height="wrap_content"
android:layout_width="0dip"
android:layout_weight="1"
android:orientation="vertical">
<include
Name相关的UI
android:id="@+id/edit_name"
layout="@layout/structured_name_editor_view" />
<include
拼音名
android:id="@+id/edit_phonetic_name"
layout="@layout/phonetic_name_editor_view" />
LinearLayout>
<include
照片相关的UI
android:id="@+id/edit_photo"
android:layout_marginRight="8dip"
android:layout_marginEnd="8dip"
layout="@layout/item_photo_editor" />
LinearLayout>
<LinearLayout
中间部分Item的显示在此处
android:id="@+id/sect_fields"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical"
android:layout_marginBottom="16dip"/>
添加其他字段 按钮
<Button
android:id="@+id/button_add_field"
android:text="@string/add_field"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_gravity="center"
android:layout_marginBottom="32dip"/>
LinearLayout>
com.android.contacts.editor.RawContactEditorView>
那么问题来了:中间的那部分布局(电话、地址……)去哪儿了?
搜索有可能包含这些内容的线性布局sect_fields
,发现在RawContactEditorView
类中初始化为mFields
:
mFields = (ViewGroup)findViewById(R.id.sect_fields);
那么只需要看代码中对mFields添加了什么uI!
回到之前的bindEditors()
方法,RawContactEditorView
对象editor
从xml中解析完成后,执行了setState
方法:
editor.setState(rawContactDelta, type, mViewIdGenerator, isEditingUserProfile());
RawContactEditorView
类,找到setState
方法:public void setState(RawContactDelta state, AccountType type, ViewIdGenerator vig,boolean isProfile)
……
// 遍历当前账户所有可能的item种类,如电话,姓名,地址……,并分别创建自定义视图KindSectionView
for (DataKind kind : type.getSortedDataKinds()) {
……
final KindSectionView section = (KindSectionView)mInflater.inflate(
R.layout.item_kind_section, mFields, false);
section.setEnabled(isEnabled());
section.setState(kind, state, false, vig);
mFields.addView(section);
……
}
手机账户下的imme
类型如下:
the mimeType isvnd.android.cursor.item/name
the mimeType is#displayName
the mimeType is#phoneticName
the mimeType isvnd.android.cursor.item/photo
the mimeType isvnd.android.cursor.item/phone_v2
the mimeType isvnd.android.cursor.item/email_v2
the mimeType isvnd.android.cursor.item/postal-address_v2
the mimeType isvnd.android.cursor.item/nickname
the mimeType isvnd.android.cursor.item/organization
the mimeType isvnd.android.cursor.item/note
the mimeType isvnd.android.cursor.item/im
the mimeType isvnd.android.cursor.item/sip_address
the mimeType isvnd.android.cursor.item/group_membership
the mimeType isvnd.android.cursor.item/website
发现遍历了当前账号类型中所有可能的数据类型(DataKind),
创建了相关的自定义视图KindSectionView
对象section
,
再将section
对象添加到mFields
中显示,
这个mFields
正是之前在RawContactEditorView
类中初始化的线性布局:
mFields = (ViewGroup)findViewById(R.id.sect_fields)。
到这里,基本可以确定,中间部分(也就是除了Name、Photo 和底部的添加字段Button之外的部分),就是通过这个mFields
动态的根据当前账户类型添加编辑的KindSectionView
条目来填充的。
首先观察一下KindSectionView
的布局文件item_kind_section
:
<com.android.contacts.editor.KindSectionView
xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical">
<include 这是一个TextView,title
android:id="@+id/kind_title_layout"
layout="@layout/edit_kind_title" />
<LinearLayout 线性布局,用于添加EditText
android:id="@+id/kind_editors"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical" />
<include 添加新条目的TextView,初始化状态不可见
android:id="@+id/add_field_footer"
layout="@layout/edit_add_field" />
com.android.contacts.editor.KindSectionView>
KindSectionView
加载完xml文件之后,会执行onFinishInflate
方法:mTitle = (TextView) findViewById(R.id.kind_title);
mEditors = (ViewGroup) findViewById(R.id.kind_editors);
mAddFieldFooter = findViewById(R.id.add_field_footer);
把Xml文件中三个主要的部分都得到了,接下来重点就是观察代码中对他们做了什么。
在第12步中,加载完xml文件之后,执行KindSectionView
的setState
方法:
section.setState(kind, state, false, vig);
将rawContactDelta
对象state
传递给了KindSectionView
类的setState
方法:
进入KindSectionView
类的setState
方法:
mKind = kind;
mState = state;
rebuildFromState();
先进行局部变量的赋值。
rebuildFromState()
方法: for (ValuesDelta entry : mState.getMimeEntries(mKind.mimeType)) {
//……遍历当前账户可能的键值对,比如电话、Email、地址……
createEditorView(entry); //这个方法应当是创建EditText的方法!
}
在这个方法中,对mState
集合中所有Mime类型的ValuesDelta
集合(ArrayList
类型)进行遍历,而后将每一个 ValuesDelta
对象 entry
作为参数调用了createEditorView(entry)
也就是创建各个种类的EditText
方法,根据entry
对象创建相应的EditText
!
简单说,就是创建mState
中存在的类型的EditText
。
当然……这还都只是猜测,需要进入createEditorView
方法确认。
createEditorView
方法:view = mInflater.inflate(layoutResId, mEditors, false);
Editor editor = (Editor) view;
editor.setValues(mKind, entry, mState, mReadOnly, mViewIdGenerator);
第13步初始化的mEditors
对象(也就是那个被猜测应该是放EditTExt
的线性布局)在这里被使用!
editor
对象是TextFieldsEditorView
类的对象,进入TextFieldsEditorView
的setValues
方法,看看他是如何根据entry
对象创建EditText
的:public void setValues(DataKind kind, ValuesDelta entry, RawContactDelta state, boolean readOnly,ViewIdGenerator vig)
{
int fieldCount = kind.fieldList.size(); //获取所有可能的datakind的总数
for (int index = 0; index < fieldCount; index++) //遍历所有可能的datakind,
{
final EditText fieldView = new EditText(mContext); //创建EditText对象,之后进行配置
fieldView.setLayoutParams……
fieldView.setTextAppearance(getContext(), android.R.style.TextAppearance_Medium);
fieldView.setHint(field.titleRes); //EditText的Hint
……
fieldView.addTextChangedListener(new TextWatcher() //注册TextChangedListener
{
@Override
public void afterTextChanged(Editable s) {
// Trigger event for newly changed value
onFieldChanged(column, s.toString());
}
mFields.addView(fieldView); //将EditText添加到当前的线性布局中!
}
注释基本解释了如何通过一个ValuesDelta
(理解为键值对集合)对象entry
创建布局中的所有EditText
。
至此,联系人编辑界面的显示原理基本分析完成。
对联系人数据的操作基本流程:
以新增联系人为例:
基本流程图如下:
总结这个流程:
1. 展开编辑界面视图,同时创建相应的RawContactDeltaList对象mState。
2. 将用户输入的联系人信息实时地保存到mState对象中。
3. 用户点击保存按钮,在服务中启动新线程,根据mState中的对象构建ContentProviderOperation数组(理解为构建Sql语句)。
4. 将ContentProviderOperation数组交给ContentResolver处理(理解为执行Sql语句),操作数据库。
代码详细逻辑分析:
第一步,从界面封装数据: RawContactDeltaList
对象mState
1. 联系人编辑界面ContactEditorActivity
,输入完毕后点击Save按钮,触发ContactEditorFragment
类的save ()
方法:重要代码如下:
Intent intent =ContactSaveService.createSaveContactIntent(
mContext,mState,SAVE_MODE_EXTRA_KEY, saveMode, isEditingUserProfile(),
((Activity)mContext).getClass(), ContactEditorActivity.ACTION_SAVE_COMPLETED,
mUpdatedPhotos);
mContext.startService(intent);
可以看到存储新建联系人是通过ContactSaveService
的createSaveContactIntent
方法开始的,重要的是其中第二个参数是RawContactDeltaList
对象mState
,显然这是从Fragment
的各个EditText
控件返回到ContactSaveService
的数据,那问题就是这个mState
是如何组织数据的呢????
mState
是什么类的对象。 mState
是RawContactDeltaList
类的对象,先分析一下这个类是什么数据结构: RawContactDeltaList
类:内部的存储结构是ArrayList
,可以理解为 单个联系人所有账户的数据集合。
RawContactDelta
类:包含RawContact
对象(即一个联系人某一特定帐户的信息)。
RawContact
类:raw contacts
数据表内的一条数据。存储Data表中一些数据行的集合及一些其他的信息,表示一个联系人某一特定帐户的信息。
所以他的存储结构为: HashMap
ValuesDelta
:类似ContentValues
的键值对数据结构,是一个HashMap
。用来存储data表的数据,key为Mime
类型。
ContactEditorFragment
开始: onActivityCreate
方法: bindEditors();
进入此方法:
int numRawContacts = mState.size();
for (int i = 0; i < numRawContacts; i++) {
// TODO ensure proper ordering of entities in the list
final RawContactDelta rawContactDelta = mState.get(i);
editor.setState(rawContactDelta, type, mViewIdGenerator, isEditingUserProfile());
发现他遍历了mState
集合
将每一个rawContactDelta
对象作为参数传入RawContactEditorView
类的setState
方法。
实际上如果只是保存单个账户的联系人信息,这里mState
内的rawContactDelta
对象只会有一个。
RawContactEditorView
类的setState
此方法: public void setState(RawContactDelta state, AccountType type, ViewIdGenerator vig,
boolean isProfile) {
for (DataKind kind : type.getSortedDataKinds()) {
final KindSectionView section = (KindSectionView)mInflater.inflate(
R.layout.item_kind_section, mFields, false);
section.setEnabled(isEnabled());
section.setState(kind, state, false, vig);
mFields.addView(section);
可以发现,首先遍历了当前用户账户所有的可能条目种类,
rawContactDelta
对象传递给了KindSectionView
类的setState
方法:mKind = kind;
mState = state;
rebuildFromState();
先进行局部变量的赋值,然后进入到rebuildFromState()
方法:
for (ValuesDelta entry : mState.getMimeEntries(mKind.mimeType)) {
createEditorView(entry);
}
在这个方法中,又对mState
集合中所有Mime
类型的ValuesDelta
集合(ArrayList
类型)进行遍历,而后将每一个 ValuesDelta entry
对象作为参数调用了createEditorView
(也就是创建各个种类的EditText)方法,根据entry对象创建相应的EditText
!
createEditorView
方法:editor.setValues(mKind, entry, mState, mReadOnly, mViewIdGenerator);
editor
对象是TextFieldsEditorView
类,进入TextFieldsEditorView
的setValues
方法,看看他是如何根据entry对象创建EditText的:public void setValues(DataKind kind, ValuesDelta entry, RawContactDelta state, boolean readOnly, ViewIdGenerator vig)
{
int fieldCount = kind.fieldList.size(); //获取所有可能的datakind的总数
for (int index = 0; index < fieldCount; index++)//遍历所有可能的datakind
{
final EditText fieldView = new EditText(mContext);//创建EditText对象,之后进行配置
fieldView.setLayoutParams……
fieldView.setTextAppearance(getContext(), android.R.style.TextAppearance_Medium);
fieldView.setHint(field.titleRes); //EditText的Hint
……
fieldView.addTextChangedListener(new TextWatcher() //注册TextChangedListener
{
@Override
public void afterTextChanged(Editable s) {
// Trigger event for newly changed value
onFieldChanged(column, s.toString());
}
mFields.addView(fieldView); //将EditText添加到当前的线性布局中!
}
注释基本解释了如何通过一个ValuesDelta
(理解为HashMap)对象entry创建布局中的所有EditText
。
TextFieldsEditorView
: EditText
绑定了监听器addTextChangedListener
,当EditTest内容发生改变时回调onFieldChanged
方法:进入此方法:saveValue(column, value);
TextFieldsEditorView
的saveValue
方法:protected void saveValue(String column, String value) {
mEntry.put(column, value);
}
发现这个方法将EditText
中用户输入的字符串实时地放到entry
这个以当前column
为key的ValueData
键值对中。
回顾到第5步中:KindSectionView
类中的for循环遍历操作:entry
是mState
集合的一个对象,因此也就是说:当用户编辑EditText
的同时,也改变了mState
集合。
以上,就是ContactSaveService
的createSaveContactIntent
中第二个关键参数mSTate
对象的由来。
第二步,将数据封装为ContactsProviderOperation
数组,并提交:
这个对象mState
很重要,因为当用户点击保存Button时,
就会启动ContactSaveService
的createSaveContactIntent
方法,开始保存联系人的操作:
1, 进入此方法:
public static Intent createNewRawContactIntent(Context context,
ArrayList values, AccountWithDataSet account,Class extends Activity> callbackActivity, String callbackAction)
{
serviceIntent.putParcelableArrayListExtra(
ContactSaveService.EXTRA_CONTENT_VALUES, values);
}
第二个参数values
就是上文中分析的mState
,可以看到放到了Intent中传递,key是EXTRA_CONTENT_VALUES,后面会通过Intent传递这个对象(已经实现parcelable接口)。
2, 完成上述操作之后,在ContactEditorFragment
中会调用startService
启动ContactService
:
此Service继承自IntentService
,在单独的Thread执行联系人的添删改查(耗时)操作。
在ContactSaveService
启动之后,在onHandleIntent(Intent)
中对Intent的action进行匹配:
if (ACTION_SAVE_CONTACT.equals(action)) {
saveContact(intent);
CallerInfoCacheUtils.sendUpdateCallerInfoCacheIntent(this);
}
3, 可以发现对存储联系人匹配的分支调用了ContactSaveService
的saveContact
方法:
private void saveContact(Intent intent) {
//1,得到之前保存的mState对象,赋值给state
RawContactDeltaList state = intent
.getParcelableExtra(EXTRA_CONTACT_STATE);
//2,在这里建立ContentProviderOperation操作数组
final ArrayList diff=
state.buildDiff();
ContentProviderResult[] results = null;
//3,提交给ContentResolver,批量提交操作。
results = resolver.applyBatch(ContactsContract.AUTHORITY,
diff);
4, 首先取出Intent中传递过来的mState
,执行buildDiff()
构造ContentProviderOperation
数组diff
。
那么这段程序的的迷惑之处在于ContentProviderOperation
数组是怎么通过一个
RawContactDeltaList
对象mState
构建的?
5, 进入RawContactDeltaList
的diff
方法:
for (RawContactDelta delta : this) {
//此处传入的diff是一个空ArrayList对象:
delta.buildDiff(diff);
}
在for循环中遍历了this对象,也就是mState
对象,取出了其中所有的RawContactDelta
对象,如果只是保存到一个账户,这里的RawContactDelta
对象只会有一个。
然后调用delta.buildDiff(diff)
,diff
是一个空ArrayList
对象,并且此时是空对象。
6, 进入RawContactDelta
的buildDiff(ArrayList
方法:
for (ArrayList mimeEntries : mEntries.values()) {
for (ValuesDelta child : mimeEntries) {
//根据child键值对构建builder对象
builder = child.buildDiff(Data.CONTENT_URI);
//构造ContentProviderOperation数组!
possibleAdd(buildInto, builder);
}
}
有两层for循环,完成了对ContentProviderOperation
数组的构建。
外层的循环mEntries
对象包含了被保存的联系人所有的数据,本身的数据结构是HashMap
,
此时mEntries
的数据类似这样:
可以观察到,mEntries
的key是mime
类型,value是对应的data
值组成的ArrayList
。
{
vnd.android.cursor.item/phone_v2=[{ IdColumn=_id, FromTemplate=false, is_super_primary=0, data_version=0, mimetype=vnd.android.cursor.item/phone_v2, data2=2, is_primary=0, _id=593, data1=1111-111-1111, }],
vnd.android.cursor.item/postal-address_v2=[{ IdColumn=_id, FromTemplate=false,
data_version=0, mimetype=vnd.android.cursor.item/postal-address_v2, _id=594,
data1=ManchesterUnitid, is_super_primary=0, data4=ManchesterUnitid, data2=1,
is_primary=0, }],
}
7, 最终在内层循环调用了ValuesDelta
的buildDiff
方法,参数targetUri=Data.CONTENT_URI
:
public ContentProviderOperation.Builder buildDiff(Uri targetUri)
{
ContentProviderOperation.Builder builder = null;
if (isInsert()) {
mAfter.remove(mIdColumn);
//创建builder对象,关联目标table,这里是Data表
builder = ContentProviderOperation.newInsert(targetUri);
//配置builder参数
builder.withValues(mAfter);
}
//返回
return builder;
}
这里用到了ContentProviderOperation
的内部类Builder
,那Builder
类是什么?
简单说来就是为ContentProviderOperation
数组的构建提供服务的。
一个ContentProviderOperation
对象构建的基本流程就是这样的:
* ContentProviderOperation.newInsert(targetUri)
创建builder对象
* Builder.withValues(ContentValues values)
按照ContentValues构建Builder的参数
* 最后调用Builder
的build()
方法返回一个ContentProviderOperation
对象!
Builder简介:
Used to add parameters to a ContentProviderOperation. The Builder is first created by calling ContentProviderOperation.newInsert(android.net.Uri),
ContentProviderOperation.newUpdate(android.net.Uri),
ContentProviderOperation.newDelete(android.net.Uri)
or ContentProviderOperation.newAssertQuery(Uri).
The withXXX methods can then be used to add parameters to the builder. See the specific methods to find for which Builder type each is allowed. Call build to create the ContentProviderOperation once all the parameters have been supplied.
8, 然后看方法体内执行:
可以看到执行了ContentProviderOperation
的静态方法:newInsert(targetUri)
,完成了对ContentProviderOperation.builder
的创建,然后使用builder.withValues(mAfter)
完成了对builder
添加的参数。
9, 方法返回后回到第六步:
//根据child键值对构建builder对象
builder = child.buildDiff(Data.CONTENT_URI);
// 构造ContentProviderOperation数组!
possibleAdd(buildInto, builder);
发现构建builder
对象并在其中配置参数之后,马上执行了possibleAdd
方法。
10, 进入possibleAdd
方法:
private void possibleAdd(ArrayList diff,
ContentProviderOperation.Builder builder) {
if (builder != null) {
//在这里构建了ContactsProviderOperation数组!
diff.add(builder.build());
}
}
经过以上分析,
经过层层遍历,完成了ContentProviderOperation
数组的构造,
这时候构建完毕的ContentProviderOperation
数组diff
是类似这样的:
[
mType: 1, mUri: content://com.android.contacts/raw_contacts,
mSelection: null, mExpectedCount: null, mYieldAllowed: false, mValues: aggregation_mode=2 data_set=null account_type=null account_name=null, mValuesBackReferences: null,
mSelectionArgsBackReferences: null,
mType: 1, mUri: content://com.android.contacts/data, mSelection: null, mExpectedCount: null, mYieldAllowed: false, mValues: data2=2 mimetype=vnd.android.cursor.item/phone_v2
data1=1111-111-1111, mValuesBackReferences: raw_contact_id=0, mSelectionArgsBackReferences: null,
mType: 1, mUri: content://com.android.contacts/data, mSelection: null, mExpectedCount: null, mYieldAllowed: false, mValues: data2=1
mimetype=vnd.android.cursor.item/postal-address_v2
data1=ManchesterUnitid, mValuesBackReferences: raw_contact_id=0,
mSelectionArgsBackReferences: null,
]
11, 程序返回到第3步
最初的ContactSaveService
类:
回到saveContact
方法,将构造完毕ContentProviderOperation
数组diff
作为参数,调了用contentResolver
的
applyBatch(ContactsContract.AUTHORITY,diff)
提交修改……
基本流程就是到这里就OK了,接下去就是ContatcsProvider
与数据库的操作了。
与ContactsProvider2、数据库的交互
1, 之后深入Contacts的数据操作层ContactsProvider2
:
然后追溯ContentResolver
的applyBatch()
方法:
ContentProviderClient provider = acquireContentProviderClient(authority);
return provider.applyBatch(operations);
2, 根据authority
参数,可以知道acquireContentProviderClient
方法返回的provider
是ContactsProvider2
,所以之后调用了ContactsProvider2
的applyBatch
方法:
return super.applyBatch(operations);
3, 调用了父类AbstractContentProvider
中的applyBatch
方法:
final int numOperations = operations.size();
final ContentProviderResult[] results =
new ContentProviderResult[numOperations];
for (int i = 0; i < numOperations; i++) {
results[i] = operation.apply(this, results, i);
}
4, 发现最终执行了ContentProviderOperation.apply()
方法:
if (mType == TYPE_INSERT) {
Uri newUri = provider.insert(mUri, values); }
if (mType == TYPE_DELETE) {
numRows = provider.delete(mUri, mSelection, selectionArgs);
} else if (mType == TYPE_UPDATE) {
numRows = provider.update(mUri, values, mSelection, selectionArgs);
} else if (mType == TYPE_ASSERT) {
}
我们执行的新增联系人操作,也就是Insert操作。
5, 因此进入Insert分支,调用了ContentProvider2
的insert
方法:
Uri result = insertInTransaction(uri, values);
6, 追踪到ContactsProvider2.insertInTransaction(Uri uri, ContentValues values)
方法:
实现了对URI的匹配,确定执行对哪个数据库的进行插入操作,如果uri是对Data表的操作:
//匹配URI对应的Insert操作表:
case DATA:
case PROFILE_DATA: {
invalidateFastScrollingIndexCache();
id = insertData(values, callerIsSyncAdapter);
mSyncToNetwork |= !callerIsSyncAdapter;
break;
}
7, 最后ContactsProvider2. insertData
方法实现了对底层数据库的直接操作:
final SQLiteDatabase db = mDbHelper.get().getWritableDatabase();
//根据mime类型获取合适 的DataRowHandler类对象
DataRowHandler rowHandler = getDataRowHandler(mimeType);
//使用合适的DataRowHandler对象直接对数据库执行操作
id = rowHandler.insert(db, mTransactionContext.get(), rawContactId, mValues);
return id;
至此,一个联系人的插入操作分析完毕。
添删改查操作的基本流程都类似。
值得注意的是删除联系人并不是真正的删除联系人数据。
用户在联系人列表选择联系人的删除,本地联系人url匹配只是删除contacts
表中的数据,标记raw_contacts
表的字段deletde
为1,而Data
表的数据并没有发生变化。url匹配删除Sim卡联系人或者同步联系人时删除,会直接删除raw_contacts
表的数据,并触发触发器raw_contacts_deleted
,将data
表,agg_exceptions
表,contacts
表的数据全部删除。
当用户进入到联系人编辑界面,删除某个数据。也就是只对联系人的data数据进行删除,而联系人数据未发生变化,这样会根据删除内容获得ContentProviderOperation
数组。最后会调用applyBatch()
函数进行数据更新。
调用applyBatch()
函数过程中,会读取ContentProviderOperation
数组,而数组的每一条记录都会带有一个URI,通过匹配URI
,找到对应的表进行删除操作。操作成功后得到返回结果。
最后根据mimetype
类型数据,获得不同的DataRowHandler
,进行data
数据的删除。
实时获得Sim卡的状态,对Sim上的联系人导入到本地数据库,或者将本地数据中Sim卡联系人删除。数据库Contacts表和raw_Contacts表表中有字段indicate_phone_or_sim_contact表示是否为Sim卡联系人,并区分出Sim1,Sim2上的联系人。
Mtk平台中实现了开机自动导入SIm卡联系人数据的功能。
SimContacts
类负责显示Sim卡中的联系人数据,并与用户交互。AdnList
负责与Sim卡交互,SimaContacts
继承自AdnList
,而AdnList
继承自ListActivity
。 如何交互Sim卡数据?
这里主要是简单应用层的操作,IccProvider
屏蔽了sim卡内部复杂的操作。
使用一个继承自AsyncHandler
的QueryHandler
类封装了异步查询操作:
AsyncHandler类的定义
说明:A helper class to help make handling asynchronous ContentResolver queries easier.
ContentResolver异步查询操作的帮助类,其实它同样可以处理增删改。
AsyncQueryHandler的作用
查询其API便可知,它担供:
startInsert
startDelete
startUpdate
startQuery
这四个操作,并提供相对应的onXXXComplete
方法,以供操作完数据库后进行其它的操作,这四个 onXXXComplete
方法都是抽象方法,可以在子类中实现想要的操作,在本例中是使用QueryHandler类实现了这几个方法,查询完毕后将数据填充到ListView
中。
为什么要使用AsyncQueryHandler
当然也可以使用ContentProvider去操作数据库。这在数据量很小的时候是没有问题的,但是如果数据量大了,可能导致UI线程发生ANR事件。当然你也可以写个Handler去做这些操作,只是你每次使用ContentProvider时都要再写个Handler,必然降低了效率。
因此API提供了一个操作数据库的通用方法。
如何使用AsyncQueryHandler
指定需要查询的数据的URI,与ContentResolver的query方法中的参数并无太大区别。
本例中查询Sim卡联系人数据的的uri是:
Uri.parse("content://icc/adn");
然后调用查询方法:
mQueryHandler.startQuery(QUERY_TOKEN, null, uri, COLUMN_NAMES,
null, null, null);
具体分析:
1. 注册一个BootCmpReceiver
检测开机广播事件,被触发之后启动SIMProcessorService
。
2. SIMProcessorService
继承service
组件,主要实例化了SIMProcessorManager
对象,注册了ProcessorManagerListener
监听器。接受到BootCmpReceiver
发送过来的处理Intent
之后,调用SIMProcessorManager
的handleProcessor
方法。
3. SIMProcessorManager
的handleProcessor
方法根据传递过来的Intent
,在createProcessor
方法中创建相应的Processor
,比如SIMImportProcessor
、SIMRemoveProcessor
、SIMEditProcessor
、SIMDeleteProcessor
。可以观察到有导入SIm卡数据、移除Sim卡数据、编辑Sim卡数据、删除Sim卡数据。
4. 本次操作为导入SIm卡联系人,所以创建的Processor为SIMImportProcessor
,发现其基类为ProcessorBase
,实现了Runnable
接口,因此SIMImportProcessor
类可以理解为Thread
的target
,其run()
方法是线程执行体。
5. SIMImportProcessor
的run()
方法实现了什么功能?首先调用ContentResolver
的query
方法,指定uri
为SIm卡联系人数据的uri
,并进行查询操作(通过匹配Authority
可以得知这里调用的其实是IccProvider
类),得到联系人数据游标Cursor
对象。这一步完成了Sim卡联系人数据的读取。
6. 然后再执行importAllSimContacts
方法,构建ContentProviderOperation
数组OperatioList
,通过ContentResolver
的applyBatch(uri, OperatioList)
方法批量提交对IccProvider
的操作,也就是对数据库的操作,。这一步完成了Sim卡联系人数据写入到Sqlite。
7. 那么,这个线程池是什么时候启动的呢?在第三步的createProcessor
方法之后,将创建的Processor
添加到ProcessorManager
,ProcessorManagerListener
监听器会执行Excute
方法执行被添加的Processor
其内部机制在线程池中执行Processor
类。
预备知识:
Sim卡中存储的号码的类型:
ADN: Abbreviated dialing number, 就是常规的用户号码,用户可以存储/删除。
FDN:Fixed dialer number,固定拨号,固定拨号功能让您设置话机的使用限制,当您开启固定拨号功能后,您只可以拨打存储的固定拨号列表中的号码。固定号码表存放在SIM卡中。能否使用固定拨号功能取决于SIM卡类型以及网络商是否提供此功能。
SDN:Service dialing number,系统拨叫号码,网络服务拨号,固化的用户不能编辑。
从以上的描述,可以看到,一般情况下访问SIM卡联系人数据就是访问ADN。
时序图:
上述第二节,第五步执行ContentResolver
的query
方法时,根据Authority
可以得知匹配的ContentProvider
是IccProvider
:
在IccProvider
的Query
方法中,会执行loadFromEf
方法。
在loadFromEf
中,要先得到一个IIccPhoneBook
对象:
IIccPhoneBook iccIpb =
IIccPhoneBook.Stub.asInterface(ServiceManager.getService("simphonebook");
发现这个对象是用AIDL接口来获取到的,
那么 ServiceManager.getService("simphonebook")
究竟获取了一个什么实体对象呢?
ICCProvider
中调用Stub
的实体类的getAdnRecordsInEf
方法:adnRecords = iccIpb.getAdnRecordsInEf(efType);
这是通过AIDL接口实现的方法调用,最终是调用到了Stub
实体类的getAdnRecordsInEf
方法.
那么可以知道,这个实体类首先必然存在getAdnRecordsInEf()
方法,这个实体类的对象是通过ServiceManager.getService
来获取的,那么找到addService
的地方就可以发现它了。
IccPhoneBookInterfaceManagerProxy
类符合需求:在他的构造函数中执行了addService()
方法,而且存在getAdnRecordsInEf
方法, IccPhoneBookInterfaceManagerProxy
类就是上文中的Stub
实体类。 IccPhoneBookInterfaceManagerProxy
类继承了IIccPhoneBook.Stub
,
在它的构造函数中执行了addService
方法:
String serviceName =
PhoneFactory.getServiceName("simphonebook", phoneId);
if(ServiceManager.getService(serviceName) == null) {
ServiceManager.addService(serviceName, this);
}
addService
方法传入参数为当前IccPhoneBookInterfaceManagerProxy
类的对象,
因此,在IIccPhoneBook iccIpb =IIccPhoneBook.Stub.asInterface(ServiceManager.getService("simphonebook");
是获得的就是IccPhoneBookInterfaceManagerProxy
类的对象。
ICCProvider
类中iccIpb.getAdnRecordsInEf
方法实际就调用到了IccPhoneBookInterfaceManagerProxy
类的getAdnRecordsInEf
方法。 getAdnRecordsInEf
方法中,执行:mIccPhoneBookInterfaceManager.getAdnRecordsInEf(efid);
看到getAdnRecordsInEf
这个方法名就可以知道,这个方法是获取Sim卡内Adn类型联系人数据的方法。
IccPhoneBookInterfaceManager
中实现了getAdnRecordsInEf
方法 getAdnRecordsInEf
方法中,执行:adnCache.requestLoadAllAdnLike(efid, adnCache.extensionEfForEf(efid), response);
adnCache
是类AdnRecordCache
的对象
7. AdnRecordCache
:
在类AdnRecordCache
中实现了requestLoadAllAdnLike
方法,
requestLoadAllAdnLike
中,执行:
new AdnRecordLoader(mFh).loadAllFromEF
(efid, extensionEf,obtainMessage(EVENT_LOAD_ALL_ADN_LIKE_DONE, efid, 0))
这里实例化一个类AdnRecordLoader
的对象,并且调用该对象的loadAllFromEF
方法
AdnRecordLoader
AdnRecordLoader
中实现了loadAllFromEF
方法, loadAllFromEF
方法中,执行:mFh.loadEFLinearFixedAll(ef, obtainMessage(EVENT_ADN_LOAD_ALL_DONE));
mFh
是类IccFileHandler
的对象,实际上是它的子类TDUSIMFileHandler
的对象,继承关系是:TDUSIMFileHandler
继承自SIMFileHandler
继承自IccFileHandler
9. 进入IccFileHandler
在类IccFileHandler
中实现了loadEFLinearFixedAll
方法,
在loadEFLinearFixedAll
方法中,执行:
mCi.iccIOForApp(COMMAND_GET_RESPONSE,fileid, getEFPath(fileid, is7FFF),
0, 0, GET_RESPONSE_EF_SIZE_BYTES,null, null, mAid, response);
联系上下文,mCi
是RIL
类的对象,RIL
是Radio Interface Layer
的缩写,即无线接口通信层。
之后涉及的东西比较底层……以后再慢慢分析……
IccPhoneBookInterfaceManager
类的IccPhoneBookInterfaceManager
方法返回得到Sim卡Adn联系人数据List
数据。IccProvider
的loadFromEf
方法:for (int i = 0; i < size; i++) {
loadRecord(adnRecords.get(i), cursor, i);
}
发现遍历了List
中的数据,放到cursor
对象中,最后返回这个cursor
对象,也就是返回给了最初IccProvider
调用的query
方法返回的Cursor
对象。
导入的基本流程与开机导入Sim卡联系人类似,同样是先query得到SIM卡联系人数据,然后写入联系人数据库,不再做分析。
导出流程就是反过来……
华为的需求:手机联系人详情界面增加一个导出到卡1/卡2/Exchange账户的optionMenu。
具体做的时候完全可以走SIm卡联系人导入导出的流程,只需要指定导入导出数据的uri即可。
SD卡导入导出主要是通过vCard的形式,存储到sd卡或者从sd卡读取指定的vCard文件并进行解析。
从Sd卡导入联系人主要流程:
1. 联系人主界面PeopleActivity
响应选项菜单的onOptionsItemSelected
事件。
2. 弹出Import/Export对话框ImportExportDialogFragment
中选择Import,启动导入界面ImportVCardActivity
.
3. ImportVCardActivity
最终通过startService
启动VCardService
服务。
4. ImportVCardActivity
启动VCardCacheThread
来进行将Vcard文件从外部Sd卡复制到手机内部存储,然后构建Importrequests
数组,该数组封装了被导入Vcard文件的信息。
5. 通过调用VCardService
的HandleImportRequest
通知VCardService
导入VCard。
6. VCardService
启动ImportProcessor
线程,通过实现的一个Vcard文件解析类VCardEntryConstructor
类,第4步构建的Importrequests
数组作为参数,依次导入VCard中的每个联系人(readOneVCard
方法)。
7. 在VCardService
处理导入的过程中,会把过程状态通知给NotificationImportExportListener
,后者负责更新通知状态栏中的信息。
visio时序图如下:
联系人导出到Sd卡与导入流程类似,略。
在Contacts应用内搜索联系人, 主要步骤:
1. 在主界面PeopleActivity
点击联系人搜索按钮,触发onAction
方法。
2. 调用restartLoader
来启动Loader
异步更新数据。
3. 在LoadeManager
的回调接口onCreateLoader
创建、配置Loader
,包括查询的Uri
等,此阶段配置的uri参数为Contacts.CONTENT_FILTER_URI
。
4. Loader
启动后调用ContactProvider2
的query
方法,
匹配的uri为Contacts.CONTENT_FILTER_URI
的分支。
5. 在ContactProvider2
的appendSearchIndexJoin
方法中拼接Sql语句,并调用Sqlite的底层query
语句查询。
6. 完成查询后回调LoaderManager
的onLoaderFinish
刷新UI。
搜索tan字符串的时候,sql语句为:
SELECT _id, display_name, agg_presence.mode AS contact_presence, contacts_status_updates.status AS contact_status, photo_id, photo_thumb_uri, lookup, is_user_profile, snippet
FROM view_contacts
JOIN (SELECT contact_id AS snippet_contact_id, content AS snippet FROM search_index WHERE search_index
MATCH 'content:tan* OR name:B791AB* OR tokens:tan*'
AND snippet_contact_id IN default_directory) ON (_id=snippet_contact_id) LEFT OUTER JOIN agg_presence ON (_id = agg_presence.presence_contact_id) LEFT OUTER JOIN status_updates contacts_status_updates ON (status_update_id=contacts_status_updates.status_update_data_id) ORDER BY phonebook_bucket, sort_key
发现其实最后经过sqlite语句的拼接,查询的是view_contacts
视图。
android联系人的搜索机制如下:
当新建了一个联系人的时候,例如名字为:【abcd】,那么会在raw_contacts表的对应数据中的display_name显示【abcd】,同时在insert的时候会在name_lookup表中存储进去一个normallized_name字段,这个字段是根据名字【abcd】转换成的16进制码,使用的方法是NameNormalize.normalize()方法。
在查询的时候使用的是ContactsProvider2里面的query方法,当输入查询条件时【a】,会使用NameNormalize.normalize()方法将【a】转换成16进制码,然后再进入name_lookup中去查询对应的raw_contacts_id,从而对应出contact显示在界面上。
也就是说,google 的查询并不是根据display_name来进行的,而是通过转换的normallized_name来进行匹配查询,在NameNormalizer.Java文件中定义了normalize方法,这个方法是进行转换的方法,对于数字和字母,做了直接转换的处
理,对于一些特殊字符做了特别的处理,举例如下:
如果输入的是【,】【.】那么google会将这种字符当作分隔符,即输入【a,b,c.d】的话,名字就是【a,b,c.d】,在处理这个名字的时候首先按照【,】【.】来进行分割,分割成【a】【b】【c】【d】后再转换成lookup条件,那么此时在查询的时候输入了【a】,匹配到【a,b,c.d】,再输入【,】时,系统会认为输入的是分隔符,那么会认为用户想要查询结果的基础上再次进行查询,也就是常说的在搜索结果中继续查询,所以此时再输入【a】的时候系统就会认为是在上一次的结果中(【a,b,c.d】)再此查询【a】,那么还是可以匹配到【a,b,c.d】,所以造成了下面的现象:
1.输入【a,a】/【a,c】/【d,d】/…..
2.查询出结果【a,b,c.d】.
而对于一些其他的特殊字符(非数字,非字符),如【@】【_】等等,在转换的时候会自动将这些字符过滤掉,但却保留了分割的特性,即
出现了如下的现象:
1.保存联系人名称为【first@second#three】
2.输入条件【firstsecond】,结果为:【first@second#three】
3.输入条件【three,second】,结果为:【first@second#three】(因为保留的分割特性)
4.输入条件【first@se】,无结果(因为转换时去掉了字符@)
上述即为google default对于查询的机制,关于转换的代码可以在NameNormalizer.java中进行分析。
通过添加Google帐号,并开启同步,则会将Gmail中联系人同步到本地数据库,也可以将本地联系人同步到Gmail中。而且也支持Exchange服务帐号同步。
1,联系人分享
关键类:
ContactDetailActivity
:联系人详细信息显示界面。
ContactLoaderFragment
:被包含于Aty中的Fragment。
ContactDetailLayoutController
:控制布局,填充数据。
分享联系人的实现步骤:
* 在联系人详细信息界面,选择分享。
* 得到当前联系人的uri
* 设置Intent属性、携带指定联系的uri:
final Intent intent = new Intent(Intent.ACTION_SEND);
intent.setType(Contacts.CONTENT_VCARD_TYPE);
intent.putExtra(Intent.EXTRA_STREAM, shareUri);
final Intent chooseIntent = Intent.createChooser(intent, chooseTitle);
2,桌面快捷方式和文件夹
createLauncherShortcutWithContact()
ShortcutIntentBuilder
3,联系人字符分组、字母表导航效果实现机制:
关键问题:需要知道联系人名字的首字母。
把中文转换为拼音字符,这样就可以实现排序,按照字母导航的效果。
发现在rawContacts
表中:
发现Android已经在Sqlite中自动实现了 汉字-拼音 转换功能,直接读取sort_key
这个列的数据就可以。
1,得到联系人数据,并按照sort_key
排序,通过listview显示。
2,用户拖动滑动块时显示字母提示框(A_Z)。
上面的实现都比较简单,问题是sort_key是如何自动生成的?
HanziToPinyin.java
在ContactsProvider2
下,负责将汉字转化为拼音
4,联系人侧边栏字母导航条如何实现?
Android L中contact应用是没有侧边栏的,但是字母导航的数据仍然是可以读到,我们只需要搞个自定义控件,画出A-Z的字母导航条,并监测触摸事件,在Contacts中的listview
中setSelection
点击的字母位置就可以。
public class SideBar extends View {
public static String[] b = { "#", "A", "B", "C", "D", "E", "F", "G",
"H", "I", "J", "K", "L", "M", "N", "O", "P", "Q", "R", "S", "T",
"U", "V", "W", "X", "Y", "Z"};
protected void onDraw(Canvas canvas) {
int height = getHeight()-20;
int width = getWidth();
int singleHeight = height / index.length;
for (int i = 0; i < index.length; i++) {
paint.setColor(android.graphics.Color.parseColor("#b6b6b6"));
paint.setTypeface(Typeface.DEFAULT_BOLD);
paint.setAntiAlias(true);
paint.setTextSize(20);
if (i == choose) {
paint.setColor(Color.parseColor("#28c0c6"));
paint.setFakeBoldText(true);
}
float xPos = width / 2 - paint.measureText(index[i]) / 2;
float yPos = singleHeight * i + singleHeight;
canvas.drawText(index[i], xPos, yPos, paint);
paint.reset();
}
}
@Override
public boolean dispatchTouchEvent(MotionEvent event) {
final int action = event.getAction();
final float y = event.getY();
final int oldChoose = choose;
final OnTouchingLetterChangedListener listener =
onTouchingLetterChangedListener;
final int c = (int) (y / getHeight() * index.length);
if (event.getX() > getWidth()) {
setBackgroundDrawable(new ColorDrawable(0x00000000));
choose = -1;
invalidate();
if (mTextDialog != null) {
mTextDialog.setVisibility(View.INVISIBLE);
}
return true;
}
switch (action) {
case MotionEvent.ACTION_UP:
setBackgroundDrawable(new ColorDrawable(0x00000000));
choose = -1;//
invalidate();
if (mTextDialog != null) {
mTextDialog.setVisibility(View.INVISIBLE);
}
break;
default:
// setBackgroundResource(R.drawable.sidebar_background);
if (oldChoose != c) {
if (c >= 0 && c < index.length) {
if (listener != null) {
listener.onTouchingLetterChanged(index[c]);
}
if (mTextDialog != null) {
mTextDialog.setText(index[c]);
mTextDialog.setVisibility(View.VISIBLE);
}
choose = c;
invalidate();
}
}
break;
}
return true;
}
}
至此contacts应用层的分析基本结束,后面会再写数据层contactsProvider2的分析。