Using we are always busy with to transfer different messages from layer to layer and them to the user, But when it comes to error handling, are all these methods required and likely to get fired or even predictable? MVP interfaces presenter view presenting What is the problem exactly? showErrorOnOffline() showErrorOnServiceNotResponding() showErrorOnUnableToParseResult() showErrorOnNoResponse() and we know that there could be more… We want to show errors to the user, so we add some for every error to their ’s and call them by , but how many errors are going to be handled? The dilemma also shows up when we are about to some general methods inside a interface which all views extend that one. methods View interface Presenter generalize BaseView Recently I have come up with a new idea which is worth to share with the community and get some feedback on… Talk is cheap; show me the code I use to generalize my interfaces and extend them from some Base interfaces which contain whatever everyone needs: public interface { BaseView void showMessage(String message);  

void showOfflineMessage(boolean isCritical);  

void **showErrorMessage**(Throwable throwable);  

void showProgress();  

void hideProgress(); } and in my child I extend it like: View interface public interface extends { TopUpView BaseView void showBankGateway(String url);

void **showBankGatewayError**();

void setVoucherResult(int amount, String voucher);

void **showVoucherError**(); } But wait a minute ! Isn’t it more convenient to handle errors with one single method, shared between all ? sub-interfaces In this example, I removed all error methods in TopUpView and try to use the one in BaseView (i.e. ) showErrorMessage First of all, I have to mention that usually, these errors happen in implementation of which usually comes from an API call using : onError RxJava retrofit if (isConnected) {subscription = interactor.applyVoucher(voucher, amount).subscribe(calculateResponse ->{if (null != view)view.hideProgress(); /\* ... \*/  
        },  
        throwable -> {  
            if (null != view) {  
                view.hideProgress();  

                if (isConnected)  
                    **view.showVoucherError();**  
                else  
                    view.showOfflineMessage(false);  
            }  
        }; } else {if (null != view)view.showOfflineMessage(false);} As I mentioned, there is a general method which has been never called, leaving out the SOLID principle: showErrorMessage() : “many client-specific interfaces are better than one general-purpose interface.” Interface segregation principle , and here comes a better solution… I’m a fan of Java and since errors in Java are propagated using Exceptions, why not use them in the MVP layers communications? Let’s create some custom exception classes for errors that might happen: public class extends { VoucherException Exception public **VoucherException**(Throwable throwable) {  
    super(throwable);  
} } Bear in mind that you can encapsulate more fields, if that’s the case and then pass them to the view: throwable -> {if (null != view) {view.hideProgress(); if (isConnected)  
    view.showErrorMessage(new **VoucherException**(throwable));  
else  
    view.showOfflineMessage(false);  
} }; This is how the handles the error occurrence and other View interfaces become more cleaner: BaseView’s showErrorMessage() public interface extends { TopUpView BaseView void showBankGateway(String url);

void setVoucherResult(int amount, String voucher); } , and we present errors inside our or according to exception we received: Activity Fragment @Overridepublic void showErrorMessage(Throwable throwable) {Timber. (throwable, "Error!"); e if (throwable _instanceof_ **VoucherException**)  
    showToastMessage(getString(R.string._error\_voucher_));  
else if (throwable _instanceof_ **TopUpException**)  
    showToastMessage(getString(R.string._error\_application_)); } The last but not the least, we don’t need to hard-code any more error messages in the layer!!! This is how layer shows relevant error messages from resources (R file) to user! Presenter View TL;DR I have used exceptions to handle errors using one method inside my and try to clean my code by removing duplicate error methods. showErrorMessage BaseView interface UPDATE: According to some responses to this article and more researches about this solution is fine but it is not the best practice and you have to take care of all exceptions happening inside using a separate method in the layer. MVP, Presenter View Thanks for reading this. I am always busy with improving and cleaning my codes, so please leave a comment if you are okay with this solution and will use it inside your project? and if not why? Share this article if you think it is useful, and follow me for more articles . Mohsen Mirhoseini Argi _I am a senior Android Developer with about nine years experience in the field of Computer Software engineering. I have…_mirhoseini.info Mohsen Mirhoseini - Senior Android Developer

Super

A useful memory debugger plugin for Android Studio

Yet another MVP article — Part 5: Writing Test using a mixture of Dagger and Espresso

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

MVP — How to present different errors on View Layer using only one method?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

My first experiences with Kotlin

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

My first experiences with Kotlin

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps