Swiggy is a super app that hosts a range of business lines, including Food Delivery, Instamart, Dineout, Minis, Insanely Good, Mall, and more. Each of these business lines operates on its own distinct technology stack, with React Native being among the frameworks utilized.

There was a sharp increase in the time taken to complete the configuration phase of the build process on adding react native to our app. For configuring the project, it was taking more than 1 minute. Imagine waiting at least 1 minute every time you want to see your changes 😔

To debug, let’s first understand how our app is built by the gradle build system.

The build process of gradle goes through various build phases.

The build phases of gradle are

1. Initialization phase — In this phase Gradle tries to identify all the projects involved in the build process.

2. Configuration phase — During this phase, Gradle executes the build script of each project identified in the previous phase

3. Execution Phase — This is the last phase. During this phase, Gradle identifies the tasks that need to be executed created in the previous phase, and executes them according to their dependency order. All the build work and activities are done in this phase. For example: compiling the app, generating build etc.

Now that we know the phases of the gradle build process, let’s debug this.

To debug, let’s run a gradle scan to see what is taking so much time.
To run a gradle scan, you can execute the below command

./gradlew dependencies --scan

Running this will generate a link to get the details of the tasks that were executed.

By going to the configuration tab ( you can reach it by clicking on performance from the navigation rail and then pressing on the configuration tab), it was observed that the total configuration time for our app was 1 minute and 26 seconds, with 1 minute and 7 seconds (86% of the time) being spent on executing the native_modules.gradle script.

If your react native app has a dependency on react-native-community, then your app will need to apply the native_modules.gradle script. Applying it 1 time can increase the configuration time by around 30 seconds. This was applied two times (one time in settings.gradle and one time in another module), so the increase in time was doubled for us.

After going through the code written in native_modules.gradle, it was observed that 2 node commands are being executed by the script.

1.node -e "try {console.log(require('@react-native-community/cli').bin);} catch (e){console.log(require('react-native/cli').bin;}” — This command resolves the command line path. This command executes very fast.

2. node $cliPath config — This command generates a JSON output which the gradle command uses to generate PackageList.java. Sample output for this command can be found here — gist link

The majority of the configuration time is spent in running the node config command.
To reduce the configuration phase time, we decided to modify the native_module’s gradle script and cache the output of the config command as it is same for every project configuration given that the package.json and its dependencies have not changed.

This is how the existing script works

and this will how the modified native_modules.gradle will work

Explanation

1. We are going to cache the output of the node config command and save the output of it in the node_command_output.json file. We will also save the current package.json in cached_package.json and the current package-lock.json in cached_package-lock.json so that we can compare them later while deciding whether to use cached_output or not.
2. We are replacing the output of the node config command by replacing the result of root.absolutePath with “to_be_replaced_with” so that the output remains the same for any developer working on the project. We will replace “to_be_replaced_with” back to the root.absolutePath when we are going to use the cache.

The modified native_module.gradle script can be downloaded from here — https://gist.github.com/balvinderg/d7b93e329c84ae81eab7936f9c9b8f54

If you are on the latest version of React Native community , you can use this — https://gist.github.com/balvinderg/d6fafbb75c06e4388cf51ac3d1bf41a1

To make sure that all the devs use the same native_modules.gradle script, you can use patch-package.

To add patch-package, you can add patch-package as a devDependencies in package.json and a script to run patch-package when node modules are installed.

{
  "name": "example",
  "private": true,
  "version": "0.0.0",
  "description": "",
  "scripts": { //Add this in your package.json
    "postinstall": "patch-package" //Add this in your package.json
  },
  "devDependencies": { 
    "patch-package": "6.4.7" //Add this in your package.json
  }
}

Now run command

npx patch-package @react-native-community/cli-platform-android

after modifying the native_modules.gradle script.
This will ensure all devs are using the same native_modules.gradle script while running the builds.

Results

After modifying the native_modules.gradle script, our configuration time decreased from 1m 26s to 12s i.e an 86% decrease in configuration time 🚀🚀

Savings Per Day

Average build generation per day in Android team— 55
Average Savings per build — 74 seconds
Total Savings — 55 * 74 = 4070 seconds ~= 1 hour per day

Resources

1. https://www.npmjs.com/package/patch-package
2. https://proandroiddev.com/understanding-gradle-the-build-lifecycle-5118c1da613f

Optimizing Configuration time for Android apps that use React Native was originally published in Swiggy Bytes — Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Part 1 — Creating the Bubble’s Layout

What to Eat?

It’s a question I have found myself pondering a lot of times. Well, I don’t have to anymore. Why?

Introducing Swiggy’s WhatToEat, a feature that enhances the traditional food-ordering journey by adding the crucial element of discovering food through emotions.

Goal

The goal of “WhatToEat” is to help users overcome decision fatigue while ordering food. The feature aims to simplify the decision-making process by allowing users to indicate their current mood or specific cuisine preferences through bubbles.

In this multi-part series, I will explain how we used Jetpack Compose to create the WhatToEat feature.

• In the part 1 of our series, we’ll focus on recreating the eye-catching bubble layout that you see in this feature.
• In the next part of the series, I will explain how we animated each of the bubbles.

Creating the Bubble’s Layout

1. The layout consists of a list of bubbles.
2. The bubbles are following a 1–2–1–2–1… and so on pattern.
3. Every bubble’s position is randomly moved in both horizontal (X) and vertical (Y) directions.

Our bubble’s UI is very simple. Its just a image with text underneath it.
In compose, this is how we implemented it.

