Menu

Android Native

Dockerize data assets such as database and SQL client on Raspberry Pi.

Baking Data Apps Into Raspberry Pi

, , , , , 0

In an earlier blogpost, we looked at why Docker is such an indispensable tool in the developer or data scientist’s toolkit, especially for shipping code that runs consistently across different environments. The Raspberry Pi, with its ARM architecture, provides a great example. Running software developed in traditional x86 environments on the Raspberry Pi can be challenging. Docker helps surmount these challenges and saves us endless frustration.

Show Me The Money Expense-Tracking App

I recently built an app for tracking expenses, particularly when my kid spent too much money on Zomato, a food delivery app! The idea was to set a monthly budget and track expenses against it. Visualizing data is crucial for self-adjustment on the path to improvement. The expense tracking system I built allows tracking expenses in common categories such as groceries, restaurants, utilities, etc.

The UI in PyQt6 for CRUD operations on Postgres warehouse. The MVC has Python with business objects in Pydantic and the SQLAlchemy ORM.
The expenses are managed through the app with a PyQt6 app that has a Postgres backend. The user can create a new expense, retrieve it for viewing, update it and apply changes or delete it. The Python implementation uses PyQt6 for UI and Pydantic for business objects with SQLAlchemy ORM.

I developed the app in the Python programming language. The app’s GUI, built in PyQt6, supports CRUD operations on a Postgres database. Users can create, view, update, and delete expenses. The architecture is a standard MVC framework with Pydantic business objects and SQLAlchemy ORM. 

Additionally, I built a dashboard in Grafana, a browser-based dashboarding tool. I developed the app on my MacBook and deployed it on the “always on” Raspberry Pi 400 at home.

Eat Humble Pie Code portability issues

I encountered many hurdles when porting code to the Raspberry Pi. The PyQt6 library couldn’t be installed in a virtual environment using the pip installer, so I installed it system-wide from the Debian repository. This prevented running my Python code in the virtual environment. Consequently, other dependencies like Pydantic and SQLAlchemy also had to be installed system-wide.

I built an expense tracking application to monitor day-day expenses and generate informative summaries. I used Grafana to construct a dashboard featuring interactive visualizations.
Get Grafana on Raspberry Pi. Build and share interactive visualizations.

I pulled the official Docker image for Postgres to get the database running. See this blogpost. However, finding a suitable SQL client was surprisingly difficult. I tried TablePlus, DBeaver, and Pgdmin, but each had issues post-installation, rendering them unusable.

A bad workman always blames his tools. Was I using the wrong tools or is the Raspberry Pi just Rubbish Pi?

It's Raining Containers Containerize the asset

The Raspberry Pi, being resource-constrained compared to a desktop, poses challenges in installing and running software. Docker can be invaluable in such situations. I was already running Postgres in a Docker container on the Raspberry Pi and found ARM-compatible containers for Pgadmin and Grafana. The pgAdmin container, provided by Elestio, is available as elestio/pgadmin.

Here’s how to install it:

  1. Pull the image: docker pull elestio/pgadmin
  2. Run the container:
	docker run --name pgadmin_service \
	-d -p 8080:8080 \
	--network docker-net \
	-e PGADMIN_DEFAULT_EMAIL=handsomest.coder@email.com \
	-e PGADMIN_DEFAULT_PASSWORD=topsecret \
	-e PGADMIN_LISTEN_PORT=8080 \
	-v ~/path/to/pgadmin/servers.json:/pgadmin4/servers.json \
	elestio/pgadmin

This command starts a Pgadmin container named pgadmin_service in the background, accessible via http://localhost:8080, connected to the docker-net network, using the specified email and password for initial login credentials, and mounting a servers.json file for predefined server connections.

Don't Dally, Do Docker  Summary

