EigenDaksh: MVP

Showing posts with label MVP. Show all posts

PART 7. ADVANCED ANDROID TUTORIAL - IMPLEMENTING MVP FOR RECYCLERVIEW

Read

In the previous lesson, you have seen that implementing MVP for a Fragment is pretty straightforward and simple, especially if you are using Dependency Injection. But how do we implement a passive RecylerView (or any other adapter views for that matter)?

Generally, we create a collection within the adapter to hold the data. But this approach breaks the MVP principle because our RecyclerView is rendering View as well as handling the responsibility of holding the data. Ideally, the data should be stored in the Presenter.

In our sample application, we resolve this problem by treating each item in the collection as a separate MVP view.

public class WeatherAdapter extends RecyclerView.Adapter{

    private static final int LIST_ITEM_TODAY = 0;
    private static final int LIST_ITEM_GENERAL = 1;

    public interface OnWeatherItemClickListener {
        void onItemClick(long id);
    }

    private final WeatherItemPresenter mPresenter;
    private final OnWeatherItemClickListener mListener;


    public WeatherAdapter(WeatherItemPresenter presenter, OnWeatherItemClickListener listener) {
        this.mPresenter = presenter;
        this.mListener = listener;
    }

    @Override
    public WeatherViewHolder onCreateViewHolder(ViewGroup parent, int viewType) {
        View view;
        switch (viewType) {
            case LIST_ITEM_TODAY:
                view = LayoutInflater.from(parent.getContext()).inflate(R.layout.list_item_forecast_today,
                        parent, false);
                return new WeatherViewHolder(view, mListener);
            case LIST_ITEM_GENERAL:
                view = LayoutInflater.from(parent.getContext()).inflate(R.layout.list_item_forecast,
                        parent, false);
                return new WeatherViewHolder(view, mListener);
        }
        return null;
    }

    @Override
    public void onBindViewHolder(WeatherViewHolder holder, int position) {
        mPresenter.onBindWeatherRowViewAtPosition(holder, position);

    }

    @Override
    public int getItemCount() {
        return mPresenter.getRowCount();
    }

    @Override
    public int getItemViewType(int position) {
        if(position == 0) {
            return LIST_ITEM_TODAY;
        } else {
            return LIST_ITEM_GENERAL;
        }
    }

    public void renewItems(List items) {
        mPresenter.renewItems(items);
        notifyDataSetChanged();
    }

Then we can make our ViewHolder implement an interface which is a typical View interface of the MVP.

    public static class WeatherViewHolder extends RecyclerView.ViewHolder implements WeatherItemRowView {

        TextView dateTextView;
        TextView maxTempTextView;
        TextView minTempTextView;
        TextView cityTextView;
        ImageView iconImageView;
        TextView descriptionTextView;
        OnWeatherItemClickListener mListener;

        public WeatherViewHolder(View itemView, OnWeatherItemClickListener listener) {
            super(itemView);
            this.mListener = listener;
            dateTextView = itemView.findViewById(R.id.list_item_date_textview);
            maxTempTextView = itemView.findViewById(R.id.list_item_high_textview);
            minTempTextView = itemView.findViewById(R.id.list_item_low_textview);
            cityTextView = itemView.findViewById(R.id.list_item_cityname);
            iconImageView = itemView.findViewById(R.id.list_item_icon);
            descriptionTextView = itemView.findViewById(R.id.list_item_forecast_textview);
        }

        @Override
        public void setClickListener(final long id) {
            itemView.setOnClickListener(new View.OnClickListener() {
                @Override
                public void onClick(View view) {
                    mListener.onItemClick(id);
                }
            });
        }

        @Override
        public void setDateString(String dateString) {
            dateTextView.setText(dateString);
        }

        @Override
        public void setCityName(String cityName) {
            cityTextView.setText(cityName);

        }

        @Override
        public void setMaxTemp(String maxTempString) {
            maxTempTextView.setText(maxTempString);

        }

        @Override
        public void setMinTemp(String minTempString) {
            minTempTextView.setText(minTempString);
        }

        @Override
        public void setIcon(int icon) {
            iconImageView.setImageResource(icon);

        }

