Jetpack Compose promotes a declarative way of building user interfaces: the UI is a direct representation of the current state.

However, when dealing with dialogs, alerts, or pop-ins, many Android developers still rely on event-based patterns that do not fully align with Compose’s philosophy.

In this article, we will explore a state-driven approach to managing conditional dialogs in Jetpack Compose, using simple and generic examples.

The Common Pitfall: Treating Dialogs as Events

A common implementation looks like this:

• The ViewModel emits a “show dialog” event

• The UI listens and displays the dialog once

This is often implemented using:

• SingleLiveEvent

• SharedFlow

• Channel

While this works, it introduces several drawbacks:

• Events can be lost during configuration changes

• Dialogs may reappear unexpectedly after recomposition

• The UI becomes harder to test

• Business rules leak into Composables

With Compose, where recomposition is frequent and intentional, these issues become more noticeable.

Rethinking Dialogs as State

Instead of asking:

“When should I show this dialog?”

We should ask:

“In which UI state should this dialog be visible?”

If the dialog is visible, it should be explicitly represented in the UI state.

This simple mindset shift leads to cleaner and more predictable code.

Defining the UI State

Let’s start with a simple screen where a user completes a profile.

In some cases, we want to display a warning dialog if certain conditions are met.

data class ProfileUiState(
  val user: UserUiModel?,
  val warning: WarningUiModel?,
  val isLoading: Boolean = false
)

Here:

• warning == null → no dialog
• warning != null → dialog is displayed

Modeling Dialog Content

We model dialog content using a sealed interface:

sealed interface WarningUiModel {
  val title: String
  val message: String


  data class MissingEmail(
    override val title: String,
    override val message: String
  ) : WarningUiModel


  data class IncompleteProfile(
    override val title: String,
    override val message: String
  ) : WarningUiModel

}

This makes the UI expressive and type-safe, while keeping business logic out of the Composable.

Showing the Dialog in Compose

In the Composable, we simply react to the state:

@Composable
fun ProfileScreen(
  uiState: ProfileUiState,
  onConfirmWarning: () -> Unit
) {

  uiState.warning?.let { warning ->
    AlertDialog(
      onDismissRequest = {},
      title = { Text(warning.title) },
      text = { Text(warning.message) },
      confirmButton = {
        TextButton(onClick = onConfirmWarning) {
          Text("OK")
        }
      }
    )
  }
  
  // Rest of the screen content

}

There is:

• No event observer

• No side effect

• No manual dialog control

The UI simply reflects the current state.

Selecting the Appropriate Warning in the ViewModel

The ViewModel decides which warning should be shown, based on domain rules.

private fun selectWarning(user: UserUiModel): WarningUiModel? {
  return when {
    user.email.isNullOrBlank() ->
      WarningUiModel.MissingEmail(
        title = "Missing information",
        message = "Please add an email address to continue."
      )
    
    !user.isProfileComplete ->
      WarningUiModel.IncompleteProfile(
        title = "Profile incomplete",
        message = "Some required fields are still missing."
      )
    
    else -> null
  }
}

Only one warning is exposed at a time, keeping the UI logic simple.

Consuming the Warning

When the user confirms the dialog, the ViewModel updates the state:

fun onWarningConfirmed() {
  _uiState.update { currentState ->
    currentState.copy(warning = null)
  }
}

As soon as warning becomes null, the dialog disappears automatically.

Why This Pattern Works Well

This approach offers several advantages:

• Dialog visibility is explicit and deterministic
• No lost or duplicated events
• Easier ViewModel unit testing
• Cleaner Composables
• Business logic stays in the ViewModel

Most importantly, it embraces Compose’s declarative nature.

When Are Events Still Useful?

Event-based approaches are still relevant for:

• Navigation actions

• Snackbars and toasts

• Analytics or logging side effects

But for dialogs that represent business rules or user decisions, modeling them as state is often the better choice.

Conclusion

In Jetpack Compose, dialogs do not need to be treated as special cases.

By modeling them as part of the UI state, we gain clarity, predictability, and robustness.

This state-driven approach scales well as applications grow and helps teams maintain a clean separation between UI and business logic.

If you are building Compose screens today, this pattern is well worth considering.

Stop Treating Dialogs as Events: A State-Driven Approach in Jetpack Compose was originally published in Bforbank Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Randomness is everywhere in modern software – from the shuffle button in your music player to the dice rolls in your favorite video game. But have you ever wondered what’s really happening when you call Math.random() or use a random function in your code? The truth is, these «random» numbers are anything but random. They’re the product of sophisticated mathematical algorithms that create the illusion of randomness. Let’s dive into the fascinating world of pseudorandom number generators and uncover the mathematics that powers modern computing.

The Mathematical Foundation: Probability Theory Meets Computation

At its core, random number generation in computers is built on probability theory. In mathematics, we define probability through the concept of a probability space, which consists of three components: a sample space (all possible outcomes), a set of events (subsets of outcomes), and a probability measure that assigns likelihoods to events.

However, computers are deterministic machines – they follow precise instructions and produce predictable outputs. This creates an interesting paradox: how can a deterministic system produce random behavior? The answer lies in PseudoRandom Number Generators (PRNGs), which use deterministic algorithms to produce sequences that appear random for practical purposes.

The foundation of computational randomness rests on the concept of uniform distribution. A truly uniform random variable has the property that any value within its range is equally likely. For continuous variables, this means the probability density function is flat across the interval [0,1). For discrete variables, each possible outcome has equal probability.

The Algorithms Behind the Magic

Linear Congruential Generator (LCG): The Simple Workhorse

The most fundamental random number algorithm is the Linear Congruential Generator, which follows a beautifully simple mathematical formula:

Xᵢ₊₁ = (a × Xᵢ + c) mod m

Where:

• Xᵢ is the current random number
• a is the multiplier (0 < a < m)
• c is the increment (0 ≤ c < m)
• m is the modulus (m > 0)
• X₀ is the seed value

This algorithm works by performing modular arithmetic on a linear transformation of the previous value. The choice of parameters is crucial: poor choices can lead to short periods and obvious patterns, while good choices can create sequences that appear quite random.

For example, with parameters a=3, c=3, m=7, and seed X₀=5, we get the sequence: 5, 4, 1, 6, 0, 3, 5, 4, 1, 6… Notice how it eventually repeats – this is characteristic of all pseudorandom generators.

Mersenne Twister: The Modern Standard

Most modern programming languages use a more sophisticated algorithm called the Mersenne Twister. Developed in 1997 by Makoto Matsumoto and Takuji Nishimura, this algorithm provides several advantages over simpler LCGs:

• Incredibly long period: 2¹⁹⁹³⁷ – 1 (a Mersenne prime)
• High-dimensional equidistribution: uniform in 623 dimensions
• Efficient implementation: uses bitwise operations for speed

The Mersenne Twister works with a state array of 624 32-bit integers. It uses complex bit manipulation operations including shifts, XORs, and masks to transform the internal state and produce random numbers. The algorithm’s name comes from its period length being a Mersenne prime.

The generation process involves several steps:

1. Twisting: Transforming the state array using bitwise operations
2. Tempering: Applying additional transformations to improve randomness
3. Output: Producing the final random number

Cryptographically Secure PRNGs: When Security Matters

For applications requiring security, such as cryptography, standard PRNGs are insufficient because they’re predictable if you know the algorithm and internal state.

Cryptographically Secure PRNGs (CSPRNGs) address this by providing two crucial properties:

1. Next-bit test: Given any sequence of bits, there’s no polynomial-time algorithm that can predict the next bit with probability significantly greater than 50%
2. State compromise extension: Even if an attacker learns the internal state, they cannot determine previous outputs
3. CSPRNGs typically use cryptographic hash functions or block ciphers to mix entropy and produce unpredictable outputs. They gather entropy from various system sources like mouse movements, keyboard timing, and disk I/O patterns.

The Critical Role of Seeds

Every pseudorandom generator needs a starting point called a seed. The seed value is crucial because:

• Deterministic behavior: The same seed produces the same sequence
• Reproducibility: Enables debugging and scientific reproducibility
• Security implications: Predictable seeds compromise security

Good seed selection involves:

• Uniqueness: Avoiding reuse across different instances
• Randomness: Ensuring no patterns or correlations
• Adequate size: Matching the PRNG’s state size

Common seed sources include system time, hardware random number generators, user input timing, and environmental noise. For cryptographic applications, seeds must be truly unpredictable.

Real-World Applications