Using Docker images for Pgadmin and Postgres provided a smooth path to setting up these vital data assets on my Raspberry Pi. This approach should generally be the default for installing software in app development. For example, when building home automation systems, it’s beneficial to containerize services like Mosquito MQTT, Node-Red, InfluxDB, and Grafana that are part of developer’s IoT stack. Refer to this YouTube video for a guide. For managing all these containers with a graphical UI, use Portainer, available as a free community edition from Docker. 

Unlock the full potential of AI with our FastAI course, where you’ll not only master AI integration into applications but also gain essential skills like Docker, crucial for deploying and managing your apps in real-world environments. Learn to bridge the gap between development and practical implementation, ensuring your AI solutions are robust, scalable, and ready for end-users. Join us to transform your technical expertise into powerful, customer-ready applications.

charlesdeluvio-6F4k4R9B6kk-unsplash

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

, , , , , , , , 0

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:

  1. 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.
  2. 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:

  1. 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.
  2. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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. 
  6. 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.
  7. 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.
  8. 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:

  1. 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
  2. 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.
  3. 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

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

Recap: 

  1. Create a repository interface in the package “repository” in Domain layer, which will be used by the Presentation layer.
  2. Implement the repository interface in the package “repository” in the Data layer.
  3. 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!

charlesdeluvio-6F4k4R9B6kk-unsplash

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

, , , , 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:

  1. 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.
  2. return ChapterInfo(...): The function returns a new ChapterInfo object, and within the parentheses, it initializes the properties of the ChapterInfo object.
  3. 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

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

Recap:

  1. Create data models in the “remote” package in Data layer for Firestore CRUD operations.
  2. Create data models in the “domain” package in Domain layer to use in the app’s business logic.
  3. 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.

charlesdeluvio-6F4k4R9B6kk-unsplash

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

, , , , , 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

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

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.

charlesdeluvio-6F4k4R9B6kk-unsplash

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

, , , , , , , , 0

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.
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:

  1. 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.
  2. 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:

  1. 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.
  2. 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.
  3. 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:

  1. 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.
  2. Loop Through Documents: for (document in querySnapshot.documents) {} iterates through each document (record) returned by the Firestore query.
  3. 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.
  4. 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.
  5. 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".
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.

charlesdeluvio-6F4k4R9B6kk-unsplash

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

, , , 0

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:

  1. 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.)
  2. 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.
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:

  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. 

An architectMVVM-ToCure 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.

fahrul-azmi-cFUZ-6i83vs-unsplash

A Guide to Enhancing User Experience by Integrating Image Picker Functionality in Your Android App

, , , , , 0

Alice, our intrepid explorer of Android Wonderland, had a grand vision for her Vaxin app. She dreamed of allowing users to personalize their experience by choosing an image from their phone’s gallery. Little did she know the adventures that awaited her.

Part 1: Alice’s Journey in the Android Wonderland

With unwavering determination, Alice declared a state variable named imageURI to hold the URI of the chosen image. She was well-prepared and cleverly used the Elvis operator to provide a default image just in case. She had learned from her previous adventures in Wonderland that it’s wise to be prepared for the unexpected.

	val imageURI = remember {
    mutableStateOf<String>(
        child.imageURI?.toString() ?: "android.resource://${context.packageName}/drawable/child"
    )
}

Suddenly, out of thin air, the enigmatic Cheshire Cat materialized before Alice.

“Would you tell me, please, which way I ought to go from here?” Alice enquired.

“The depends a good deal on which image you want to show,” said the Cat.

“I don’t much care which one –” said Alice.

“Then it doesn’t matter which one you show,” said the Cat.

“– so long as the user picks one,” added Alice as an explanation.

“Then be sure to look in the Coil library,” said the Cat, “for a looking glass into the content that your URI will find as surely as White Rabbit has fur and whiskers.”  

With that cryptic message, the Cheshire Cat vanished into thin air once again, leaving Alice to tease out the meaning of his words.

