УПРАВЛІННЯ ФАЙЛАМИ І двійкові дані в Android додатку

&nbsp

Постачальникам вмісту часто доводиться управляти великими фрагментами двійкових даних, наприклад бітовими картами або музичним кліпом Необхідність зберігання великих файлів з даними не може не відбитися на проектуванні програми і, швидше за все, серйозно вплине на продуктивність програми Постачальник вмісту може передавати файли через URI При цьому в ідентифікаторі ресурсу полягає інформація про фізичне розташування потрібних файлів, а сам клієнт може цього і не впізнати Отже, клієнти використовують унікальні ідентифікатори ресурсів, що містяться в постачальниках вмісту, щоб отримувати доступ до самих файлів, але не до інформації про те, де саме ці файли знаходяться Такий рівень опосередковане дозволяє постачальнику вмісту управляти цими файлами найбільш доцільним способом, не допускаючи витоку інформації до клієнта Якби така витік відбувався, вона могла б навіть призводити до змін коду в клієнті, якби постачальника вмісту треба було змінити спосіб зберігання фізичних файлів В принципі, набагато простіше змінювати тільки сам постачальник, а не всі його потенційні клієнти Клієнтам абсолютно не потрібно знати, що безліч медіафайлів, якими володіє постачальник вмісту, можуть перебувати у флеш-памяті, на карті памяті або взагалі в мережі, оскільки постачальник вмісту надає файли за допомогою набору унікальних ідентифікаторів ресурсів, а клієнт вже здатний обробити ці ідентифікатори При поводженні з кожним конкретним URI клієнт просто буде використовувати метод ContentResolver openlnputStream, а потім зчитувати дані з результуючого потоку

Крім того, при спільному використанні великих обсягів даних декількома додатками (оскільки додаток Android не повинно зчитувати або перезаписувати файли, створені іншим додатком) постачальник вмісту може використовуватися для доступу до відповідних (спільне) байтам Отже, коли постачальник вмісту повертає покажчик до файлу, цей покажчик повинен мати вигляд content: / / URI, а не імя файлу у форматі Unix При використанні content :/ / URI файл можна відкривати і зчитувати, тільки розташовуючи правом доступу, отриманим від постачальника вмісту, який володіє файлом, а не від клієнтського додатку (клієнтське додаток не повинно мати доступу до прав на файл)

Крім того, необхідно враховувати, що система введення-виведення, що відноситься до файлової системи, набагато швидше і багатофункціональні, ніж система обробки обєктів двійковій компонування (BLOB) бази даних SQLite Тому набагато краще використовувати файлову систему Unix для безпосереднього зберігання двійкових даних Та й яка користь від приміщення двійковій інформації в базу даних, якщо пошук за цими даними неможливий

Для реалізації вищеописаного підходу в додатку документація SDK Android пропонує одну стратегію, яка полягає в тому, що постачальник вмісту долговременно зберігає дані у файлі, а також зберігає в базі даних унікальний ідентифікатор ресурсу, content: / / URI Цей ідентифікатор вказує на файл, як це показано на рис 122 Клієнтські програми передають URI, що міститься в цьому полі, ContentProvider openStream для отримання потоку байтів від зазначеного в URI файлу

Рис 122 Типове використання курсорів і постачальників вмісту в паттерне MVC, вживаному в Android

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

У стовпці pi cture таблиці user зберігатиметься content: / / URI, який вказує на рядок у таблиці userPi cture Стовпець _data з таблиці userPicture буде вказувати на реальний файл з файлової системи Android

Якби шлях до файлу зберігався безпосередньо в таблиці user, то клієнти отримували б шлях, але не могли відкрити розташований по ньому файл, так як файлом володіє додаток, що передає файли постачальнику вмісту, а клієнти не мають права доступу до цих файлів Але в рішенні, запропонованому тут, доступ контролюється класом ContentResolver, який буде розглянуто нижче

При обробці запитів клас ContentResolver шукає стовпець з назвою _data Якщо вдається знайти файл, вказаний в цьому стовпці, то метод openOutputStream постачальника вмісту відкриє файл і поверне клієнтові обєкт Java іо OutputStream Саме цей обєкт був би повернутий клієнту, якби він сам міг відкрити файл Клас ContentResolver входить до складу того ж додатка, що і постачальник вмісту Тому він може відкрити файл, тоді як клієнт – не може

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

Джерело: Android Програмування на Java для нового покоління мобільних пристроїв

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*