Вот один из способов решения такой проблемы.
Ваша проблема в том, что какой-то код имеет смысл помещать в презентер, однако он слишком Android
y, поэтому вы можете просто interface
его обойти.
В основном вам нужны две вещи, которые могут выполнять определенные функции.
interface CapturingSoundPlayer {
void playSound();
}
interface ImageCapturer {
void captureImage();
}
Обратите внимание, что имена и сигнатуры методов зависят от вас и от того, что вам нужно, я просто использую их, чтобы подчеркнуть.
Теперь для вашего приложения совершенно безопасно иметь эти два интерфейса в качестве зависимостей, они не имеют ничего общего с Android, мы просто исключили технологию из уравнения и оставили только поведение.
Вам нужно передать эти зависимости своему докладчику и использовать их при необходимости.
class Presenter {
private final CapturingSoundPlayer soundPlayer;
private final ImageCapturer capturer;
Presenter(CapturingSoundPlayer soundPlayer, ImageCapturer capturer) {
this.soundPlayer = soundPlayer;
this.capturer = capturer;
}
void onCaptureButtonClicked() {
soundPlayer.playSound();
capturer.captureImage();
}
}
Теперь реализация для этих интерфейсов может быть полностью отделена от вашей деятельности, что делает ваше представление все еще глупым.
Эти интерфейсы (и их реализация) являются просто логическими единицами/сущностями, которые ваш докладчик использует для разделения логики. Я просто думаю о функциях «захват» и «воспроизведение звука» как о простых действиях, как view.showLoading
, и ваш докладчик играет оркестратор, он использует «что-то» для управления представлением, которое является интерфейсом представления, и использует что-то еще управлять звуком, который является интерфейсом для этого.
если репозитории считаются источниками данных, то, на мой взгляд, эти помощники не подходят под это определение.
Если у вас есть утилита для извлечения захваченных изображений, это в основном можно рассматривать как репозиторий для ваших изображений, но простое получение изображения — это просто еще одно действие.
Вы можете структурировать/организовать их по своему усмотрению, но только потому, что вы используете MVP, не каждый создаваемый вами класс должен быть одной из этих букв (M/V/P).
Иногда любому из этих уровней потребуются классы, логические единицы, чтобы что-то делать, чтобы у вас было лучшее разделение задач.
Учтите, что у вас довольно сложная логика форматирования, было бы разумно выделить ее в отдельный класс, отличный от ведущего, но означает ли это, что отдельный класс теперь является моделью? Можно, но не обязательно.
person
elmorabea
schedule
11.12.2017