Относится к Model в терминах MVP.
Подробное описание архитектуры приложений - здесь.
Рассмотрим наиболее распространенные сущности, принадлежащие к этому слою.
Говоря о репозиториях, следует вспомнить паттерн, который собственно так и называется “Репозиторий”. Суть его в том, чтобы создать некий слой абстракции над какими-либо конкретными источниками данных, будь то например ваша база данных или веб-сервис. Задача репозитория стать промежуточным звеном между тем кто запрашивает данные и тем кто их отдает. Важно понимать, что все что находится выше репозитория не должно знать о том, как он устроен и откуда он берет эти данные. Это может быть сетевой запрос, запрос в базу данных или же все вместе, так называемый гибридный запрос, который подразумевает проведение конкатенации запросов на сервер и кеш по некому установленному вами правилу.
Выделение такого интерактора (репозитория) делает вашу архитектуру более гибкой, и она с легкостью может быть адаптирована по мере развития общей конструкции приложения.
Пакет, соответствующий репозиторию должен, кроме самого репозитория, содержать:
-
Интерфейс Api для Retrofit
-
Модели для парсинга ответов сервера
-
Модели для формирования запроса к серверу
-
Класс кеша для этого репозитория, и сопутствующие ему другие классы
-
Остальные детали, которые скрываются под абстракцией репозитория
Определение геолокации не всегда простая задача, особенно если в вашем приложение точное определение местоположения играет ключевую роль. Геолокацию можно определить несколькими способами - это может быть стандартный LocationManager в Android, это может быть PlayServices, это может быть запрос в сеть и др. В свою очередь каждый из этих способов может работать с высокой точностью или с низкой, через GPS или WI-FI, с использованием последней успешной локации или без и тд. Все эти точные настройки и алгоритмы должны быть прикрыты большим уровнем абстракции. Подразумевается, что данный интерактор имеет, к примеру, один публичный метод getLocation(), который возвращает текущую локацию пользователя. Но как и откуда эта локация была получена знает только сам интерактор.
Для использования локации уже существует готовый модуль.
Инициализация приложения чаще всего происходит на экране сплеша. Под инициализацией понимается выполнение определенного набора правил, от которых зависит дальнейшее поведение приложения. Например, миграции приложения на новую версию или же получение и обновление токена, получение локации и тд.
Принято выделять данную логику в отдельный интерактор.
Интерфейс данного интерактора будет описан всего лишь одним методом - initialize().
Данный интерактор инкапсулирует действия, которые необходимо выполнить при смене сессии или пользователя. Среди таких действий могут быть - очистка кэша, запрос на logout, кэширование токена и тд.
Реализация этого интерактора включает в себя работу с репозиторями, которые, как мы помним, также принадлежат к этому слою. Например, UserRepository и TokenStorage.