October 2023

October 10 2023

Unleash Your Creativity with MIT AppInventor: Build Awesome Apps That Amaze Friends

sanjaybhatikar AppInventor Animation, Mole Mash, Sprite

Have you ever dreamed of creating your own amazing app but felt overwhelmed by the complexities of traditional app development? Meet AppInventor, the revolutionary platform developed by MIT and Google that empowers everyone, regardless of their technical background, to build incredible apps with ease. With over 18 million users spanning all ages and backgrounds, AppInventor has been used to craft more than 85 million apps. All you need to get started is a laptop with a web browser like Chrome and an Android phone to turn your ideas into reality!

What Can You Create with AppInventor?

Unleash Your Creativity with MIT AppInventor: Build Awesome Apps That Amaze Friends

The possibilities with AppInventor are endless. Here’s a glimpse of the innovative apps that creators have brought to life:

Show-and-Tell: Craft interactive apps that seamlessly blend images, audio, or video to share knowledge. Whether it’s introducing people to local art pieces or aiding in meditation practices, you can make learning engaging and fun.
Animated Games: Dive into the world of classic games like Space Invaders, Mole Mash, or Pong. Build games that captivate and challenge users with animated characters, touch gestures, and sensor interactions.
Maps and Navigation: Develop location-based apps that provide directions and guide users to local attractions, ensuring they never miss out on exciting experiences.
Artificial Intelligence: Explore the realm of chatbots and computer vision to create intelligent applications that understand and interact with users in a human-like manner.

Building the App Screen

AppInventor boasts a user-friendly drag-and-drop interface that simplifies app creation. Begin by crafting the app’s screen, effortlessly placing graphical elements like images, buttons, sliders, and spinners. Organize these components using layouts to maximize screen real estate. For drawing and animation, leverage the canvas element, which responds to touch gestures, and populate it with animated characters or sprites for interactive games. Beyond visible elements, AppInventor lets you integrate various functionalities, such as sensors, social media connectors, databases, and even AI components.

Building the App Logic

Modern apps rely on event-driven architecture, where actions are triggered by events like user gestures, sensor data, or timers. With AppInventor, you build these logic routines using blocks that you simply drag and drop onto the coding canvas, where they seamlessly snap together to form programs. These blocks act as the fundamental building blocks of your app, representing either data or operations on data. Whether you’re performing arithmetic operations, text analysis, or time-related tasks, AppInventor offers an array of blocks to fulfill your programming needs, from creating a simple pedometer to crafting an AI-powered chatbot.

Demo: Mole Mash

Take, for instance, the classic game of Mole Mash, where the mole rapidly changes its location on the screen, and players score points by tapping it. AppInventor makes it a breeze to create this game with just a few blocks. By adding a timer element and configuring it to trigger every second, you can implement a callback function called ‘moveMole’ using blocks. In this custom function, you calculate the mole’s coordinates using a random number generator and ensure it stays within the screen boundaries. With minimal code, you breathe life into your game!

A Vibrant User Community

AppInventor encourages collaboration and learning within a community of fellow coders. Its active user community provides invaluable support, fostering an environment where problem-solving becomes a shared journey. This mirrors the collaborative nature of the tech industry, where community assistance plays a crucial role in the coding process.

Skillsets You’ll Develop

Coding with AppInventor hones a wide range of valuable skills, including:

Designing captivating user interfaces with stunning graphics.
Harnessing smartphone sensors to enhance app functionality.
Creating animated games featuring sprites and canvases.
Orchestrating events using timers.
Crafting program flow control with loops and conditional statements.
Modeling data using contemporary structures like lists and dictionaries.
Storing data locally or in cloud databases.
Mastering event-driven programming.
Grasping principles of object-oriented programming.
Exploring the fascinating world of artificial intelligence.
And many more!

So, what would you like to build with the limitless potential of MIT AppInventor? Let your creativity soar, and turn your app ideas into reality today!

Unlock Your App Potential with Our MIT AppInventor Course!

🚀 Ready to transform your app dreams into reality?
🌟 Join us and discover the power of MIT AppInventor.
🧠 Learn to create engaging apps, from games to AI-driven solutions.
👩‍💻 No coding experience needed – just bring your ideas!