Random number generation powers countless applications across industries:

Security and Cryptography

• Key generation: Creating secure encryption keys
• Token generation: Producing session tokens and CSRF protection
• Password generation: Creating strong, random passwords
• Digital signatures: Ensuring uniqueness in cryptographic operations

Gaming and Entertainment

• Procedural content generation: Creating infinite worlds in games like Minecraft
• AI behavior: Making NPCs unpredictable and interesting
• Loot systems: Determining item drops and rarity
• Card shuffling: Ensuring fair play in digital card games

Scientific Computing

• Monte Carlo simulations: Modeling complex systems in physics, finance, and engineering
• Statistical sampling: Drawing representative samples from populations
• Optimization algorithms: Stochastic optimization and genetic algorithms
• Machine learning: Random initialization of neural networks, data shuffling

Simulation and Modeling

• Weather prediction: Ensemble forecasting methods
• Financial modeling: Risk assessment and option pricing
• Traffic simulation: Urban planning and optimization
• Queueing theory: Network and service optimization

The Future of Randomness

As computing evolves, so does random number generation. Emerging trends include:

• Quantum random number generators: Using quantum phenomena for true randomness
• Hardware-based generators: Physical and Environnemental Entropy Sources for high-quality randomness (a video worth watching: The Lava Lamps That Help Keep The Internet Secure)
• Parallel generators: Algorithms optimized for multi-core and GPU environments
• Machine learning approaches: Using neural networks to improve randomness quality

Conclusion

Random number generation represents a beautiful intersection of mathematics, computer science, and practical engineering. While the numbers aren’t truly random, the sophisticated algorithms behind them serve our needs remarkably well. Understanding these algorithms helps us make better choices about which generators to use, how to seed them properly, and what limitations to consider.

Whether you’re securing sensitive data, building a game or conducting scientific research, the humble random function is working behind the scenes, creating the illusion of chaos from mathematical order. The next time you call Math.random() or use a random function, remember: you’re not just getting a random number – you’re benefiting from decades of mathematical research and engineering refinement.

The mathematics of randomness reminds us that sometimes, the most useful solutions come from embracing the tension between what we want (true randomness) and what we can actually achieve (pseudo-randomness). In this gap between ideal and reality, we find practical tools that power modern computing.

Bonus

Different programming languages implement random number generation with varying approaches:

• Python: Uses the Mersenne Twister as its default generator, accessible through the random module. Provides both simple functions and a class-based interface.
• Java: Offers multiple generators including Random (LCG-based) and SecureRandom (CSPRNG). The newer SplittableRandom provides better performance for parallel applications.
• C++: Prior to C++11, only provided a basic rand() function. Modern C++ includes a comprehensive <random> header with multiple engines and distributions.
• JavaScript: Provides Math.random() which returns values in [0,1). The implementation varies by browser but typically uses high-quality algorithms.

The Hidden Mathematics of Randomness: Demystifying Random Functions in Programming was originally published in Bforbank Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Well, none of us wants to see our software crash in production after delivering a new feature to one component or service. In today’s complex software landscape, ensuring that components of a system interact seamlessly is crucial for delivering high-quality applications. Integration testing plays a vital role in validating these interactions, preventing costly defects that can arise from unexpected behaviors or misconfigurations.

Integration Testing

It is a type of testing where software components are incrementally integrated and then tested. The main goal is to guarantee, for each use case, that your application behave as expected and satisfies the intended criteria by testing the interactions between components or services.

Why Integration Testing matters ?

• Early detection of defects
  Identify issues at an earlier stage of development, reducing the cost and time required for remediation.
• Improved system stability
  By verifying that components work together as expected and ensuring the overall stability and reliability of the system after delivering new features.
• Enhanced collaboration and documentation
  It fosters collaboration among development teams by providing a shared understanding of how components interact and illustrating different scenarios.

Challenges of manual Integrating testing

Executing integration tests manually is really Time-consuming. Manually testing all possible interactions with a certain component may take a lot of time and can be extremely error-prone which can lead to inconsistent results and missed scenarios. Furthermore, as the system grows in complexity, maintaining manual test cases becomes increasingly challenging.

The power of Automation

To overcome those challenges, of manually testing, automation is essential. The idea behind this concept is to integrate the execution of a set of tests while delivering new features. This was, we can:

• Improve efficiency: Reduce the time and effort required for testing.
• Ensure consistency: Guarantee that tests are executed the same way every time for each pre-defined use case.
• Increase test coverage: Execute numerous test cases more frequently.

One of the best ways to apply these concepts is by relying on another concept: continuous integration (CI). Integrate testing into your development workflow can help us catch issues early in development stage

In the next section, we will discover how to write, automate and integrate integration tests in development workflow using Karate and Gitlab CI.

What is Karate ?

Karate is a behavior-driven development (BDD) framework that simplifies API testing. It combines the simplicity of Cucumber with the power of Karate DSL which allows for creating powerful API test cases in a BDD format using Gherkin syntax, making it easy to write executable specifications that can be used for testing components and for different use cases.

Karate is the only open-source tool to combine API test-automation, mocks, performance-testing and even UI automation into a single, unified framework. The syntax is language-neutral, and easy for even non-programmers. Assertions and HTML reports are built-in, and you can run tests in parallel for speed.
karatelabs.io

It is a versatile, powerful and well documented tool for API testing, making it a popular choice among developers and testers. A full documentation is available on GitHub.

Automating Integration Tests

In today’s fast-paced tech world, speed and high quality are a must. Manual testing can slow down progress and does not guarantee a bug-free release. Automating integration tests speeds up the process, allowing developers to focus on creating great features instead of checking for bugs. Running tests automatically after every code change ensures that issues are found and dealt with quickly. This leads to faster and well tested releases without any regression. Regular automated testing means your software stays reliable as new features are added. If something breaks, you catch it early before it impacts users. To do this, in this article, we will use Karate for writing tests and GitLab CI to automate running tests.

What is GitLab CI ?

Now, let’s talk about GitLab CI. This is a powerful tool for Continuous Integration (CI). It helps automate the process from code commit to deployment, much like a well-oiled machine. Once you set up GitLab CI, it can run your tests every time you make changes. Think of it as having a safety net — whenever you take a leap, it checks if everything is okay before you land.

Sample Project (Hands on)

Typical Project Structure

When integrating Karate into a real-world application, the structure of your test setup can vary based on your requirements and how you want to manage testing. Broadly, there are different common approaches:

1. Including Karate Tests in Your Microservice
   In this approach, Karate tests are added directly to your microservice project. This is particularly useful for testing the service in isolation, as you can mock external dependencies (e.g., external APIs or databases) to create controlled test environments. This approach keeps the test and application code in the same repository, simplifying version control and CI/CD workflows. Since the tests are tightly coupled with the microservice, the team responsible for the development and maintenance of the service is also responsible for writing and maintaining its integration tests. This approach works well when the focus is on validating the behavior of a single microservice, possibly with mocked external dependencies.
2. Dedicated Karate Project for Integration Testing
   In this approach, you create a separate project (or module) dedicated to integration tests. This is ideal when you want to test the complete integration of your microservice with its external dependencies in a real-world-like setup. The tests in this project cover the interactions and integrations between multiple microservices or the system as a whole. The central QA or testing team are responsible for maintaining the project to ensure consistency across services and to manage cross-service scenarios effectively. This approach is ideal for end-to-end testing, ensuring that the entire system works as expected when multiple microservices interact.

For the purposes of this article, we’ll focus on the second approach — a dedicated Karate project for integration testing in order to centralize the integration test code in the same project to test all our future microservices.

Test Structure

To simplify the example, we’ll omit creating a custom microservice and instead use the PetStore API (full documentation available here). This allows us to focus on the testing techniques and features of Karate without the overhead of setting up and managing a backend service.

Karate tests consist of *.feature files, where each file can define one or more scenarios. For the Pet store API, we might structure our test scenarios around major resources like Pet, Store, and User.

Setting Up Karate with Maven

First, set up Karate in a Maven project by adding dependencies in the pom.xml:

<dependency>
    <groupId>com.intuit.karate</groupId>
    <artifactId>karate-junit5</artifactId>
    <version>1.4.1</version> <!--latest version when writing this article-->
    <scope>test</scope>
</dependency>

You can find the complete project on GitHub 🚀

1. Testing the Pet Resource

A test scenario to add a new pet might look like this:

Feature: Petstore Pet API

