Удаление файлов с помощью ContentResolver, а не удаление их с помощью file.delete ()

Я только что написал функцию в приложении для Android, которая удаляет файл, используя стандартный класс «Файл» в Java. то есть:

String fileName= "/mnt/Gallery/Img001.jpg";
File file = new File(fileName);
file.delete();

Хотя описанная выше процедура достаточно проста, мне было интересно, есть ли какое-либо преимущество в том, чтобы делать то же самое с помощью ContentResolver. Любой совет будет принят во внимание

Cheers,

Jarryd

------------------------------------------ РЕДАКТИРОВАТЬ ------ ----------------------------------

Вот пример удаления файла с помощью Content Resolver. В этом примере предполагается, что удаляемый файл является изображением и что его 'id' известен.

long mediaId = 155; // NOTE: You would normally obtain this from the content provider!
Uri contentUri = MediaStore.Images.Media.EXTERNAL_CONTENT_URI;
Uri itemUri = ContentUris.withAppendedId(contentUri, mediaId);

int rows = getContentResolver().delete(itemUri, null, null);

String path = itemUri.getEncodedPath();
if(rows == 0)
{
    Log.e("Example Code:","Could not delete "+path+" :(");
}
else
{
    Log.d("Example Code:","Deleted "+path+ " ^_^");
}
 PerracoLabs28 июн. 2012 г., 05:47
А как правильно удалить файл через контент-провайдера? Я пытался: getContentResolver (). Delete (Uri.fromFile (новый файл (fileName)), ноль, ноль); Но я получаю исключение "Неизвестный URL".
 Jazza12 июн. 2012 г., 05:25
После небольшого расследования я обнаружил, что есть преимущество, когда удаленный файл управляется «Поставщиком контента» Android. Изображения, например, хранятся в таблице изображений, чтобы приложения могли быстро просматривать список изображений на устройстве. Использование «getContentResolver (). Delete (uri, null, null)» в вашей деятельности автоматически удалит связанную запись в таблице содержимого. Простое использование «file.delete ()» удалит только физический файл, после чего сканеру мультимедиа потребуется запросить обновление таблицы содержимого.
 Jazza02 июл. 2012 г., 04:25
@ Женя: Сначала я совершил ту же ошибку, что и вы, передав «URL» файлу, который я пытался удалить. Функция delete () требует 'uri', который указывает на строку в таблице поставщика контента. Эту строку нельзя получить, вызвав Uri.fromFile ()! Я отредактировал свой вопрос выше, чтобы проиллюстрировать, как построить этот Uri.

Ответы на вопрос(1)

Решение Вопроса

еимущества по сравнению с непосредственным манипулированием данными.

Вы можете подумать о том, где находится файл и кто его может удалить.

Сценарий 1

Файл находится на SD-карте (путь, доступный для вашего приложения), а ваше приложение удаляет его.

Решение Поскольку путь доступен для вас, Java-подход будет работать с файлом Uri, например:

file: //mnt/sdcard/downloads/image.jpe

Сценарий 2

Файл находится в другом приложении (например, в Dropbox), и ваше приложение должно удалить файл.

Решени: Это означает, что файл фактически находится в частном хранилище другого приложения. Файл: Uri будет вышеупомянутый подход даст вам доступ запрещен. Таким образом, вашему приложению потребуется извлечь Uri контента из приложения, содержащего файл, и вызвать его поставщика контента для удаления.

fileUri = Uri.parse ("content: //" + packageContainedTheFile "+ fileId); // замените его на Uri, полученный из приложения. getContext (). getContentResolver (). delete (fileUri, null, null);

Сценарий 3

File находится в каталоге пакета вашего приложения, т.е. в data / data / com.yourpackage / yourfolder / yourfile.xxx, и ваше приложение является единственным, удаляющим его.

Решение Здесь любой из вышеуказанных подходов будет работать, так как у вас есть доступ для удаления файла. Ури будет выглядеть так:

file: //data/data/yourpackage/folder/file.ex

Основным преимуществом использования контент-провайдера здесь является то, что вы автоматически получаете модель наблюдателя. Обратные вызовы провайдера контента - это четко определенная точка входа, откуда данные изменяются. Следовательно, это желаемое место, чтобы уведомить других об изменениях, используя:

getContext (). getContentResolver (). notify (uri, null)

Предположим, у вас есть представления, которые показывают список таких элементов файла. Как только удаление будет завершено, вы можете получить уведомление.

Сценарий 4

File находится в каталоге пакетов вашего приложения, то есть в data / data / com.yourpackage / yourfolder / yourfile.xxx, и вы хотите предоставить функцию удаления другим приложениям.

Решени: Это похоже на сценарий 1, наоборот. Другие приложения не могут удалить файл в вашем личном хранилище с помощью Uri, например

file: //data/data/yourpackage/folder/file.ext // работает только для вашего приложения

Им нужно будет позвонить вашему контент-провайдеру, чтобы сделать это с помощью Uri.

content: // providerAuthority / delete / id, который ваш поставщик контента должен будет сопоставить с абсолютным путем file.ext.

Резюм

В заключение, использование поставщика контента необходимо в некоторых сценариях, а в других - необязательно. Это во многом зависит от требований вашего приложения. Если у вас есть представления, CursorLoaders на месте и вы хотите получать информацию об обновлениях или хотите предоставить удаление данных вашего приложения другим приложениям, контент-провайдер - самый чистый подход.

Ваш ответ на вопрос