Content Provider는 안드로이드 어플리케이션의 작업처리를 위한 핵심적인 기술입니다. 이 기술은 안드로이드 기기의 주소록, 미디어 스토어, 즐겨찾기, 전화통화 내역등과 같은 데이터들을 공유하여 개발자가 이를 불러오고 업데이트 할 수 있게 합니다. 잘나가는 안드로이드 앱들 중에서 Content Provider 기술을 사용하거나 구현하지 않는 앱은 거의 없다고 보셔도 될것입니다.
Content Provider에 특별히 놀라운 기술은 없습니다. 개발자는 Url을 통하여 대상을 선정하고, SQL로 이들을 쿼리하고, Cursor로 데이터를 가져오는(Iterate) 것 뿐입니다. Content Provider는 그들이 정의된 대로 행동하고, 행동을 정의하고 사용하는것은 매우 쉽습니다. 그러나 이들을 의도된대로 사용하지 않아(Anti-pattern) 앱을 불안정하게 만드는 경우가 있습니다.
Android Framework상에 제시된 Content Provider는 SDK에서 android.provider 패키지 요약 페이지에 잘 설명되어 있습니다. 프레임워크는 보편적인 작업을 자동화 해주고 유용한 상수들을 위한 상징적인(symbolic) 이름을 제공하기 위하여 몇가지의 헬퍼 클래스를 제공합니다.
문제는, 위 패키지에 정의된 것보다 더 많은 Content Provider가 시스템에 존재한다는것입니다. 물론 정의되지 않은 Content Provider들을 사용할 수는 있지만, 사용하지 않는것을 권장합니다. 구글이 제공하는 몇가지 앱들중에서, 이런 정의되지 않은것들을 '내부적'으로 사용하여 데이터에 접근하는 경우가 있기 떄문입니다. 단 안드로이드는 오픈소스 프로젝트이기 떄문에, 안드로이드 소스 패키지에서 이들을 find나 grep과 같은 셸 명령등을 실행하여 찾아내는것은 어려운 일이 아닙니다.
(소스를 이런 방법으로 검색한다는것은 매우 훌륭한 아이디어라 생각되며, 아마 진지한 개발자들은 이를 주기적으로 할지도 모르겠습니다. 주소록 데이터베이스에서 주소를 가져오는 코드를 짤때 의구심이 드신다면, 이 방법을 사용해보세요. 안드로이드 기본앱이 어떻게 이를 처리하고 있는가 소스를 뒤져보시거나, 아니면 코드를 그대로 베껴쓰세요, 그래도 이는 무조건 합법입니다)
이야기를 다시 Content Provider로 돌려봅시다. 예를들어서, 시스템에 기본 내장된 메시징(문자메시지등을 위한) 앱이 있고 이 앱은 메시지를 보여주고 이전 메시지도 보여준다고 칩시다. 이 앱이 있다고 해서 무조건 이것을 개발에 사용할 수 있는 것은 아닙니다. 안드로이드 개발팀은 다음 버전에서도 동일한 메시징 앱을 사용할것이라 보장하지 않으며, 더 나아가 다음버전에서 이 앱을 제거할지도 모릅니다.
더 안좋은 경우는, 특정 제조사가 안드로이드 기기를 현재 SDK 기반으로 제작하고, 그 기준을 모두 만족했다 하더라도, Content Provider와 같은 기능을 사용하지 않는 자신만의 고유한 메시징 앱을 가지고 있을지 모른다는 것입니다. 이 경우에는 개인 개발자의 앱은 말썽을 일으킬 것이며 이는 분명 개인 개발자의 잘못입니다.
그러므로, 우선 문서화 되지 않은 Content Provider을 찾아보세요, 이는 배우기 아주 좋은 아이디어로 가득 차 있을것입니다. 하지만 이를 사용하지는 마세요. 만약 사용하실거라면, 어떤 나쁜일이 생겨도 여러분 스스로가 이를 헤쳐나가셔야 합니다.
===============================
갑자기 생각난 하나의 앱 아이디어, 실현 여부의 확인도중 위의 글을 발견했다. 2개의 책을 참고했는데 위에 대한 언급은 없고 그냥 문서화 되지 않은 Content Provider를 사용하는것이 당연하다는듯이 적어놓았다. 위에 대한 실질적인 예제로 삼성의 갤럭시S가 있는데, 이는 내장된 문자 앱을 사용하는것이 아니라 삼성 고유의 앱을 사용하기 떄문에 Content Provider를 사용할때엔 문자를 읽어올 수 없다. 삼성측에서는 보안을 위해 막아놨다고는 하는데 글쎼.. (그래도 다행인건 broadcastReciever를 사용하여 들어온 문자는 읽을 수 있다는것?) 우리나라 안드로이드 기기 제조회사에서는 안드로이드에 대한 각자만의 최적화를 너무 잘해놓으셔서... 아우 씐나!!
The notion of a Content Provider is central to getting things done in an Android application. This is the mechanism used to expose many of a device's data resources for retrieval and update: Contacts, media store, bookmarks, phone-call log, and so on. It’s hard to find an interesting Android app that doesn’t either use or implement (or both) a Content Provider.
There’s nothing magical or terribly surprising about Content Providers - you address them by Url, query them with SQL, and iterate them with a Cursor. They do what they say they do and get out of the way and they’re easy to create and use. But there’s a common anti-pattern, a way to misuse them that can potentially get your app into trouble, and maybe we’ve made it a little too easy.
The Content Providers that the Android framework gives you are described in the SDK’s android.provider package summary. For many of them, the framework provides helper classes of one sort or another, to help automate common chores and provide symbolic names for useful constants.
The problem is, there are more Content Providers in the system than are documented in that package, and while you can use them, you probably shouldn’t. They’re there because some of the Google-provided apps use them internally to access their own data resources. Because Android is an open-source project, it’s easy enough to find them just by running shell commands like find and grep over the source tree.
(By the way, searching the source tree like this is an excellent idea, something that probably every serious developer does regularly. Not 100% sure of the best way to write code to display a record from the Contacts database? Go ahead, have a look at how the built-in app does it; even better, steal some code; it’s perfectly legal.)
Back to Content Providers. For example, there’s one inside the built-in Messaging (A.K.A. texting or SMS) app that it uses to display and search your history. Just because it’s there doesn’t mean you should use it. The Android team isn’t promising that it’ll be the same in the next release or even that it’ll be there in the next release.
It’s worse than that; someone could ship an Android device based on the current SDK that follows all the rules but has its own enhanced messaging application that doesn’t happen to have such a Content Provider. Your app will break on such a device and it’ll be your fault.
So, go ahead and look at the undocumented Content Providers; the code is full of good ideas to learn from. But don’t use them. And if you do, when bad things happen you’re pretty well on your own.
댓글