Upon the completion of the common module, the thought of the separation of concerns did not occur to me, as I was more entangled on completing the module itself.

After some feedback from the developers, it was evident that the common module has become a monolith, where in essence I was breaking the foundation of S.O.L.I.D. Principles.

common module has code for everything, from networking to UI and everything else. But I didn't account for the use-case where a person may want to use only some components (networking for example), instead of everything out of this library.

Ideally, developers should also have the option to cherry-pick the components they like, instead of shoving everything to them.

Memory Leak due to ShimmerLayout

When using ShimmerLayout provided by Team Supercharge, memory leaks were happening, which was detected by LeakCanary.

Migrate from default Groovy Build Scripts to Kotlin Build Scrips using Gradle KTS.

Handle JsonDataException

Summary

com.squareup.moshi.JsonDataException is caused due to mismatch between the JSON String received as the response and the Data Class with Response.

The most common cause of this mismatch is the mismatch of the data type.

This was not handled within BaseViewModel.kt.

Explanation

Consider this JSON:

{
    "name": "Leonardo",
    "age": 22
}

And the Data Class,

data class ScientistResponse(
    @field: Json(name = "name") val name: String?,
    @field: Json(name = "age") val age: String?
)

As you can notice, the field age in ScientistResponse is String, but from JSON, we are receiving the value of field age as an Int.

This causes the com.squareup.moshi.JsonDataException.

Now, currently in the BaseViewModel.kt, under the method handleException(), com.squareup.moshi.JsonDataException is not handled:

/**
  * Handles the different types of Exceptions that may have caused during
  * performing REST API Call.
  *
  * @param TypeREST Any Class which holds the response of REST API Call.
  * @param TypeErrorResponse Any Class which extends [BaseErrorResponse], acts as the
  *   Error Response Body.
  * @param throwable Instance of [Throwable] denoting the Exception Super-Class which contains
  *   more details about the error cause.
  * @param errorResponseClass [Class] of [TypeErrorResponse].
  * @param handleErrorCode Lambda Expression that processes the Error Code before
  *   executing 'handleError'.
  */
private fun <TypeREST, TypeErrorResponse : BaseErrorResponse> handleException(
    throwable: Throwable,
    errorResponseClass: Class<TypeErrorResponse>,
    handleErrorCode: (Int, TypeErrorResponse) -> ResultWrapper.Error<TypeREST>
): ResultWrapper.Error<TypeREST> = when (throwable) {
    is ConnectException -> ResultWrapper.Error.NetworkConnectionError()
    is SSLHandshakeException -> ResultWrapper.Error.SSLHandShakeError()
    is IOException -> ResultWrapper.Error.NetworkError()
    is HttpException -> handleHTTPException(throwable, errorResponseClass, handleErrorCode)
    else -> ResultWrapper.Error.Other()
}

So, whenever JsonDataException is caused, the code handles it as an error type of Other by returning ResultWrapper.Error.Other.
The nature of ResultWrapper.Error.Other is that error in fetching REST API is notified, but the cause is not mentioned.

Due to this existing code, we can not determine at the end why the JSON Exception is caused.