Alice continued her journey in the direction the Cheshire Cat pointed out. She created a magical portal using Coil’s AsyncImage composable to display the selected image. The image was not just displayed; it was crafted into a neat circular shape and cropped to perfection to avoid any distortion. Alice marked it as clickable, adding a “TODO” to remind herself to complete this part of her adventure.

	AsyncImage(
    model = imageURI.value,
    contentDescription = "Generic Child",
    contentScale = ContentScale.Crop,
    modifier = Modifier
        .padding(5.dp)
        .size(75.dp)
        .clip(shape = CircleShape)
        .clickable {
            TODO("Lauch Image Picker")
        }
)

Just then, she noticed the Queen of Hearts was behind her, observing her code. With a stern tone, she questioned Alice’s action.

“Who gave you permission to use the image gallery in your app? Off with her head!“

“Don’t be silly,” said Alice. But she had turned thoughtful, looking for a way to launch the image gallery from within the app and obtain a URI to the selected image.

Part 2: The Enchanted Image Picker

As Alice contemplated her next move, the White Rabbit hurried by, nervously clutching his pocket watch and casting furtive glances at the time ticking by.

“Alice, you must use rememberLauncherForActivityResult. It’s like a magical gate that leads to a world of images. When the user picks an image, the launcher will provide you with the image’s URI.”

He took the pocket watch out of his waistcoat and remarking on how late he was, scurried off.

Alice followed the White Rabbit’s guidance and set up the launcher, ready to open the image picker.

	val singlePhotoPickerLauncher = rememberLauncherForActivityResult(
	contract = ActivityResultContracts.PickVisualMedia(),
	onResult = { uri ->
		Log.d(TAG, "Got content uri: ${uri}")
		uri?.let {
			imageURI.value = it.toString()  // For immediate preview
		}
	}
)

With the URI in her grasp, Alice displayed the image on the screen using AsyncImage, inserting singlePhotoPickerLauncher into the callback of the clickable event, much like hanging a beautiful painting on the wall of her app.

	 AsyncImage(
		model = imageURI.value,
		contentDescription = "Generic Child",
		contentScale = ContentScale.Crop,
		modifier = Modifier
			.padding(5.dp)
			.size(75.dp)
			.clip(shape = CircleShape)
			.clickable {
	 			singlePhotoPickerLauncher.launch(
					PickVisualMediaRequest(
	 					ActivityResultContracts.PickVisualMedia.ImageOnly
					)
				)
			}
	)

As she marveled at her creation, a curious apparition appeared in the air. It puzzled her at first, but she soon recognized it as the grinning Cheshire Cat. Alice was delighted to have someone review her code.

“How are you getting on?” said the Cat as soon as its mouth was big enough to speak.

Alice waited patiently until the eyes appeared and then nodded. “It’s no use speaking to it,” she thought, “until its ears have come, or at least one of them.”

In another minute, the whole head appeared, and Alice put down her keyboard to share her coding adventure. The Cat seemed satisfied with what it had seen and started fading just as miraculously as she had appeared.

But before vanishing completely, the Cheshire Cat left Alice with a valuable piece of advice.

“Beware, Alice, there may be villains who delete images from the gallery. There are 4 types of URI and they are not all the same. The URI from the image picker is a content URI. Always remember to copy the content to your app’s local storage and obtain a file URI that you persist to the app’s database.”

Alice felt a pang of unease. “What if the Queen of Hearts has already deleted the image from the gallery?” she wondered.

Determined to secure her chosen image, Alice wrote a function to read the content from the content URI into a byte array and then write the byte array to a file. This process gave her the precious file URI she sought.

	fun getFileURI(contentUri: Uri, childId: String, context: Context, contentResolver: ContentResolver): Uri {
	/* Read contents at content URI into byte array */
	val imBytes = contentResolver.openInputStream(contentUri)?.use {
		it.readBytes()
	}
	/* Write byte array into a local file with appropriate name */
	val file = File(context.filesDir, "${childId}.jpeg")
	FileOutputStream(file)?.use {
		it.write(imBytes)
	}
	/* Get the file URI to persistently access image */
	return file.toUri()
}

