Dhis2 Mobile UI library documentation, installation and usage is explained in DHIS2 Developer portal

The Compose Compiler plugin can generate reports / metrics around certain compose-specific concepts that can be useful to understand what is happening with some of your compose code at a fine-grained level. You can read more about it here.

To generate the reports / metrics, run the following Gradle command

./gradlew assembleDebug -PenableComposeCompilerReports=true

This would generate the output at <module>/build/compose_metrics

We are using Paparazzi for screenshot testing.

class InputChipSnapshotTest {

  @get:Rule
  val paparazzi = paparazzi()

  @Test
  fun launchChip() {
    paparazzi.snapshot {
      ColumnComponentContainer {
        InputChip(label = "Label", selected = false, badge = "3")
        InputChip(label = "Label", selected = true, badge = "3")
      }
    }
  }
}

./gradlew designsystem:testDebugUnitTest

Runs tests and generates an HTML report at /build/reports/paparazzi/ showing all test runs and snapshots.

./gradlew designsystem:verifyPaparazziDebug

Runs screenshot tests and verifies them against committed golden images. Failures generate diffs at /build/paparazzi/failures.

Golden images are generated and committed by GitHub Actions, not locally.

1. Push your screenshot test changes your working a branch.
2. Run the Generate Paparazzi Golden Images workflow from the Actions tab in GitHub.
3. If verification fails, the workflow records new images, re-runs verification, and commits the updated snapshots to the same branch.
4. Re-run CI (or ./gradlew designsystem:verifyPaparazziDebug locally) to confirm everything is green.

If you cannot trigger workflows on the upstream repository, run the workflow on your fork branch and include the generated snapshot commit in your pull request.

The Mobile UI documentation is integrated in the developer portal. It uses Docusaurus, a modern tool to build documentation pages.

The documentation is written in Markdown. The sidebar is automatically generated based on the metadata of the different files. It follows the rules explained in the autogenerated sidebar docs. In short, every file must have a sidebar_position label at the beginning of the document, which defines the position of the document relative to its folder. Then, each folder has a _category_.yml file, which has a position property defining the position of that folder relative to its parent folder.

It is possible to nest as many folders as desired following that pattern.

It is possible to build the Developers portal documentation to test your changes.

Steps to test:

1. Do the changes in the Mobile UI docs and push them to a branch in github.
2. Download the Deverlopers portal repository.
3. Change the branch in the Mobile UI block in the file docs-migrate.js to point to your branch.
4. Follow the instructions in CONTRIBUTING to build the docs.