provider

<provider>

문법:

<provider android:authorities="list"
          android:enabled=["true" | "false"]
          android:exported=["true" | "false"]
          android:grantUriPermissions=["true" | "false"]
          android:icon="drawable resource"
          android:initOrder="integer"
          android:label="string resource"
          android:multiprocess=["true" | "false"]
          android:name="string"
          android:permission="string"
          android:process="string"
          android:readPermission="string"
          android:syncable=["true" | "false"]
          android:writePermission="string" >
    . . .
</provider>

상위 엘리먼트:

<application>

하위 엘리먼트:

<meta-data> <grant-uri-permission> <path-permission />

설명:

컨텐트 프로바이더 - ContentProvider의 서브클래스 ? 를 선언한다. 그것은 애플리케이션에 의해 관리되는 데이터에 대한 구조적인 접근을 제공한다. 애플리케이션의 일부가 되는 모든 컨텐트 프로바이더는 매니페스트 파일에 있는 <provider> 엘리먼트에 의해 표시되어야 한다. 선언되지 않는 어떤 것도 시스템에서 볼 수 없으며, 그러므로 실행하지 않을 것이다(여러분 애플리케이션의 일부로써 개발하는 컨텐트 프로바이더만을 선언할 필요가 있으며, 여러분의 애플리케이션이 사용하는 다른 애플리케이션에 의해 개발되는 것들에 대해서는 선언할 필요가 없다)

안드로이드 시스템은 content: URI의 권위authority 영역으로 컨텐트 프로바이더를 구분한다. 예를 들어 다음에 나오는 URI가 ContentResolver.query()에 전달된다고 가정하자.

content://com.example.project.healthcareprovider/nurses/rn

content: 스키마scheme는 그 데이터가 컨텐트 프로바이더에 속하는 것으로 간주하며, 권위authority(com.example.project.healthcareprovider)는 특정 프로바이더를 구분한다. 그러므로 권위authority는 고유해야 한다. 일반적으로 이 예제에서처럼, 권위authority는 ContentProvider 서브클래스에 대한 전체 이름이다. URI의 경로path 영역은 특정 데이터 서브셋subset을 구분하기 위해 컨텐트 프로바이더에 의해 사용될 수도 있다. 하지만 그 경로path는 매니페스트 안에 선언되지는 않는다.

컨텐트 프로바이더 사용과 개발에 관한 정보에 대해서는 7장. “컨텐트 프로바이더”를 보라.

애트리뷰트:

android:authorities

컨텐트 프로바이더의 영역 아래에 있는 데이터를 구분하는 하나 또는 그 이상의 URI 권위authority 목록. 복수의 권위authority는 세미콜론으로 그 이름들을 구분함으로써 나열된다. 충돌을 회피하기 위해, 권위authority 이름은 Java 스타일 네이밍naming 규약을 사용해야 한다(com.example.provider.cartoonprovider와 같이). 일반적으로 그것은 ContentProvider 서브클래스의 이름이다.

디폴트는 없다. 적어도 하나의 권위authority가 지정되어야 한다.

android:enabled

컨텐트 프로바이더가 시스템에 의해 인스턴스화될 수 있는 지 여부 ? 만약 될 수 있다면 “참true” 아니라면 “거짓false” 이다. 디폴트 값은 “참true”이다.

<application> 엘리먼트는 컨텐트 프로바이더를 포함하여, 모든 애플리케이션 컴포넌트에 적용되는 그것 자신의 enabled 애트리뷰트를 가진다. 컨텐트 프로바이더가 활성화될 수 있게 하기 위해서는 <application>과 <provider> 애트리뷰트 둘 다 “참true”(디폴트로 그것들 모두가 그렇듯이)이 되어야 한다. 만약 둘 중 어느 하나가 “거짓false”이라면, 프로바이더는 비활성화된다; 그것은 인스턴스화 될 수 없다.

android:exported

컨텐트 프로바이더가 다른 애플리케이션의 컴포넌트에 의해 사용될 수 있는 지 여부 ? 만약 사용될 수 있다면 “참true” 아니라면 “거짓false”이다. 만약 “거짓false”이라면, 프로바이더는 동일 애플리케이션의 컴포넌트 또는 동일 유저user ID를 가진 애플리케이션에게만 유용하다. 디폴트 값은 “참true”이다.