        @Override
        public void setDescription(String description) {
            descriptionTextView.setText(description);
        }
    }

What is the advantage of this approach? If you look at the code in our sample application, you would clearly see that we have successfully moved the logic of providing data for each row to the presenter. Our Presenter knows nothing about the View layer's concrete implementation or about the Android framework! I would advise you to practice implementation of RecyclerView using this approach before moving forward. In the next lesson, we will discuss Room persistence library which is my favorite ORM. It plays very nicely with Rx as well!

PART 6. ADVANCED ANDROID TUTORIAL - Implementing MVP

By apurushottam

Read

0 Comments

Unfortunately, there is no “standard” way to implement MVP for Android apps 😐. There are many variations of MVP and developers adjust this pattern idea to their own style and needs. And since this is my blog, it's my way or highway 👹. My style of MVP implementation is more focused on testability rather than ease of implementation. It is based on two principles:

The View should be dumb: Reduce the functionality of the View to the absolute minimum. The View should only be responsible for rendering the screen and should have no data contained in it. This improves the testability dramatically.
The Presenter should be framework-independent: Presenter should not depend on Android classes. This part can be tricky sometimes. But do not worry, there are plenty of examples online and with practice, you would get better at it.

For looking at my way of implementing MVP, go to the addnotes section of the screens module in the sample application. Here the Fragment AddNoteFragment is our View. This View implements a simple interface which are the methods related to rendering something on the screen. This ensures that our View is dumb or passive.

Make your Presenter implement an interface which should contain the methods it needs to act as a communicator between the Model and the View. As you can see, this Presenter is handling the responsibility of adding a new note to the the database (our Model) and informing the Fragment (our View) about the state of the application. There is no direct communication between the Model and the View.

The only part remaining now is to provide the "Presenter" to our View. The best way to do that is by dependency injection. In the AddNoteFragment you can see an example of that. In our sample application there is a separate module for injecting the presenters wherever required.

@Module
public class PresenterModule {

    private final Context mContext;

    public PresenterModule(Context mContext) {
        this.mContext = mContext;
    }

    @Provides
    @Singleton
    public WeatherPresenter provideWeatherPresenter() {
        return new WeatherPresenterImpl(mContext);
    }

    @Provides
    @Singleton
    public WeatherDetailPresenter provideWeatherDetailPresenter() {
        return new WeatherDetailPresenterImpl(mContext);
    }

    @Provides
    @Singleton
    public NotesListPresenter provideNotesListPresenter() {
        return new NotesListPresenterImpl(mContext);
    }

    @Provides
    @Singleton
    public AddNotePresenter provideAddNotePresenter() {
        return new AddNotePresenterImpl(mContext);
    }

    @Provides
    @Singleton
    public NoteDetailPresenter provideNoteDetailPresenter() {
        return new NoteDetailPresenterImpl(mContext);
    }

}

In the next lesson of the series, we will discuss how to implment a RecyclerView without breaking the MVP principle.

PART 5. ADVANCED ANDROID DEVELOPMENT - MVP ARCHITECTURE

By apurushottam

Read

0 Comments

Maintaining a clean architectural pattern is imperative for project maintenance and ensuring that it is clean, testable, and expandable. In Android domain, the classic Model View Controller pattern is no longer the default choice for developers. More and more developers are shifting their loyalty to Model View Presenter pattern (including me 😝).

Watch the two videos about the MVC and MVP patterns before proceeding.

Why MVP is being preferred over MVC?

While using Android SDK and Google documentation, you will get the impression that the Android ecosystem is tailor-made for MVC. But as your project grows more in complexity and size, it quickly becomes clear that this pattern is not ideal for writing tests. It does not offer the same level of separation of concerns as MVP. Some of the benefits that MVP pattern offers us over MVC can be summarized as follows:

The user interface can be unit tested. Inside the unit test, we replace the view with a test driver that makes calls to the presenter.
The user interface is developed completely isolated from the application logic. They can be developed independently of each other.

It can't be all good. There must be some catch here 😈. Yes of course. There are certain drawbacks to the MVP approach too.

It requires more effort 😕.
For every screen or window, we require separate presenters and contracts, which may ultimately complicate our project.

In spite of these potential problems, I am a strong advocate of MVP, because if you adhere to it strictly, even for very complex projects, you can successfully avoid spaghetti code situation.

Differences Between MVP and MVC?

The important differences between the two patterns are:

In MVP, there is one to one mapping between View and Presenter (for example, one presenter for every fragment). For a complex View, we can even have more than one presenter! In MVC, the Controller can share multiple views.
In MVP, the View is totally stupid 😂. It only knows how to render a screen on the device. It does not know anything about the model (not even it's existence!). In MVC, the View can directly communicate with the model. Hence, the big problem! How to test them separately?

Now that I have again convinced (coerced 😈) you to believe that MVP is better, in the next article of this series I will discuss MVP in more detail. I have used MVP pattern in the sample application and I will use its code to demonstrate implementation of MVP pattern for Android projects.

EigenDaksh

PART 7. ADVANCED ANDROID TUTORIAL - IMPLEMENTING MVP FOR RECYCLERVIEW

PART 6. ADVANCED ANDROID TUTORIAL - Implementing MVP

PART 5. ADVANCED ANDROID DEVELOPMENT - MVP ARCHITECTURE

Why MVP is being preferred over MVC?

Differences Between MVP and MVC?

Follow Us

Recent Posts

Facebook

Search This Blog

Labels

Social Media Icons 2

Report Abuse

About Me

Facebook