📆 Enroll now and embark on your app-building journey!

October 9 2023

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

sanjaybhatikar Android Native, Architecture, Jetpack Compose Asynchronous I/O, Firebase, Firestore, Kotlin, Kotlin Flow, Repository, Sealed class

Repository Open a door to the Data layer

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

We have coded CRUD operations and provided data models in Data layer to support I/O. We have modeled data to align with domain business logic and housed these models in the Domain layer for other layers to use. We have provided mapping functionality between sets of data models. So are we ready to access data?

There is some more work (!) to do, in order that we build a professional app that is responsive and doesn’t throw up surprises when contingencies occur.

We want to be mindful of the following:

Remote I/O operations take an undefined amount of time and are unpredictable due to contingencies such as poor internet connectivity, insufficient access privilege or remote service outages. We need to account for these contingencies in our app.
We want to offer a responsive User Experience (UX) that doesn’t keep the user waiting or require unnecessary clicks for user action to be completed.

The repository pattern is where this management overhead resides. At the very least, we implement the following features as we open the door to data in our app:

Exception Handling: We wrap I/O operations in a try-catch block and print diagnostic error messages. We can further enhance this to look for specific errors and fine-tune how we handle contingencies.
Event Emissions: We emit results, whether success or failure, as events to take advantage of Kotlin flows in our app. Streaming events in this ways offers a superbly elegant way to serve content in a dynamically updating UI that is listening for events.

The effect is magical!

Data Contract Define the contract in Domain layer

Let’s look at sample code. Following the pattern of programming to an interface, we define the repository’s interface in the Domain layer in the package repository. Here is the interface, which resides in package “repository” in the Domain layer.

	interface QuizRepository {
    suspend fun getModuleNames(
        fetchFromRemote: Boolean
    ): Resource<List<ChapterInfo>>

    suspend fun getModuleContents(
        name: String
    ): Flow<Resource<List<QuizQuestion>>>
}

The code defines an interface named QuizRepository that outlines the functions required for interacting with data related to the quiz modules. The functions are designed for use for asynchronous I/O in Kotlin Coroutines. They can take advantage of Kotlin flows to sequentially emit events in place of one return value. Let’s unpack the functions defined in this interface:

suspend fun getModuleNames(fetchFromRemote: Boolean): Resource<List<ChapterInfo>>: This function fetches a list of module names (representing different sections or chapters) that are part of the quiz app. It is marked with suspend to indicate that it should be called from a coroutine or another suspending function, as it is designed to perform network I/O operations asynchronously. It takes a Boolean parameter fetchFromRemote, which suggests whether the data should be fetched from a remote data source (e.g., a server) or if it can be retrieved from a local cache or other sources. The exact behavior can be fine-tuned in the implementation. It returns a Resource object wrapping a List of ChapterInfo. The Resource class is often used to represent the result of asynchronous operations and can hold data, loading states, or error messages.
suspend fun getModuleContents(name: String): Flow<Resource<List<Quiz>>>: This function is responsible for fetching the contents of a specific quiz module based on its name. It is also marked with suspend, indicating it’s a suspending function suitable for asynchronous operations. It takes a name parameter representing the identifier of the quiz module to retrieve. It returns a Flow of Resource wrapping around a List of Quiz objects. A Flow is a cold asynchronous data stream that emits values over time. The Resource class is designed to wrap around a generic type so as to encapsulate any result type from a successful I/O operation.

In summary, the QuizRepository interface defines functions to fetch module names and module contents. These functions return data wrapped in a Resource object, indicating the status of the operation (e.g., success, loading, or error). The implementation of such an interface provides the actual logic for fetching data, including network requests, database queries, or other data retrieval methods, using modulating flags like fetchFromRemote to tune the behavior. This structure allows for flexibility in handling data sources and provides a clean separation of concerns in the app’s architecture.

Data Access Flesh out the contract in Data layer

Being in the Domain layer, the interface only knows the data models in the home layer. The implementation however requires use of assets we have built out in the Data layer. Hence, we put the implementation in the package “repository” in the Data layer.