Scenario: Add a new pet to the store
    Given url 'https://petstore.swagger.io/v2/pet'
    And request { "id": 123, "name": "Fluffy", "photoUrls": ["https://example.com/photo.jpg"], "status": "available" }
    When method post
    Then status 200
    And match response.name == 'Fluffy'

2. Testing the Pet Resource

This scenario tests placing an order:

Scenario: Place an order for a pet
    Given url 'https://petstore.swagger.io/v2/store/order'
    And request { "id": 1, "petId": 123, "quantity": 2, "status": "placed" }
    When method post
    Then status 200
    And match response.status == 'placed'

3. Testing the User Resource

A test scenario for creating a user:

Scenario: Create a new user
    Given url 'https://petstore.swagger.io/v2/user'
    And request { "id": 101, "username": "testUser", "firstName": "John", "lastName": "Doe", "email": "john.doe@example.com" }
    When method post
    Then status 200

4. Fetching a Pet by ID

This scenario uses a parameterized path for retrieving a pet by ID:

Scenario: Find pet by ID
    Given url 'https://petstore.swagger.io/v2/pet/123'
    When method get
    Then status 200
    And match response.name == 'Fluffy'

Advanced Features in Karate

• Parameterized Tests: To run tests with different values, use the Examples keyword. (example)
• Data-Driven Tests: Use data tables in Karate to send multiple test data variations through a scenario. (example)
• Reusability: Define reusable code in Background or as * def functions to be used across scenarios.

5. Another example for a scenario to test in Karate

When we run that PetManagement.feature, we will have a karate-report for the results (available also in jsonformat)

In order to run those tests on feature merge, we need to configure our .gitlab-ci.yml in our project.

Configure GitLab CI

To trigger a GitLab CI/CD pipeline when a merge request is merged into the develop branch, you can set up a .gitlab-ci.yml file with specific jobs to run tests. Here’s a sample pipeline configuration to execute whenever a merge request is merged

stages:
  - test

trigger_karate_tests:
  stage: test
  only:
    - merge_requests
    - develop  # or other branches you want to run the tests on
  script:
    - echo "Triggering Karate test pipeline..."
    - |
      curl -X POST \
        -F token=$KARATE_TRIGGER_TOKEN \
        -F ref=main \
        -F variables[ENVIRONMENT]=$TARGET_ENV \
        https://gitlab.com/api/v4/projects/YOUR_KARATE_PROJECT_ID/trigger/pipeline
  # Wait for the triggered pipeline to finish before proceeding (optional)
  allow_failure: false

TARGET_ENV: To specify which environment to test. This can be part of the URL of the service to be tested.

KARATE_TRIGGER_TOKEN is a sensitive value and should be protected. To secure this value in GitLab, you should store it as a protected CI/CD variable in GitLab. This way, it won’t be exposed in the pipeline logs or GitLab configuration files, and it will be accessible only to authorized branches or users. Here’s how to securely configure the KARATE_TRIGGER_TOKEN:

Add KARATE_TRIGGER_TOKEN as a CI/CD Variable

1. Go to your main project’s Settings > CI/CD > Variables section.
2. Click Add variable.
3. Enter KARATE_TRIGGER_TOKEN as the Key.
4. Paste the trigger token you generated in the Karate project as the Value.
5. Enable Mask to hide the token in job logs (this prevents accidental logging of sensitive information).
6. Enable Protect to restrict the token to protected branches (e.g., main, develop) and prevent it from being used in unprotected pipelines or feature branches.

While this approach focuses on running integration tests after deploying a new artifact, a more robust strategy involves testing the artifact before deployment. In this approach, we would first build the new artifact, then run the integration tests on it. Only if the tests pass would we proceed with deploying the artifact to production. This ensures that the new artifact is validated early in the process, minimizing the risk of deploying faulty code and improving the reliability of the release pipeline. This strategy provides an additional layer of confidence before introducing changes to the live environment.

Summary

Automated integration testing is an essential practice for modern software development, helping teams ensure that components interact smoothly and that new features do not introduce regressions. By combining Karate, a powerful BDD framework, with GitLab CI/CD, teams can automate the process of running comprehensive integration tests every time a change is made. This approach reduces the risk of errors, improves efficiency, and ensures higher quality and stability of the software in production.

Karate simplifies API testing with its easy-to-write scenarios and robust feature set, including support for data-driven tests, parallel execution, and seamless integration with CI tools like GitLab. With Karate, developers can write tests that are both human-readable and executable, ensuring that their systems behave as expected. Furthermore, using GitLab CI allows teams to automate the execution of these tests on every commit or merge, ensuring that issues are caught early in the development cycle.

By following the practices outlined in this article, teams can streamline their integration testing process, achieve faster feedback, and ultimately build more reliable software. With the integration of Karate and GitLab CI, developers can confidently automate integration tests, making the process faster, more consistent, and scalable while maintaining the integrity of their applications.

Link: Karate GitHub Project

Automated Integration testing — using Karate & GitLab CI was originally published in Bforbank Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Android Makers Paris 2025 — Jour 1

Comme chaque année, j'ai eu la chance d'assister à la nouvelle édition d'Android Makers dans les beaux locaux du beffroi de Montrouge et je vous invite à revivre avec moi cette journée riche en découverte. Entre modularité, sécurité, refonte d'application et deep dive dans les entrailles de Compose puis de comment fonctionne les Regex, nous partons ensemble faire le tour de ce programme chargé.

1. Ultra fast Build et Architecture Modulaire

La journée a démarré sur les chapeaux de roues avec la présentation de Cyril Mottier un développeur d’amo, qui nous a plongé dans les arcanes de l’architecture modulaire. Leur défi ? Optimiser les temps de build, un enjeu crucial dans le développement d’applications complexes, d'autant plus quand on est dans un secteur ultra concurrentiel et toujours en mouvement des applications de réseaux sociaux. Il a partagé leur approche, articulée autour d’une modularisation poussée du projet. En divisant l’application en modules indépendants et grâce à une compréhension fine de l'algorithme de compilation, ils ont réussi à réduire significativement les temps de build et à améliorer l'efficacité de leur équipe. Cette présentation a souligné l’importance d’une bonne architecture, non seulement pour la maintenabilité du code, mais aussi pour la productivité des développeurs. J’ai pu observer que la modularisation, bien qu’elle représente un investissement initial parfois conséquent comme c'est le cas ici, est une stratégie payante sur le long terme.

2. Refonte et Design System : L’Odyssée de Coyote

Coyote, ce n’est pas qu’une application d’avertisseur pour les conducteurs, c’est aussi une entreprise qui a su innover dans son approche de refonte de son application. La deuxième conférence, animée par l’équipe de Coyote, nous a offert une plongée captivante dans le monde de la refonte d’application. Leur approche a été guidée par la mise en place d’un design system unifié, capable de servir leurs trois applications (iOS / Android / device Coyote). Le plus intéressant réside dans leur gestion des variations : chaque composant peut exister en versions Small ou Large, pour s’adapter aux différents contextes d’utilisation. Coyote a également partagé son organisation de la gestion de l’interface utilisateur, chaque Composable majeur ayant son propre UiState et ViewModel. Cela assure un contrôle fin de l’état de l’interface et une séparation claire des responsabilités facilitant les imports d'une application a une autre. De plus, ils utilisent google screenshot testing pour s’assurer qu’il n’y aura pas de régressions. Une belle démonstration de la synergie entre dev et design dans le cadre d'une refonte d'application.

3. Cybersécurité mobile : Les Menaces Cachées

La troisième conférence nous a fait prendre conscience des menaces qui rôdent dans le monde du mobile. Zimperium une société de sécurité mobile, nous a ouvert les yeux sur les vulnérabilités et les techniques d’attaque actuelles. On a été plongé dans le monde de la cybersécurité avec des exemples concrets :
Magisk : Un plugin qui permet de rooter le téléphone et de le dissimuler aux applications, dont l'utilisation a explosé ces dernières années.
Frida : Un outil d’injection de code, un cauchemar pour la sécurité.
Un exemple assez fou a été donné, une application malveillante qui imite toutes les applications bancaires en Europe. L’utilisateur lance son application bancaire et en fait il s’agit de l’application malveillante qui se lance à la place reproduisant à la perfection la UI de la banque afin de récupérer les virements de l'utilisateur à son profit.
Cette session a été un véritable électrochoc, nous rappelant que la sécurité ne doit jamais être prise à la légère. Il est crucial pour les développeurs d’intégrer des pratiques de sécurité rigoureuses dès les premières étapes du développement.

