Главная » Разработка для Android » УПРАВЛЕНИЕ ФАЙЛАМИ И ДВОИЧНЫЕ ДАННЫЕ в Android приложении

0

 

Поставщикам содержимого часто приходится управлять большими фрагментами двоичных данных, например битовыми картами или музыкальным клипом. Необходимость хранения больших файлов с данными не может не отразиться на проектировании приложения и, скорее всего, серьезно повлияет на производительность программы. Поставщик содержимого может передавать файлы через URI. При этом в идентификаторе ресурса заключается информация о физическом местоположении нужных файлов, а сам клиент может этого и не узнать. Итак, клиенты используют уникальные идентификаторы ресурсов, содержащиеся в поставщиках содержимого, чтобы получать доступ к самим файлам, но не к информации о том, где именно эти файлы находятся. Такой уровень опосредованное позволяет поставщику содержимого управлять этими файлами наиболее целесообразным способом, не допуская утечки информации к клиенту. Если бы такая утечка происходила, она могла бы даже приводить к изменениям кода в клиенте, если бы поставщику содержимого потребовалось изменить способ хранения физических файлов. В принципе, гораздо проще изменять только сам поставщик, а не все его потенциальные клиенты. Клиентам совершенно не нужно знать, что множество медиафайлов, которыми располагает поставщик содержимого, могут находиться во флеш-памяти, на карте памяти или вообще в сети, поскольку поставщик содержимого предоставляет файлы при помощи набора уникальных идентификаторов ресурсов, а клиент уже способен обработать эти идентификаторы. При обращении с каждым конкретным URI клиент просто будет использовать метод ContentResolver. openlnputStream, а потом считывать данные из результирующего потока.

Кроме того, при совместном использовании больших объемов данных несколькими приложениями (поскольку приложение Android не должно считывать или перезаписывать файлы, созданные другим приложением) поставщик содержимого может использоваться для доступа к соответствующим (совместно используемым) байтам. Следовательно, когда поставщик содержимого возвращает указатель к файлу, этот указатель должен иметь вид content: / / URI, а не имя файла в формате Unix. При использовании content:// URI файл можно открывать и считывать, только располагая правом доступа, полученным от поставщика содержимого, который владеет файлом, а не от клиентского приложения (клиентское’ приложение не должно иметь доступа к правам на файл).

Кроме того, необходимо учитывать, что система ввода-вывода, относящаяся к файловой системе, гораздо быстрее и многофункциональнее, чем система обработки объектов двоичной компоновки (BLOB) базы данных SQLite. Поэтому гораздо лучше использовать файловую систему Unix для непосредственного хранения двоичных данных. Да и какая польза от помещения двоичной информации в базу данных, если поиск по этим данным невозможен?

Для реализации вышеописанного подхода в приложении документация SDK Android предлагает одну стратегию, которая заключается в том, что поставщик содержимого долговременно сохраняет данные в файле, а также сохраняет в базе данных уникальный идентификатор ресурса, content: // URI. Этот идентификатор указывает на файл, как это показано на рис. 12.2. Клиентские приложения передают URI, содержащийся в этом поле, ContentProvider. openStream для получения потока байтов от указанного в URI файла.

Рис. 12.2. Типичное использование курсоров и поставщиков содержимого в паттерне MVC, применяемом в Android

Говоря подробнее, чтобы осуществить такой файловый подход, в документации рекомендуется не создавать гипотетическую пользовательскую таблицу таким образом:

В столбце pi cture таблицы user будет сохраняться content: // URI, указывающий на строку в таблице userPi cture. Столбец _data из таблицы userPicture будет указывать на реальный файл из файловой системы Android.

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

При обработке запросов класс ContentResolver ищет столбец с названием _data. Если удается найти файл, указанный в этом столбце, то метод openOutputStream поставщика содержимого откроет файл и вернет клиенту объект Java. іо. OutputStream. Именно этот объект был бы возвращен клиенту, если бы он сам мог открыть файл. Класс ContentResolver входит в состав того же приложения, что и поставщик содержимого. Поэтому он может открыть файл, тогда как клиент – не может.

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

Источник: Android. Программирование на Java для нового поколения мобильных устройств

По теме:

  • Комментарии