CategoriesLibrary

Switching to Hilt from Dagger

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.

Continue reading
CategoriesArchitecture

Android MVVM architecture with clean error handling – Part 2

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.

Continue reading
CategoriesLibrary

Using Paging 3 library to consume large data set over the network

Jetpack paging library introduces a hassle-free way to implement pagination for a large set of data. Paging 3 is the latest iteration of the library and a few months ago it released the stable version. In this article, we will look into how to use this library to consume large data set over REST API. This project is build using MVVM architecture. For network call integration I’m using Retrofit with Moshi.

In MVVM architecture each layer has different responsibilities. Paging 3 library has different components which align with these architecture layers. Take a look at the below diagram.

Continue reading
CategoriesArchitecture

Android MVVM architecture with clean error handling – Part 1

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.

Continue reading
CategoriesNavigation

Coordinator Layout Like Animation on Fragment Using Motion Layout to have Seamless Transition when using Using Navigation Component

Navigation component Introduction made using single activity UI pattern easy. Although it introduces a stranded way to follow a single activity UI design pattern it comes with its own challenges to overcome. One of which is to have a seamless transition between coordinator design fragment and other fragments.

The issue with using coordinator layout design with Navigation Component

When implementing the navigation component activity act as a navigation fragment holder. Fragments in the navigation component consume the data coming from the view model and display for users to interact with users. Activity holds navigation fragments and toolbar. The app toolbar is placed inside activity because it’s common for most of the fragments. This works fine as long as there is no need to implement a design involving coordinator layout. Coordinator layout does those beautiful collapsing animation by using CollapsingToolbarLayout inside AppBarLayout. The app toolbar also needed to stay inside CollapsingToolbarLayout.

Continue reading