Структура класса для ContentProvider, имеющего несколько вложенных таблиц - PullRequest
Новая
       7

Структура класса для ContentProvider, имеющего несколько вложенных таблиц

2 голосов
/ 17 февраля 2010

В документе ContentProvider указано сделать ОДНУ запись в AndroidManifest для вашего класса ContentProvider. Если ваш класс поддерживает несколько вложенных таблиц, то для каждой должна быть объявлена ​​одна константа CONTENT_URI. Как? Вы не можете сделать это, если вы не подкласс для каждой вложенной таблицы. Почему бы просто не иметь несколько провайдеров?

Реализуете ли вы поставщиков таблиц как потомков? С несколькими вложенными таблицами все еще существует только ОДИН класс ContentProvider?

Как видите, меня смущает документация. Читается:

Определить публичный статический финал Uri с именем CONTENT_URI. Это строка, которая представляет полный контент: URI, который Ваш поставщик контента обрабатывает. Вы должен определить уникальную строку для этого значение. Лучшее решение - использовать полное имя класса контент-провайдер (сделан строчными). Так, например, URI для Класс TransportationProvider может быть определяется следующим образом: 

public static final Uri CONTENT_URI = 
               Uri.parse("content://com.example.codelab.transporationprovider");

Если у провайдера есть подтаблицы, также определите константы CONTENT_URI для каждой из подтаблиц. Все эти URI должны иметь одинаковые полномочия (поскольку это определяет поставщика контента) и различаться только по их путям. Например: 

content://com.example.codelab.transporationprovider/train 
content://com.example.codelab.transporationprovider/air/domestic 
content://com.example.codelab.transporationprovider/air/international

Итак, сколько классов мы создаем, чтобы справиться с поездом, воздушным / бытовым и воздушным / международным?

1 Ответ

3 голосов
/ 17 февраля 2010

Если ваш класс поддерживает несколько подстолы тогда должен быть один Константа CONTENT_URI объявлена ​​для каждый. Как? Вы не можете сделать это, если вы подкласс для каждой подстоли.

Не называйте их всех CONTENT_URI, тогда. Это имя не очень полезно для третьих лиц, так как у них не будет доступа к вашему исходному коду для доступа к этому статическому члену данных. Документация тоже смутила меня, и я даже как бы попугаю их инструкции в своей единственной книге, но я отхожу от этого и буду дорабатывать свои материалы, чтобы соответствовать.

Лучше всего искать своих поставщиков контента (ContactsContract, CallLog и т. Д.).

Реализуете ли вы под-таблицу провайдеры как потомки? С несколько вложенных таблиц, есть еще только ОДИН класс ContentProvider?

Имей столько, сколько хочешь. Вы можете сделать это с одним классом или с внутренними классами (см. ContactsContract), или с чем угодно.

...