37-я встреча сообщества IT talk в Петербурге. Тема: «Android: думайте через данные» Докладчик: Андрей Хитрый, старший Android-разработчик студии Trinity Digital. http://it-talk.dataart.ru/events/events-spb/2016/03/priglashaem-druzej-na-37-j-it-talk-v-peterburge/

1. Android - думайте через
данные
Андрей Хитрый, Trinity Digital
1/19

2. Введение
- Множество способов построения приложения
- Различные библиотеки для работы с сетью/данными/потоками
- Нет единственно верного способа передачи данных в приложении
- Удобно ли тестировать операции над данными через UI
- Я хранил данные в json файлах и не стыжусь этого
2/19

3. Проектирование != Архитектура
- Очень много времени уделяется архитектуре, очень мало
проектированию
- Добавление стека Rx, не дает априори хорошей архитектуры
- Модель является основой приложения, но зачастую программисты
относятся к ней, как к вспомогательной структуре
- Данные должны быть структурированы(с этого и начнем)
3/19

4. Антипаттерн: TheApplication extends Application
4/19

5. Антипаттерн: BaseActivity/BaseFragment
- Удобно обращаться к данным (+)
- Обращения к данным находятся в одном месте(+/-)
- Дублирование методов получения, в случае обращения не из UI(-)
- Во многих случаях дописывается логика косвенно относящаяся к модели
5/19

6. Антипаттерн: BaseActivity/BaseFragment
6/19

7. Серверное API, кому оно нужно?
- Должно проектироваться ДЛЯ приложения
- Проектируется ДЛЯ пользовательского интерфейса
- Любой набор данных это объект и должен иметь идентификатор
- Мобильный разработчик проектирует приложение, учитывая серверные
данные, локальные данные и пользовательский интерфейс
7/19

8. Серверные данные VS Локальные данные
- Удобство разделения серверных данных от локальных может быть
иллюзорно
- Постарайтесь объединять сходные по сущности данные
- Локальными данными являются также и UX данные
- Нужно определить данные, которые мы синхронизируем через наш
сервер и те, которые мы синхронизируем при помощи Android (новые
версии API Android)
8/19

9. Различные хранилища данных
- Очевидно, что минимизация хранилищ, это хорошо
- Preferences -> Настройки, сами по себе являются структурой
- Восстанавливаемые данные можно хранить в кеше
- Не восстанавливаемые данные должны всегда находиться в хранилище
9/19

10. Поток данных или Bundle Hell
10/19

11. Поток данных или Bundle Hell
- Передача данных между Activity/Fragment должна быть минимизирована
- Данные не должны храниться в потоке Fragment1->Fragment2-
>Fragment3->CompleteFragment
- Все объекты должны иметь идентификатор!
- Передача только идентификатора уменьшает связность
11/19

12. Толстая модель: почему?
- Часть валидации данных переносится на модель
- Все операции над данными проводятся через модель, никаких прямых
запросов к базе
- За счет переноса запросов и валидации часть тестирования
выполняется только через модель или через модель и mock объект для
доступа к апи сервера
12/19

13. Толстая модель: запросы к серверу
- Формируем сложный запрос, как объект базы
- Получаем запрос по его идентификатору
- Ответ записываем в базу, оповещаем UI о результате
- Отложенные запросы, запросы требующие подтверждения, длительные
операции требующие запроса статуса имеют соответствующие поля в
базе
13/19

14. Толстая модель: простой пример
14/19

15. Толстая модель: логика в UI без объектов базы
15/19

16. Толстая модель: логика в UI без объектов базы
16/19

17. Запрос к серверу через модель
17/19

18. Преимущества
- Можно использовать с DI, Rx или использовать Observable
- Все операции над моделью со стороны сервера и клиента находятся
изолированно в классе модели
- При правильном проектировании в модель не будет добавлено много
методов
- Легко внедрить ограничения данных(через валидаторы, выброс
исключений, возврат строки с ошибкой, в зависимости от детализации)
- В UI отсутствуют преобразования данных
- Сама по себе модель заставляет на этапе проектирования больше
времени уделять полировке API 18/19

19. Андрей Хитрый
Trinity Digital
ak@trinitydigital.ru
19/19