Android MVP open Activity from Presenter, anti-pattern?

Question

Would it be an anti-pattern if from a Presenter layer I open an Activity?

If so, should I manage the navigation of the app from the View Layer?

Answer 1

Yes it's an anti-mvp-pattern. Based on passive view in MVP, you lost your testability, because you don't have to deal with the android framework in your presenter.

So it's better to manage the navigation of the app from the View Layer.

class MyPresenter {     MyPresenter.View view;      void backButtonClicked() {         view.navigateToHomeScreen();     }      public interface View {         void navigateToHomeScreen();     } }  class MyActivity extends Activity implements MyPresenter.View {     @Override     void navigateToHomeScreen() {         startActivity(...)     }      @OnClick(R.id.my_button)     void onClick() {         presenter.backButtonClicked();     } }  

Also another advantage of this way is that it will be easy to replace activity with a fragment or a view.

Edit 1:

Morgwai said this way will break separation of concern and single responsibility, but you cannot have single responsibility every where. Sometime you need to violate it. Here is an example from Google for MVP:

TaskDetailPresenter calls ShowEditTask which is responsible to open a new Activity inside TaskDetailFragment.

But also you can use CommandPattern which is a better approach

interface NavigationCommand {     void navigate(); } 

So, Presenter will use it when it needs.

Answer 2

As I wrote in my comment to the accepted answer, I think that managing navigation from the view layer is a clear breaking of separation of concerns rule: views should contain ONLY methods to update current UI screen.

The problem originates from the android platform design as Activity and Fragment classes contain both methods to operate on UI screen and to send intent objects that start other activities like startActivity.

A clean way to solve this would be to create some Navigator interface that would contain methods related to navigation, make activities implement it and inject it into presenters as well. This way at least from the presenters' standpoint navigation and UI manipulation would be separated. It may however look odd from activities' standpoint: now they would often implement both interfaces (Navigator and View) and pass their reference 2 times to the presenter. If because of this reason you decide to manage navigation from your view layer then at least keep methods for navigating separate from those for manipulating UI: never perform navigation and UI manipulation in the same method.