2016-11-25 3 views
4

Я нахожусь там, где мне нужно воспроизвести звуковой файл, когда пользователь нажимает кнопку на виде.Android MVP: какой слой должен хранить переменную контекста

Для MediaPlayer требуется создать контекст.

Каков наилучший способ для ввода кода инициализации MediaPlayer?

Должен ли я передать контекст методу презентатора и воспроизвести его там?

Или это нормально, просто играть на виду.

+0

Деятельность - это контекст –

+0

, вы должны написать, что внутри деятельности. В противном случае презентатор не имеет никакого смысла –

ответ

4

Context является частью Android View слоя в MVP, так Presenter не должен иметь ни малейшего представления об этом, и вы не должны передать его presenter.

Вы должны добавить методы к интерфейсу View и реализовать его в вашем андроиде компонентов зрения (т.е. Activity или Fragment) и использовать их, чтобы сделать какое-либо действие View слоя, как воспроизведение звука.

Presenter должен запросить UI-событие, а View должен его обработать!

Вот MVP образец с использованием Dagger, RxJava и Дооснащение, которые могут помочь вам узнать больше о MVP в Android:

https://github.com/mmirhoseini/marvel

+1

Мне нравится этот ответ, потому что он короткий и отвечает на мой вопрос. В основном я буду держать логику MediaPlayer/MediaRecorder внутри. – user1017674

1

Если вам нужен общий контекст, вы можете расширить приложение, объявить статическую контекстную переменную и после того, как вы сможете получить этот Контекст в своем презентаторе.

+0

Стандартное предупреждение: не размещайте классы контекста Android в статических полях; это утечка памяти (а также прерывает Instant Run) – Darko

5

I часто вводят код бизнес-логики в Модельный слой (не путайте с mo del в базе данных). Я часто переименовываю как XManager, чтобы избежать путаницы (например, ProductManager, MediaManager ...), поэтому класс-презентатор просто использует для поддержания рабочего процесса.

Правило большого пальца не ограничено или, по крайней мере, ограничено пакет андроидного импорта в классе презентатора. Эта лучшая практика помогает вам легче тестировать класс презентатора, потому что ведущий теперь просто простой Java-класс, поэтому нам не нужна инфраструктура Android для тестирования этих вещей.

Например, это мой рабочий процесс mvp.

Просмотреть класс: Это место, где вы храните все свое видение, такое как кнопка, textview ... и вы устанавливаете для всех этих компонентов на этом уровне все слушатели. Также в этом представлении вы определяете класс Listener для презентационных инструментов позже. Компоненты вашего представления вызовут методы в этом классе слушателя.

class ViewImpl implements View { 
    Button playButton; 
    ViewListener listener; 

    public ViewImpl(ViewListener listener) { 
    // find all view 

    this.listener = listener; 

    playButton.setOnClickListener(new View.OnClickListener() { 
     listener.playSong(); 
    }); 
    } 

    public interface ViewListener { 
    playSong(); 
    } 
} 

Presenter класс: Это где вы храните вид и модель внутри для вызова позже. Также класс презентатора будет реализовывать интерфейс ViewListener, определенный выше. Основной точкой ведущего является рабочий процесс логики управления.

class PresenterImpl extends Presenter implements ViewListener { 
    private View view; 
    private MediaManager mediaManager; 

    public PresenterImpl(View, MediaManager manager) { 
     this.view = view; 
     this.manager = manager; 
    } 

    @Override 
    public void playSong() { 
     mediaManager.playMedia(); 
    } 
} 

класс менеджер: Вот основной код бизнес-логики. Возможно, у одного ведущего будет много менеджеров (зависит от того, как усложнять представление). Часто мы получаем класс Context через некоторые рамки для инъекций, такие как Dagger.

Class MediaManagerImpl extends MediaManager { 
    // using Dagger for injection context if you want 
    @Inject 
    private Context context; 
    private MediaPlayer mediaPlayer; 

    // dagger solution 
    public MediaPlayerManagerImpl() { 
    this.mediaPlayer = new MediaPlayer(context); 
    } 

    // no dagger solution 
    public MediaPlayerManagerImpl(Context context) { 
    this.context = context; 
    this.mediaPlayer = new MediaPlayer(context); 
    } 

    public void playMedia() { 
    mediaPlayer.play(); 
    } 

    public void stopMedia() { 
     mediaPlayer.stop(); 
    } 
} 

Наконец: Положите эти вещи вместе в деятельности, Fragments ... Вот место инициализации вида, менеджер и назначить всех ведущий.

public class MyActivity extends Activity { 

    Presenter presenter; 

    @Override 
    public void onCreate() { 
     super.onCreate(); 

     IView view = new ViewImpl(); 
     MediaManager manager = new MediaManagerImpl(this.getApplicationContext()); 
     // or this. if you use Dagger 
     MediaManager manager = new MediaManagerImpl(); 
     presenter = new PresenterImpl(view, manager); 
    } 

    @Override 
    public void onStop() { 
    super.onStop(); 
    presenter.onStop(); 
    } 
} 

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

Это такой длинный пост для ответа на ваш вопрос. Я думаю, что это подходит, потому что у каждого есть своя собственная реализация MVP (поток ядра тот же, но меньшинства разные). Поэтому я представляю здесь рабочий процесс, который я часто использую в работе. Надеюсь, вы увидите, что это полезно :)

Смежные вопросы