Do you see how the separation of concerns works? The repository opens a door to the Data layer and defines the contract in the interface. The contract, in the Domain layer, is written in the language of the domain. The contract’s implementation resides in the Data layer. We can choose to change the implementation should we make changes in the Data layer, for example, cache remote data locally. These changes need not affect the contract, wherein this detail is abstracted away.

Now let’s look at a concrete function where the I/O operation is implemented.

	 override suspend fun getModuleContents(name: String): Flow<Resource<List<QuizQuestion>>> {
	 return flow {
            emit(Resource.Loading(true))
            try {
                val knowledgeBank = fireStoreCRUD.fetchModuleContents(name)
                emit(Resource.Success(data = knowledgeBank))
            } catch (e: Exception) {
                emit(Resource.Failure(message = e.message ?: "Got not contents for ${name} in Firestore!"))
            } finally {
                emit(Resource.Loading(false))
            }
        }
    }

Here, we have an implementation of the getModuleContents function within the repository, which fetches the contents of a specific quiz module. This function returns a Flow of Resource<List<Quiz>>. Let’s break down how it works:

override suspend fun getModuleContents(name: String): Flow<Resource<List<Quiz>>> { ... }: This function is marked with override as it provides the concrete implementation of the abstract suspend function of the same name in the interface.
return flow { ... }: The function returns a Kotlin Flow, which is a cold asynchronous data stream that emits values over time. The emissions use the Resource class to represent the state of the I/O operation – whether success, failure or work-in-progress.
emit(Resource.Loading(true)): The initial emission within the flow indicates that the operation is in a loading state, with Resource.Loading(true) signaling that loading has started.
try { ... } catch (e: Exception) { ... } finally { ... }: The core logic of the function is enclosed within a try-catch-finally block to handle different scenarios during the data retrieval process.
val knowledgeBank = fireStoreCRUD.fetchModuleContents(name): Inside the try block, it attempts to fetch the contents of the specified quiz module by calling function fetchModuleContents from a fireStoreCRUD instance passed to the repository via dependency injection. The function is responsible for making a request to the Firestore database.
emit(Resource.Success(data = knowledgeBank)): If the data retrieval is successful (i.e., no exceptions are thrown), it emits an event of type Resource.Success with the fetched List<Quiz> in variable knowledgeBank as the data payload. This indicates that the operation was successful, and makes the retrieved data available to the consumers of this Flow.
catch (e: Exception) { ... }: If an exception is thrown during the data retrieval process, it catches the exception. It then emits an event of type Resource.Failure with an error message derived from the exception, or a default message if no message is available. This indicates that there was a failure in retrieving the data.
finally { ... }: The finally block is used to ensure that the loading state is correctly updated, regardless of whether the data retrieval was successful or encountered an error. It emits an event of type Resource.Loading(false) to signal that the loading has completed.

In summary, this function returns a Flow that emits a sequence of Resource objects to represent the status of the data retrieval operation. It starts by emitting a loading state, then attempts to fetch the data. If successful, it emits a success state with the retrieved data; if an error occurs, it emits a failure state with an error message. Finally, it emits a loading state indicating that the operation has completed, whether successfully or with an error. This design allows the UI to respond to different states (loading, success, failure) and appropriately display the data or error messages to the user.

Resource Create class Resource for state emissions

A traditional function returns a single result at the end of the operation. By contrast, a Kotlin Flow allows us to emit events asynchronously as many times as needed in an operation. A sealed class is commonly used for handling different states or outcomes of such an asynchronous operation, when making network requests or performing database queries.

	sealed class Resource<T>(val data: T? = null, val message: String? = null) {
    class Success<T>(data: T?): Resource<T>(data)
    class Failure<T>(message: String, data: T? = null): Resource<T>(data, message)
    class Loading<T>(val isLoading: Boolean = true): Resource<T>(null)
}

Here, we have defined a sealed class named Resource<T> that has three subclasses:

Success<T>: This subclass represents a successful outcome of an operation. It contains a nullable data attribute to hold the result of the operation, which is of a generic type T. It inherits from the Resource<T> class, passing the data to its parent class constructor
Failure<T>: This subclass represents a failed outcome of an operation. It contains a message attribute, which can hold an error message or description, and an optional data attribute that can contain additional data related to the failure. It also inherits from the Resource<T> class, passing both data and message to its parent class constructor.
Loading<T>: This subclass represents a loading or in-progress state of an operation. It includes a isLoading attribute, which is a boolean indicating whether the operation is still loading. It does not carry any data or message, so it passes null to the parent class constructor.

By using this sealed class, we can create instances of Resource to represent different states of our app’s operations, making it easier to handle and communicate the results, errors, and loading states in a consistent and safe manner throughout your app. We will use this class in ViewModel to provide real-time updates to our UI based on the state of asynchronous operations.

Conclusion Takeaway and Next Steps

Recap:

Create a repository interface in the package “repository” in Domain layer, which will be used by the Presentation layer.
Implement the repository interface in the package “repository” in the Data layer.
Implement sealed class Resource in package “util”.

Now we are ready to use the repository access data in the Presentation layer. However, before we can use the repository in View Model, there is one more set up we need to take care of. This is, setting up the repository for injection into the View Model using Dagger-Hilt!

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

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

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.

October 4 2023

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

sanjaybhatikar Android Native, Architecture, Jetpack Compose Android, API, CRUD, Firebase, Firestore, MVVM, Quiz

Firestore CRUD Operations Add Firestore storage to the app

CRUD in an acronym representing the data operations

Create
Retrieve
Update
Delete

CRUD represents the primary data operations. We house the code for CRUD operations on Firebase Firestore in the package “remote” in the Data layer. Firebase provides a Software Development Kit (SDK) to make querying from inside the Android app relatively easy and with only a few lines of code. But queries are only a small part of what we need to integrate Firebase storage into our app. In this article, we will look at the other components following Model-View-View Model (MVVM) architecture.

The package “remote” in the Data layer houses the client-side code for CRUD operations on remote storage. It includes the data models that align with how data are structured in remote storage location.

CRUD Interface Define interface for CRUD operations

First, we define an interface with an abstract function for each query. It is always a good practice to program to an interface. That means that even if implementation details change later, we have a contract for the data operations that specifies the input and the output of each function.

The contractual outputs are described in data models that align with the structure of information in Firestore. These are Kotlin data classes which, together with the interface and implementation, are all part of the package “remote”.

Here is an example of the interface:

	package com.example.androidally.play.data.remote

import com.example.androidally.play.domain.model.ChapterInfo
import com.example.androidally.play.domain.model.Quiz

interface FireStoreCRUD {

    suspend fun fetchModuleNames(): List<ChapterInfo>

    suspend fun fetchModuleContents(name: String): List<Quiz>
}

This code defines an interface named FireStoreCRUD in the com.example.androidally.play.data.remote package. The interface declares two abstract functions for interacting with a Firestore database, specifically for fetching data related to our quiz app:

suspend fun fetchModuleNames(): List<ChapterInfo>: This function is responsible for fetching a list of ChapterInfo objects. ChapterInfo is a data model representing information about different chapters or modules within the quiz app. Each ChapterInfo object has attributes describing a chapter such as the chapter title and description. The function is marked as suspend for asynchronous I/O and it returns a List<ChapterInfo>, retrieving multiple chapter info objects.
suspend fun fetchModuleContents(name: String): List<Quiz>: This function is responsible for fetching a list of Quiz objects based on a specified chapter name. Quiz is another data model representing quiz-related information and has attributes including the question, answer, an optional explanatory image, and id of a YouTube video with start time of the track. The function retrieves quizzes associated with the supplied chapter name. Like the previous function, this one is also marked as suspend for asynchronous I/O operations. It returns a List<Quiz>, retrieving multiple quiz objects.

Overall, this interface defines a contract for fetching data related to quiz modules from a Firestore database. The contract is currently limited in scope since we are in the early stages of the project. More functions will be added later. The actual implementation of these functions involves making database queries using the Firebase SDK. This code resides in a concrete class that implements this interface. This separation of interface and implementation allows for flexibility and testability in our code.

We have specified two data models in our interface. Let us look at one of these next.

Data Model Structure document to use in app

Here is the data class ChapterInfoFire.

	package com.example.androidally.play.data.remote

import ...

data class ChapterInfoFire(
    val name: String = "",

    @PropertyName("Title")
    val title: String = "",

    @PropertyName("Description")
    val description: String = "",
)

The data class ChapterInfoFire represents a Firestore document. Here’s an explanation of the attributes:

name (String): This attribute serves as a unique identifier of a chapter or module within our quiz app. Given the Firestore hierarchy of fields within a document within a collection, we stash the name of the document along with the chapter’s title and description, for ease of retrieval of chapter-associated data in Firestore.
title (String): The title property is annotated with @PropertyName("Title") to indicate that it corresponds to the “Title” field in our Firestore document. The @PropertyName annotation allows us to specify the mapping between the property name in our data class and the field name in Firestore. In our app, this property represents the display title or name of the chapter/module.
description (String): Similar to title, the description property is annotated with @PropertyName("Description"). This property corresponds to the “Description” field in our Firestore document, representing a long description of the chapter/module.

In summary, ChapterInfoFire is a Kotlin data class used to map Firestore documents into a format that our Android app can work with. Each instance of this data class represents a chapter/module in our quiz app and includes properties for the chapter’s name (name), title (title), and description (description). The @PropertyName annotations indicate how these properties are mapped to specific field names in Firestore documents. When we retrieve data from Firestore, we can use this data model to conveniently work with the retrieved chapter/module information in our app’s code.

We still need to flesh out the abstract function declared in the interface and include the query for data retrieval and any related processing. We will override the function in the implementation. Let’s look at a code snippet that gives a flavor of the querying process.

CRUD Implementation Implement querying functions

Here is a sample code with query and processing of the the result in a try-catch block:

	try {
	val querySnapshot = firestore.collection("AndroidAllyContents").get().await()
	for (document in querySnapshot.documents) {
		var chapterInfoFire = document.toObject<ChapterInfoFire>()
        chapterInfoFire = chapterInfoFire?.copy(
			name = document.id
		)
		chapterInfoFire?.let {
			moduleNames.add(it.toChapterInfo())
		}
		Log.d("FIRE_CRUD", "Got chapter id ${chapterInfoFire?.name} title ${chapterInfoFire?.title}")
	}  
} catch (e: Exception) {
	e.printStackTrace()
}

The code block is a Kotlin snippet that uses the Firebase Firestore SDK to retrieve data from our collection “AndroidAllyContents” and then maps the result to a list of ChapterInfo objects. Here’s an explanation of what each part of the code does:

Firestore Query: val querySnapshot = firestore.collection("AndroidAllyContents").get().await() creates a query to fetch all documents from the Firestore collection “AndroidAllyContents.” It then uses the .get() method to execute the query and retrieve the results as a QuerySnapshot. The .await() function is used with Kotlin Coroutines to suspend execution until the query operation is complete. This is common when working with asynchronous Firestore queries.
Loop Through Documents: for (document in querySnapshot.documents) {} iterates through each document (record) returned by the Firestore query.
Document Mapping: var chapterInfoFire = document.toObject<ChapterInfoFire>() maps each document to ChapterInfoFire, using the toObject method to perform this mapping, Then, chapterInfoFire = chapterInfoFire?.copy(name = document.id) updates the name property of the chapterInfoFire object with the id of the Firestore document. This id is a unique identifier that is usually automatically assigned by Firestore to each document as a primary key. Here, we have manually provided the id by concatenating title words into a composite word in camel case. Lastly, chapterInfoFire?.let { moduleNames.add(it.toChapterInfo()) } checks if chapterInfoFire is not null. If it’s not null, it converts the chapterInfoFire object to a Domain data model ChapterInfo and adds it to the moduleNames list for return.
Logging: Log.d("FIRE_CRUD", "Got chapter id ${chapterInfoFire?.name} title ${chapterInfoFire?.title}") logs information about each retrieved chapter/module. It displays the name and title properties of the chapterInfoFire object in the Android log using the “FIRE_CRUD” tag.
Exception Handling: The entire code block is enclosed within a try-catch block to handle any exceptions that may occur during the Firestore query or mapping process. If an exception is thrown, it is printed to the Android log using e.printStackTrace().