@Composable
fun Bubble(imageUrl: String,
           subtitle: String,
           modifier: Modifier = Modifier,
           contentDescription: String? = null) {
    Column(modifier) {
        AsyncImage(model = imageUrl, contentDescription = contentDescription)
        Text(text = subtitle)
    }
}

Now let’s focus on creating the 1–2–1 pattern.
A naive approach to build this would be to create this layout using column with multiple rows inside it. For eg

@Composable
fun NaiveLayout(bubbles: List<Bubble>){
    Column(modifier = Modifier.fillMaxWidth().padding(top = 86.dp)) {
        Row(modifier = Modifier.fillMaxWidth(),
            horizontalArrangement = Arrangement.Center) {
           Bubble()
        }
        Row(modifier = Modifier.fillMaxWidth(),
            horizontalArrangement = Arrangement.SpaceAround) {
            Bubble()
            Bubble()
        }
        Row(modifier = Modifier.fillMaxWidth(),
            horizontalArrangement = Arrangement.Center) {
            Bubble()
        }
        Row(modifier = Modifier.fillMaxWidth(),
            horizontalArrangement = Arrangement.SpaceAround) {
            Bubble()
            Bubble()
        } 
        ... and so on
    }
}

Why is this approach naive?

1. This layout will not scale if we decide to add more patterns. We will need to add new layouts for each pattern.
2. This layout does not support animating the bubbles individually.
3. The columns and rows approach is too restrictive. We are dependent on the arrangment property for the bubble’s position. We cannot place the bubble anywhere.
4. Earlier we saw that each bubble was randomly moved in the X and Y direction. We cannot do this in this approach (We can do it by using translationY and padding but i feel like that would just be a hackish way to do this).

So what will be a better approach to make this?

The answer is Custom Layout.

Custom layout gives us the capability to control each composable’s position on a pixel level and is also very simple to use.

To create a custom layout, compose has a composable called Layout.

Layout composable accepts a list of composable and a measurePolicy(this is a way to measure and position the composables).

Before going to the layout’s code, let’s create an interface for placing the bubbles.
The interface will have 2 methods

1. place — This method will return us the x and y coordinates for the bubble at position index.
2. getLayoutHeight — This will accept the number of bubbles, the bubble’s height and return us the total height the bubbles will take.

interface BubblePlacer{

    /** This function calculates the x and y poisiton for the bubble at any index.
     *  [maxWidth] and [widthOfBubble] is used to help decide the x position of the bubble
     *  [density] is used to convert dp to px
     *  [heightOfBubble] is used to calculate the y position
     *  [topPadding] is the padding from top of the screen
     */
    fun place(
        index: Int,
        maxWidth: Int,
        heightOfBubble: Int,
        widthOfBubble: Int,
        topPadding: Int,
        density: Float
    ): IntOffset // this has getters for getting the x and y position.

    /** This function is used to calculate the height of the layout.
     *  [heightOfBubble] and [numberOfBubbles] is used to calculate the y position
     *  [topPadding] is the padding from top of the screen
     */
    fun getLayoutHeight(
        numberOfBubbles: Int,
        heightOfBubble: Int,
        topPadding: Int,
        density: Float
    ): Int
}

• You can see the implementation here for the 1–2-1 bubble pattern: https://shorturl.at/akS46
• Detailed Explanation for the same can be found at https://shorturl.at/rAHX1

Now that we have that capability to get the x and y position for each bubble and also the total height of the bubbles, we just have to use them in our custom layout.

@Composable
fun BubbleLayout(bubblePlacer: BubblePlacer, bubbles: List<Bubble>, topPadding: Int, modifier: Modifier = Modifier) {
    Layout(modifier = modifier, content = {
        repeat(bubbles.size) {

            Bubble(
                imageUrl = bubbles[it].imageUrl,
                subtitle = bubbles[it].title,
            )

        }
    }) { measurables, constraints ->
        val bubbles = measurables.map {
            it.measure(constraints)
        }
        val topPaddingPx = (topPadding * density).roundToInt()
        val bubbleHeight =
            bubbles[0].height // use the first bubble's height for reference to calculate layout height
        val layoutHeight = bubblePlacer.getLayoutHeight(
            bubbles.size,
            bubbleHeight,
            topPaddingPx,
            density,
        ) // calculate the layout height
        layout(constraints.maxWidth, layoutHeight) { 
            bubbles.forEachIndexed { index, bubble ->
                val position = bubblePlacer.place(
                    index,
                    constraints.maxWidth,
                    bubbleHeight,
                    bubbles[index].width,
                    topPadding = topPaddingPx,
                    density
                ) // find the position
                bubble.place(position.x, position.y) // place it

            }
        }
    }

and we are done.

Creating an interface for placing the bubbles and calculating the layout’s height offers us several advantages:

1. Separation of UI and Logic: The interface encourages a clear separation between the user interface and the underlying logic. This separation enhances maintainability and allows for the development of reusable layout-related components.
2. Scalability: The interface makes it possible to add new bubble patterns in the future without affecting the UI Part of code. For example we have if we want to implement a 2–1–2 pattern, we will just need to a create a new bubble placer and pass it to our custom layout.

Final Product 🚀

Credits — Arun Sharma Raj Gohil Thank you for helping and guiding while working on this project.

Resources

https://developer.android.com/jetpack/compose/layouts/custom

Building the WhatToEat Experience on Android was originally published in Swiggy Bytes — Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.