Git hooks are scripts that automatically run on a particular git event. These git events could be committing a change, checking out a branch or performing a rebase. Hence, making them an important mechanism to enhancing automation and removing tedious manual work that are prone to human error. In this blog post, we will explore three custom git hook implementations that can be added to an Android project that will not only enhance developer productivity but also increase automation throughout the development workflow. I highly encourage you to explore and customize these git hooks to match your needs.

Git hooks are files that are named in a certain way for git to start using them in the git workflow. To get started, create a .githooks folder in the root of the project. Then create the separate files for the desired git hook you wish to use. For example, if you want to run a command prior to a commit, you can create a file named pre-commit in the .githooks folder, which will contain the implementation on what needs to be executed. Then whenever a commit is being made, the pre-commit hook will run the script and create the commit only if the script has passed. In this blog post, we will create three files named pre-commit, commit-msg and post-commit respectively. Since we are adding them to the .githooks folder, we can push these to the remote source control repository to share them with the team.

Once the .githooks folder is created with all three git hook files, ensure that they have the permission to be executed. The next step is to configure the hooksPath to allow git to target this folder when running the git hooks for the repository. Open the terminal and navigate to the root of the project, then execute the following command shown in step 2.

Step 1 - Create the folder and files

.githooks/
  - pre-commit
  - commit-msg
  - post-commit

Step 2 - Configure git to use this folder

git config core.hooksPath .githooks

Pre-commit

The pre-commit is a git hook that gets executed prior to a commit. Once the changes have been added and a git message is provided, git will execute the pre-commit script. If the script has finished successfully, then it would proceed to making the commit. However, if the script has failed, the commit would not be created. This is extremely useful if you wish to perform additional verification on the changes prior to creating a commit on your local machine.

From prior experience, the lint task is usually the step that often fails a pipeline. Whether it is a code formatting issue or an unused import that has been added, it can be quite annoying to wait for the CI pipeline to finish to indicate whether the pull request has any lint issues. Rather than relying on the lint check on the CI pipeline, which can take a lot of resources and long time to process, the lint check can be executed on the local machine using the pre-commit hook. If no lint issues are present in the new changes, it will proceed with the commit. Or else, it will alert the developer that lint issues are present and the fix is required before a commit can be created. This will significantly reduce the feedback loop from minutes to just seconds. To run the link check in your pre-commit hook, check out the code below in step 3.

Note: pre-commit hooks can be used for anything, so feel free to use a different linter, such as ktlint or detekt, or perform a different task such as building the app or running unit tests. However, the pre-commit checks should be a quick and small task since they are expected to be executed every time a commit has been made.

Step 3 - Create a pre-commit file and add the lint check

#!/bin/sh
#
# An example hook script to verify that the changes do not contain
# any lint issues. The hook will prevent a commit to be made if the
# status of the lint task is a non-zero result.
# To enable this hook, the file has to be named "pre-commit".

# Run Android Lint
./gradlew lintDebug
status=$?

# Display messaging based on the result
if [ $status -eq 0 ]; then
  echo "======================================================="
  echo "Pre-commit check passed. Changes will now be committed."
  echo "======================================================="
else
  echo "======================================================="
  echo "Pre-commit check failed. Changes include lint issues."
  echo "======================================================="
fi
exit $status

Commit-msg

The commit-msg hook is a git hook that executes a script whenever a commit message has been entered. The script is provided the path of a temporary file that contains the proposed git message. This is the perfect place to validate the commit message. If the git commit does not the meet the standard set by the team, the commit-msg could fail the script and prevent the commit to be made. This is a great and easy way to align the team to use a specific git commit structure.

An example of a commit-msg hook could be to examine the commit message that is going to be added and determine if it includes vital information, such as the corresponding ticket number. Since most teams use some sort of project management tool, such as Jira, all tasks need to be associated with a ticket number. This can be a useful technique for debugging which commits belong to which tasks when parsing the develop or main branch. Ideally, not much work should be included in this git hook apart from checking the git commit (consider using post-commit instead). The code in step 4 shows an example of a commit-msg hook that parses the commit message and validate if it starts with a ticket number.

Step 4- Create a commit-msg file and add the check

#!/bin/sh
#
# An example hook script to check the commit log message.
# Called by "git commit" with one argument, the name of the file
# that has the commit message.  The hook should exit with non-zero
# status after issuing an appropriate message if it wants to stop the
# commit.
# To enable this hook, rename this file to "commit-msg".

commit_msg=$(cat $1)

# Check if commit message starts with DROID. Replace with your ticket name.
if [[ $commit_msg == DROID-* ]]; then
  echo "======================================================="
  echo "Commit-msg check passed. Changes will now be committed."
  echo "======================================================="
  exit 0
