1

Building the UI for Your Messaging App

In this first chapter, we're going to start building a messaging app called WhatsPackt (referring to a popular messaging app that you probably already know about). At this point in the project, we must make some important technical decisions and create the structure needed to build it. This is what we will be focusing on, as well as working on the app's user interface.

By the end of this chapter, you will have hands-on experience creating a messaging app from scratch, organizing and defining the app modules, deciding which dependency injection framework you will use, using Jetpack Navigation to navigate between the app features, and using Jetpack Compose to build the main parts of the user interface.

This chapter is organized into the following topics:

• Defining the app structure and navigation
• Building the main screen
• Building the chats list
• Building the messages list

Technical requirements

Android Studio is the official standard integrated development environment (IDE) for developing Android apps. Although you can use other IDEs, editors, and Android tools if you prefer, all the examples in this book will be based on this IDE.

For that reason, we recommend that you set up your computer with the latest stable version of Android Studio installed. If you haven't already, you can download it here: https://developer.android.com/studio. By following the installation steps, you will be able to install the IDE and set up at least one emulator with one Android SDK installed.

Once installed, we can start creating the project. Android Studio will offer us a set of templates to start with. We will choose the Empty Activity option, as shown in the following screenshot:

Figure 1.1: Android Studio new project template selection with the Empty Activity option selected

You will then be asked to select a project and package name:

Figure 1.2: Android Studio - adding a new project name and package name

After that, you're all set! Android Studio will generate the main folders and files needed so that you can start working on our project. Your project structure should look as follows:

Figure 1.3: Android Studio - project template structure

Note that all the code for this chapter can be found in this book's GitHub repository: https://github.com/PacktPublishing/Thriving-in-Android-Development-using-Kotlin/tree/main/Chapter-1/WhatsPackt.

Now, we are ready to start coding our new messaging app. To do so, we will have to make some important technical decisions: we will have to decide how our project is going to be structured, how we will navigate between the different screens or features, and how we are going to set and provide the components needed (defining and organizing the dependencies between every component).

Defining the app structure and navigation

Before designing the app structure, we must have a basic idea of the features it should include. In our case, we want to have the following:

• A main screen to create new or access already existing conversations
• A list containing all the conversations
• A screen for a single conversation

As this is going to be a production-ready app, we must design its code base while considering that it should be easy to scale and maintain. In that regard, we should use modularization.

Modularization

Modularization is the practice of dividing the code of an application into loosely coupled and self-contained parts, each of which can be compiled and tested in isolation. This technique allows developers to break down large and complex applications into more manageable parts that are easier to maintain.

By modularizing Android applications, modules can be built in parallel, which can significantly improve build time. Additionally, independent modules can be tested separately, which makes it easier to identify and correct errors.

While the most common way to create modules in Android development is by utilizing the Android libraries system via Gradle dependencies, alternative build systems such as Bazel and Buck also facilitate modularization. Bazel provides a robust system for declaring modules and dependencies, and its parallelized building capabilities can lead to even faster build times. Similarly, Buck also supports modular development by providing fine-grained build rules and speeding up incremental builds.

By exploring various build systems, such as Gradle, Bazel, and Buck, developers can find the most suitable modular approach to structure their Android applications. Each build system offers unique features for managing dependencies and organizing code, enabling developers to implement various patterns to achieve a modular architecture.

Among the organizational patterns, the most common ones are modularization by layers and modularization by feature modules.

Modularization by layers

It is common to structure an app by grouping its components based on a set of layers depending on the architecture chosen by the developers. One popular architecture is clean architecture, which splits the code base between the data, domain (or business), and presentation layers.

With this approach, each module focuses on a specific layer of the architecture, such as the presentation layer, domain layer, or data layer. These modules are usually more independent of each other and may have different responsibilities and technologies, depending on the layer they belong to. Following this pattern, our app structure would look like this:

Figure 1.4: App modularization by layers

From this diagram, you can see why layer modularization is also referred to as vertical modularization.

Modularization by feature

When modularizing an app by feature (or using horizontal modularization), the application is divided into modules that focus on specific features or related tasks, such as authentication or navigation. These horizontal modules can share common components and resources. We can see this structure in the following figure:

Figure 1.5: App modularization by feature

In our case, we are going to have a main app module that will depend on every one of the feature modules that our app needs (one for every one of the features we are going to implement). Then, every one of the feature modules will also depend on two other common modules (in this example, we have divided them into common and common_framework, using the first to include framework-independent code, and the second to use code that depends on the Android framework).

One of the main advantages of this pattern is that it can scale with the company if it evolves into a feature-based team (where every team is focused on a single or group of features). This will enable every team to be responsible for one feature module, or a set of feature modules, where they have ownership of the code in those modules. It also allows teams to be easily autonomous regarding their problem space and features.

WhatsPackt modularization

In our WhatsPackt example, we are going to combine both modularization approaches:

• We will use a modularization based on features for our features.
• We will use a modularization based on layers for the common modules. This will allow us to share common code between the feature modules.

The structure of our modules and its dependencies will be as follows:

Figure 1.6: Our app modules structure and dependencies

Now, we are going to start creating this structure in Android Studio. To create a module, follow these steps:

1. Select File | New... | New Module.
2. In the Create New Module dialog, choose the Android Library template.
3. Fill in the Module name, Package name, and Language fields, as shown here:

Figure 1.7: The Create New Module dialog

1. Click Finish.

We will have to do this same process for all the modules we want to build, except for the :app module, which should have been already created when we created the project. This is going to be our main point...