In the build.gradle.kts file of your plugin project, you need to specify the dependencies required for the plugin to work properly, along with some basic configurations. Here’s an example setup for your plugin:

Gradle Plugin Implementation

To achieve our goal of automating the generation of files from Figma for Jetpack Compose using a gradle plugin, we need to follow these steps:

• analyze the structure of DSM tokens and prepare corresponding models
• find all possible flavors that contain tokens describing each client’s design in the project
• somehow analyze this data and learn to generate the necessary files
• make it convenient and wrap it in gradle tasks
• …
• write code!

As we can see, the file contains color descriptions, which can be cascaded and composed of multiple logical levels, where the last one contains the information we are interested in. Typically, resources have a similar structure, where their type and value are specified.

{
  "color": {
    "m3": {
      "white": {
        "description": "",
        "type": "color",
        "value": "#ffffffff",
        "blendMode": "normal"
      },
      "black": {...},
      "sys": {
        "light": {...},
        "dark": {...}
      },
      "ref": {...},
      "key-colors": {...},
      "source": {...},
      "surfaces": {...},
      "state-layers": {...}
    }
  },
  "font": {...},
  "typography": {...}
}

Regarding color, we are interested in its value, so the corresponding class will contain its hexadecimal representation.

Gradle tasks

During the task registration, we need to set all the fields marked by annotations, namely — the path to the JSON file, the path to the folder of our flavor, and the final package of the generated file.

For easing our lives, we’ll hardcode some things, but if more flexibility is needed, it’s worth looking into gradle extensions.

Since this task is abstract, some configurations are left to the implementation. Therefore, the structure for the task that will generate a file with colors will look like this:

To make our tasks runnable, we need to register them in the project.

Firstly, using the plugin, we need to determine what build variants exist in the project and register a task for each type.

Now, let’s get to the most interesting part — how file generation actually happens.

For this, we need to use a tool called KotlinPoet. It allows us to easily create the files we need. The entire mechanism consists of various builders, with which we add file types, their properties, values, and so on.

The essence of our task lies in parsing JSON, obtaining the necessary data, and writing it to the corresponding files.

Since we’re familiar with the structure of the JSON file, we can write a function that will iterate through it and collect the data. In the end, it will be a map with keys as field names and values as models.

Once we have the list of all fields, we use KotlinPoet to describe what we want to create in the file, which will contain an object with the fields that were read. As a result, we should have files that look like this:

If needed, we can directly use styles and colors.

And that’s it! Our initial task is complete. Now we have the ability to upload the file to the project, run the task, and get the files that can be used in development. What used to be done manually and could contain errors due to human factors now works smoothly and doesn’t require additional dependencies (the previous Android and current iOS solutions required installing a ton of Node.js modules to run a script that didn’t fully accomplish its tasks and still requires developer intervention).

Non-obvious challenges

Developing a plugin is half the battle; there will always be something that goes wrong:

• due to the complexity of the project, the designers didn’t use Material Design properly and created dozens, if not hundreds, of custom-named colors and styles; as a result, using the standard MaterialTheme was not possible, and our plugin generated custom ColorScheme and Typography classes
• a considerable amount of time was spent on initial development and migration; however, if you have a clean Material setup and don’t need to spend hours resolving token naming issues with designers, this shouldn’t be a problem
• all @Preview annotations must be wrapped in our custom theme
• designs themselves can be a problem; one of the clients had a button with a gradient, although a color should have been used for this token; this was elegantly resolved with a workaround solution, but we strongly urged designers not to allow such conflicts in the future
• configuration complexity — while the process itself is straightforward, issues like the previous one may require significant changes to the plugin’s logic or model structure

That’s all. Share in the comments if you’ve built similar solutions or if you know how to avoid writing a custom theme every time for previewing. If anyone needs the code, the entire project is available here.

This article is previously published on proandroiddev.com