With the URI secured, Alice was ready to ship it to the View Model for persistence in the Room database. She expanded the launcher to do just that, wrapping the URI in data class OnAddChildPhoto of sealed class AddChildEvent for handling all user-originated events from that screen. She used the View Model’s onEvent method for the transfer. 

	val singlePhotoPickerLauncher = rememberLauncherForActivityResult(
	contract = ActivityResultContracts.PickVisualMedia(),
	onResult = { uri ->
		Log.d(TAG, "Got content uri: ${uri}")
		uri?.let {
			imageURI.value = it.toString()  // For immediate preview
			val fileURI = getFileURI(it, child.childName, context, contentResolver)
			Log.d(TAG, "Got file URI: ${fileURI}")
			onEvent(AddChildEvent.OnAddChildPhoto(
				imageURI = fileURI,
				child = child
			))
		}
	}
)

At long last, it was time to reveal the image picker feature.

A Guide to Enhancing User Experience by Integrating Image Picker Functionality in Your Android App

Image Picker

Pick an image from the phone’s image gallery. 

Github

Image Added

Selected image is added to the app and displayed on the card.

View My Work

A Guide to Enhancing User Experience by Integrating Image Picker Functionality in Your Android App
jene-stephaniuk-CzcZIt9bRb4-unsplash

Elevate Your App’s Aesthetics: Crafting a Vibrant and Tasteful Color Scheme with Material Theme

, , , 0

Material 3 is Google’s latest design system that brings a refreshed look and feel to Android applications. One of its key components is theming, which includes defining a cohesive color scheme for your app. This guide will focus on using Material 3 for theming, with a particular emphasis on colors, composition, and light and dark themes, with practical implementation steps.

Vaxin Demo

Color Hierarchy in Material 3 Theming:

Material 3 defines a color hierarchy consisting of several key color categories:

  1. Primary: The primary color is the main color that defines your brand identity and is used for visually prominent elements. It is like the star player on your team.
  2. Secondary: The secondary key color complements the primary color and plays a supportive role. It is like the wingman, providing harmony and balance to the design.
  3. Tertiary: The tertiary key color is like the wildcard, providing contrasting accents and provoking interest. The tertiary color is typically a color that is created by mixing a primary color with a secondary color. It makes visual elements ‘pop’!
  4. Background: Neutral colors are used for background and surfaces in the app. They create a clean and unobtrusive backdrop for content, ensuring readability and visual balance.
  5. On-Color: This category includes color variations that ensure text and icons remain visible and legible when placed on top of the primary, secondary, tertiary, or background colors.

By using these colors effectively, you can create a well-balanced and visually engaging design that captures the user’s attention, communicates your brand identity, and ensures a pleasant user experience.

Color Selection and Usage:

Elevate Your App’s Aesthetics: Crafting a Vibrant and Tasteful Color Scheme with Material Theme

Primary

The primary color sets the overall tone of the app. Here, we have used it to attach prominence to the clickable tiles of which there is one for each upcoming vaccination.

Inverse Surface Variant

We have further accented each tile with a cresting wave pattern in bezier curves. We have picked from among the “surface variants” used to stylize shapes or surfaces.

Tertiary

The tile for an overdue vaccine is made to ‘pop’ with tertiary color, drawing attention with noticeable contrast. The container has the corresponding tertiary container color.

The theme includes specific color variations like “Primary Container” and “On Primary Container” in the Material 3 theming system. These variations are part of Material 3’s extended color system and are used for fine-tuning the appearance of different UI elements within your app. Let’s explore these variations:

  1. PrimaryContainer (MaterialTheme.colorScheme.primaryContainer): In Jetpack Compose, we use containers for laying out visual elements. This color is typically used for the  container of a primary element. It harmonizes with the coloration of primary elements in the foreground, such as buttons, cards, etc. 
  2. onPrimaryContainer (MaterialTheme.colorScheme.onPrimaryContainer): This color is designed to ensure text and icons remain readable and accessible when placed on top of the primary container. It provides sufficient contrast to maintain good visibility. You can use it for text and icons within primary containers to ensure readability.

The theme extends to container variations for primary, secondary and tertiary elements. Every container has the on-container color variants for legibility of text and icons.

To summarize, the primary color comes in four flavors as follows: primary, on primary, primary container, on primary container. Likewise, secondary and tertiary.

Surface Variant

Neutral colors serve as a backdrop against which the main content is served. Here, a title, a colorful image and descriptive text appear prominently in the foreground against a dark background.

Surface Tint

Among the many variants of surface color is a tint which is applied here to the viewport that presents detailed vaccine information.

Image Graphics

The image accompanying the description is clipped to a circle and cropped to fit without distortion.

Elevate Your App’s Aesthetics: Crafting a Vibrant and Tasteful Color Scheme with Material Theme

Light and Dark Themes:

Material 3 supports both light and dark themes to enhance user experience and cater to user preferences. When designing your app, consider the following:

  • Light Theme: Typically uses a light background with dark text and components. It provides a clean and inviting appearance suitable for most scenarios.
  • Dark Theme: Inverts the color scheme, featuring dark backgrounds with light text and components. It is easier on the eyes in low-light conditions and can offer a unique visual aesthetic.

Implementation Checklist:

  1. Create Theme with Theme Builder:
  • Visit the Material 3 Theme Builder website.
  • Provide the primary color in hex code and the builder will generate the scheme, including primary, secondary, tertiary, and background colors.
  • Export the generated Color.kt and Theme.kt files for Jetpack Compose.

2. Integration into Your Project:

  • Cut and paste the contents of each file into the eponymous file in the util package of your project. Be sure to include the dark and light colors.

3. Apply Colors to UI Elements:

  • In MainActivity, the root composable must be wrapped in the app theme for theming to work. The app theme is declared in Theme.kt near the end. Optionally, further wrap the root composable in a Surface with tonal elevation to apply background theme color to every screen.
  • Apply the primary colors to the main elements in each screen, specifying the theme color like so: MaterialTheme.colorScheme.primary. Utilize onPrimary, primaryContainer and onPrimaryContainer as needed.
  • Likewise, apply secondary, and where needed, tertiary colors to style UI components. Fine-tune the aesthetics using  the variants included with the theme, experimenting to get the desired effect.

By following these steps and leveraging Material 3 theming principles, you can create visually appealing and user-friendly Android apps that align with the latest design trends and provide a consistent and engaging user experience.

cdc-9MVMgP2zhgs-unsplash

Vaxin: App for Keeping a Child’s Vaccinations on Track

, , , , , , , , , , , 0

Vaxin: App for Keeping a Child’s Vaccinations on Track

Vaxin App

“Ensuring your child receives timely vaccinations is crucial for their health and well-being. However, managing the schedule for 24 vaccinations within the first 18 months of your child’s life can be a daunting task for parents. That’s where the Vaxin app comes to the rescue. With Vaxin, you can effortlessly keep track of your child’s vaccination schedule, leaving you free from the stress of keeping everything in mind. Simply enter your child’s birthday, and you’re all set to ensure they receive the vaccinations they need on time, promoting their health and peace of mind for parents.”

View Github
Vaxin: App for Keeping a Child’s Vaccinations on Track

Monitor Status

Look up the vaccination schedule for what’s coming up next. Overdue items are called out.

Learn More

Stay Informed

View hand-curated and up-to-date medical information about vaccines from bonafide sources like US Centers for Disease Control.

View My Work

Vaxin: App for Keeping a Child’s Vaccinations on Track
windows-YzLMmxDTrvI-unsplash

Handling UI Events in Jetpack Compose

, , , , , , 0

