MVP Android - Сколько докладчиков?

Question

У меня есть быстрый вопрос. Я пытаюсь (и боюсь) разрабатывать свое приложение с шаблоном проектирования MVP.

Могу ли я спросить, для каждого вида (активности, фрагмента) должен ли я иметь отдельный класс презентатора?

Существует не так много ресурсов, которые я могу видеть в Интернете, что ясно показывает образцы MVP. Может ли кто-нибудь поделиться, если у них есть?

PS Я также использую RecyclerViewAdapter в этом приложении, чтобы любые указатели на которые будут оценены

Заранее спасибо

Answer 1

Конструкция Model-View-Controller возникла очень рано softwaredesign и первоначально использовался для таких вещи как элемент кнопки. Вы используете MVP (в основном то же, что и MVC), чтобы получить архитектуру, которая является модульной и, следовательно, ее легко поддерживать, разделяя представление из логики.

Учитывая ваш вопрос, я думаю, что вам действительно нужен один класс за просмотр. Это будет наиболее распространенный подход.

http://antonioleiva.com/mvp-android/ дает теоретический обзор MVP.

Answer 2

Хотя старый, это очень интересный вопрос. Поскольку MVP/MVC/MVVM в наши дни является своего рода «гудными словами» в сообществе Android, этот вопрос заслуживает более полного ответа (IMHO).

Короткий ответ:

Single ведущий может использоваться с несколькими видами

Длинный ответ:

В общем, не существует единого определения MVP/MVC - есть многие подходы к реализации этих архитектурных моделей. Вы не указали определение «своего» MVP, поэтому я могу только догадываться, что вы имеете в виду.

При этом в «объектно-ориентированном программировании» есть некоторые «лучшие практики», которые должны (в идеале) учитывать любую реализацию любого архитектурного шаблона.

Что вы спросите, можете ли вы повторно использовать реализацию одного презентатора с разными видами, не так ли? Давайте рассмотрим этот вопрос через призму принципов SOLID.

"L" означает Лисковский принцип замены (LSP). Это один из самых непонятных принципов SOLID, но общая идея этого принципа говорит следующее:

LSP: если кусок кода работает с объектом класса А, он должен также работать совместно с объектами любой подкласс а (то есть подклассы должны быть полезными вместо того, чтобы везде)

Примером нарушения LSP в Android является Context: sublasses из Context (например Application и Activity) не эквивалентно.Некоторый код, который требует Context, может работать без сбоев с Application, но если вы перейдете Activity, произойдет утечка памяти (это очень распространенная ошибка в приложениях Android, вызванная прежде всего нарушением LSP разработчиками Google).

Назад на главную вопрос. Я предполагаю, что ваш ведущий выглядит следующим образом (обратите внимание на интерфейс для просмотров):

public class SomePresenter { 

    /** 
    * Views bound to this presenter must implement this interface 
    */ 
    interface SomeView { 
     void doSomething1(); 
     void doSomething2(); 
    } 

    public void bindView(SomeView someView) { 
     // view binding logic 
    } 

    // more presenter's methods 

} 

LSP утверждает, что любой класс, который реализует SomeView может использоваться с SomePresenter. Ведущий не должен заботиться о том, соответствует ли реализация SomeViewActivity, Fragment или, может быть, просто макет для модульного теста.

Итак, полный ответ на ваш вопрос: один ведущий может быть повторно использован с разными представлениями, если ведущий не зависит от конкретных реализаций представлений, а только от их суперкласса.

Дополнительная информация:

Я бы предположил, что вы спросили ваш вопрос, потому что, с одной стороны, вы чувствовали, что один ведущий должен иметь возможность работать с различными видами (просто подумайте о тестировании A/B от разных пользовательских интерфейсов), но, с другой стороны, тот факт, что представления - это Activity и Fragment, заставил вас почувствовать себя некомфортно с этой мыслью.

Мое личное мнение таково, что в MVC/MVP ни Activity, ни Fragment не должны быть видами. Обоснование этой претензии приводится в этом сообщении: Why Activities in Android are not UI Elements.

Я также предлагаю вам взглянуть на другой подход к implementation of MVP in Android - если вы будете использовать этот, было бы очевидно для вас, что ведущий должен иметь возможность работать с различными видами, и у вас не было бы такого чувства: «что-то не так».

Answer 3

Ваша деятельность/Фрагмент должен иметь 1 докладчика. Я хотел бы сделать все мои действия, чтобы простираться от BaseActivity, а затем, я делаю это BaseActivity требует Presenter см этот пример:

public abstract class BaseActivity<Presenter extends BasePresenter> extends AppCompatActivity { 

    protected Presenter mPresenter; 

    @NonNull 
    protected abstract Presenter createPresenter(@NonNull final Context context); 

    @Override 
    protected void onCreate(final Bundle savedInstanceState) { 
     super.onCreate(savedInstanceState); 
     mPresenter = createPresenter(this); 
     mPresenter.onCreate(savedInstanceState); 
     } 
    } 
    // other lifecycle methods 

И затем, создать абстрактный BasePresenter

public abstract class BasePresenter { 

protected BasePresenter() { 
} 

@NonNull 
public static BasePresenter nullPresenter(@NonNull final Context context) { 
    return new BasePresenter() {}; 
} 

@CallSuper 
public void onCreate(@Nullable final Bundle savedInstanceState) { 
} 

сейчас , при создании активности, выполните следующие действия:

public class MyActivity extends BaseActivity<MyActivityPresenter>{ 


@Override 
MyActivityPresenter createPresenter(@NoNull final Context context){ 
    return new MyActivityPresenter(all, Your, Dependencies, Here); 
    } 
} 

Теперь смотрите this video и понять на удовлетворения претензий активность/View Wi тонкий MVP.