[android] ContactsContract ( 주소록 ) 사용하기 어렵당. ㅠ

[android] ContactsContract ( 주소록 ) 사용하기 어렵당. ㅠ

안드로이드에서 제공하는 주소록 ( ContactsContract ) DB 를 사용하기가 예전처럼 녹녹치가 않다.

더 체계와되어 가공이 더 쉽도록 변형된 주소록의 형태로 ContactsContract 가 등장했지만,

그만큼 복잡도도 올라가서 이해하는 데 높은 난이도가 요구된다.

하지만 한번 trial and error 등을 통해서 익숙해지면,

사용하는데 큰 무리는 또 없을 것으로 예상된다.

안드로이드의 주소록은 ContactsContract 클래스가 base 가 된다.

Contacts, RawContacts, Data 이렇게 3개의 주요 Table 을 통해 contact 정보가 관리되는데,

각각의 table 은 조금씩 다른 정보를 가지고 있다.

Data 테이블

다양한 형태의 정보를 저장하는데 RawContact 에서 참조하는 데이터들을 저장한다.

한 row 는 이름, 사진, 이메일 주소, 폰 번호, 그룹정보 등의 정보를 저장한다.

그 행이 무슨 데이터를 가지고 있는지를 나타내는 MIME 타입이 있는데,

예를 들어 Phone.CONTENT_ITEM_TYPE 이면, 그 행에는 전화번호가 저장된다.

ContactsContract.CommonDataKinds 클래스는 MIME 타입들을 subclass 로 제공한다.

개발자가 필요한 경우 추가적인 MIME 타입 정의도 가능하다.

RawContacts 테이블

Raw Contacts 테이블은 하나의 "사용자계정과 연관된 Data 집합"과 해당 인물에 대한 추가정보를 저장한다. 주소 정보 소스는 구글계정, Exchange 계정, 페이스북 계정일 수 있다.

Contacts 테이블

Contacts 테이블은 동일대상을 나타내는 하나 혹은 그 이상의 RawContacts 의 집합정보를 담는다.

Contacts ContentProvider 는 RawContacts 정보를 하나의 Contacts 로 모은다.

Contacts 에 저장된 정보는 RawContacts 를 기반으로 framework를 통해 자동으로 정리되는 형태이기에

query 는 할 수 있지만 수정은 어렵다.

암시적 주소록 결합.

사용자가 여러개의 주소 정보 소스로부터 주소 정보를 싱크할 때

framework는 동일한 대상에 대해 겹치는 주소정보 ( Raw Contact ) 를 하나로 결합하여

하나의 주소 집합( Contact )로 만들어 둔다.

하지만 개발자가 편의에 따라서 RawData 를 조합하여 작업을 수행해야 할 경우가 많이 발생한다.

주소록 결합은 다음의 규칙을 따라 결합한다.

이름이 동일하다.

이름에 순서만 다른 동일 단어가 사용되었다.

이름에 공통적인 짧은 이름이 있다.

전화번호, 이메일주소, 별명 등을 공유하고 있다.

이 주소록 결합은 안드로이드가 임의로 만드는 것으로 영구적인 자료가 아니라 주소록 변화에 따라 유동적으로 변하는 내용이다.

명시적 주소록 결합.

개발자가 Aggregation Mode 를 주어서 주소 결합을 수행할 수도 있다.

RawContact 의 Aggreation mode 인

AGGREGATION_MODE_DEFAULT

AGGREGATION_MODE_DISABLED

AGGREGATION_MODE_SUSPENDED

중 하나를 선택하여 추가하여 자동주소결합에 대해 설정을 줄 수 있다.

Lookup Key?

주소록에 부과된 ID 는 쉽게 변경될 수 있다.

따라서 Lookup Key 라는 것을 주어 그 유동성을 제약하는데..

빈번한 주소록 검색 작업 등을 겪는다면 id 와 lookup 키를 모두 저장(캐시)하는 것이 좋다.

id 를 기반으로 찾는 것은 매우 빠른데, 찾은 정보와 lookup key 가 일치하는지 보고

만약 일치하지 않는다면 lookupkey 를 기반으로 찾으면 된다.

2017.07.01 내용 보강

ContactId 가 바뀌는 대표적 케이스는 Contact Aggregation 이 일어날 때이다.

A 라는 Contact 와 B 라는 Contact 이 Aggregation 이 되면, A, B 둘 중 하나의 ID 는 Invalid 해지는 것은 저명하다.

( A 가 Host 가 되었을때 새로운 ContactId 가 부여될지 아니면 A 의 Id 를 따라갈지는 확인해보지 않았다. )

Lookup Key 는 Raw Contact 에 대한 서버측 식별자와 연관된 문자열 이다.

즉 ContactId 가 바뀌는 대표적인 Aggregation case 에도 RawContactId 는 변하지 않기 때문에 이 Lookup key 로 해당 contact 을 찾을 수 있는 것이다.

이러한 연유로 어떤 Contact 접근 포인트를 준비할 때는 ContactId와 LookupKey 를 함께 Cache 하는 것이 좋다.

aggregation mode, aggregation_mode_default, aggregation_mode_disabled, aggregation_mode_suspended, Android, android 주소록, android 주소록 db, Contacts, contacts table, contacts 테이블, contactscontract, contactscontract.commondatakinds, data, data table, data 테이블, exchange account, facebook account, google account, lookup, lookup key, mime 타입, query, rawcontacts, rawcontacts table, rawcontacts 테이블, table, user account, 계정, 구글 계정, 명시적 결합, 사용자 계정, 안드로이드, 안드로이드 주소록, 안드로이드 주소록 db, 암시적 결합, 주소록, 주소록 db, 태그를 입력해 주세요., 페이스북 계정