ід використання Intent Service у випадках, коли потрібно паралельна обробка операцій або ж забезпечення долгоживущего сервісу, проте для цілей поточного проекту Intent Service підходить ідеально.
Модуль фонової обробки операцій повідомляється з декількома компонентами додатку, не всі з яких вимагають зворотного зв'язку для звіту про виконання операцій. Таким чином, можна виділити дві роздільні ланцюжки даних, перша з яких використовується для оновлення стану кеша, а друга - для читання даних з БД.
Перша ланцюжок представлена ??наступним набором послідовних операцій:
. Користувальницький введення.
. Реакція на введення в активують.
. Відправка команди сервісу фонової обробки.
. Виклик віддаленого веб API.
. Отримання даних у форматі JSON.
. Перетворення даних до виду, використовуваному на клієнті.
. Передача даних для оновлення в БД.
З іншого боку, друга ланцюжок описується таким чином:
. Старт активують.
. Створення завантажувача і підписка його на оновлення БД.
. Очікування поновлення і передача даних в активують по готовності.
. Перехід до пункту 3 для відстеження актуальності даних.
Варто відзначити, що ланцюжки незалежні один від одного і ініціюються різними модулями. Крім того, одночасно запускається відразу кілька ланцюжків другого типу, при цьому вони можуть почати своє виконання не чекаючи закінчення першої ланцюжка. Дана схема є працездатною за рахунок того, що операції оновлення БД ініціюються модулем фонової обробки операцій, а операції читання даних з БД виконуються модулями завантаження даних після того, як модуль роботи з БД видасть подія про успішне оновлення даних.
3. Функціональне проектування
У даному розділі детально розглядається функціонування програмних модулів. Перераховано всі присутні класи і більшість їх компонентів. Склад і відносини класів також показані на діаграмі класів (креслення ГУІР.400201.128 РР.2).
. 1 Опис взаємодії з сервером
Однією з головних функцій мобільного клієнта є обмін даними з сервером. Для цих цілей був розроблений інтерфейс, що описує набір веб-методів для комунікації між компонентами. Іншими словами, прикладний програмний інтерфейс (application programming interface, далі API). API базується на трьох основних принципах:
. Формат переданих даних - JSON.
. Інформація про користувача передається з кожним запитом за допомогою базової аутентифікації HTTP (Basic Authentication).
. Для відправки даних використовуються HTTP POST запити.
На даний момент сервер надає п'ять веб-методів доступних клієнтові, опис яких представлено нижче. Методи перераховані в порядку їх виклику додатком. Як тільки користувач натискає кнопку «Увійти» на екрані авторизації, викликається метод login для перевірки прав доступу. Якщо доступ отримано, додаток по черзі викликає методи stores і categories для поновлення локального кешу, в той час як користувач може робити знімок. Після того як користувач зробить фото, він потрапляє на сторінку метаданих, заповнивши які, відправляє фото на сервер, іншими словами виробляється виклик методів upload_photo і save_photo.
. Авторизація користувача (../api/login)
Вхідні дані:
{
}
Відповідь сервера:
{
role raquo ;: user
}
Опис:
Даний метод використовується для первісної авторизації користувача та отримання його ролі, яка може бути використаний надалі. На поточний момент існує три ролі: «user», «merchandizer» і «admin». Будь-яка з даних ролей дозволяє користуватися додатком, хоча надалі це поведінка може бути змінено, зокрема, деякі функції можуть стати недоступними для деяких ролей.
. Отримання списку магазинів (../api/stores)
Вхідні дані:
{
version raquo ;: 10
}
Відповідь сервера:
[
{
id raquo ;: 102,
version raquo ;: 11,
active raquo ;: true,
name raquo ;: Coolman ,
street raquo ;: Кульман ,
...