else
  echo "======================================================="
  echo "Commit-msg check failed. Commits must start with DROID-"
  echo "======================================================="
  exit 1
fi

Post-commit

The post-commit hook is a git hook that executes a script after the commit has been created. The status of the hook, unlike the previous hooks, have no impact on the commit itself. It is ideally used in scenarios to notify or perform additional tasks after the commit has successfully been created. Example of this could be capturing the commit log statement from the previously created commit, building an app for distribution or notifying various stakeholders through some communication channel.

The example of the post-commit hook in this blog post is to build a release APK once a commit has been made on the release branch. These commits are usually updating the build version and name. Once the developer has updated the version and starts to make the release, they would often push the update to their CI/CD pipeline. In parallel, the post-commit hook could generate a release APK that can be distributed internally or stored in a specific directory on the local machine. However, automatic distribution to Firebase App Distribution or Google Play Console should be done on the CI/CD pipeline as it is more efficient and secure. The code in step 5 shows an example of a post-commit hook creating a release APK when a commit is made on a release branch.

Step 5 - Create a post-commit file and add the check

#!/bin/sh
#
# An example hook script to perform additional tasks during the
# post-commit flow. In this case, it creates a release APK if
# the commit has been made on the release branch.
# Status of this script does not impact the commit.
# To enable this hook, rename this file to "post-commit".

branch_name=$(git symbolic-ref --short -q HEAD)

if [[ $branch_name == release* ]]; then
  echo "======================================================="
  echo "Performing post-commit hook. Building release APK..."
  ./gradlew assembleRelease
  echo "======================================================="
else
  echo "==========================================================="
  echo "Committing on a non-release branch, skipping post-commit..."
  echo "==========================================================="
fi

Conclusion

Git hooks are a powerful tool to enhance automation within the codebase. Developers spend a lot of time performing manual tedious tasks that take them away from problem solving or adding any value to the business. With git hooks, some of the tasks can be done more quickly and efficiently on the local machine to boost developer productivity. Best of all, these hooks can be shared with the team which can help create a standard of practice when developing and maintaining an Android project.

Till next time, keep automating!

A few months ago, Jetpack Compose was promoted to beta allowing everyone to get a glimpse of what the future state of Android development could look like. Following this announcement, a new Android Developer Challenge was launched to promote the new framework through a series of four challenges with a chance to win exciting prizes. Since the announcement was a great interest to me, I took part in the challenge to learn more about the upcoming framework. In this blog post, I'll share my initial experience with Jetpack Compose.

Jetpack Compose

Jetpack Compose is a new declarative user-interface (UI) framework within the Android ecosystem to help create beautiful UI with less code. As opposed to the traditional imperative UI development where the user-facing views are created in a tree-like structure of widgets through the inflation of an XML layout file, Jetpack Compose provides Kotlin APIs to create composable functions that emit the UI in a declarative manner. In a sense, the views are initially created in the composition stage and only then the necessary changes are applied whenever the state has changed. Similar to SwiftUI, the core programming language is responsible for creating the UI which favours both the ease of use as well as the notion of reusability when it comes to development.

What Surprised Me

There were a few things that surprised me when I started working on the Android Developer Challenge. The first one was working with the preview mode where I could visually see the changes as soon as I applied them. This could drastically reduce the development time as I would no longer have to re-run my application on a device. In addition to that, working with Jetpack Compose felt very similar to Flutter. Both frameworks share the same look-and-feel when it comes to how the UI is so easily presented in the source code. Finally, Jetpack Compose is supported by a wide range of Jetpack libraries that have the corresponding Compose dependency, such as Jetpack Navigation for Compose. This will make it easier for Android projects to integrate the new framework without much effort. If a project is following an architecture pattern that separates the UI from the business logic layer, then Jetpack Compose can replace the Activity or Fragment source code with Composable functions that will handle the UI and state, without impacting the business logic.

Challenge 1 - Thinking in Compose

In the first challenge, the task was to create a puppy adoption application with two screens. The first screen will showcase a list of all the puppies followed by the puppy's detail on the second screen. The challenge focused on the basics of Jetpack Compose and the building blocks of creating UI from the Kotlin APIs. Views, such as Text, are added in the Composable function annotated by the Composable tag. This tells the framework that this function takes data as input and emits UI elements.

Jetpack Compose takes a series of Composable functions and draws them during the composition stage with some initial data. If the state has changed at some point, the changed composable function is executed again with new data which is then redrawn. Jetpack Compose automatically handles this process of recomposition very efficiently and only updates the view that have changed since last redraw.

Source code of the first challenge.