4. Debuguer les Recompositions dans Android Studio : Les coulisses des devs d'Android Studio.

Les équipes d’Android Studio sont venus sur scène pour nous dévoiler des outils et astuces de debugage sur les recompositions. Cette conférence fut technique, nous avons pu voir qu’il est possible d’avoir des logs sur le degré de stabilité des paramètres lors des recompositions grâce aux breakpoints (Stable / Unstable). Une autre fonctionnalité intéressante, c’est la possibilité de faire un break point et de lui configurer un "println" qui s'affichera sur le terminal (fini les log en dur dans le code). On peut aussi injecter une valeur dans une variable en cours de debugage et de continuer à jouer notre code avec cette nouvelle valeur, idéale pour simuler des correctifs.

Aussi, si on souhaite avoir de meilleures performances avec notre device il est préférable d’utiliser un cable usb-3 ( attention usb-3 != usb-c) afin d'avoir une meilleure vitesse d'envoie des data. Un message de notification sera fait dans Android Studio si ce n’est pas le cas.

5. Regex : L’Odyssée Intergalactique de Ben Kadel

La dernière conférence était la plus surprenante et théâtrale de la journée. Comme a son habitude Ben Kadel nous a embarqués dans une aventure bien a lui et celle là était intergalactique avec l'exploration du monde des Regex. Imaginez, un vaisseau spatial qui s’écrase sur la planète Regex, et notre périple commence à travers les sombres mystères des expressions régulière tout essayant de déjouer les plans de son alter ego maléfique Ken Badel. En tout cas, il a toujours une manière atypique et divertissante de capter notre attention pour nous apprendre des sujets complexes. C’était agréable de terminer par cette conférence pour clôturer cette riche journée.

Conclusion : Une journée riche en apprentissages.

Android Makers 2025 a été bien plus qu’une simple série de conférences. C’était une véritable immersion dans les enjeux et les innovations du développement Android. De l’optimisation des builds à la cybersécurité, en passant par la refonte d’application et les subtilités de Compose, chaque présentation a apporté son lot de connaissances et de réflexions. Bien sûr je n'ai pas pu parler des autres sujets qui ont été abordé comme l'émergence de l'IA dans le développement, les réflexions organisationnelles sur le mobileOps et les applications multiplateforme en KMP, ni des chaleureuses conversations que j'ai pu avoir avec mes confrères. Je vous en parlerais surement plus lors d'une prochaine édition, dont je suis sur sera encore mieux que la précédente.

Android Makers Paris 2025 — Jour 1 was originally published in Bforbank Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Datadog provides a comprehensive solution for monitoring and observability in modern applications. In this article, we’ll guide you through integrating Datadog into your Android application, setting up logging, and configuring dynamic session sampling with Firebase Remote Config.

1. Setting Up Datadog in Your Android Application

Before integrating Datadog, ensure you have a Datadog account with an API key. Then follow these steps:

Step 1: Add Dependencies

Update your build.gradle file to include the Datadog SDK:

dependencies {
    implementation "com.datadoghq:dd-sdk-android:1.+"
    implementation "com.google.firebase:firebase-config:21.2.1" // Firebase Remote Config
}

Step 2: Initialize Datadog

Initialize Datadog in your Application class :

import com.datadog.android.Datadog
import com.datadog.android.DatadogConfig

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()

        // Basic configuration
        val config = DatadogConfig.Builder("<CLIENT_TOKEN>", "<ENVIRONMENT>")
            .build()

        // Initialize Datadog
        Datadog.initialize(this, config)
    }
}

Replace <CLIENT_TOKEN> and <ENVIRONMENT> with your Datadog client token and the environment name (e.g., production, staging).

Step 3: Grant Required Permissions

Ensure your AndroidManifest.xml contains the required permissions:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

2. Integrating Logging with Datadog

Step 1: Create a Logger

Use the Logger API to start capturing logs:

import com.datadog.android.log.Logger

val logger = Logger.Builder()
    .setNetworkInfoEnabled(true) // Attach network information
    .setLogcatLogsEnabled(true) // Forward logs to Logcat
    .build()

Step 2: Log Events

Capture log messages of various levels:

logger.i("Info message: App started")
logger.w("Warning message: Low memory")
logger.e("Error message: Network failure")

You can also add custom metadata:

logger.d("Debug message", attributes = mapOf("user_id" to "12345"))

3. Dynamic Session Sampling with Firebase Remote Config

Session sampling limits the percentage of logs sent to Datadog, helping you manage quota usage. Using Firebase Remote Config, you can dynamically adjust the sample rate without deploying new versions of your app.

Step 1: Set Up Firebase Remote Config

1. Add Firebase to your Android project.
2. In the Firebase Console, define a parameter datadog_sample_rate with a default value (e.g., 100.0).

Step 2: Fetch the Sample Rate

Retrieve and apply the sample rate during Datadog initialization:

import com.datadog.android.DatadogConfig
import com.google.firebase.remoteconfig.FirebaseRemoteConfig

class MyApplication : Application() {
    override fun onCreate() {
        super.onCreate()

        val remoteConfig = FirebaseRemoteConfig.getInstance()
        remoteConfig.setDefaultsAsync(mapOf("datadog_sample_rate" to 100.0))
        remoteConfig.fetchAndActivate().addOnCompleteListener { task ->
            if (task.isSuccessful) {
                val sampleRate = remoteConfig.getDouble("datadog_sample_rate").toFloat()

                val config = DatadogConfig.Builder("<CLIENT_TOKEN>", "<ENVIRONMENT>")
                    .setSampleRate(sampleRate) // Dynamic sample rate
                    .build()

                Datadog.initialize(this, config)
            }
        }
    }
}

Step 3: Update Sampling Rate Remotely

Use the Firebase Console to update the datadog_sample_rate value. The new rate will be applied after the next fetch interval (default is 12 hours, configurable via Firebase).

4. Best Practices

• Use Tags: Attach tags (e.g., userId, deviceType) for better log searchability.
• Avoid Sensitive Data: Exclude personal or sensitive data from logs.
• Leverage Log Levels: Use appropriate log levels (DEBUG, INFO, ERROR) to prioritize issues.

Sampling Strategies

• Monitor Usage: Use Datadog’s quota dashboard to track log volume.
• Start High, Then Optimize: Begin with a high sample rate (e.g., 100%) during development and gradually lower it in production.
• Dynamic Updates: Regularly adjust the sample rate using Firebase Remote Config based on real-time monitoring.

Conclusion

By integrating Datadog for logging and leveraging Firebase Remote Config for dynamic session sampling, you can efficiently monitor your app’s performance while staying within log quotas. These tools provide flexibility and control, ensuring that your application remains stable and well-observed.

For more details, refer to the official documentation.

How to Integrate Datadog into Your Android Application for Logging and Dynamic Sampling was originally published in Bforbank Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

As software engineer, one of the popular problems we deal with is ensuring data consistency. In Event-Driven Architecture (EDA), it is mandatory; in other words, your system goes wrong when the data exchange (publish/consume) is not coherent.

In EDA when using Kafka (or any other message brokers like RabbitMQ) to exchange messages and having a database to store the business data model. There are two different types of operations : Database transaction and kafka message publication.

Database Transaction: This involves operations that ensure data integrity and consistency within a single database. It is managed by the database management system (DBMS) and follows ACID (Atomicity, Consistency, Isolation, Durability) properties.

Kafka message publication: The capability to push an event to a message broker. The capability to use a transaction also exists, but only to ensure atomicity between an event consumption and an event publication.

-> This involves coordinating transactions across multiple systems, such as a database and a message broker like Kafka. Ensuring atomicity and consistency across these systems is challenging due to the lack of a global transaction manager and the inherent differences in how these systems handle transactions.

“Enough theory, let’s dive into the problem”

(In this article, I’ll describe a fake production story with a very simple Java demo. This should be understandable for both technical and non-technical readers)

Example of a first tentative to ensure data consistency and transactional aspect:

@Transactional    
public User createUser(User user) {
        // Persist user to the database
        User savedUser = userRepository.save(user);

        // Push message to Kafka
        kafkaTemplate.send(TOPIC, savedUser);

        return savedUser;
    }

At this time, I believed that will work well and it’s quite a great and simple implementation… until I was called to help investigating issues in Production.

There were about 600 users created in our store but we didn’t receive the notification for 4 users.

As I trusted my implementation, I wonder how it was possible to happen?

By talking with my colleagues, I figured out that something can go wrong between the step of writing to the database and publishing the message. The system becomes inconsistent.