When crafting an Android app, one essential aspect to consider is the seamless handling of user-generated events within the User Experience. The Model-View-ViewModel (MVVM) architecture provides an elegant solution for streamlining event-handling by centralizing it within the View Model. Let’s explore the structure of an onEvent function, which serves as the hub for managing these events.

	fun onEvent(event) {
	/* TODO */
}

To effectively register callbacks for each event, a when block is utilized. This block checks the event’s signature and triggers the associated callback when a match is found. However, identifying event signatures can be complex due to the diverse nature of events, including button clicks, phone rotations, finger drags, and keyboard inputs.

	fun onEvent(event) {
		when(event) {
			is OnTextClicked -> {
				
			}
			is OnKeyboardInput -> {
				
			}
			is OnButtonPressed -> {
				
			}
			else -> Unit
        }
    }

To address the challenge of passing a multitude of diverse events to the onEvent function while preserving the uniqueness of each user action, a sealed class is introduced, to wrap around various events while offering a unified interface for event handling. Here is an example:

	sealed class ScreenEvent {
    data class OnItemClicked(val item: Item): ScreenEvent()
    data class OnItemNameChanged(val itemName: String): ScreenEvent()
    object OnItemAdded: ScreenEvent()
}

In this example, the ScreenEvent class encapsulates various events, each represented by a subclass. It encapsulate events like OnItemClicked, which might represent a user’s interaction with a UI element, OnItemNameChanged, signifying keyboard input, or OnItemAdded, indicating an action initiated through a floating button. Essentially, ScreenEvent comprehensively covers all permissible user actions mediated by the UI

Within this structure, data classes play a crucial role by holding event-specific information, ensuring that the View Model can process and respond to these events effectively. Conversely, objects within this class serve as signals, indicating when an event occurs without requiring additional data.

Typically, the ScreenEvent class is placed within a presentation package, along with the screen components and View Model, to maintain a clean and organized project structure.

With the groundwork laid by ScreenEvent, we are now well-prepared to further expand the functionality of the View Model, enabling it to seamlessly handle a wide range of user interactions and events.

	fun onEvent(event: ScreenEvent) {
        when(event) {
            is ScreenEvent.OnItemClicked -> {

            }
            is ScreenEvent.OnItemNameChanged -> {
                
            }
            is ScreenEvent.OnItemAdded -> {
				
			}
            else -> Unit
        }
    }

What remains now is to flesh out the callbacks. There are two types of code that go in here: 

  1. CRUD operations: These are operations to create, retrieve, update, or delete app data. Such data are typically found locally in the app’s database or remotely in Cloud storage. These operations are not directly implemented in the View Model. Instead, the MVVM architecture employs a repository pattern, offering methods for CRUD operations within the repository. This separation ensures that any changes or modifications to the management of storage can be isolated to the data layer where the repository is implemented.
  2. One-time UI events: These events involve actions such as displaying a message in a Snackbar or navigating to a different screen. Achieving this necessitates the use of LaunchedEffect() within the Composable to observe UI-triggered events. Additionally, a dedicated class, UIEvent, is introduced to encapsulate the variety of View Model-triggered events.
Handling UI Events in Jetpack Compose

The final step in the process involves calling these methods within the Composable, associating them with specific UI elements to create a cohesive and responsive User Experience.

In conclusion, the Model-View-ViewModel (MVVM) architecture, with its central onEvent function, offers a comprehensive solution for managing user-generated events in Android app development. By encapsulating event-handling within the View Model, developers can streamline the process of responding to diverse user actions, from button clicks to phone rotations and keyboard inputs.

Notably, any changes in UI state variables, neatly encapsulated within the View Model, are efficiently reflected in the User Interface, ensuring a responsive and dynamic user experience. In our upcoming post, we’ll delve deeper into View Model-triggered events, often referred to as one-time events. These events encompass crucial aspects like navigation events, showcasing how the MVVM architecture seamlessly bridges the gap between the View Model and the UI, providing a robust foundation for creating exceptional Android applications. Stay tuned for more insights into this exciting topic.