Tag: LiveData

I wrote an article a few months back explaining my approach to error handling in MVVM architecture. since that, I had a chance to apply this approach to a few projects I was working on. While my approach still holds strong I have noticed a few places where I can improve to make this approach even better. These changes I’m about to make still follow the same flow as I had in my first article.

More control in Handling processing status

In the previous article, I had a boolean mutable live data variable in BaseViewModel which is used by the UI layer to show the loading animation on the screen to notify the user that the application is doing some processing. The problem with having a boolean value is that on some screens you will need to do different things based on the status of “completed”, “processing” and “error”. Obviously, this boolean value can not store 3 values for UI to refer to and do the necessary changes base on status. To handle this I have to introduce the below enum class.

MVVM architecture is a popular architecture among android developers due to it being more suitable for most of the project sizes which provide more flexibility to scale project with code separation. Google JetPack libraries also work with this architecture like bread and butter to make it easier to implement reactive solutions with less boilerplate code. Error handling is a huge part of any project when it’s come to giving a good user experience. In this article, I’m going to show my approach to handling errors which allows you to develop cleaner functional requirements while treating error handling is as a separate stream.

To have a good error handling solution first we need to understand which parts of our application generates errors and what we need to communicate to the user. Let’s start from the bottom layer of our architecture which is the repository layer. Application all network and database related business logic are situated in this layer. When it comes to network call-related errors we need to inform users with descriptive error messages almost all the time. The only exception to this is errors that cause because internal issues (Bad Json phrasing). In those cases providing a generic error with description is enough. When It comes to database-related error handling most of the time we will have to inform the success and fail status of the database operation. The only exception to this is errors that cause when writing optional recodes to the database. An example of this would be caching network calls to use on offline mode. When it comes to the middle layer which is the view model layer, Usually form-related validation is done in this layer. in case of validation fail we need to showcase those errors underneath the edit text or to other elements to guide users.