Key issues: Atomic transaction

Atomicity (all-or-nothing) between database operations and message publishing is not guaranteed -> it leads to inconsistent data.

If we choose to fix the consequences and not the issue’s root cause, it takes a tremendous amount of time to find the corrupted data and patch it manually.

This is just a simple example and may not usually happen in real life, but in a complex system, this is one of the pain points in scaling Event-Driven Architecture.

The solution : Outbox pattern

If we can not have a single transaction operating kafka and database to ensure atomicity , then we should handle them independently. It is the principle of the outbox pattern that i have learned from my colleagues and chapter engineering. It’s called Transactional Outbox Pattern.

Firstly, we need to create another table, such as “outbox”, to store the state of the message to be published. We persist the state changes of the business data and the “event data” using an atomic operation. Both succeed together or fail together.

Secondly, we trigger the “event data” based on status by using a scheduled job to retrieve all the committed messages and ready for asynchronous publishing

Regarding the diagram:

So let’s jump into the refactor code !

Outbox event and business use case :

public enum OutboxEvent {
  USER_CREATION,  // event type for user creation
  USER_UPDATED,   // event type for user updated
  CARD_CREATION  //  event type for card creation
}
public enum OutboxStatus {
  PENDING, // state of pending
  FAILED, //  state of failed
  SENT   //   state of sent
}

public class OutboxEvent {
    private UUID id; // unique identifier
   
    private UUID businessId; // business id linked to business data
    
    private OutboxType eventType; // outbox event type
    
    private OutboxStatus status; // outbox status

    private LocalDateTime lastModifiedTime; // last modified

  public OutboxEvent(UUID businessId, OutboxType eventType, OutboxStatus status) {
    this.id = null;
    this.businessId = businessId;
    this.eventType = eventType;
    this.status = status;
    lastModifiedTime = LocalDateTime.now();
  }
// constructor, getter setter
}

@Transactional(propagation = Propagation.REQUIRED)
    public User createUser(User user) {
        // Persist user to the database
        User savedUser = userRepository.save(user);

        // Create outbox event
        OutboxEvent outboxEvent = new OutboxEvent(
                                        savedUser.id(), 
                                        OutboxType.USER_CREATION,
                                        OutboxStatus.PENDING
                                   );
        outboxEventRepository.save(outboxEvent);
        return savedUser;
    }

p/s: propagation = Propagation.REQUIRED -> support a current transaction; create a new one if none exists.

Here, I created an outbox model to store the state of event data. We can have the business ID which is linked to the business data model, the status of the outbox like PENDING, FAILED, SENT, etc., or outboxType as I want to handle many event types.

Now in my use case, I don’t have any more interaction with Kafka or any distributed transaction. It focuses only on data persistence.

Then, i have a scheduling job to publish event data :

// EnableScheduling

    public void publishEvents() {
        List<OutboxEvent> events = outboxEventRepository.findByPendingEvents();
        for (OutboxEvent event : events) {
            // userWrappedService convert the outbox event to message event
            var message = userWrappedService.toMessage(event)
            kafkaTemplate.send(TOPIC, message);
            event.setStatus(OutboxStatus.SENT);
            event.setLastModifiedTime(LocalDateTime.now());
            outboxEventRepository.save(event);
        }
    }

p/s: we can improve it by:

• Sending multiple records in a single batch to Kafka
• Implementing idempotent processes
• Improving the process of retry

Here, I would like to ensure the message is published correctly. I don’t need to worry about business data as it was guaranteed in my previous use case.

I want to improve this code to ensure the message is sent successfully before marking the event as sent. I collect events that are successfully sent and use a batch update to reduce the number of database calls.

Here is the refactored code :

// EnableScheduling
public void publishEvents() {
        List<OutboxEvent> events = outboxEventRepository.findByPendingEvents();
        List<OutboxEvent> successfullySentEvents = new ArrayList<>();

        for (OutboxEvent event : events) {
            var message = userWrappedService.toMessage(event);
            ListenableFuture<SendResult<String, Message>> future = kafkaTemplate.send(TOPIC, message);

            future.addCallback(new ListenableFutureCallback<>() {
                @Override
                public void onSuccess(SendResult<String, Message> result) {
                    event.setStatus(OutboxStatus.SENT);
                    event.setLastModifiedTime(LocalDateTime.now());
                    successfullySentEvents.add(event);
                }

                @Override
                public void onFailure(Throwable ex) {
                    log.error("Failed to send event: {}", event.getId(), ex);
                }
            });
        }

        if (!successfullySentEvents.isEmpty()) {
            outboxEventRepository.saveAll(successfullySentEvents);
        }
    }

Finally, I have refactored my implementation to prevent distributed transactions issues. After this refactor, I observed that the issues previously faced in Production no longer occur.

Summary

Understanding distributed transactions and implement Outbox pattern is not an easy thing when you face this problem for the first time. I believe it’s one of the best solutions when dealing with consistency issues in an Event Driven Architecture.

The goal: have the guarantee that the database and message publication will be synchronized (eventual consistency). If it makes your system more resilient, why wouldn’t you try it ?

In my article, i would like to thank you @ABDERRAHIM Zied for supporting and helping me work effectively with the outbox pattern. Together, we made the system of order card at @BforBank more resilient.

A Java and Kafka Adventure : The road to data consistency with OutBox Pattern was originally published in Bforbank Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kafka Connect is a very powerful tool for streaming data between Apache Kafka to another system. Often you may need to include static fields in your data or to set a field to a static value. This article explains how to do so via Kafka connect with practical examples.

How to ?

Within Kafka Connect, Single Message Transform (SMT) helps you to make simple and lightweight modifications to individual messages.

Use case 1: Adding a static field

In this example, we will add a field that does not exist in the original record. To do so we will use SMT InsertField

We will insert a static field labeled origin using a static value of Earth.

"transforms": "InsertField",
"transforms.InsertField.type": "org.apache.kafka.connect.transforms.InsertField$Value",
"transforms.InsertField.static.field": "origin",
"transforms.InsertField.static.value": "Earth"

Original record:

{
 "firstName": "Marty", 
 "lastName": "McFly"
}

Transformed record:

{
 "firstName": "Marty", 
 "lastName": "McFly", 
 "origin": "Earth"
}

Use case 2: Masking a field

In this example, we will mask some fields. To do so we will use SMT MaskField.

We will perform two transformations:

• First one we will mask the field cardNumber to a masked value ***-***-****
• Second one will will mask two fields office and mobile to a masked value +xx-xxx-xxxxxxx

"transforms": "CardNumberMask,PhoneMask",

"transforms.CardNumberMask.type": "org.apache.kafka.connect.transforms.MaskField$Value",
"transforms.CardNumberMask.fields": "cardNumber",
"transforms.CardNumberMask.replacement": "***-***-****",

"transforms.PhoneMask.type": "org.apache.kafka.connect.transforms.MaskField$Value",
"transforms.PhoneMask.fields": "office,mobile",
"transforms.PhoneMask.replacement": "+xx-xxx-xxxxxxx"

Original record:

{
 "cardNumber": "1230-5460-9000-0000", 
 "office": "+33145310884",
 "mobile": "+33766250585"
}

Transformed record:

{
 "cardNumber": "***-***-****", 
 "office": "+xx-xxx-xxxxxxx",
 "mobile": "+xx-xxx-xxxxxxx"
}

Use case 3: Inserting a field or setting static value to a field that might already exist

In the two previous uses cases, we either have inserted a field that does not exist in the original record or have modified an existing field in the original record. What if the field may exist or not and we want to set a static value ?

• Using only InsertField will cause an error if the field already exists because you cannot insert an already existing field
• Using MaskField will not do the job if the field does not exist, as MaskField will not add it.

The trick to complete that is to mix ReplaceField and InsertField

In this example, we will set a static field labeled origin using a static value of Earth. But, the field might already exists or not. So, first, we will rename the field viaReplaceField , then we will insert the target field with target value via InsertField.

"transforms": "RenameOrigin, InsertOrigin",
"transforms.RenameOrigin.type": "org.apache.kafka.connect.transforms.ReplaceField$Value",
"transforms.RenameOrigin.renames": "origin:defaultOrigin"
"transforms.InsertOrigin.type": "org.apache.kafka.connect.transforms.InsertField$Value",
"transforms.InsertOrigin.static.field": "origin",
"transforms.InsertOrigin.static.value": "Earth"

Original record:

{
 "firstName": "Marty", 
 "lastName": "McFly"
 "origin": "Mars" // Might not exist in the original record
}

Transformed record:

{
 "firstName": "Marty", 
 "lastName": "McFly",
 "defaultOrigin": "Mars" // Not present in the transformed if not present in original record
 "origin": "Earth"
}

Conclusion

In this article, we have seen the usage of Single Message Transform (SMT) on top of Kafka Connect to make simple and lightweight modifications to individual messages. We have seen how to insert a static field or mask an existing field or how to handle it if the field that we want to insert might already exist or not and we want to set a static value.

To go further: https://docs.confluent.io/platform/current/connect/transforms/overview.html

Kafka tips & tricks #01: Static field and static value with Kafka Connect was originally published in Bforbank Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Imagine you’re giving someone directions to your house. You wouldn’t just say, “Get here.” You’d describe each turn and landmark along the way. That’s what’s a script for a computer!

A script, is a set of instructions written in a programming language. It tells a computer what to do, step by step to achieve a specific mission.

Scripts could perform a variety of tasks such as:

• automate process,
• data entry and file manipulation,
• backup and restore operations,
• communicate between homogenous or heterogenous systems…

Note: Scripting in this context means “tooling”; that small code we write to achieve a task, not taking in consideration the nature of the used language wether it was a compiled, interpreted or a hybrid language.

« Basically, scripting is not a technical term. When we call something a scripting language, we’re primarily making a linguistic and cultural judgment, not a technical judgment » Larry Wall — Perl.com

Usually when talking about scripts, the first reflex that cames in mind (not for python users) is to create a new .sh file, also called “Shell Script” file.
Shell script is good ! until nobody in your team will remember what it was created for and how it should run.

As a software developer, specifically Apple Software developer, I can say i’m convinced that in a team were all player ‘speaks’ a common language like “Swift” it would be better to use it not only for developing, but also for tooling.

An Apple Software developer might forget the Shell Script syntaxe for a loop or a condition, but never in swift.

Maintaining scripts over the time won’t require re-explaining each instruction since it is naturally readable for Apple Software developers.

Hello World !

Let’s start simple, a script that prints Hello World !
Create a file script.sh and paste in it:

#!/bin/sh
echo "hello, world!"

Then add to the current session user the right to execute it, then run it:

chmod +x script.sh 
./script.sh

The result should be “hello, world!” printed in terminal. Easy !

In order to receive arguments passed to the script during its call, also easy.
let’s update the script.sh file:

#!/bin/sh
echo "hello $1"

Then call it with arguments:

./script.sh John

The result should be “hello John” printed in terminal. Yet easy !

We can also use interruption to request parameter from the user and read it within the script:

#!/bin/sh
echo "Whom to greet ?"
read fullname
echo "hello $fullname"

Run it

./script.sh

> Whom to greet ? 
> John
> hello John

A piece of cake, until I tell you I want, for exemple, a script that add a text to an image ! ooh yeah it’s getting complicated.
To do so with shell script we need to install 3rd party solution such as ImageMagick or others.
But as Apple Software developer we know that combining a text and an image ain’t that complicated for Swift !

Hello World, the Swift way !

First of all, we need to check if we already have Swift toolchain installed:

swift -version
> swift-driver version: 1.115.1 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1)
> Target: arm64-apple-macosx14.0

If its not see installation page for Xcode or Swift Toolchain, it depends on the platform to be used on.

To start, create a file Script.swift and paste in it:

import Foundation

print("hello, world!")

save and run:

swift Script.swift

Same result as the first shell script !