여러분은 컨텐트 프로바이더를 제공할 수 있지만 여전히 퍼미션 애트리뷰트를 가지고 그것에 대한 접근을 제한할 수 있다.

android:grantUriPermissions

보통 컨텐트 프로바이더의 데이터에 접근할 수 있는 퍼미션을 가지지 않은 것이 일시적으로 readPermission, writePermission, 그리고, permission 애트리뷰트에 의해 강제된 제약을 극복하고 그 데이터 접근을 할 수 있는 퍼미션을 부여받을 수 있는 지 여부 ? 만약 퍼미션이 부여될 수 있다면 “참true” 아니라면 “거짓false”이다. “참true”이라면 컨텐트 프로바이더의 모든 데이터에 대해 퍼미션이 부여될 수 있다. “거짓false”이라면 퍼미션은 <grant-uri-permission> 서브엘리먼트 안에서 나열된 데이터 서브셋subset에 한해서만 부여될 수 있다.

퍼미션을 부여하는 것은 퍼미션에 의해 보호된 데이터에 대해 애플리케이션 컴포넌트에게 한 번의 접근을 제공하는 방법이다. 예를 들어 이메일 메시지가 첨부파일을 포함할 때, 메일 애플리케이션은 그것을 열기 위한 적절한 뷰어가 해당 컨텐트 프로바이더의 모든 데이터를 볼 수 있는 일반적인 퍼미션을 가지고 있지 않을 지라도 그 뷰어를 호출할 지 모른다.

그런 경우에, 그 컴포넌트를 활성화하는 인텐트 오브젝트 내의 FLAG_GRANT_READ_URI_PERMISSION과 FLAG_GRANT_WRITE_URI_PERMISSION 플래그에 의해 퍼미션이 부여된다. 예를 들어 메일 애플리케이션은 Context.startActivity에 전달되는 인텐트 내에 FLAG_GRANT_READ_URI_PERMISSION를 넣을 수 있다. 그 퍼미션은 인텐트에 있는 URI에 국한된다.

만약 여러분이 이 애트리뷰트를 “참true”로 설정하거나 또는 <grant-uri-permission> 서브엘리먼트를 정의함으로써 이 기능을 활성화한다면, 여러분은 부여한 URI가 프로바이더로부터 지워지게 될 때, Context.revokeUriPermission()을 호출해야 한다.

또한 <grant-uri-permission> 엘리먼트를 보라.

android:icon

컨텐트 프로바이더를 나타내는 아이콘. 이 애트리뷰트는 이미지 정의를 포함하는 드로어블drawable 리소스에 대한 레퍼런스로써 설정되어야 한다. 만약 그것이 설정되지 않으면, 전체 애플리케이션을 위해 지정된 아이콘이 대신 사용된다(<application> 엘리먼트의 icon 애트리뷰트를 보라).

android:initOrder

동일 프로세스가 보유하고 있는 다른 컨텐트 프로바이더에 상대적으로, 컨텐트 프로바이더가 인스턴스화되어야 하는 순서. 컨텐트 프로바이더들 사이에 의존성이 있을 때, 그것들 각각에 대해 이 애트리뷰트를 설정하는 것은 그 의존성이 요구되는 순서대로 그것들을 생성하는 것을 보장한다. 그 값은 간단한 정수integer 값이며, 더 높은 숫자들이 먼저 초기화된다.

android:label

컨텐트 프로바이더에 대한 사용자가 읽을 수 있는 라벨. 만약 이 애트리뷰트가 설정되지 않으면, 전체 애플리케이션에 대한 라벨 설정이 대신 사용된다 (<application> 엘리먼트의 label 애트리뷰트를 보라).

라벨은 사용자 인터페이스의 다른 문자열처럼 로컬라이즈 될 수 있도록 문자열 리소스에 대한 레퍼런스로 설정되어야 한다. 하지만 편의상 여러분이 애플리케이션을 개발하는 동안, 그것은 또한 원시 문자열로써 설정될 수 있다.

android:multiprocess

컨텐트 프로바이더의 인스턴스가 모든 클라이언트 프로세스에서 생성될 수 있는 지 여부 ? 만약 인스턴스가 여러 프로세스에서 실행될 수 있다면 “참true”, 아니라면 “거짓false”이다. 디폴트 값은 “거짓false”이다.

보통 컨텐트 프로바이더는 그것을 정의했던 애플리케이션 프로세스 안에서 인스턴스화 된다. 하지만 이 플래그가 “참true”으로 설정되면, 시스템은 그것과 상호작용하길 원하는 클라이언트가 있는 모든 프로세스 내에서 인스턴스를 생성할 수 있다. 따라서 프로세스 간 통신 오버헤드를 방지한다.

android:name

컨텐트 프로바이더, 즉 ContentProvider의 서브클래스를 구현하는 클래스의 이름. 이것은 전체 클래스 이름이어야 한다(“com.example.project.TransportationProvider” 같이). 하지만 단축형으로 이름의 첫 번째 문자가 마침표라면 그것은 <manifest> 엘리먼트에 지정된 패키지 이름뒤에 덧붙여진다.

디폴트는 없다. 이름은 반드시 지정되어야 한다.

android:permission

클라이언트가 컨텐트 프로바이더의 데이터를 읽거나 쓰기 위해 가져야 하는 퍼미션의 이름. 이 애트리뷰트는 읽기와 쓰기 모두에 대해, 하나의 퍼미션을 설정하는 편리한 방법이다. 하지만 readPermission과 writePermission 애트리뷰트가 이것보다 우선권을 갖는다. 만약 readPermission 애트리뷰트 또한 설정된다면, 그것은 컨텐트 프로바이더에 쿼리하는 것에 대한 접근을 통제한다. 그리고 만약 writePermission 애트리뷰트가 설정된다면, 그것은 프로바이더의 데이터를 수정하는 것에 대한 접근을 통제한다.

퍼미션에 관한 더 많은 정보에 대해서는, 앞에 나왔던 퍼미션 섹션과 8장. “보안과 퍼미션”을 보라.

android:process

컨텐트 프로바이더가 실행되어야 하는 프로세스 이름. 보통 애플리케이션의 모든 컴포넌트는 애플리케이션을 위해 만들어진 디폴트 프로세스에서 실행된다. 그 프로세스는 애플리케이션 패키지과 같은 이름을 가진다. <application> 엘리먼트의 프로세스 애트리뷰트는 모든 컴포넌트들을 위한 다른 디폴트를 설정할 수 있다. 그러나 각각의 컴포넌트는 그것 자신의 process 애트리뷰트를 사용해서 디폴트를 오버라이드 할 수 있으며, 이것은 여러분으로 하여금 애플리케이션을 여러 프로세스에 걸쳐 분포시키게 하는 것을 가능하게 한다.

만약 이 애트리뷰트에 할당된 이름이 콜론(“:”)으로 시작된다면, 애플리케이션에 사적인private 신규 프로세스가 필요할 때 생성되며, 액티비티는 그 프로세스에서 실행된다. 만약 프로세스 이름이 소문자로 시작하면, 액티비티는 그 이름을 가지는 글로벌 프로세스 안에서 실행될 것이며 이는 그렇게 하도록 하는 퍼미션을 가지는 경우에 가능하다. 이것은 다른 애플리케이션에 있는 컴포넌트들이 프로세스를 공유하는 것을 가능하게 하며, 리소스 사용을 감소시킨다.

android:readPermission

클라이언트가 컨텐트 프로바이더에 쿼리하기 위해 가져야 하는 퍼미션. 또한 permission 과 writePermission 애트리뷰트를 보라.

android:syncable

컨텐트 프로바이더의 제어하에 있는 데이터가 서버 상의 데이터와 동기화되어야 하는 지 여부 ? 만약 동기화되어져야 한다면 “참true” 그리고 아니면 “거짓false”이다.

android:writePermission

클라이언트가 컨텐트 프로바이더에 의해 제어되는 데이터를 변경하기 위해 가져야 하는 퍼미션. 또한 permission과 readPermission 애트리뷰트를 보라.

도입:

API 레벨 1

더 보기:

Content Providers

↑ Go to top

Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License.

Android 2.0.1 r1 - 02 Dec 2009 15:26

Site Terms of Service - Privacy Policy - Brand Guidelines