2016-10-03 6 views
2

У меня есть ведущий P. Он предназначен для управления всем для определенного вида вида V. У меня несколько просмотров вот так: V1, V2, ... Vn. Взаимодействие с одним видом Vx, может иметь эффекты на другие другие виды Vy.Android MVP, как координировать несколько просмотров?

Каков наилучший способ для этого? Должны ли докладчики разговаривать друг с другом? Должен ли ведущий ссылаться на все мнения?

ответ

4

One View не должен знать ничего о других. Вид должен взаимодействовать только с его презентатором. Один докладчик также не должен знать о других докладчиках. Чтобы избежать событий объединения, используйте события (EventBus, Otto, RxJava Subjects ...).

+0

Может ли основной обзор поговорить с главным докладчиком, который рассказывает об основном представлении и суб/вложенных представлениях. А суб/вложенные взгляды говорят со своими ведущими? – Deal

+1

HI Deal, Что вы подразумеваете под вложенным представлением? Иерархически в XML? Логически? Приведите пример. Если у вас несколько видов на экране, и какое-то представление логически вложено, лучше использовать плоскую структуру view-presenter без какой-либо вложенности. Давайте посмотрим на пример экрана приложения Gmail в [этой статье] (http://hannesdorfmann.com/mosby/mvp/). Не могли бы вы указать на вложенный вид в этом примере? – Torbik

+0

Кроме того: Конкретный вид должен взаимодействовать только с его презентатором. И лучше, если конкретный Presenter не взаимодействует с каким-либо представлением, кроме своего собственного. Если Presenter хочет изменить smth в другом представлении, он должен вытолкнуть Presenter этого представления (например, используя шину событий) или повлиять на другое представление через Модель. – Torbik

1

Одним из подходов являются ведущим P холдинга вида V и вида V унаследует V1, V2 ... Vn. Методы будут доступны для V во всех контейнерах View (Фрагменты и действия).

public interface MainView extends BaseView, ErrorView{ //V 
    void showProducts(@Nullable List<Product> products); 
} 


public interface BaseView{ //V1 
    void setLoading(boolean loading); 
    void showConfirmationDialog(@StringRes int title, @StringRes int message); 
} 

public interface ErrorView{ //V2 
    void showErrorSnackBar(@StringRes int message); 
} 


public class ProductListFragment extends ... implements MainView{ 


} 

По моему опыту, это работает отлично, кроме беспорядка и пустых методов, что не хорошо с точки зрения читаемости.

Держать ссылки других Ведущих внутри вашего основного докладчика прекрасно, пока вы гарантируете, что они живы. Это может привести к анти-шаблону.

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

@Override 
public void showProducts(List<Product> products){ 
    // do something with products that Presenter1 has dispatched for presenting 
    presenter2.doSomethingOnProducts(); 
} 

Это бесшовные связи между заинтересованными сторонами в результате.

Смешивание Observer Узор с MVP тоже прекрасен.

+0

Вы можете уточнить "view' V' inherit 'V1',' V2', ... 'Vn'. Методы будут доступны для V во всех контейнерах View." Я не уверен, что я следую тому, что здесь означает «наследовать». Видовые представления V одинаковы, просто многие из них содержатся в увеличенном виде (просмотр списка изображений) – Deal

+0

@Deal См. Мое редактирование с минималистичным фрагментом примера. –