Note that we can add the shebang (#!) and the path to swift binary at the beginning of the swift file and run it without specifying the interpreter “swift”:

#!/usr/bin/swift
import Foundation

print("hello, world!")

and run it this way:

chmod +x Script.swift 
./Script.swift

Let’s try to read argument passed during script call. We need to update our script to be like:

import Foundation

print("hello \(CommandLine.arguments[1])")

Call it with the argument:

swift Script.swift John

We should have the same result as the Shell script “hello John”

Moving on to reading from standard input example, another update to our script and it should be like:

import Foundation

print("Whom to greet ?")
var name = readLine(strippingNewline: true)
print("hello \(name ?? "")")

At this level there is no big difference between Shell and Swift scripts.

Why Swift script can be better alternative to a shell script ? Remember the first line of the Swift script;

import Foundation

We are able to use the full potential of Foundation Framework or Any other framework or library we will include within our script.

Here is a demo sample where we need to execute some setup depending on the input value of a configuration name:

import Foundation

enum Configuration: String, CaseIterable {
    case DEBUG
    case QUALIF
    case PPROD
    case PROD
}

// Demo setup func
func setup(with configuration: Configuration) {
    print(configuration.rawValue)
}

let input = CommandLine.arguments[1]
// Check if this CFG Name is Supported or Not 
guard let configuration = Configuration(rawValue: input) else {
    // CFG Name not Supported
    print("can't find configuration for name \(input)")
    print("available configurations are:")
    Configuration.allCases.forEach {
        print($0.rawValue)
    }
    exit(1)
}
// Perform specifique action for CFG
switch configuration {
case .DEBUG, .QUALIF, .PPROD, .PROD:
    setup(with: configuration)
}

Now let’s see how to do the merge between a text and and image. Given the input is BforBank Logo image:

import AppKit

extension NSImage {
    convenience init? (url: URL) {
        guard let iconData  = try? Data (contentsOf: url) else {
            return nil
        }
        self.init(data: iconData)
    }
    var asPNGData: Data? {
        guard let imageData = tiffRepresentation, let newRep = NSBitmapImageRep(data: imageData) else {
            return nil
        }
        return newRep.representation(using: .png, properties: [:])
    }
}

func addBadge(_ text: String, imageSize: CGSize, with color: NSColor) {
    let paragraphStyle = NSMutableParagraphStyle()
    paragraphStyle.alignment = NSTextAlignment.center
    paragraphStyle.lineBreakMode = .byWordWrapping

    let attributes: [NSAttributedString.Key: Any] = [
        .font: NSFont.systemFont(ofSize: 120),
        .paragraphStyle: paragraphStyle,
        .foregroundColor: color
    ]

    let textRect = NSRect(x: 0, y: imageSize.height * 3/4, width: imageSize.width, height: imageSize.height * 1/4)
    
    NSColor(red: 0.78, green: 0.25, blue: 0.28, alpha: 1.00)
        .drawSwatch(in: textRect)
    
    text.draw(
        with: textRect.insetBy(dx: 20, dy: 60),
        options: [.usesLineFragmentOrigin, .truncatesLastVisibleLine], attributes: attributes)
}

// Get the original Icon file url
let iconUrl = URL(filePath: FileManager.default.currentDirectoryPath + "/Icon.png")

// Build NSimage from Icon file url
guard let iconImage = NSImage(url: iconUrl) else {
    print("Error: couldn't find Icon.png")
    exit (1)
}

// Read Badge Text from standard input
print("Badge Text:")
var badgeText = readLine(strippingNewline: true)

// Apply text on badge
let badgedIcon = NSImage(size: iconImage.size, flipped: true) { rect -> Bool in
    iconImage.draw(in: rect)
    addBadge(badgeText ?? "", imageSize: iconImage.size, with: .white)
    return true
}

// Generate png Data from the combined image
guard let pngData = badgedIcon.asPNGData else {
    print("Error: couldn't convert image to png data")
    exit (1)
}

// Generate new file with the png Data
let outputURL = URL(filePath: FileManager.default.currentDirectoryPath + "/BadgedIcon.png")
try pngData.write (to: outputURL)

> swift Script.swift
> Badge Text:
> Alpha

“et Voila”:

This was a drop in an ocean, with swift we can:

• automate templating and code generation directly from apis documentation, check (Stencils)
• access system process just like shell script (Process)
• benefit from Swift existing advantages ( Rich frameworks, Structured concurrency, Macro, Property wrappers, SPM …)

Finally for All Swift developers;

“It feels at home” Natan Rolnik — SwiftConnection 2024

Here we can find a good talk at SwiftConnection 2024 where we can see further subjects such as the usages of Stencil for templating and automated generation, Macros ...

A good article that tackle more the usage of Process.

And a random Swift subject to read as a bonus “Swift REPL” Read-Eval-Print-Loop 😉

Scripting with Swift was originally published in Bforbank Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ll explore the different layers of clean architecture (Data, Domain, and Presentation) and demonstrate how to implement each step. However, we won’t cover implementing a RemoteMediator, as my project doesn’t utilize an internal database.

For my example, I’ve chosen the theme of cheese because… well, I’m French.

1 — Imports and Clean architecture

First, let’s discuss about imports. Since we’re using clean architecture, our Domain layer is unaware of the other layers of the application and that also mean it should be composed of Kotlin dependencies only.

You might be thinking this presents a problem. Paging 3 is an Android library, so we can’t integrate it directly into the Domain layer… Don’t worry, Google has anticipated this! There are versions of Paging 3 without Android dependencies, like the one used for testing :

dependencies {
  val paging_version = "3.3.4"

//DATA
  implementation("androidx.paging:paging-runtime:$paging_version")

//DOMAIN
  // alternatively - without Android dependencies for tests
  testImplementation("androidx.paging:paging-common:$paging_version")

  // optional - RxJava2 support
  implementation("androidx.paging:paging-rxjava2:$paging_version")

  // optional - RxJava3 support
  implementation("androidx.paging:paging-rxjava3:$paging_version")

  // optional - Guava ListenableFuture support
  implementation("androidx.paging:paging-guava:$paging_version")

//PRESENTATION
  // optional - Jetpack Compose integration
  implementation("androidx.paging:paging-compose:3.3.4")
}

You can then integrate the appropriate dependency into each of your layers, depending on whether you need the Android-dependent version or not.

2 — Implementing the Data Source

We’ll begin on the data layer by implementing PagingSource. This class allows us to manage how we retrieve and store responses from our API for Paging.

class CheesePagingSource @Inject constructor(//Hilt for injection
  private val apiRequestManager: ApiRequester,//A class handling all my api calls
  private val cheeseService: CheeseService, 
  private val limit: Int,            //the number of cheese fetch by api
) : PagingSource<String, CheeseItem>() {

  override suspend fun load(params: LoadParams<String>): LoadResult<String, CheeseItem> {
    val response = apiRequestManager.request(
      service = "CHEESE_SERVICE",
      call = {
        cheeseService.getCheeseItems(
          cursor = params.key,
          limit = limit
        )
      },
      converter = { it.toEntity() }
    )
    return onLoadResponse(response)
  }

  override fun getRefreshKey(state: PagingState<String, CheeseItem>): String? {
    return null
  }

  private fun onLoadResponse(
    response: Result<EveryCheeseItem>
  ): LoadResult<String, CheeseItem> {
    return when (response) {
      is Result.Success -> {
        val cheeseList = response.data.cheeses
        LoadResult.Page(
          data = cheeseList,
          prevKey = null,
          nextKey = response.data.cursor
        )
      }
      is Result.Failure -> {
        LoadResult.Error(response.error.throwable ?: Throwable())
      }
    }
  }
}

The load function’s purpose here is to return a LoadResult object containing the data from our API call. I preferred to separate the API call from the part that handles the Result type (Success or Failure), to be more readable.

What’s most important to us is the returned LoadResult object. Here, we’ll send it our cheeseList objects, already transformed into Entities for is use in the Domain layer.

Regarding keys (prevKey / NextKey / getRefreshKey), I’m using a cursor instead of traditional integer-based pagination. That’s why prevKey and getRefreshKey is always null, as everything resides on the same page.

is Result.Success -> {
  val cheeseList = response.data.cheeses
  LoadResult.Page(
    data = cheeseList,
    prevKey = null,
    nextKey = response.data.cursor
  )
}

3 — Implementing the Repository

Our PagingSource will be utilized in our remote Repository, as it’s part of creating our Flow with the Pager object.

class CheeseRemoteRepository @Inject constructor(
  private val apiRequestManager: ApiRequester,
  private val cheeseService: CheeseService
) : CheeseRepository {

  override suspend fun getCheeseItems(limit: Int): Flow<PagingData<CheeseItem>> {
    return Pager(
      config = PagingConfig(pageSize = limit),
      pagingSourceFactory = {
        CheesePagingSource(
          apiRequestManager = apiRequestManager,
          cheeseService = cheeseService,
          limit = limit
        )
      }
    ).flow
  }
}

Here, we simply create the Pager object, passing it a PagingConfig and our PagingSource to create a flow of PagingData<Value>. You can think of PagingData as a wrapper around your values that simplifies interaction within the presentation layer.

4 — The Use Case

This can be a quick step depending on your implementation. Here, the use case will simply act as a bridge between the Data and Presentation layers.

class GetCheeseItemsUseCase @Inject constructor(
  private val cheeseRepository: CheeseRepository,
) {
  suspend fun execute(size: Int): Flow<PagingData<CheeseItem>> =
    cheeseRepository.getCheeseItems(limit = size)

}

5 —The ViewModel

Now, we enter the ViewModel. This is where we’ll declare our state and retrieve our PagingData flow to apply transformations. Typically, we want to map our entity model from Domain to a UI model representing our UI, which is entirely possible using the map extension function available for PagingData. However, be aware that PagingData doesn’t have all the extensions that Flow offers.

The second change we want to make is using the .insertSeparators method provided by PagingData. This allows us to add elements directly into our flow like a header, a divider and so on. To achieve this, I recommend creating a sealed class with all the element types you want to display in your UI.

sealed class CheeseDisplayItem{
  data object NoCheeseDisplayAvailable : CheeseDisplayItem()
  data object NoMoreCheeseDisplay : CheeseDisplayItem()
  data object CheeseDisplayListTitle : CheeseDisplayItem()
  data class CheeseItem(val cheeseItemUiModel : CheeseItemUiModel) : CheeseDisplayItem()
}

private val cheeseState: MutableStateFlow<PagingData<CheeseDisplayItem>> = MutableStateFlow(value = PagingData.empty())
val state: MutableStateFlow<PagingData<CheeseDisplayItem>> get() = cheeseState

private fun getCheeseItems() {
  viewModelScope.launch {
    getCheeseItemsUseCase.execute(
      size = 15,
    ).distinctUntilChanged()
      .map { pagingData ->
        pagingData
          .map {
            it.toUiModel()   // transform your entity model to uiModel if needed
          }
          .insertSeparators { before, after ->
            when {
              before == null && after == null -> CheeseDisplayItem.NoCheeseDisplayAvailable   //no item was found
              before == null && after != null -> CheeseDisplayItem.CheeseDisplayListTitle     // first item on the list
              after == null -> CheeseDisplayItem.NoMoreCheeseDisplay                          // last item on the list
              else -> null                                                        // always put null for the other case
            }
          }
      }
      .cachedIn(viewModelScope)
      .collect {
        cheeseState.value = it
      }
  }
}

6 — Displaying Data in the Screen

The first step is to retrieve your state and create a LazyPagingItems instance. You can then display the different types from your sealed class in your UI.

One of the key features of Paging is that you can manage your loading states with much greater precision, as you can see in the example below :

val cheeseItems: LazyPagingItems<CheeseDisplayItem> = viewModel.timelinePaging.collectAsLazyPagingItems()

LazyColumn(modifier = Modifier.padding(horizontal = BFBTheme.spacing.spacing16)) {
  //display items depending on its type
  items(count = cheeseItems.itemCount) { index ->
    when (val cheeseItem = cheeseItems[index]) {
      CheeseDisplayItem.CheeseDisplayListTitle -> CheeseTitle()
      CheeseDisplayItem.NoCheeseDisplayAvailable -> NoCheeseFound()
      CheeseDisplayItem.NoMoreCheeseDisplay -> NoMoreCheese()
      is CheeseDisplayItem.CheeseItem -> Cheese(cheeseItem.cheeseItemUiModel)
      else -> Unit
    }
  }
  // Manage different type of loading state thanks to Paging
  cheeseItems.apply {
    when {
      loadState.refresh is LoadState.Loading -> {
        item { Text(text = "LOADING") }
      }

      loadState.refresh is LoadState.Error -> {
        item { Text(text = "Error when refresh") }
      }

      loadState.append is LoadState.Error -> {
        item {
          Text(text = "Error when append")
        }
      }
    }
  }
}

There you have it! I hope this has shed some light on implementing Paging3. Don’t hesitate to leverage its advantages to optimize your display by configuring the Pager’s PagingConfig, utilizing insertSeparators, and taking advantage of the simplified loading state management.

GL HF

For more information

https://developer.android.com/topic/libraries/architecture/paging/v3-overview

Paging 3 through clean architecture was originally published in Bforbank Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Kafka Streams is a powerful framework for building real-time, event-driven applications, allowing data processing in near real-time with scalability. One of its core components is the State Store, which holds intermediate results and makes operations like aggregations, joins, and windowing possible.

However, there may come a time when the state in these stores requires modification. This might be necessary to resolve data inconsistencies, accommodate schema changes, or fix bugs in the state. In this guide, we’ll explore an effective approach to patch Kafka Streams State Stores.

What is a Kafka Streams State Store?

A State Store in Kafka Streams is a local, persistent storage system where data is saved and accessed during stream processing. It is especially critical for maintaining the state of aggregations, joins, and windowed operations.

There are three common types of State Stores:

• KeyValueStore: Stores key-value pairs and is ideal for lookups and simple updates.
• WindowStore: Holds windowed data, allowing access to records within specific time windows.
• SessionStore: Maintains session data, useful for session-based activities that require tracking start and end times.

To ensure fault tolerance, Kafka Streams can back up this data to Kafka topics (called changelog topics). In case of a failure, the state store can be restored from the changelog. When you need to modify this data for patching, however, the process becomes more complex.

Why Patch the Kafka Streams State Store?

Patching a state store isn’t something you do on a whim. It’s typically required when there’s a problem or significant change in the system. Here are the main scenarios where patching becomes necessary:

• Data Corruption: Over time, the data in the state store may become inconsistent or corrupted, whether due to bugs or external factors. You’ll need to patch the store to restore data integrity.
• Schema Changes: If your application’s data schema evolves (e.g., new fields, changing data types), the existing state may no longer be valid. Patching the state store ensures it aligns with the new schema.
• Business Logic Updates: If the business logic for computing state (such as how you calculate aggregates or process joins) changes, the historical state data may need to be updated to reflect those changes.
• Bug Fixes: Sometimes, incorrect logic or bugs can lead to faulty states in the store. In such cases, you must patch the store to fix the erroneous data.
• Data Migration: When migrating data between systems or Kafka Streams instances, you might need to update or completely overwrite the state store’s data with new values.

While patching is necessary in some cases, it can also be risky. Improper handling of the patching process can lead to data loss, application crashes, or inconsistent states across different nodes in a distributed Kafka Streams application.

Exemple of a KeyValueStore patching

Let’s walk through a specific use case of patching a KeyValueStore<String, String>. Our goal is to update entries in the store where (key+i, value) becomes (key+i, valuepatched) for entries where i % 2 == 0.

Here’s the core Processor implementation used to achieve this update

package com.kafka.stream.migration.demo.process.process;

import org.apache.kafka.streams.processor.PunctuationType;
import org.apache.kafka.streams.processor.api.ContextualProcessor;
import org.apache.kafka.streams.processor.api.ProcessorContext;
import org.apache.kafka.streams.processor.api.Record;
import org.apache.kafka.streams.state.KeyValueStore;

import java.time.Duration;

public class MyMigrationProcess extends ContextualProcessor<Object, Object, String, String> {

    private final String storeName;
    private final Duration punctuateIntervalDuration;
    private boolean isPunctuatedOnce;

    private KeyValueStore<String, String> store;

    public MyMigrationProcess(String storeName, Duration punctuateIntervalDuration) {
        this.storeName = storeName;
        this.punctuateIntervalDuration = punctuateIntervalDuration;
        this.isPunctuatedOnce = false;
    }

    @Override
    public void init(ProcessorContext<String, String> processorContext) {
        super.init(processorContext);
        store = processorContext.getStateStore(storeName);
        processorContext.schedule(punctuateIntervalDuration, PunctuationType.WALL_CLOCK_TIME, this::punctuate);
    }

    private void punctuate(long clockTime) {
        if (isPunctuatedOnce) {
            return;
        }
        this.isPunctuatedOnce = true;
        var iterator = store.all();
        while (iterator.hasNext()) {
            var next = iterator.next();
            if (Integer.parseInt(next.key.replace("key", "")) % 2 == 0) {
                String patchValue = patchValue(next.value);
                store.put(next.key, patchValue);
            }

        }
    }

    private String patchValue(String value) {
        return value + "patched";
    }

    @Override
    public void process(Record<Object, Object> emptyRecord) {
        //Do nothing
    }

}

• One-Time Punctuation: The punctuate method ensures the patching logic runs only once. It iterates over the store entries and selectively modifies entries based on the condition (i % 2 == 0).
• State Store Iteration: store.all() is used to access and modify each entry in the store.

Building the Topology

Because this patching operation doesn’t require an input topic (we’re simply walking through the state store to apply updates), we can bypass Kafka’s topic validation by creating a dummy stream. It serves only as a trigger for our custom processor and does not consume any real data. We achieve this by using a regular expression pattern that Kafka Streams interprets as a valid input, even though there are no matching topics.

streamsBuilder
.stream(Pattern.compile("dummy-topic-juste-to-generate-stream"))
.process(() -> new MyMigrationProcess(STORE_NAME, Duration.ofSeconds(1)), STORE_NAME);
        

• Pattern.compile("dummy-topic-just-to-generate-stream"): This regular expression bypasses Kafka’s requirement for a real input topic, allowing the processor to run independently.
• Processor Execution: The custom processor (MyMigrationProcess) is attached directly to the stream, and it executes the patching logic solely on the state store.

This workaround is effective for triggering processors when you don’t need actual streaming data, enabling focused modifications on the state store contents.

Testing using TopologyTestDriver

Using TopologyTestDriver is significantly faster than an EmbeddedSingleNodeKafkaCluster, and it allows for precise simulation of various timing scenarios. By calling advanceWallClockTime, you can simulate the progression of stream time to trigger scheduled callbacks like punctuation exactly when needed.

Keep in mind that TopologyTestDriver operates as a single-partition simulation, so when testing scenarios that involve multiple partitions, results may differ from a fully distributed Kafka environment.

package com.kafka.stream.migration.demo.process;

import org.apache.kafka.common.serialization.Serdes;
import org.apache.kafka.streams.StreamsConfig;
import org.apache.kafka.streams.Topology;
import org.apache.kafka.streams.TopologyTestDriver;
import org.apache.kafka.streams.state.KeyValueStore;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.autoconfigure.kafka.KafkaProperties;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.kafka.test.context.EmbeddedKafka;
import org.springframework.test.context.ActiveProfiles;

import java.time.Duration;
import java.util.Properties;
import java.util.stream.Stream;

import static org.assertj.core.api.Assertions.assertThat;

@ActiveProfiles("test")
@SpringBootTest
class MyMigrationTest {

    @Autowired
    Topology topology;

    @Autowired
    Properties testProp;

    @Autowired
    KafkaProperties kafkaProperties;

    @Test
    void should_patch_state_store() {

        //Given
        testProp.putAll(kafkaProperties.getProperties());
        TopologyTestDriver topologyTestDriver = new TopologyTestDriver(topology, testProp);

        KeyValueStore<String, String> keyValueStore = topologyTestDriver.getKeyValueStore("my-state-store-name");
        var ids = Stream.iterate(0, i -> i + 1).limit(10).toList();
        ids.forEach(i -> keyValueStore.put("key" + i, "value" + i));

        //When stream advanced by one second
        topologyTestDriver.advanceWallClockTime(Duration.ofSeconds(1));

        //Then only key mod 2 = 0 is patched
        ids.stream().filter(i -> i % 2 == 0).forEach(i -> assertThat(keyValueStore.get("key" + i)).isEqualTo("value" + i + "patched"));
        ids.stream().filter(i -> i % 2 != 0).forEach(i -> assertThat(keyValueStore.get("key" + i)).isEqualTo("value" + i));

    }

}

Conclusion

In summary, patching a Kafka Streams State Store requires careful planning and execution to avoid disruptions. By implementing a custom Processor, as demonstrated in the example, you can iterate over and selectively modify data within the KeyValueStore. Using a one-time punctuation, this approach triggers the patching logic without needing an active input stream. Testing with TopologyTestDriver enables you to simulate time progression and validate the patching logic, ensuring reliable results before deployment.

This method provides a controlled and efficient way to apply updates to state stores, whether to fix data inconsistencies, adapt to schema changes, or adjust business logic all while minimizing risk to the ongoing streaming process.

Additional Resources

• Github demo link: https://github.com/maroinemlis/kafka-stream-migration-demo
• Kafka Streams Documentation
• Monitoring Kafka Streams State Stores
• https://www.confluent.io/fr-fr/blog/test-kafka-streams-with-topologytestdriver/

How to patch entirely a Kafka Streams state store ? was originally published in Bforbank Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.