ішніх додатків, які планують контактувати з постачальником, або ж обмежити видимість постачальника власних додатком. В останньому випадку, фактично, необхідність у постачальнику вмісту відпадає, і програміст вільний сам вирішувати, як реалізовувати інтерфейс для взаємодії з БД. У даному проекті БД використовується для кешування даних сервера і немає необхідності робити доступними ці дані для зовнішніх компонент. Модуль роботи з БД надає набір відкритих методів для асинхронного оновлення вмісту БД, а також надає можливість для підписки класу-оглядача на події від БД. В даному випадку, такими подіями є факти отримання нових даних. В якості оглядачів використовуються проксі-об'єкти, що є частиною модулів завантаження даних. Процес підключення до БД для читання даних виглядає наступним чином:
. Модуль-ініціатор читання (в даному випадку, модуль редагування метаданих) запитує у менеджера завантажувачів створення нового об'єкта-завантажувача, вказуючи події, до яких буде підключений клас оглядач, а також клас-слухач, що викликається по готовності даних.
. Створюється новий автономний завантажувач, який, через проксі-об'єкт, підписується на події поновлення певних даних у БД. Якщо менеджер завантажувачів бачить, що необхідний завантажувач вже був створений, він віддає існуючий замість створення нового.
. По готовності завантажувача, а також при наступних подіях від БД викликається метод зворотного виклику в класі-инициаторе читання, в який передаються отримані дані.
Варто відзначити, що менеджер завантажувачів - це системний об'єкт класу Loader Manager, який служить для взаємодії з конкретними завантажувач (спадкоємцями класу Loader), а також забезпечує підтримку їх автономного життєвого циклу. У той же час, конкретні завантажувачі є користувацькими класами, що реалізовують необхідні методи для обробки даних, а також надають можливість підписки на довільні події ззовні.
Ще одним не видно користувачеві модулем є веб-клієнт. В даному випадку, це клас реалізує взаємодію з веб API на клієнтській стороні. Основними його функціями є установка з'єднання з сервером, виклик віддалених веб-методів, а також перетворення структур даних від використовуваних додатком абстракцій до встановленим форматом веб API. Основною причиною винесення веб-клієнта в окремий модуль є універсальність модуля обробки фонових операцій. Беручи до уваги необхідну функціональність розроблюваного докладання, не має сенсу виділення кількох сервісів для різних типів (робота з мережею, робота з БД) фонових операцій. Подібне розділення викликало б лише зайву складність при синхронізації роботи компонент і пересилці даних. Таким чином, виділення окремих компонент - веб-клієнта і модуля роботи з БД - підкреслює їх спеціалізацію, а також вказує на роль модуля фонової обробки даних, як контексту виконання фонових операцій.
Модуль фонової обробки операцій побудований на базі Android-сервісу і призначений, як випливає з назви, для здійснення витратних за часом операцій поза основного потоку виконання. Крім основного свого призначення, модуль визначає слабозв'язаного інтерфейс для обміну з іншими великими модулями програми через ІНТЕНТ. Типовий хід роботи програми не визначає паралельних операцій, тому сервіс використовується як черга для обробки ресурсоємних операцій в окремому потоці. Для цього використовується входить до складу Android SDK клас Handler. За допомогою спадкування від цього класу, можна отримати готову чергу подій з користувальницькою обробником повідомлень - об'єктів класу Message, здатних передавати в обробник всі необхідні дані. Примірник підкласу Handler може бути асоційований з будь-яким потоком, що дозволяє організовувати межпотоковую комунікацію для забезпечення зворотного зв'язку з основним потоком виконання. Незважаючи на це, в даному проекті використовується інший спосіб комунікації, заснований на ІНТЕНТ. Подібний підхід дозволяє більш просто організувати доступ до сервісу з декількох модулів програми. На щастя, ОС Android надає часткову реалізацію подібного шаблону обробки повідомлень - клас Intent Service. Об'єкт даного класу являє собою Android-сервіс, який при старті запускає окремий фоновий потік виконання і асоціює з ним об'єкт Handler, залишаючи користувача право самому визначити, як будуть оброблятися отримані ІНТЕНТ. Якщо один або кілька ІНТЕНТ приходять під час обробки попередніх, то вони автоматично додаються в кінець поточної черги обробки операцій. IntentService самостійно поміщає ІНТЕНТ в об'єкти-повідомлення для постановки в чергу обслуговування і витягує їх безпосередньо передаючи в метод-обробник. Особливістю даної реалізації є те, що Inten Service підтримує лише одну чергу обробки повідомлень, а також автоматично завершується після виконання всіх операцій з черги для економії ресурсів телефону. Дані особливості змушують відмовлятися в...
