October 9 2023

Fire Up Your App With Firebase Firestore in MVVM Architecture With Jetpack Compose (Part IV)

sanjaybhatikar Android Native, Architecture, Jetpack Compose Cache, Data Model, Room Database 0

Business Logic Model data for ingestion into the app

Fire Up Your App With Firebase Firestore in MVVM Architecture With Jetpack Compose (Part IV)

We define data models in the Data layer for storage and separate data models in the Domain layer for implementing the core business logic of our app. Storage can take various forms, such as when we introduce caching, requiring its own set of data models in the Data layer for local database operations.

But why the need for distinct data models? The choice of storage technology significantly influences our data design. In the case of relational databases, like Room DB for caching, data must conform to an atomic entity structure. Consequently, we place the corresponding data models in the package “local” within the Data layer and employ them for CRUD operations.

In contrast, NoSQL databases, like Firebase Firestore, offer more flexibility. Firestore’s data organization revolves around collections of documents, where each document contains named slots for numeric or textual data. This organizing principle is reflected in the design of our data models, which we place in the package “remote” within the Data layer.

The Domain layer harmonizes over differences by presenting data models in a manner closer to how we typically conceptualize domain entities, ensuring they fit seamlessly into our app’s business logic. We introduce a package “mapper” in the Data layer to house the code for mapping between these different sets of models. We house this code in the Data layer, adhering to the principle that the Domain layer may not know about other layers but the other layers know about Domain layer.

Mapper Write extension functions for mapping

We implement a mapper as an extension function of the source class that returns an object of the target class. This one-one mapping is fairly typical. The simplicity of business logic in your use-case means we do not need to deal with nested data structures, complex joins or aggregates.

Here is a sample mapper function.

	fun ChapterInfoFire.toChapterInfo(): ChapterInfo {
    return ChapterInfo(
        name = name,
        title = title,
        description = description
    )
}

The ChapterInfoFire.toChapterInfo() function is an extension function that maps an instance of the ChapterInfoFire data class into an instance of the ChapterInfo data class. In Kotlin, an extension function allows adding new functionality to an existing class without modifying its source code.

Here’s a breakdown of how the function works:

ChapterInfoFire.toChapterInfo(): This is the function signature, indicating that it’s an extension function for the ChapterInfoFire class, and it will return a ChapterInfo object.
return ChapterInfo(...): The function returns a new ChapterInfo object, and within the parentheses, it initializes the properties of the ChapterInfo object.
name = name, title = title, description = description: Here, it’s copying the values of the properties from the ChapterInfoFire object to the corresponding properties in the ChapterInfo object. The name, title, and description properties in the ChapterInfo object are set equal to the values of the same-named properties in the ChapterInfoFire object.

In summary, this extension function simplifies the process of converting a ChapterInfoFire object into a ChapterInfo object by copying the values from one to the other.

This example shows how we map data from the Data layer to the Domain layer. It allows seamless data flows while ensuring separation of concerns in MVVM architecture.

Conclusion Takeaways and Next Steps

Recap:

Create data models in the “remote” package in Data layer for Firestore CRUD operations.
Create data models in the “domain” package in Domain layer to use in the app’s business logic.
Implement mapper functions in the “mapper” package to map data models between Data and Domain layers.

We have now set the stage for ingestion of data into the app. But we have yet to address all aspects of data management for a professional app. For example, our query may fail due to a poor network connection. We need to address this possibility and ensure the app handles off-the-happy-path scenarios gracefully.

Another important consideration is, we want to use Kotlin’s data structures to manage data flows to deliver a responsive user experience that doesn’t keep the user waiting and minimizes or eliminates unnecessary clicks. In other words, we need a repository pattern. That’s coming up next.

October 4 2023

Fire Up Your App With Firebase Firestore in MVVM Architecture With Jetpack Compose (Part III)

sanjaybhatikar Android Native, Architecture, Jetpack Compose Data Class, Data Model, Firebase, Firestore 0

Domain Layer Bridge between Data and Presentation

Fire Up Your App With Firebase Firestore in MVVM Architecture With Jetpack Compose (Part III)

A key feature of the Domain layer is that it must not know about the Data and Presentation layers, but the other layers may know about it. The Domain layer serves as a crucial bridge between the Data and Presentation layers. Why do we need this bridge?

Because the design considerations that drive “How?” we shape data are different for “When?“we want store data and “When?“we want to work with data in our app. That means we need to maintain two sets of data models and the code that maps between them. So far, we have seen the storage side of the story. Now let us look at the domain side.

Data Models Define data models for other layers

In our screen, we want to present a ToC, which is a list of chapters. Here is what the model for a single chapter looks like:

	data class ChapterInfo(
    val name: String,
    val title: String,
    val description: String
)

Compare with the model ChapterInfoFire in the Data layer’s package “remote”. These models are very alike.

The domain model for a quiz is as follows:

	data class Quiz(
    val questionNumber: Int,
    val question: String,
    val answer: String,
    val image: String?,
    val youTubeVideoId: String,
    val timestamp: Int,
    val chapterKey: String,
    val isActive: Boolean
)

Here, we employ a questionNumber attribute to facilitate both the ranking and unique identification of questions within a chapter or module. The quiz question may have an explanatory image to accompany the answer. The quiz includes a YouTube video identified by youTubeVideoId with explanatory content. A timestamp marks the start time of relevant content on the video track. The chapterKey attribute is employed as a reference to the parent chapter or module, enhancing the ease of navigating associated information.

In the realm of relational databases, the navigation of data relationships across tables is guided by foreign key constraints, ensuring a structured approach. However, Firestore’s NoSQL design opts for a more flexible approach by discarding these constraints to reduce upfront storage design complexity. Nevertheless, this flexibility comes at the cost of requiring additional logic in our application code to navigate these relationships. For intricate relationship scenarios, it may be beneficial to explore alternatives, such as leveraging a “built-to-suit” backend solution with technologies like PostgreSQL and a Python FastAPI wrapper to streamline complex data interactions.

Both the data models we have shown (and any others we need in the future) are housed in package “model” in Domain layer.

Conclusion Takeaways and Next Steps

We have defined the data models in the Domain layer. Our “Android Ally” quiz app does not have complex processing logic at this stage and the models sufficiently structure data for presentation. Where should the logic of mapping between sets of models reside? For this, we have package “mapper” in the Data layer. Let’s look at that next.