Challenge 2 - Managing State

In the second challenge, the task was to create a countdown timer application using state in Jetpack Compose. A state is any piece of information that can change at any time. Since the view can be recomposed multiple times at any given time, the remember keyword binds the state to the local storage allowing it to survive the recomposition. In addition, the observeAsState keyword adds a LiveData on an object and observes when the object has changed.

The timer application made use of state, remember and observeAsState in its implementation. The state kept track of whether the app was in a countdown mode or whether the user has yet to start the timer. Based on this, the specific UI was shown to the user. When the timer had started, the viewmodel was responsible for launching the thread that would count down and update the object that the LiveData was bound to. Whenever the time value changed, the UI would redraw the Text view that held the timer value.

Source code of the second challenge.

Closing Remarks

Working with Jetpack Compose is quite different from traditional UI development for Android. There are a lot of new keywords and principles added when working with the new declarative framework. It could be a learning curve, but I am excited to see what the future holds for modern Android development. In the meantime, I got to enjoy a cool prize from the Android Developer Challenge.

Building software at scale requires a team of developers that are continuously modifying the codebase in parallel. These modifications can range from feature development, bug fixes or optimizations. When building at scale, it is essential to have a continuous integration (CI) pipeline that automates the flow of validating new changes to ensure that no errors or undesired side-effects are introduced. With the combination of automated CI pipeline and code review, we get a workflow that allows teams to be agile and flexible in the development of a software product.

Setting the stage: Most development teams follow a Gitflow workflow, a process that standardizes the branching model around the release process. All new development changes are branched off as features branches from the develop branch and gets merged only once if it has passed the CI pipeline and code review. This is also the main entry-point where new changes are being introduced so it is essential to catch issues with the codebase earlier in the process. Branches such as main, hotfix and release are used when dealing with releases.

Building for Android: The development cycle for Android is not any different. If teams are following the Gitflow workflow, they will require a CI pipeline that will automatically validate the changes through the Gradle build system. These validation can range from analyzing the correctness of the source code written in Java or Kotlin as well as the resource and dependency management within the Android framework. In the following sections, we will explore how we can build a CI pipeline that can help us validate new changes specifically for Android.

CI Pipeline

At minimum, the CI pipeline for Android requires a 3-step validation that will help validate the stability and correction of the application. The pipeline is split into stages to provide early feedback whenever an issue is discovered.

Compile and Build

The first step of validation is to ensure that the project can compile and build on the CI pipeline when new code is introduced. Without a CI pipeline, it would be pretty annoying to track down a change that broke the project for the entire team. While the project is compiling and building, Gradle is also being synced to ensure the build configurations are correct and able to download the required project dependencies. The build system will also package and generate the build artifact (APK or AAB). All of these operations are signs of validation that no errors are being introduced into the codebase.

What issues are we trying to catch?

• Syntax errors or invalid build configurations
• Incorrect management of project dependencies
• Errors that prevent the creation of the build artifact

Lint

After validating that the project can be compiled and built, the second step of validation is to ensure that the codebase does not have any structural issues. Issues within the Kotlin codebase can lead to performance or reliability issues. A static code analysis tool can catch issues with formatting, complexity, exception handling, multithreading and much more. With the introduction of this tool, projects will adhere to a code quality standard throughout the development flow. Some static code analysis tools for Android projects are:

• Detekt (Kotlin)
• Ktlint (Kotlin)
• Android Lint (Android framework)

What issues are we trying to catch?

• Catching any static code analysis issues in our Kotlin codebase
• Catching any issues in our implementation within the Android framework regarding accessibility, usability and performance

Tests

Despite validating that the project can be built and does not contain any static code analysis issues, it is not enough to ensure that the actual implementation is correct. The third step of validation is ensuring that implementation behaves as it should when the application is being used by the user. In this stage, we will require tests that validate the correctness of our business logic as well as the UI layout. The testing for Android projects can be broken down to unit tests that validate pure Kotlin code and instrumented tests running on an Android device that validate the UI or any logic that requires the Android SDK. The validation requires the execution of the entire test suite.

What issues are we trying to catch?

• New logic behaves as it should
• New changes did not introduce any errors or undesired side-effect in other parts of the codebase

Conclusion

The CI process helps us validate new changes through an automated and repetitive process granting us the confidence that nothing will break. If errors are found in this process, developers can quickly resolve without impacting the customer experience. Validating an Android project requires the analysis and testing of various areas of focus independently. Only when we merge all of these validation stages into a single pipeline, the decision regarding the stability of the application can be made. In the efforts to remain agile and flexible, the CI pipeline needs to be growing side-by-side with development such that it can perform fast and reliable analysis and validation for future development work.