Architecture Design – Chathuranga Shan

Switching to Hilt from Dagger

Posted on May 18, 2022

I had been using Dagger for all my projects as the dependency injection solution. It was the go-to library for managing dependencies in your application when developing an application with testability and code separation in mind. The Dagger library was not originally designed for the Android framework. Because of that Dagger was not that easy to work within the Android framework but once you figure out how to use it, it’s the best solution available for android project dependency injection. The Hilt library is the new dependency injection solution for android which replaces the Dagger. The Hilt was built specifically for Android project development. It reduced the significant amount of code that we need to write and it has built-in support for ViewModel injection.

In this article, I’m using my old project which I used in the MVVM error handling article series. I have expanded that project into an indoor plant selling sample application. This way we have a few screens to work with plus it covers most of the dependency injection scenarios that we face in real-world application development. You can find the code in this repository. Refer to dagger_to_hilt_start branch for the start point of the application. you will be able to see the end result of this implementation on dagger_to_hilt_end branch. In this article, I will mainly focus on explaining how to perform the transition to Hilt from Dagger. Even though I will get into the details of the Hilt library I will include some parts of official documentation in this article because there is no point in rewriting the same details. So let’s clean the project and delete all the files inside “di” folder.

Architecture

Android MVVM architecture with clean error handling – Part 2

Posted on April 2, 2022

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.

Architecture

Android MVVM architecture with clean error handling – Part 1

Posted on May 19, 2021

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.