In summary, this code retrieves documents from our Firestore collection, maps them to a data model (ChapterInfoFire), and then converts them into Domain data model (ChapterInfo) before adding them to a list (moduleNames) for returning the result. It also logs information about each retrieved chapter/module. Exception handling is included to handle any potential errors during the Firestore query or mapping operations.

Conclusion Takeaways and What's Next

The Domain layer houses the business logic whereby data are processed and prepared for display in the Presentation layer. Storage technology dictates how data are structured in the Data layer, which is often not how we want data structured to work with in the Domain layer. Hence the Domain layer provides data models to make the data “fit for purpose”.

At this point, we have what we need to retrieve information from Firebase Firestore in the Data layer. Where next? In MVVM architecture, the Domain layer houses the business logic whereby data are processed and prepared for display in the Presentation layer. Typically, the manner in which we structure data for storage differs from the manner in which structure data to work with in the app’s business logic. Hence, the Domain layer also provides the data models to use for this purpose. Let’s look at these models next.

October 4 2023

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

sanjaybhatikar Android Native, Architecture, Jetpack Compose Android, MVVM

When developing a scalable Android app, architectural choices are key. In this series, we will construct a quiz app, utilizing the power of Model-View-ViewModel (MVVM) architecture. Our app, designed with Jetpack Compose and powered by Firebase Firestore, also leverages Dagger-Hilt for Dependency Injection.

Before we dive into the details, let’s establish a few assumptions:

Our Android project is already set up as a Jetpack Compose project, complete with the necessary Firebase SDK dependencies. (Note: Authentication is not included in this stage of the project.)
The Firebase project has been configured, and Firestore contains sample data ready for querying. Firestore organizes data into Collections of Documents.

In a nutshell, our app, named ‘Android Ally,’ serves as a teaching aid for native Android development. It delivers content through a series of quizzes, organized into modules such as ‘Android Basics.’ Each module represents a collection of quizzes, each comprising a question, an answer, and various data attributes, including a unique numerical rank within the module. The quiz flow involves presenting questions, revealing correct answers, and allowing users to self-assess their responses as ‘correct,’ ‘partially correct,’ or ‘incorrect.’ This process repeats, and users can also review the knowledge base at their discretion.

At this stage of app development, we’re focusing on a single screen displaying the Table of Contents (ToC) fetched from the backend. Future phases will involve running quizzes for anonymous users and implementing caching. Features like authentication will be introduced in later stages.

Our current spotlight is on a single Firestore Collection named ‘AndroidAllyContents,’ with sample Documents like ‘AndroidBasics,’ ‘JetpackComposeUI,’ and more. Each of these modules in the ToC will eventually have its own Collection, with each quiz stored within individual Documents.

With this foundation, let’s dive into the implementation process.

The Model-View-View Model (MVVM) architecture has three layers: 1. Data: This is the storage layer for data that is consumed during app’s usage and may include data generated by user..2. Presentation: This is the User Interface (UI) where information is presented to the user and interaction with user takes place. 3. Domain: This is the bridge between the Data and Presentation layers where data are shaped in the manner required for presentation. It includes the rules necessary to transform data.

As shown in the figure, The Model-View-View Model (MVVM) architecture has three layers:

Data: This is the storage layer for data that is consumed during app’s usage and may include data generated by user..
Presentation: This is the User Interface (UI) where information is presented to the user and interaction with user takes place.
Domain: This is the bridge between the Data and Presentation layers where data are shaped in the manner required for presentation. It includes the rules necessary to transform data.

An architecture provides the bare skeleton that is fleshed out with code. It is instructive to examine how the code is structured in packages in each layer to uncover the mechanics of the app. For example, the Data layer’s package remote contains all the client-side code for remote storage. We will step through the structure to understand the components of the app and how they relate to each other.

In order to keep it simple, we will start confine our scope to a single screen that displays a Table of Contents. It is a plain display consistent with the goal of this series. We will start by examining the client-side code for Firebase Firestore storage.