DEV Community: Sridhar Subramani

AI Needs More Than Just a Model: The Missing Role of Context, Orchestration, and Agents

Sridhar Subramani — Sun, 23 Mar 2025 16:40:26 +0000

Solving the AI Puzzle: Why External Context, Orchestration, and Agents Are Key to Intelligence

Disclaimer:

This blog is intended as a beginner-friendly guide to AI, specifically focusing on why Large Language Models (LLMs) should interact with agents to solve any AI query.

It does not cover advanced topics such as training, fine-tuning, or building LLMs from scratch because, at the time of writing, I am not deeply familiar with these areas. However, my experience comes from building an in-house orchestration system, which serves as the central component for facilitating communication between different AI components to solve any AI query. This system routes requests from input agents to classifiers and further to specific agents and tools, ultimately generating a response.

The goal is to introduce key concepts, terminology, and importance of Agents and the need for Orchestration.

Target Audience:

Beginners in AI who are exploring concepts like LLMs, agents, and orchestration.
Developers from Non-AI Domain & Enthusiasts looking to understand how AI models interact with real-world systems.
Product Managers seeking high-level insights without deep technical details.

Analogy

If we think of the human brain as an AI model (e.g., an LLM), then the hands, vocal cords, eyes, etc. would be its agents.

In humans, the brain processes sensory inputs and issues commands to physical agents (e.g., muscles). Here's a simplified analogy:

Your retina captures visual data of a ball coming toward you. The retina acts as an input agent, sending this data to the brain for processing.
Your brain analyzes the visual input and decides that you need to catch the ball. The brain functions as the LLM in this analogy.
The brain sends a signal to your hands to catch the ball. Your hands serve as the output agent, executing the action.

If the brain (LLM) is trained properly, it instructs your hands to act correctly. However, if the training is insufficient, it might make an incorrect decision, such as instructing your eyes to close instead of catching the ball, leaving you vulnerable to an accident.

AI (LLM) can process input, reason with it, and generate outputs, much like the brain processes sensory data and makes decisions. However, just as the brain requires physical agents like hands to interact with the environment, LLMs require agents to bridge the gap between reasoning and action.

Assume we use LLaMA 3.2 as the LLM. Our primary input and output type is text, which makes interaction straightforward. While this works well for text-based outputs like answering questions, it doesn't suffice for all use cases. For instance, text output is suitable when we only want an answer, but if we need to perform an action (e.g., sending an email, opening a file), the LLM cannot handle this because its sole responsibility is to generate text-based outputs. It has no inherent capability to perform actions or interact with the physical or digital world.

Importance of Agents in AI

What are Agents

From our earlier analogy, we assumed that our hands and eyes are agents in the physical world. In the digital world, we call the software component an agent; an agent is anything that can enhance your LLM to read its environment, and it can provide some actionable output from the LLM response.

Can LLM Directly Call Agents?

At present, LLMs cannot directly perform actions. They can:

Understand the input.
Provide reasoning and structured outputs.

However, LLM can instruct at best what should happen but cannot interact with the environment directly to p*erform those actions*. For instance:

An LLM can generate an HTML response but cannot open a browser to display it.
It can suggest sending an email but cannot send it.

To bridge this gap, we need output agents. These agents read the LLM's output and perform the necessary actions.

Example: Output Agent

If the LLM generates an HTML response, an output agent can:

Open a web browser or embed a browser within an application.
Render the HTML content for the user to view.

How Agents Extend the Capabilities of LLMs

Agents serve as intermediaries that interact with the LLM to sense the environment or execute actions.

To make the LLM's outputs actionable, we need to augment the system with agents that can process inputs going into the LLM and/or process output from the LLM to make it perform any actions.

Let's consider we are going to create an agent-based system that leverages an LLM to function as a humorous AI assistant.

In this setup, we define two key agents: the Input Agent and the Output Agent.

Flow of Request Handling

User submits a query.
The Input Agent receives the query, appends a system prompt, and forwards it to the LLM.
The LLM processes the prompt, understands the context, and generates a response accordingly.
The Output Agent, which understands the LLM's response format, parses it and executes the necessary actions - such as rendering the output, speaking it aloud, or performing other predefined tasks.

User → Input Agent → LLM → Output Agent

Example:

Let's consider an example where we instruct the LLM to entertain the user with a joke and format the response in HTML:

System Prompt: "You are a funny AI. Your job is to entertain users. Make sure your responses are in HTML format with inbuilt styles."

Query: "Tell me a joke."

Input to LLM = "System Prompt + Query"

The user submits the "Tell me a joke" query, Input Agents creates a Prompt to LLM by appending the "System Prompt with the User Query."

Expected Output from LLM:

<html lang="en">
  <body style="font-family: Arial; color: blue;">
    <p>Why don't scientists trust atoms? Because they make up everything!</p>
  </body>
</html>

The LLM successfully generates the output, but displaying it as a webpage or further acting on this HTML requires an output agent.

The output agent we created recognizes the HTML format in the response. thus rendering the output in a web browser.

What we discussed so far is a simple agent system where each agent is hardwired to interact with the LLM in a predefined way. While this setup works for limited use cases, it becomes impractical as we introduce more agents and tasks.

For example:

What if we want to add a new agent that performs speech synthesis?
What if multiple agents need to work together dynamically, rather than following a fixed sequence?
What if we need to support multiple LLMs based on different tasks?
How do we manage interdependencies between agents efficiently?

A manually hardcoded agent system is rigid and difficult to scale. Each new agent requires manual integration, and there's no flexibility in execution. To build t*ruly scalable AI applications, we need a **dynamic system that can decide which agents to use, route tasks efficiently, and adapt to new capabilities*, all without modifying the entire workflow.

This is where Orchestration comes in, acting as the brain of the system, intelligently managing agents, LLM interactions, and task execution.

The Need for an Orchestrator

Agents play a crucial role in AI systems by extending the capabilities of LLMs. However, since LLMs cannot directly call agents, we need a central component, an Orchestrator that connects the LLM with the required context and agents to complete a task.

List of Components in the Orchestrator System

Assume we are going to create an orchestrator system that has the below components:

Input Client: Sends user queries to the Orchestrator.
Agents: Responsible for different tasks, categorized as:
- Classifier Agent: Determines the type of request and decides which agent should handle it.
- Intermediate Agent: Performs predefined tasks.
LLM: Processes input queries and helps in decision-making.

The Orchestrator itself runs as a daemon process, exposing APIs that allow input clients, agents, and the LLM to register and interact within the ecosystem.

In this system, we assume:

Multiple input clients and agents can register.
Only one LLM can be registered at a time.

Registration Process

Input Clients register with a unique ID so that the Orchestrator knows where to send responses once the request is fulfilled.
LLM is also registered, so agents and input clients can access it via the Orchestrator when needed.
Agents register with:
- A unique ID
- A description of the agent role
- An input schema specifying what kind of input agent expect to perform predefined task
- An output schema defining what agent will return after processing

This metadata allows the LLM to determine whether the system has the necessary capability to process a given request.

Example Query Flow

User Query:
"Take a snapshot from the dashboard camera, merge it with a selfie from the interior camera, and send it to Sridhar's email."

Agents & Their Responsibilities

[1] Camera Agent

Role: Captures snapshots from either the dashboard or interior camera.

Description: "I'm a Camera Agent. I can take snapshots from the dashboard or interior camera."

Input Schema:

{
  "takePicFromDashboard": bool,
  "takePicFromInterior": bool
}

Output Schema:

{
  "dashboardPicPath": "string|null",
  "interiorPicPath": "string|null"
}

[2] Photo Editor Agent

Role: Creates a collage from multiple photos.

Description: "I'm a Photo Editor Agent. I can create a collage from multiple images."

Input Schema:

{
  "picPaths": ["string"]
}

Output Schema:

{
  "collagePicPath": "string|null"
}

[3] Email Agent

Role: Sends an email with multimedia attachments.

Description: "I'm an Email Agent. I can query user contacts, accept multimedia content, and send an email."

Input Schema:

{
  "emailSender": "string",
  "content": "string",
  "mimeType": "string"
}

Output Schema:

{
  "isEmailSent": bool
}

How the Orchestrator Uses LLM to Execute the Plan

When the user submits a query, the Orchestrator sends it to the LLM along with the list of registered agent descriptions.

Example LLM Prompt to Generate an Execution Plan

I want you to act as a planner. Given a user query, devise a plan to execute it.

You can find the list of attached agents to understand the system's capabilities.

Agent descriptions:
[  
  /* All agent descriptions will be added here */  
]

Input Query: "/* Replace user query here */"

Output Format:
[
  {
    "agentName": "string",
    "agentParam": { /* The input schema expected by the agent */ }
  },
  {
    "agentName": "string",
    "agentParam": { /* The input schema expected by the agent */ }
  }
]

This allows the LLM to analyze the system's capabilities and generate an execution plan.

Since the Orchestrator understands the LLM's structured response, it carefully executes the agents in the correct order to fulfill the request.

Final Execution Flow

Input Client → Orchestrator → LLM → Camera Agent → Photo Editor Agent → Email Agent → (Optional: LLM Summarizes Response)

As AI systems evolve, orchestrators will become even more essential in bridging the gap between reasoning and action. But will AI systems ever replace human roles entirely?

Will AI Replace Humans?

I see two major work streams emerging in AI:

Model Development: Engineers and researchers focused on building more efficient and powerful AI models.
Agent & Orchestration Systems: People working on AI agents, orchestration, and external context integration, which often requires domain-specific knowledge.

Let's say, we would like to build a video logging system which would be mounted on a car dashboard, an AI agent might be responsible for:

Periodically capturing photo feeds.
Geo-tagging them with location data.
And converting the data into embeddings for an LLM to process.

In this case, the agent must understand the domain, including how to interact with the camera, read GPS data, and structure the output for further AI-driven analysis. This is where human expertise in software, hardware, and system integration remains essential.

AI's Role in the Workforce

AI is already transforming the workforce by automating mundane and repetitive tasks. However,** AI is not yet at a stage where it can function independently**, for at least the next 5–10 years, human involvement will be crucial in guiding AI systems, making them more useful, adaptable, and safe.

For instance, while AI can generate code, we are still far from an AI-driven system that can write, deploy, and manage software autonomously, such as using AWS APIs to deploy a new system without any human intervention. Until AI can reliably handle real-world complexity, human oversight will be crucial.

Summary

To ensure scalability, an Orchestrator system is essential. It seamlessly integrates various agents, classifiers, and LLMs, efficiently managing request routing, coordinating multiple agents, and utilizing the LLM at different stages of the workflow to accomplish a desired task.

While there are open-source agent orchestration systems available, I haven't explored them yet. For our specific use case, we built a custom Orchestrator tailored to our requirements. Once I've had the opportunity to evaluate other solutions, I'll be able to provide more insights into the existing open-source options.

Annexure

PS: I used ChatGPT and QuillBot's grammar check to refine my writing.
https://quillbot.com/grammar-check

Getting Started with Android Testing: Building Reliable Apps with Confidence (Part 3/3)

Sridhar Subramani — Mon, 06 Jan 2025 15:16:55 +0000

Learn the Fundamentals of Android Testing, One Step at a Time (Part 3/3)

Target Audience for This Blog

This blog covers the basics of testing in Android, providing insights into setup, dependencies, and an introduction to different types of tests. It is designed to help beginners understand the fundamentals of Android testing and how various tests are implemented.

Integration testing

Integration testing typically involves testing the interactions between different components or modules of an application.

During these tests, we can visually observe the app launching, with all the interactions specified in the code happening in real time.

However, there’s an alternative approach that leverages GradleManagedDevices to run integration tests. This method skips the UI preview and executes the tests on a configured virtual or physical device. More details on this approach are provided in the next section.

Integration Testing Frameworks

Framework	Description
Robolectric	To perform android UI/functional testing on JVM without the need for android device. * Test files are located inside the test folder
AndroidX test runner	Provides AndroidJUnitRunner which is a JUnit test runner that allows to run instrumented JUnit 4 tests on Android devices, including those using the Espresso, UI Automator, and Compose testing frameworks. * Test files are located inside the androidTest folder.
UI Automator	A UI testing framework designed for cross-app functional testing, enabling interactions with both system apps and installed apps. * Test files are located inside the androidTest folder.

The following test cases, written for RobolectricTestRunner and AndroidJUnitRunner, appear similar to the Compose UI Unit Test code snippet. This is because the androidx.compose.ui.test.junit4 library provides test implementations for both JVM and Android. Using the same interfaces, tests can run on either runtime. The appropriate implementation is selected at runtime based on the configured test runner.

The androidx.compose.ui.test.junit4 module provides the ComposeTestRule and its Android-specific implementation, AndroidComposeTestRule. These rules allow you to set Compose content or access the activity. You can construct these rules using factory functions: createComposeRule for general use or createAndroidComposeRule if activity access is required.

Robolectric

In this test, we are verifying the behavior of the Login composable screen by ensuring that the login button is
enabled only when the inputs provided by the user are valid.

Initial State Validation: The test confirms that the login button is initially disabled when no inputs are provided.
Partial Input Validation: The test simulates entering invalid email and password combinations step-by-step to ensure that the button remains disabled until all conditions for validity are met.
Valid Input Validation: Finally, the test validates that the login button becomes enabled only when both the email and password meet the required validation criteria (a valid email format and a password of sufficient length).

This test ensures that the Login composable correctly enforces input validation and enables the login button only under valid conditions.

System Under Test

@Composable
fun Login(onSuccess: (email: Email) -> Unit, viewModel: LoginViewModel = hiltViewModel()) {

    LaunchedEffect(key1 = viewModel.loginState, block = {
        if (viewModel.loginState == LoginState.LoginSuccess) onSuccess(viewModel.email)
    })

    Column {
        Text(text = stringResource(id = R.string.login))

        EmailInput(modifier = Modifier
            .semantics { testTagsAsResourceId = true;testTag = "emailInput" }
            .testTag("emailInput")
            .fillMaxWidth(),
            value = viewModel.email.value ?: "",
            isEnabled = viewModel.loginState !== LoginState.InProgress,
            onValueChange = viewModel::updateEmail)

        PasswordInput(modifier = Modifier
            .semantics { testTagsAsResourceId = true;testTag = "passwordInput" }
            .fillMaxWidth(),
            value = viewModel.password.value ?: "",
            isEnabled = viewModel.loginState !== LoginState.InProgress,
            onValueChange = viewModel::updatePassword)

        if (viewModel.loginState === LoginState.LoginPending) {
            PrimaryButton(modifier = Modifier
                .semantics { testTagsAsResourceId = true;testTag = "loginButton" }
                .fillMaxWidth(),
                text = stringResource(id = R.string.login),
                enabled = viewModel.isLoginButtonEnabled,
                onClick = viewModel::login)
        }

        if (viewModel.loginState === LoginState.InProgress) {
            CircularProgressIndicator(
                modifier = Modifier
                    .semantics { testTagsAsResourceId = true;testTag = "progressLoader" }
                    .align(Alignment.CenterHorizontally)
            )
        }
    }
}

Test

class LoginKtTest {

  @get:Rule
  val composeRule = createComposeRule()

  @Test
  fun shouldEnableButtonOnlyWhenInputsAreValid() {

    val loginUseCase = mockk<LoginUseCaseImpl>(relaxed = true)
    val loginViewModel = LoginViewModel(loginUseCase)

    coEvery { loginUseCase.login(any(), any()) } returns Unit

    with(composeRule) {
      setContent { Login(onSuccess = {}, viewModel = loginViewModel) }
      // Initial State Validation  
      onNodeWithTag("loginButton").assertIsNotEnabled()

      // Partial Input Validation
      onNodeWithTag("emailInput").performTextInput("abcd")
      onNodeWithTag("loginButton").assertIsNotEnabled()

      // Partial Input Validation  
      onNodeWithTag("emailInput").performTextInput("abcd@gmail.com")
      onNodeWithTag("loginButton").assertIsNotEnabled()

      // Partial Input Validation  
      onNodeWithTag("passwordInput").performTextInput("12")
      onNodeWithTag("loginButton").assertIsNotEnabled()

      // Valid Input Validation  
      onNodeWithTag("passwordInput").performTextInput("12345")
      onNodeWithTag("loginButton").assertIsEnabled()
    }
  }
}

Click here to see in action

Dependencies

// Allows us to create and configure mock objects, stub methods, verify method invocations, and more
androidTestImplementation("io.mockk:mockk-agent:1.13.5")
androidTestImplementation("io.mockk:mockk-android:1.13.5")
androidTestImplementation("org.mockito.kotlin:mockito-kotlin:5.4.0")

// Assertion library
androidTestImplementation("com.google.truth:truth:1.1.4")

// Needed for createComposeRule , createAndroidComposeRule and other rules used to perform UI test
androidTestImplementation("androidx.compose.ui:ui-test-junit4:$compose_version") // used with AndroidTestRunner to run ui test on virtual/physical device.

// Required to add androidx.activity.ComponentActivity to test manifest.
// Needed for createComposeRule(), but not for createAndroidComposeRule<YourActivity>():
debugImplementation("androidx.compose.ui:ui-test-manifest:$compose_version")

Setup

Create a app/src/test/resources/robolectric.properties file and define the robolectric properties.

instrumentedPackages=androidx.loader.content
application=dagger.hilt.android.testing.HiltTestApplication
sdk=29

Android JUnit test

AndroidJUnitRunner is a test runner which lets us run the test on android virtual/physical/GradleManaged devices, including those using the Espresso, UI Automator, and Compose testing frameworks.

System Under Test

We have two composable screens: LoginScreen and ProfileScreen, both inside MainScreen.

The LoginScreen contains:
- email and password input fields
- A submit button
Functionality:
- Pressing the submit button navigates the user to the ProfileScreen.
- The ProfileScreen greets the user with a message displaying their email ID.

Test

@HiltAndroidTest
class MainScreenTest {

    @get:Rule(order = 0)
    val hiltAndroidRule = HiltAndroidRule(this)

    /**
     * Need a activity that annotated with @AndroidEntryPoint. and it has to be registered in manifest.
     * Add comment why we used createAndroidComposeRule instead of composeTestRule
     */
    @get:Rule(order = 1)
    val androidComposeRule = createAndroidComposeRule<DummyTestActivity>()

    @Test
    fun shouldSuccessfullyLaunchProfileScreenWithEmailPostLogin() {

        with(androidComposeRule) {
            setContent { MainScreen() }

            onNodeWithTag("emailInput").performTextInput("abc@gmail.com")
            onNodeWithTag("passwordInput").performTextInput("12345")
            onNodeWithTag("loginButton").performClick()

            waitUntil(2500L) {
                onAllNodesWithTag("welcomeMessageText").fetchSemanticsNodes().isNotEmpty()
            }

            onNodeWithTag("welcomeMessageText").assertTextEquals("Email as explicit argument abc@gmail.com")
            onNodeWithTag("welcomeMessageText2")
                .assertTextEquals("Email from saved state handle abc@gmail.com")

            waitForIdle()
        }
    }
}

Click here to see in action

Dependencies

// Used to create AndroidHiltTestRunner from AndroidJUnitRunner
androidTestImplementation("androidx.test:runner:1.6.2")

Setup

android {

  defaultConfig {
    // testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"

    // If we are using Hilt we can extend the AndroidJUnitRunner and pass the HiltTestApplication as application component.
    testInstrumentationRunner = "com.gandiva.android.sample.AndroidHiltTestRunner"
  }
}

class AndroidHiltTestRunner : AndroidJUnitRunner() {
  override fun newApplication(cl: ClassLoader?, className: String?, context: Context?): Application {
    return super.newApplication(cl, HiltTestApplication::class.java.name, context)
  }
}

UI Automator

UI Automator is a UI testing framework designed for cross-app functional UI testing, allowing interaction with both system and installed apps. Unlike frameworks that are limited to the app under test, UI Automator provides a wide range of APIs to interact with the entire device.

This enables true cross-app functional testing, such as opening the device settings, disabling the network, and then launching your app to verify how it handles a no-network condition.

With UI Automator, you can easily locate UI components using convenient descriptors like the text displayed on the component or its content description, making test scripts more intuitive and readable.

System Under Test

We use an Android device as the system under test. The process begins by launching the home intent, bringing the device to the home screen. Once the home app is launched, we proceed to open our app for testing.

The test scenario remains the same: we navigate to the LoginScreen, enter the email and password, and press the
submit button. Upon successful submission, the app navigates to the ProfileScreen, where the user is greeted with their email ID.

Test


private const val BASIC_SAMPLE_PACKAGE = "com.gandiva.android.sample"
private const val LAUNCH_TIMEOUT = 5000L

@HiltAndroidTest
class LoginJourneyTest {

    private lateinit var device: UiDevice

    @get:Rule
    val hiltAndroidRule = HiltAndroidRule(this)

    @Before
    fun startMainActivityFromHomeScreen() {
        // Initialize UiDevice instance
        device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())

        // Start from the home screen
        device.pressHome()

        // Wait for launcher
        val launcherPackage: String = device.launcherPackageName
        MatcherAssert.assertThat(launcherPackage, CoreMatchers.notNullValue())
        device.wait(Until.hasObject(By.pkg(launcherPackage).depth(0)), LAUNCH_TIMEOUT)

        // Launch the app
        val context = ApplicationProvider.getApplicationContext<Context>()
        val intent = context.packageManager.getLaunchIntentForPackage(BASIC_SAMPLE_PACKAGE)
            ?.apply { addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK) }
        context.startActivity(intent)

        // Wait for the app to appear
        device.wait(Until.hasObject(By.pkg(BASIC_SAMPLE_PACKAGE).depth(0)), LAUNCH_TIMEOUT)
    }


    @Test
    fun shouldLaunchProfileScreenWhenLoginIsSuccess() {
        device.enterTextOnFieldWithId("emailInput", "hello@gmail.com")
        device.enterTextOnFieldWithId("passwordInput", "123456")

        device.wait(Until.hasObject(By.res("loginButton").enabled(true)), 1500L)
        assertThat(device.findObject(By.res("loginButton")).isEnabled).isEqualTo(true)

        device.clickFieldWithId("loginButton")

        device.wait(Until.hasObject(By.res("hasObject")), 3000L)

        assertThat(device.textFromFieldWithId("welcomeMessageText"))
            .isEqualTo("Email as explicit argument hello@gmail.com")
        assertThat(device.textFromFieldWithId("welcomeMessageText2"))
            .isEqualTo("Email from saved state handle hello@gmail.com")

        device.waitForIdle()
    }
}

Click here to see in action

Dependencies

// To perform UI automation test.
androidTestImplementation("androidx.test.uiautomator:uiautomator:2.3.0")

Command

./gradlew connectedAndroidTest --continue

Gradle Managed Devices

Gradle Managed Devices provide a way to configure virtual or physical devices directly in Gradle for running integration tests. Since the configuration is managed within Gradle, it gains full control over the device lifecycle, allowing it to start or shut down devices as needed.

Unlike standard Android Virtual Devices (AVDs) or physical devices, there won’t be any visual preview during the test run. Once the test completes, you can review the results in the reports generated in the build folder.

Gradle Managed Devices are primarily used for running automated tests at scale on various virtual devices, so the focus is on configuration details rather than a visual representation.

Setup

testOptions {
  managedDevices {
    devices {
      create<ManagedVirtualDevice>("testDevice") {
        device = "Pixel 6"
        apiLevel = 34
        systemImageSource = "aosp"
      }
    }
  }
}

Command

./gradlew testDeviceDebugAndroidTest

Source Code

https://github.com/sridhar-sp/android-test

Test Your Code, Rest Your Worries

With a sturdy suite of tests as steadfast as a fortress, developers can confidently push code even on a Friday evening and log off without a trace of worry.

Getting Started with Android Testing: Building Reliable Apps with Confidence (Part 2/3)

Sridhar Subramani — Mon, 06 Jan 2025 05:25:11 +0000

Learn the Fundamentals of Android Testing, One Step at a Time (Part 2/3)

Target Audience for This Blog

UI Testing

UI testing usually refers testing the user interface by simulating user action and verify the behavior of UI elements.

Famous UI Testing Frameworks

Framework	Description
Espresso	Android UI test framework to perform UI interaction and state assertion. (White box testing)
UI Automator	To perform cross-app functional UI testing across system and installed apps. (Both Black box & white box testing)
Compose UI test Junit	To provide Junit rules invoke composable function in Junit. also provides APIs to perform UI interaction and state assertion.

Compose UI + Interaction Unit Test

The Compose UI test framework allows you to verify that the behavior of your Compose code works as expected. It provides
a set of testing APIs that help you find UI elements, check their attributes, and perform user actions. Using these APIs, you can mount composable content and assert expected behaviors.

The androidx.compose.ui.test.junit4 module includes a ComposeTestRule and an implementation for Android called AndroidComposeTestRule. Through this rule you can set Compose content or access the activity. You construct the rules using factory functions, either createComposeRule or, if you need access to an activity, createAndroidComposeRule.

For Compose UI Unit Tests, you can use the RobolectricTestRunner, a JUnit Test Runner that runs test code directly on the JVM. This eliminates the need for a physical or virtual Android device, significantly speeding up test execution, ensuring consistent results, and simplifying the testing process.

However, some classes and methods from android.jar require additional configuration to function correctly. For example, accessing Android resources or using methods like Log might need adjustments to return default or mocked values. Please refer to the setup section below for the necessary configuration.

Example

In this test, we are verifying the behavior of the Login composable screen by ensuring that the login button is
enabled only when the inputs provided by the user are valid.

Initial State Validation: The test confirms that the login button is initially disabled when no inputs are provided.
Partial Input Validation: The test simulates entering invalid email and password combinations step-by-step to ensure that the button remains disabled until all conditions for validity are met.
Valid Input Validation: Finally, the test validates that the login button becomes enabled only when both the email and password meet the required validation criteria (a valid email format and a password of sufficient length).

This test ensures that the Login composable correctly enforces input validation and enables the login button only under valid conditions.

System Under Test

@Composable
fun Login(onSuccess: (email: Email) -> Unit, viewModel: LoginViewModel = hiltViewModel()) {

  LaunchedEffect(key1 = viewModel.loginState, block = {
    if (viewModel.loginState == LoginState.LoginSuccess) onSuccess(viewModel.email)
  })

  Column {
    Text(text = stringResource(id = R.string.login))

    EmailInput(modifier = Modifier
      .semantics { testTagsAsResourceId = true;testTag = "emailInput" }
      .testTag("emailInput")
      .fillMaxWidth(),
      value = viewModel.email.value ?: "",
      isEnabled = viewModel.loginState !== LoginState.InProgress,
      onValueChange = viewModel::updateEmail)

    PasswordInput(modifier = Modifier
      .semantics { testTagsAsResourceId = true;testTag = "passwordInput" }
      .fillMaxWidth(),
      value = viewModel.password.value ?: "",
      isEnabled = viewModel.loginState !== LoginState.InProgress,
      onValueChange = viewModel::updatePassword)

    if (viewModel.loginState === LoginState.LoginPending){
        PrimaryButton(modifier = Modifier
            .semantics { testTagsAsResourceId = true;testTag = "loginButton" }
            .fillMaxWidth(),
            text = stringResource(id = R.string.login),
            enabled = viewModel.isLoginButtonEnabled,
            onClick = viewModel::login)
    }

    if (viewModel.loginState === LoginState.InProgress){
        CircularProgressIndicator(
            modifier = Modifier
                .semantics { testTagsAsResourceId = true;testTag = "progressLoader" }
                .align(Alignment.CenterHorizontally)
        )
    }
  }
}

Test

This is a Compose UI unit test that runs on the JVM. Therefore, the code must be placed inside app/src/test/java/../LoginKtTest.kt .

@RunWith(RobolectricTestRunner::class)
class LoginKtTest {

  @get:Rule
  val composeRule = createComposeRule()

  @get:Rule
  var mainCoroutineRule = MainCoroutineRule()

  @Test
  fun shouldEnableButtonOnlyWhenInputsAreValid() {
    with(composeRule) {
      val loginUseCase = mockk<LoginUseCaseImpl>()
      val loginViewModel = LoginViewModel(loginUseCase)
      setContent { Login(onSuccess = {}, viewModel = loginViewModel) }
      onNodeWithTag("loginButton").assertIsNotEnabled()

      onNodeWithTag("emailInput").performTextInput("abcd")
      onNodeWithTag("loginButton").assertIsNotEnabled()

      onNodeWithTag("emailInput").performTextInput("abcd@gmail.com")
      onNodeWithTag("loginButton").assertIsNotEnabled()

      onNodeWithTag("passwordInput").performTextInput("12")
      onNodeWithTag("loginButton").assertIsNotEnabled()

      onNodeWithTag("passwordInput").performTextInput("12345")
      onNodeWithTag("loginButton").assertIsEnabled()
    }
  }
}

Dependencies

// Needed for createComposeRule , createAndroidComposeRule and other rules used to perform UI test
testImplementation("androidx.compose.ui:ui-test-junit4:$compose_version") // used with robolectric to run ui test on jvm

// Needed for createComposeRule(), but not for createAndroidComposeRule<YourActivity>():
debugImplementation("androidx.compose.ui:ui-test-manifest:$compose_version")

// Dependency injection for For instrumented tests on JVM
testImplementation("com.google.dagger:hilt-android-testing:2.49")
kaptTest("com.google.dagger:hilt-compiler:2.49")

// Needed to run android UI test on JVM instead of on an emulator or device
testImplementation("org.robolectric:robolectric:4.10.3)

// Helper for other arch dependencies, including JUnit test rules that can be used with LiveData, coroutines etc
testImplementation("androidx.arch.core:core-testing:2.2.0")

Setup

testOptions {
        unitTests {
            // Enables unit tests to use Android resources, assets, and manifests.
            isIncludeAndroidResources = true
            // Whether unmocked methods from android.jar should throw exceptions or return default values (i.e. zero or null).
            isReturnDefaultValues = true
        }
}

Command

./gradlew testDebugUnitTest

Source Code

https://github.com/sridhar-sp/android-test

Test Your Code, Rest Your Worries

With a sturdy suite of tests as steadfast as a fortress, developers can confidently push code even on a Friday evening and log off without a trace of worry.

Getting Started with Android Testing: Building Reliable Apps with Confidence (Part 1/3)

Sridhar Subramani — Sun, 05 Jan 2025 15:09:22 +0000

Learn the Fundamentals of Android Testing, One Step at a Time Part 1/3

Target Audience for This Blog

Different Types of Test

The following are the primary testing types that are commonly used in software products:

Unit testing
UI testing
Integration testing

Place of Execution

Test	Execution
Unit testing	JVM
UI testing	JVM or Android device
Integration testing	Android device

Unit Testing

Unit testing usually refers to testing a particular unit of code in complete isolation from other components to ensure its correctness and functionality. Developers often use frameworks like Mockito to create stubs (test doubles), mocks, etc., to achieve this isolation.

Stub: A stub is a direct replacement for a function, interface, or abstract class (or any other dependency). It
allows us to swap the original implementation with a test-specific version, often referred to as a test dummy (or test
double).
Mock: A mock serves as a more advanced test double for a dependency. Mocking frameworks let us actively simulate different behaviours by configuring the mock to return specific responses based on inputs or conditions. Furthermore, mocks allow us to confirm interactions by verifying the existence of a method, its number of calls, and the arguments passed during each call.
Why do we need this? During testing, especially unit testing, we aim to isolate the component under test from its dependencies. This ensures that we're testing the component alone, making the tests simpler, faster, and less error-prone. Mocking or stubbing helps us avoid injecting side effects or relying on external dependencies.
Example: Imagine a ViewModel class that depends on a repository. The Repository class, in turn, makes network API calls. If we want to write a unit test for the ViewModel alone, we don’t want to incur the overhead of making actual API calls, as this can make the test error-prone due to network conditions or server response times. To avoid these side effects, we can replace the repository with a stub (test double) or a mock during the test. This ensures that we focus only on the behaviour of the ViewModel while bypassing external dependencies.

Famous Unit Testing Frameworks

Framework	Description
Junit	Testing framework for Java
Mockito	Mocking framework for unit tests written in Java/Kotlin
Truth	To perform assertions in tests

Simple Test Without Mocks

In this test suite, we are validating the behavior of the isValid() method in the Email class. The isValid()
method checks whether the email provided is a valid email address or not. We are testing three key scenarios:

Null Email: Verifying that when the email value is null, the method returns false.
Invalid Email: Checking various invalid email formats to ensure that the method correctly returns false for them (e.g., missing domain, misplaced characters).
Valid Email: Confirming that the method correctly returns true for properly formatted email addresses.

Each test ensures the isValid() method behaves as expected under different conditions, guaranteeing that the email validation works correctly.

System Under Test

data class Email(val value: String?) : Parcelable {
    fun isValid(): Boolean {
        return if (value == null) false else PatternsCompat.EMAIL_ADDRESS.matcher(value).matches()
    }
}

Test

class EmailTest {

    @Test
    fun shouldReturnIsValidAsFalseWhenEmailIsNull() {
        Truth.assertThat(Email(null).isValid()).isFalse()
    }

    @Test
    fun shouldReturnIsValidAsFalseWhenEmailIsInvalid() {
        Truth.assertThat(Email("aa@.com").isValid()).isFalse()
        Truth.assertThat(Email("aacd@aa.com@").isValid()).isFalse()
        Truth.assertThat(Email("").isValid()).isFalse()
        Truth.assertThat(Email("@gmail.com").isValid()).isFalse()
    }

    @Test
    fun shouldReturnIsValidAsTrueWhenEmailIsValid() {
        Truth.assertThat(Email("abcd@domain.com").isValid()).isTrue()
        Truth.assertThat(Email("a@domain.in").isValid()).isTrue()
    }
}

Simple Test With Mocks

In this test, we are verifying the behavior of the ProfileViewModel class, specifically the retrieval of the email address from the SavedStateHandle. The test mocks the SavedStateHandle to simulate retrieving an email address from the saved state.

Mocking Dependencies: We use mockk to mock the SavedStateHandle and LogoutUseCase, which are dependencies in the ProfileViewModel.
Testing Behavior: The mock for SavedStateHandle is configured to return a predefined email address abcd@gmail.com when the KEY_EMAIL key is accessed.
Validation: After initializing the ProfileViewModel, we assert that the emailAddress property correctly retrieves the mocked email value from the SavedStateHandle.

This test ensures that the ProfileViewModel correctly reads the email address from the saved state during its initialization.

System Under Test

@HiltViewModel
class ProfileViewModel @Inject constructor(
  savedStateHandle: SavedStateHandle,
  private val logoutUseCase: LogoutUseCase
) : ViewModel() {
  val emailAddress = savedStateHandle.get<String>(BundleArgs.KEY_EMAIL)
}

Test

@Test
fun `should return email value from saved state handle when email address is read from viewModel`() {
  val savedStateHandleMock = mockk<SavedStateHandle>()
  every<String?> { savedStateHandleMock[BundleArgs.KEY_EMAIL] } returns "abcd@gmail.com"

  val logoutUseCase = mockk<LogoutUseCase>()

  val profileViewModel = ProfileViewModel(savedStateHandleMock, logoutUseCase)
  assertThat(profileViewModel.emailAddress).isEqualTo("abcd@gmail.com")
}

Test With Mocks and Stubs

In this test, we are testing the behavior of the ProfileViewModel class when the logout function is called, ensuring that the logout process is correctly triggered and the shouldLogout state is updated.

Let me use AAA test pattern to explain the test case. AAA stands for Arrange, Act, and Assert.

Arrange:: Mocking and Stub Dependencies: We mock the SavedStateHandle to simulate retrieving the email address from the saved state, and we stub the LogoutUseCase to simulate a successful logout without performing the actual logic.
Act:: Triggering Logout: The logout function is called on the ProfileViewModel, and the coroutine is run to completion using runCurrent().
Assert: The test asserts that after calling logout, the shouldLogout state is updated to true and that the logout function was successfully called, as indicated by the isLogoutSuccess flag being true.

This test ensures that the ProfileViewModel correctly handles the logout process, updating the appropriate states and interacting with the LogoutUseCase.

System Under Test

@HiltViewModel
class ProfileViewModel @Inject constructor(
  savedStateHandle: SavedStateHandle,
  private val logoutUseCase: LogoutUseCase
) : ViewModel() {
  val emailAddress = savedStateHandle.get<String>(BundleArgs.KEY_EMAIL)

  var shouldLogout by mutableStateOf(false)
    private set

  fun logout() {
    viewModelScope.launch {
      logoutUseCase.logout(Email(emailAddress))
      shouldLogout = true
    }
  }
}

Test

@Test
fun `should call logout callback when logout button is pressed`() = runTest(testDispatcher) {
    Dispatchers.setMain(testDispatcher)

    // Arrange    
    val savedStateHandleMock = mockk<SavedStateHandle>()
    every<String?> { savedStateHandleMock[BundleArgs.KEY_EMAIL] } returns "abcd@gmail.com"

    var isLogoutSuccess = false
    val logoutStub = object : LogoutUseCase {
      override suspend fun logout(email: Email) {
        isLogoutSuccess = true
      }
    }

    val profileViewModel = ProfileViewModel(savedStateHandleMock, logoutStub)

    // Act    
    profileViewModel.logout()
    runCurrent()  // run current co routine to completion

    // Assert    
    assertThat(profileViewModel.shouldLogout).isTrue()
    assertThat(isLogoutSuccess).isTrue()
  }

Dependencies

// Regular JUnit dependency
testImplementation("junit:junit:4.13.2")

// Assertion library
testImplementation("com.google.truth:truth:1.1.4")

// Allows us to create and configure mock objects, stub methods, verify method invocations, and more
testImplementation("io.mockk:mockk:1.13.5")

Command

./gradlew testDebugUnitTest

Source Code

https://github.com/sridhar-sp/android-test

Test Your Code, Rest Your Worries

With a sturdy suite of tests as steadfast as a fortress, developers can confidently push code even on a Friday evening and log off without a trace of worry.

Beyond Boundaries: Android Inter-Process Communication with AIDL

Sridhar Subramani — Sun, 29 Dec 2024 11:46:33 +0000

A step-by-step guide to implementing reliable cross-app services

What’s AIDL

AIDL (Android Interface Definition Language) is used to create a common interface for client-server communication in Android.

Both client and server can agree on the common interface to communicate with each other using IPC.

AIDL supports all Java primitive data types and a handful of wrapper data types, such as String, List, Map, Parcelable.

Android IPC

Note: Android apps can communicate using several methods; this guide focuses on IPC via AIDL.

What we are going to build

To demonstrate AIDL in action, we’ll build a practical example: a sensor data logging system consisting of two applications:

Server App:

A service that reads various sensors and provides APIs to:

Fetch real-time sensor values
Register callbacks for sensor value changes
Manage logging sessions

Client App:

Connects to the server app and consumes the sensor data
The client app will connect to the server app by binding with the service; once binding is complete, we get a binder object, which is the implementation of the AIDL interface we both agreed on. using this binder, we can call the API exposed from Server app

Service Connector

We will also discuss a small utility class that I created to take care of the boiler plate code when binding with a service.
ServiceConnector handles binding to services and manages retries when the server crashes or stops. It provides a getService method that ⁣suspends until a connection is established or a timeout occurs.
This will come in handy when the server app crashes/stops due to some reason. The next time we call the getService method, it takes care of binding with the service and returns the binder interface.

Let’s see some code

Step 1

Create an AIDL interface The files should have .aidl extension and should be placed inside a src/main/aidl folder

package com.gandiva.aidl.remoteservices;
import com.gandiva.aidl.remoteservices.SensorDataCallback;

interface SensorDataLoggerService {
    String getSpeedInKm();
    int getRPM();
    void startLogging(in SensorDataCallback callback);
    void stopLogging(in SensorDataCallback callback);
}

package com.gandiva.aidl.remoteservices;
import com.gandiva.aidl.remoteservices.model.SensorData;

interface SensorDataCallback {
    // Create a SensorData class, which should implement android.os.Parcelable interface, and placed in java/kotlin package.
    void onEvent(in SensorData data);
}

Create a SensorData class, which should implement the ⁣android.os.Parcelable interface, and place it in the Java/Kotlin package.

package com.gandiva.aidl.remoteservices.model

import android.os.Parcelable
import kotlinx.parcelize.Parcelize

@Parcelize
data class SensorData(val sensorID: Int, val value: Int) : Parcelable

We need to share this interface with both applications, so it would be advisable to create a library module and share the interface with the two apps. Take a look at this Android library module for reference.

Step 2

Create an Android Service to expose the Binder interface implementation from onBind method

class SensorDataLoggerServiceImpl : Service() {

  companion object {
    const val SENSOR_DATA_LOGGER_BIND_ACTION = "com.gandiva.aidl.server.action.BIND_SENSOR_DATA_LOGGER"
  }

  override fun onBind(intent: Intent): IBinder? {
    if (intent.action != SENSOR_DATA_LOGGER_BIND_ACTION) return null

    val binder = object : SensorDataLoggerService.Stub() {
      override fun getSpeedInKm(): String {
        TODO("Not yet implemented")
      }

      override fun getRPM(): Int {
        TODO("Not yet implemented")
      }

      override fun startLogging(callback: SensorDataCallback?) {
        TODO("Not yet implemented")
      }

      override fun stopLogging(callback: SensorDataCallback?) {
        TODO("Not yet implemented")
      }
    }
    binder.linkToDeath(DeathRecipient { Log.d("SensorDataLoggerService", "**** Service died") }, 0)
    return binder
  }
}

For brevity, the methods just have TODO; actual implementation can be found here

Step 3

The client can try to bind the exposed service from the server app using explicit intent.
Once the service is connected, we can typecast the IBinder instance to the AIDL interface type, which both apps agreed on step 1.

@HiltViewModel
class SensorDataLoggerViewModel @Inject constructor(val appContext: Application) : AndroidViewModel(appContext) {

  companion object {
    const val SENSOR_DATA_LOGGER_PKG_NAME = "com.gandiva.aidl.server"
    const val SENSOR_DATA_LOGGER_SERVICE_NAME = "com.gandiva.aidl.server.sensor.SensorDataLoggerServiceImpl"
    const val SENSOR_DATA_LOGGER_BIND_ACTION = "com.gandiva.aidl.server.action.BIND_SENSOR_DATA_LOGGER"
  }

  private var sensorDataLoggerService: SensorDataLoggerService? = null

  var isServiceConnected by mutableStateOf(false)
    private set

  private val serviceConnection = object : ServiceConnection {
    override fun onServiceConnected(name: ComponentName?, service: IBinder?) {
      isServiceConnected = true
      sensorDataLoggerService = SensorDataLoggerService.Stub.asInterface(service)
    }

    override fun onServiceDisconnected(name: ComponentName?) {
      isServiceConnected = false
    }
  }

  fun disconnectService() {
    appContext.applicationContext.unbindService(serviceConnection)
    isServiceConnected = false
  }

  // Should call this method before accessing [sensorDataLoggerService]
  fun connectToService(appContext: Context = this.getApplication()) {
    val bindIntent = Intent().apply {
      component = ComponentName(SENSOR_DATA_LOGGER_PKG_NAME, SENSOR_DATA_LOGGER_SERVICE_NAME)
      action = SENSOR_DATA_LOGGER_BIND_ACTION
    }

    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
      appContext.bindService(bindIntent, Context.BIND_AUTO_CREATE, appContext.mainExecutor, serviceConnection)
    } else {
      appContext.applicationContext.bindService(bindIntent, serviceConnection, Context.BIND_NOT_FOREGROUND)
    }
  }

  fun showSpeed() {
    val speedInKm = sensorDataLoggerService?.speedInKm // Assume service is connected
    Toast.makeText(appContext, "Speed $speedInKm", Toast.LENGTH_SHORT).show()
  }

  fun showRpm() {
    val rpm = sensorDataLoggerService?.rpm // Assume service is connected
    Toast.makeText(appContext, "RPM $rpm", Toast.LENGTH_SHORT).show()
  }
}

In the above code, we have to explicitly call the ⁣connectToService method to initialize the connection, and post connection only, we should call any method from the (AIDL) binder instance.
So our code works under the assumption that when a showSpeed method is called, it tries to call the AIDL API irrespective of the connection. This works in the best-case scenario, but the real world will be far from the best-case scenario. The server app can crash or stop, post-initial connection, leaving the last obtained AIDL binder instance as obsolete.
So, we should have a way to call the API only when the service is connected; we can modify the showSpeed method like below to call the API when the service is connected, or call connectToService and wait for the service connection; post we are eligible to call any API.

 fun showSpeed() {
  if (isServiceConnected) {
    val speedInKm = sensorDataLoggerService?.speedInKm
    Toast.makeText(appContext, "Speed $speedInKm", Toast.LENGTH_SHORT).show()
  } else {
    connectToService() // Async operation
    // Wait for service to connect then call API
    val speedInKm = sensorDataLoggerService?.speedInKm
    Toast.makeText(appContext, "Speed $speedInKm", Toast.LENGTH_SHORT).show()
  }
}

But we have to follow the same approach everywhere before calling the AIDL API to handle the worst-case scenario. But if we do that, it will introduce a lot of boilerplate code.
The best way to deal with this is to create a utility class that takes care of this complexity. Following is one example (i.e., ServiceConnector)

Service connector

ServiceConnector exposes a getService suspend function, which will suspend until a connection is made or timeOutInMillis expires.
This handles the service connection and retry logic internally, so clients don’t have to worry about the service connection or retry in case the server died or crashed.

interface IServiceConnector<T> {
  suspend fun getService(timeOutInMillis: Long = -1): T?

  suspend fun unbindService()

  fun onServiceConnected() {}
}

open class ServiceConnector<T>(
  private val context: Context,
  private val intent: Intent,
  val transformBinderToService: (service: IBinder?) -> T?,
  private val allowNullBinding: Boolean = false
) : IServiceConnector<T> {

  private var serviceConnected = false

  private var service: T? = null

  private val mutex = Mutex()

  private var lastServiceConnection: ServiceConnection? = null

  private val logTag = "Service :: ${this.javaClass}"

  override suspend fun getService(timeOutInMillis: Long): T? {
    // If allowNullBinding is true don't care what service object is
    if (serviceConnected && (allowNullBinding || service != null)) {
      return service
    }

    if (timeOutInMillis < 0)
      return mutex.withLock { bindAndGetService() }
    return mutex.withLock { withTimeoutOrNull(timeOutInMillis) { bindAndGetService() } }
  }

  private suspend fun bindAndGetService() = suspendCancellableCoroutine { continuation ->
    val serviceConnection = object : ServiceConnection {
      override fun onServiceConnected(name: ComponentName?, binder: IBinder?) {
        resumeWithServiceInstance(binder)
      }

      override fun onServiceDisconnected(name: ComponentName?) {
        cleanUpAndResumeIfRequired()
      }

      override fun onBindingDied(name: ComponentName?) {
        cleanUpAndResumeIfRequired()
      }

      override fun onNullBinding(name: ComponentName?) {
        if (allowNullBinding) resumeWithServiceInstance(null)
        else cleanUpAndResumeIfRequired()
      }

      private fun resumeWithServiceInstance(binder: IBinder?) {
        service = transformBinderToService(binder)
        serviceConnected = true
        if (continuation.isActive) continuation.resume(service)
        onServiceConnected()
      }

      private fun cleanUpAndResumeIfRequired() {
        service = null
        serviceConnected = false
        if (continuation.isActive) continuation.resume(null)
      }

    }

    context.bindService(
      intent, serviceConnection, Context.BIND_AUTO_CREATE
    )

    lastServiceConnection = serviceConnection
  }

  @Throws(Exception::class)
  override suspend fun unbindService() {
    lastServiceConnection?.let(context::unbindService)
    serviceConnected = false
    service = null
  }
}

Extend the ServiceConnector and provide necessary information about the service to which we want to connect and the type of the binder interface.
context Context used to bind the service.
intent Explicit intent describing the service to connect.
transformBinderToService callback function called to transform the generic IBinder instance to the client-specific AIDL interface.
allowNullBinding Pass true to indicate to keep the server connected even if the server returns a null IBinder instance from the onBind method.

class SensorDataLoggerServiceCoordinator(context: Context) : ServiceConnector<SensorDataLoggerService>(
  context = context,
  intent = bindIntent(),
  transformBinderToService = { binder: IBinder? -> binder?.let { SensorDataLoggerService.Stub.asInterface(it) } },
  allowNullBinding = false
) {

  companion object {
    private const val SENSOR_DATA_LOGGER_PKG_NAME = "com.gandiva.aidl.server"
    private const val SENSOR_DATA_LOGGER_SERVICE_NAME = "com.gandiva.aidl.server.sensor.SensorDataLoggerServiceImpl"
    private const val SENSOR_DATA_LOGGER_BIND_ACTION = "com.gandiva.aidl.server.action.BIND_SENSOR_DATA_LOGGER"

    fun bindIntent(): Intent {
      return Intent().apply {
        component = ComponentName(SENSOR_DATA_LOGGER_PKG_NAME, SENSOR_DATA_LOGGER_SERVICE_NAME)
        action = SENSOR_DATA_LOGGER_BIND_ACTION
      }
    }
  }
}

To use create an instance of SensorDataLoggerServiceCoordinator and use the getService method to obtain the binder instance

@HiltViewModel
class SensorDataLoggerViewModelV2 @Inject constructor(val appContext: Application) : AndroidViewModel(appContext) {

  private val sensorDataLoggerServiceCoordinator: SensorDataLoggerServiceCoordinator by lazy {
    SensorDataLoggerServiceCoordinator(context = appContext)
  }

  fun showSpeed() {
    viewModelScope.launch {
      // Suspend till service gets connected.
      val speedInKm = sensorDataLoggerServiceCoordinator.getService()?.speedInKm
      Toast.makeText(appContext, "Speed $speedInKm", Toast.LENGTH_SHORT).show()
    }
  }

  fun showRPM() {
    viewModelScope.launch {
      // Suspend till service gets connected. or at max 1500 ms. which ever comes first.
      val rpm = sensorDataLoggerServiceCoordinator.getService(1500L)?.rpm
      Toast.makeText(appContext, "RMP $rpm", Toast.LENGTH_SHORT).show()
    }
  }

  fun disconnectService() {
    viewModelScope.launch { sensorDataLoggerServiceCoordinator.unbindService() }
  }
}

Links:
ServiceConnector

Repo:
https://github.com/sridhar-sp/android-playground/tree/main/AIDL

Simplify Your Android Builds: A Guide to Convention Plugins

Sridhar Subramani — Sun, 29 Dec 2024 11:30:07 +0000

Simplify Your Android Builds: A Guide to Convention Plugins

Learn How to Create and Use Custom Gradle Plugins

Photo by Birger Strahl on Unsplash

What’s a Convention Plugin

A convention plugin is a structured approach to organizing Gradle files, which can be used as a plugin within the Gradle
module.

Benefits

Reusable: Plugins can be reused across multiple Gradle modules, enhancing consistency and efficiency.
Easy to Maintain: Complex build logic can be developed by extending or composing other build logic and can be encapsulated into dedicated plugins (such as ArtifactDeploymentPlugin, AndroidLibraryPlugin, and AndroidComposePlugin, etc.) for ease of use.
Easy to Consume: By applying plugins, users can easily add new features to their build process without having to write complex code from scratch again.
Testable Build Logic: The build logic can be tested using TestKit to verify its behavior. (Yet to try this)

How to Add This Convention Plugin

Step 1: Create the `build-logic` Folder

Create a separate build-logic folder to organize your convention plugin code and separate it from the rest of your project’s code.
At the root level, create a settings.gradle.kts file with the following content:

     dependencyResolutionManagement {

          repositories {
              google()
              mavenCentral()
          }

          versionCatalogs {
              create("libs") {
                  from(files("../gradle/libs.versions.toml")) // Create this file if not present.
              }
          }
      }

      rootProject.name = "build-logic"
      // include(":convention") // Enable this line only after step 2

Inside the project’s settings.gradle.kts, add includeBuild(“build-logic”) within the pluginManagement block.

      pluginManagement {

          includeBuild("build-logic") // Include the build-logic

          repositories {
              // ...
              gradlePluginPortal()
          }
      }

      // ...

Step 2: Create the Build Convention Module

Add a new Java/Kotlin module under build-logic and name it as convention. In this example, the package name is com.droidstarter.convention.
Ensure that any entry like include(“:build-logic:convention”) in the root settings.gradle.kts file is removed (Studio will add this entry automatically when a new module is created).
Replace the script in the convention module’s build.gradle.kts with:

    plugins {
        `kotlin-dsl`
    }

    group = "com.droidstarter.buildlogic" // Package name for the our plugins

    java {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }

    dependencies {
        compileOnly(libs.android.gradlePlugin)
        compileOnly(libs.kotlin.gradlePlugin)
    }

    gradlePlugin {
        plugins {
            // Will add in next step
        }
    }

Add the following dependencies to libs.versions.toml:

    [versions]
    androidGradlePlugin = "8.0.2" # use latest version
    kotlin = "1.9.22" # use latest version

    [libraries]
    android-gradlePlugin = { group = "com.android.tools.build", name = "gradle", version.ref = "androidGradlePlugin" }
    kotlin-gradlePlugin = { group = "org.jetbrains.kotlin", name = "kotlin-gradle-plugin", version.ref = "kotlin" }

Add include(“:convention”) to the settings.gradle.kts file in the build-logic module, then perform a Gradle sync.

Step 3: Create a Custom Gradle Convention Plugin

First, set up a basic convention plugin named AndroidApplicationComposeConventionPlugin. This plugin will centralize
all the build configurations needed for setting up an Android project with Jetpack Compose.
ImplementPlugin<Project> to define and apply custom configurations.

    class AndroidApplicationComposeConventionPlugin : Plugin<Project> {
        override fun apply(target: Project) {
            println("*** AndroidApplicationComposeConventionPlugin invoked ***")
            // Additional configuration here...
        }
    }

    plugins {
        `kotlin-dsl`
    }

    // ...

    gradlePlugin {
        plugins {
            create("androidApplicationCompose") {
                id = "com.droidstarter.convention.application.compose" // This is the id we used to resolve our plugin.
                implementationClass = "com.droidstarter.convention.AndroidApplicationComposeConventionPlugin"
            }
        }
    }

Apply the newly created plugin to your app module or any Android application module.

    plugins {
        id("com.droidstarter.convention.application.compose")
    }

Perform a Gradle sync, and you should now see the following logs in the build window:

**** AndroidApplicationComposeConventionPlugin invoked ****

Step 4: Configure the Plugin for Android App with Jetpack Compose Build Logic

Apply the Android and Kotlin plugins within your convention plugin so that when it is applied, those plugins are automatically included. This allows you to remove them from the app module’s build.gradle.kts.

    class AndroidApplicationComposeConventionPlugin : Plugin<Project> {
        override fun apply(target: Project) {
            println("*** AndroidApplicationComposeConventionPlugin invoked ***")
            with(target) {
                with(pluginManager) {
                    apply("com.android.application") // Include android application plugin
                    apply("org.jetbrains.kotlin.android") // Ensure project build.gradle declared this plugin
                }
            }
        }
    }

Configure common settings like compileSdk, minSdk, targetSdk, sourceCompatibility, targetCompatibility, and kotlinJvmTarget.
Set up Jetpack Compose configuration, including enabling compose features and adding necessary dependencies.

class AndroidApplicationComposeConventionPlugin : Plugin<Project> {
        override fun apply(target: Project) {
            println("*** AndroidApplicationComposeConventionPlugin invoked ***")
            with(target) {
                with(pluginManager) {
                    apply("com.android.application")
                    apply("org.jetbrains.kotlin.android") // Ensure project build.gradle declared this plugin
                }

                extensions.configure<ApplicationExtension> {
                    configureKotlinAndroid(this)
                    defaultConfig.targetSdk = 34
                }
            }
        }
    }


    internal fun Project.configureKotlinAndroid(commonExtension: CommonExtension<*, *, *, *>) {
        val libs = extensions.getByType<VersionCatalogsExtension>().named("libs")

        commonExtension.apply {
            compileSdk = 34

            defaultConfig {
                minSdk = 29
            }

            compileOptions {
                sourceCompatibility = JavaVersion.VERSION_11
                targetCompatibility = JavaVersion.VERSION_11
            }

            buildFeatures {
                compose = true
            }

            composeOptions {
                // Add androidxComposeCompiler in toml
                kotlinCompilerExtensionVersion = libs.findVersion("androidxComposeCompiler").get().toString()
            }

            dependencies {
                // Add androidx-compose-bom in toml
                val bom = libs.findLibrary("androidx-compose-bom").get()
                add("implementation", platform(bom))
                add("androidTestImplementation", platform(bom))
            }
        }

        tasks.withType<KotlinCompile>().configureEach {
            kotlinOptions {
                jvmTarget = JavaVersion.VERSION_11.toString()
            }
        }
    }

Add the following dependencies to libs.versions.toml:

    [versions]
    androidxComposeCompiler = "1.5.10" # use latest version
    androidxComposeBom = "2024.02.01" # use latest version

    [libraries]
    androidx-compose-bom = { group = "androidx.compose", name = "compose-bom", version.ref = "androidxComposeBom" }

Conclusion

If the steps outlined above feel overwhelming, you can simplify the process by cloning the Android template repository available at my GitHub.
This repository already contains the essential build configurations and boilerplate setups, including Hilt, JaCoCo test reporting, and plugins for Android Library and Jetpack Compose, among other features.

Build a Distributed Task Scheduler Using RabbitMQ and Redis

Sridhar Subramani — Sun, 29 Dec 2024 11:16:23 +0000

Build a Distributed Task Scheduler Using RabbitMQ and Redis

Delay Task Execution Using RabbitMQ deadLetterExchange

Are you interested in building a task scheduler using RabbitMQ?

You may wonder why one should build a task scheduler using RabbitMQ given that it’s a message broker and has no reason to behave as a scheduler.

Well, a year ago, I was working on a hobby project where I wanted to use RabbitMQ and I happened to have a requirement of executing a piece of code after a certain time. A delayed task execution we can call it.

This is where I got curious, wondering if it is possible to delay the message execution. In other words, let’s say a message has been sent to a queue at x time and I want to consume it at x+y time, where y is configurable per message/task.

I was able to achieve this using deadLetterExchange. This is a RabbitMQ feature. By using this RabbitMQ feature as core logic, I was able to specify how much time should elapse before the consumer can consume the task or message.
But it’s not a task scheduler yet, it’s simply a delayed task execution. A task scheduler should be able to schedule and cancel tasks. Well, this is where Redis comes into play to make this into a task scheduler.

I hope the above content helps to set the context here. Let’s dive in.

Prerequisites

As part of this post, we are not going to discuss the introduction of RabbitMQ and Redis. It is assumed that you have at least a basic understanding of RabbitMQ and Redis. The sample project which is discussed here is written on NodeJS. Knowledge of NodeJS would be helpful, but it is not required.

How to achieve delayed task execution

RabbitMQ will forward the messages to the corresponding queue as soon as they are available. There is no direct way we can tell RabbitMQ to keep the message somewhere and send it to the expected queue after y time.
Let’s see how we can achieve this by using deadLetterExchange .

Dead Letter Exchanges

Messages from a queue can be dead-lettered (i.e., republished to an exchange) when any of the following events occurs:

The message is negatively acknowledged by a consumer.
The message expires due to per-message TTL.
The message was dropped because its queue exceeded a length limit.

We are going to use the second option (i.e per-message TTL) to trigger the deadLetterExchange. Let’s see it in detail.

TTL stands for Time To Live

Let’s set a TTL for each of our messages and send them to a queue. Let’s call it an intermediate queue. When declaring an intermediate queue, we set an option that when messages in this queue expire, they should be delivered to another specified exchange. Let’s call it the final exchange.

The message TTL time is the time we want to delay. The final exchange is where our consumers will consume messages from a specified queue.

So, once the message TTL expires, our consumer receives the message.

Now the question is, how do we let the message expire? It’s simple. We are sending the message to the intermediate queue right. Let’s not allow anyone to consume it from here. If the messages in this intermediate queue are not consumed till the specified TTL, then they are dead-lettered and the message will be delivered to our consumer who is happily consuming messages from the queue of final exchange.

By setting this TTL as the delay we require, and sending the message to an intermediate queue where there are no consumers, we can achieve a delayed task execution on RabbitMQ.

Below is the UML diagram to achieve delayed task execution on RabbitMQ using dead letter exchange.

RabbitMQ delayed task execution using dead letter exchange

But delayed task execution is not a task scheduler, right. Let’s see how we can build a task scheduler that will provide the option to schedule and cancel tasks using RabbitMQ and Redis.

Task Scheduler

The Role of Redis

Redis is used to track the validity of the scheduled task. Using this, we can set any scheduled task as invalid if required, and when it’s time to execute the task, we can check whether the task is valid to execute or not.

Since we would be using Redis to only store task validity information, it can be replaced with any data storage tool.

Architecture

task scheduler architecture

The list entities we’d use to build this task scheduler are as follows.

Task → Task definition.
Producer → Base class provides option to send delayed message.
Consumer → Base class to consume messages from final queue.
Task Repository → Repository class to check the task validity status.
Task Scheduler → Class provides the option to schedule and invalidate tasks.
Task Consumer → Class to consumes tasks from specified task type queue.

Task

    class Task {
      public taskId: string;
      public taskType: string; // queue name
      public ttlInSeconds: number;
      public payload: string;
    }

taskId → Unique id to identity this task.
taskType → Type of this task. this is used as a queue name so both producer and consumer can infer name the from the task type.
ttlInSeconds → The time delay after which we want this task to get executed.
payload → A JSON string describing the task; The taskType will come in handy to parse this json as per the different task types.

The taskType plays an important role. It acts as a queue name, so when a task scheduler wants to schedule a task, it can use taskType as a queue name, and whoever wants to consume the particular task type can consume it from that queue.

Following are some of the examples of taskType send-sms, send-offer-notification, send-greetings etc

Producer

    public sendDelayedMessageToQueue(taskType: string, delayInMills: number, data: string): Promise<void> {
        const INTERMEDIATE_QUEUE = `${taskType}_INTERMEDIATE_QUEUE`;
        const INTERMEDIATE_EXCHANGE = `${taskType}_INTERMEDIATE_EXCHANGE`;
        const INTERMEDIATE_EXCHANGE_TYPE = "fanout";

        const FINAL_QUEUE = taskType;
        const FINAL_EXCHANGE = `${taskType}_FINAL_EXCHANGE`;
        const FINAL_EXCHANGE_TYPE = "fanout";

        return new Promise((resolve, reject) => {
          this.assertExchange(INTERMEDIATE_EXCHANGE, INTERMEDIATE_EXCHANGE_TYPE)
            .then((_) => this.assertExchange(FINAL_EXCHANGE, FINAL_EXCHANGE_TYPE))
            .then((_) => this.assertQueue(INTERMEDIATE_QUEUE, { deadLetterExchange: FINAL_EXCHANGE }))
            .then((_) => this.assertQueue(FINAL_QUEUE, {}))
            .then((_) => this.bindQueue(INTERMEDIATE_QUEUE, INTERMEDIATE_EXCHANGE, ""))
            .then((_) => this.bindQueue(FINAL_QUEUE, FINAL_EXCHANGE, ""))
            .then((_) => {
              this.channel?.sendToQueue(INTERMEDIATE_QUEUE, Buffer.from(data), {
                expiration: delayInMills, // The delay after which we want to send this message
              });
              resolve();
            })
            .catch(reject);
        });
      }

As we discussed earlier, we need two queues to achieve this delayed task execution.

Intermediate queue → Holds the task till expiration; post expiration forwards the task to final exchange.
Final queue → This is associated with the final exchange. Our task consumer will listen to this queue.

Both the queue and its associated exchange names are formed from taskType to bring in some sort of contract between scheduler and consumer.

From the above code, we can see the intermediate queue is associated with the final exchange as a dead letter exchange.

    this.assertQueue(
        INTERMEDIATE_QUEUE, { deadLetterExchange: FINAL_EXCHANGE }
    )

Once the task expiration time has elapsed, the task will be forwarded to the final exchange, and the final exchange will route the task to the final queue.

    sendToQueue(INTERMEDIATE_QUEUE, Buffer.from(data), {
        expiration: delayInMills,
    });

Consumer

      public consume(taskType: string, handler: (payload: string) => void) {
        const FINAL_QUEUE = taskType;
        const FINAL_EXCHANGE = `${taskType}_FINAL_EXCHANGE`;
        const FINAL_EXCHANGE_TYPE = "fanout";

        this.assertExchange(FINAL_EXCHANGE, FINAL_EXCHANGE_TYPE)
          .then((_) => this.assertQueue(FINAL_QUEUE, {}))
          .then((_) => this.bindQueue(FINAL_QUEUE, FINAL_EXCHANGE, ""))
          .then((_) => {
            this.channel?.consume(
              FINAL_QUEUE,
              (msg: Message | null) => {
                handler(msg?.content ? msg?.content.toString() : "");
              },
              { noAck: true }
            );
          });
      }

A consumer will consume messages from a specific queue (i.e. taskType).

Task Repository

    interface TaskRepository {
      createTask(taskId: string, ttlInSeconds: number): Promise<void>;
      deleteTask(taskId: string): Promise<void>;
      isTaskValid(taskId: string): Promise<boolean>;
    }

This provides options to create, delete, and validate tasks.

Task Scheduler

    scheduleTask(delayInMilliseconds: number, task: Task): Promise<string> {
       return new Promise((resolve: (taskId: string) => void, reject: (error: Error) => void) => {
         this.taskRepository
           .createTask(task.taskId, task.ttlInSeconds)
           .then(() => this.producer.sendDelayedMessageToQueue(task.taskType, delayInMilliseconds, task.toJson()))
           .then(() => resolve(task.taskId))
           .catch((error) => reject(error));
       });
    }


    invalidateTask(taskId: string): Promise<void> {
        return this.taskRepository.deleteTask(taskId);
    }

The Task Scheduler will create a task entry in Redis when scheduling a task.
When we no longer want the task to be executed, the task can be deleted to mark it as invalid. The scheduleTask returns a taskId. The same can be used to invalidate the task if required.

Task Consumer

    consume(taskType: string, handler: (task: Task) => void): void {
        this.consumer.consume(taskType.toString(), async (payload: string) => {
          const task = Task.fromJson(payload);
          const isTaskValid = await this.taskRepository.isTaskValid(task.taskId);

          if (isTaskValid) handler(task);
        });
    }

The Task Consumer will listen for a specific taskType and execute it if the task is still valid.
Even after we invalidate the task by deleting it. It will be consumed by the consumer at the scheduled time. It will be the Task Consumer responsibility to check the task validity before executing the task using isTaskValid function from the Task Repository.

Demo

The demo includes two consumers and two producers.
Consider consumer 1 and 2 as email services, each microservice responsible for sending greetings and offer notification to customers.
The greeting and offer-notification are two different task types which will be produced by Greeter-Service and Offer-Notification-Service producers respectively.

The demo shows that Email-Service-1 (i.e., consumer 1) will process both greet and offer-notification tasks, where as Email-Service-2 (i.e., consumer 2) will process only offer-notification tasks.

Due to brevity, the task invalidation is not shown on the demo but is explained in the project Readme file.

I tried my best to animate and highlight log messages to indicate the event flow between scheduler and consumer. The log message includes a timestamp, which can be used to assert whether the consumer is getting a task notification at the expected scheduled time or not. I have highlighted the timestamp on both the scheduler and the consumer whenever the consumer receives a task.

Source Code

https://github.com/sridhar-sp/task-scheduler

Reference

https://www.rabbitmq.com/dlx.html
https://github.com/sridhar-sp/draw-server (Multiplayer drawing game using this task-scheduler)
https://play.google.com/store/apps/details?id=com.gandiva.draw (Production app using this task-scheduler)

Build a Tic-Tac-Toe Game In the GitHub README.md File

Sridhar Subramani — Sun, 29 Dec 2024 10:12:01 +0000

Pushing the boundaries of the markdown file using Go

What would be your initial response when someone asked “is it possible to play a tic-tac-toe game from Github README.md file” ?

If your answer is “yes”, then you are in for a delight.

Let’s dive in and see how it’s possible to make a Github README.md file as a frontend for a tic-tac-toe game.

How It All Started

You may ask why I even went on this journey, and the following are a few of the reasons behind it.

I wanted to push the boundaries of a markdown file and make it as interactive as possible.
to uniquely identify and track the traffic coming to my individual GitHub project page.

Why did I even get these wild ideas in the first place? Well, it’s because whenever I add an image or image link to the GitHub readme markdown file, it’s always getting replaced with a proxy URL when I try to open the image(proxy URL looks like this: https://camo.githubusercontent.com/some-hash ).

I wondered why it was happening like that. I mean, it’s okay to proxy an external URL, but why are even static images placed in repositories getting a proxy URL when they’re referenced from a readme file? What is GitHub trying to achieve here?

Then I thought about what would happen if there was no proxy server involved while serving the images. If there is no proxy, then the HTTP request to fetch the image will directly come to our server(where we host the image) and we can read the HTTP request and try to get a user IP address, which can be used for any tracking purposes and GitHub will have no control over it.

So I kind of understood the reason behind why Github added the image proxy server. At this stage, I wanted to know whether it’s possible to get any unique identification from the HTTP request made from the user machine as part of rendering the markdown file.

I hoped there would be a way to uniquely identify each session/machine. So I thought of building a simple game that can be played from within the markdown file itself to test that. The idea was to build a multiplayer game where each player would have their own state saved against a unique id. “Tic-tac-toe” game seems to be a good fit for this, since it’s a well-known game, and it’s fairly straightforward to implement.

After I started the development, I quickly found out there was no way we could get a unique id from the http request fired from the readme markdown file. This is because each time a request comes from a random proxy server, and on top of that, cookies are not allowed either.

So, without a unique id, there won’t be any states saved for each player, and individual gameplay is impossible. Therefore, only a single gameplay will be shared with the entire internet. (In other words, anyone in the world can see and play the game, but only one gameplay is visible to everyone; changes made by one are reflected to all.)

At this stage, I thought of abandoning the quest, but playing a game from the Github README.md file itself seems like a cool idea, even when the gameplay is shared with the entire internet. So I ran this idea by my friends, and they seemed interested in seeing how this would turn out, so I thought of investing some time in developing this.

Quick Recap

GitHub uses a proxy server to serve media content, and each time a random proxy server will be used to serve media (when the cache is disabled).
The proxy server doesn’t allow us to store cookies.
And we would like to make markdown interactive with a dynamic UI.

The Life Cycle of an HTTP Request From a GitHub Markdown File

Let’s consider the below Github project structure — where we have localImageFile.png and README.md file.

The README.md file shows two images, one from the repository itself and the other from a remote server.

Github project structure

The below sequence diagram is illustrated for loading localImageFile.png from the same repo:

Local image loading sequence

The below sequence diagram is illustrated for loading remoteImage.png from the remote server:

Remote image loading sequence

Let’s Build the Tic-Tac-Toe

Building APIs for the game — We are going to build a backend server that exposes APIs to start the game, restart the game, read the current state of the game, make a move from the user, and read the history of the game state.
How do we call these APIs from a Github Readme Markdown file — Well, we are going to create CTAs (call to action) for each of the APIs and call the APIs whenever the CTAs are clicked.
How do we create CTAs on Markdown files — For CTAs, we will use images, and when the image is clicked, an HTTP request will be fired from the markdown file.
How do we show the tic-tac-toe board on UI — You might have already guessed it. We will use images to reflect the current state of the game.

In short, the backend will return a set of images we can use as CTA, and when clicking the images, we fire the corresponding API which will manipulate the game state.

As I mentioned earlier, since we can’t identify the request made from the same system, only one gameplay will be shared with the entire internet. Hence, the backend maintains the game state of the 3x3 tic-tac-toe in a single variable. The APIs that are exposed will basically try to modify this single game state and reflect the same on the UI (i.e. the README file) using images sent from the server.

Image assets stored on the backend server

Please keep the svg file names in mind as we will go over the uses for each image file shortly.

Image assets stored on the backend server

The backend server is written in Go:

func main() {
    port := getPort()
    log.Println("Starting tic-tac-toe service at port ", port)

    http.Handle("/", http.HandlerFunc(onHome))
    http.Handle("/renderCell", http.HandlerFunc(onRenderCell))
    http.Handle("/clickCell", http.HandlerFunc(onClickCell))
    http.Handle("/renderPlayControls", http.HandlerFunc(onRenderPlayControl))
    http.Handle("/clickPlayControls", http.HandlerFunc(onPlayControlClick))
    http.Handle("/renderActivities", http.HandlerFunc(renderActivities))

    http.ListenAndServe(":"+port, nil)
}

Let’s look at each API and see what it does!

Render cell

The renderCell API takes cell index as a URL parameter and returns the cell image. For a 3x3 tic-tac-toe game, we have nine cells to render. The backend returns the corresponding cell image based on the cell’s state.
rect_x.svg is returned when the user has pressed that cell.
rect_o.svg is returned when the computer has pressed that cell.
rect_empty.svg is returned when no one has pressed that cell.
rect_x_selected.svg is returned to highlight the area won by the user.
rect_o_selected.svg is returned to highlight the area won by the computer.

Click cell

The clickCell API takes the cell index as a URL parameter and marks the cell as selected by the user (provided the cell is empty).
The clickCell API is attached to the anchor link of each cell that is rendered by the renderCell API.

Please see the screenshot below to see the markdown file content and its preview:

Markdown file content with a preview

When each cell is clicked, the server modifies the game state and reloads the page so that the new modified state can be read from the server.
Page reloading is a mandatory step. Since this is a markdown file, this is the only way to get the modified state from the server.

Reload the page

This is one of the crucial steps. Remember how GitHub uses an image proxy server to serve media files? Well, that image proxy caches the response for a certain amount of time. So we need to add the cache control response header as ‘no-cache,no-store,must-revalidate’ to disable this cache mechanism.

If we don’t disable the cache mechanism, then the proxy server will simply return the cached response and will not call our backend till the cache expires. Therefore, we won’t be able to reflect the current game state back to the user, and we will end up showing stale data (not a good user experience).

    const REDIRECT_URL = "https://github.com/sridhar-sp/tic-tac-toe"

    responseWriter.Header().Set("Content-Type", "image/svg+xml") 

    responseWriter.Header().Set("Cache-Control", "no-cache,
    no-store,must-revalidate")

    responseWriter.Header().Set("expires", "0") 
    responseWriter.Header().Set("pragma", "no-cache")

    http.Redirect(
     responseWriter, req, 
     REDIRECT_URL, http.StatusMovedPermanently
    )

Render play controls

The renderPlayControls API returns computer_start_button.svg when the game is yet to begin and restart_button.svg when the game is finished.

Click play controls

This API is attached as an anchor to renderPlayControls
When the play control button is pressed, the corresponding action takes place on the backend, such as restarting the game or letting the computer make the first move.

Please see the screenshot below to see the play control markdown file content and its preview:

Play controls preview

Render game activities

The renderActivities API returns all game activities in svg image format.

Please see the screenshot below to see the game activities markdown file content and its preview:

Game activities preview

Demo

`Player ‘X’ is a human, and Player ‘O’ is a computer.`

Please see the screenshot below to see the markdown file content and its preview:

Click here to see Markdown file with its interactive preview

Source Code

Here are the GitHub repositories for the final frontend application and the backend written in Go:

Reference

Library used

https://github.com/ajstarks/svgo

Build Android App Widgets With Jetpack Glance

Sridhar Subramani — Sun, 29 Dec 2024 09:43:41 +0000

A modern approach to building android app widgets.

Before diving into the topic, let’s quickly take a history lesson to see why this Glance is an important and long-awaited feature.

Android app widgets were released as part of Android 1.5 (Cupcake).
Code inception in 2009.
In 2012 support added to display widgets on the lock screen, and provided third party apps to act as widget host (custom launcher application) and etc.
Over the period of time android system grew and received a lot of updates on the other part of the system but got very few updates over the widget framework.

Android 12 introduces Glance framework to create app widgets using jetpack-compose (declarative style) and much more additional updates to the widget framework itself.

What’s new in Android 12

Jetpack Glance for app widgets

Declarative API to build app widget UI.
Stateful widgets.
New clean api to handle user interaction.
Custom error UI (from XML).

Other updates on the widget framework

Scalable widget preview
Better theming support
New compound buttons
New API’s added to allow runtime modification of RemoteViews

Jetpack Glance for app widgets

What is Jetpack Glance

Jetpack Glance is a new framework built on top of the Jetpack Compose runtime.
Glance offers similar modern declarative Kotlin APIs that come with Jetpack Compose which helps to build responsive app widgets.
As it builds on top of Jetpack Compose runtime it’s not directly interoperable with other existing Jetpack Compose UI elements but interoperable with existing RemoteViews.
Glance provides a base set of composables to help build “glanceable” experiences.
Using the Jetpack Compose runtime Glance can translate composables into actual RemoteViews and display them in an app widget.
Glance provides a more intuitive API to handle user interactions. It abstracts away the complexities we would encounter while using RemoteViews and PendingIntent. It provides the following predefined actions for handling user interactions.
1) actionRunCallback
2) actionStartActivity
3) actionStartService
4) actionSendBroadcast
Inbuilt support for different size UI by defining SizeMode.Single, SizeMode.Exact or SizeMode.Responsive.
State management using GlanceStateDefinition.
LocalContext, LocalState, LocalGlanceId, LocalSize. LocalAppWidgetOptions are provided to the content() method using CompositionLocalProvider.

Even though the Glance framework seems like a fundamental change to the app widget. The creation of the app widget is pretty much the same and the only change is in how we represent the UI and maintain the state.

Create GlanceAppWidget

Step 0: Add dependency

    dependencies {
        // For AppWidgets support
        implementation "androidx.glance:glance-appwidget:1.0.0-alpha04"

        // For Wear-Tiles support
        implementation "androidx.glance:glance-wear-tiles:1.0.0-alpha04"
    }

    android {
        buildFeatures {
            compose true
        }

        composeOptions {
            kotlinCompilerExtensionVersion = "1.1.0-beta03"
        }

        kotlinOptions {
            jvmTarget = "1.8"
        }
    }

Step 1: Create GlanceAppWidget

    package com.gandiva.glance.resizeable.widget

    import androidx.compose.runtime.Composable
    import androidx.glance.appwidget.GlanceAppWidget
    import androidx.glance.text.Text

    class SimpleGlanceAppWidget : GlanceAppWidget() {

        @Composable
        override fun Content() {
            Text(text = "Hello!")
        }
    }

Step 2: Attach with GlanceAppWidgetReceiver

    package com.gandiva.glance.resizeable.widget

    import androidx.glance.appwidget.GlanceAppWidget
    import androidx.glance.appwidget.GlanceAppWidgetReceiver

    class SimpleGlanceAppWidgetReceiver : GlanceAppWidgetReceiver() {
        override val glanceAppWidget: GlanceAppWidget
            get() = SimpleGlanceAppWidget()
    }

Step 3: Add widget meta-data

    <?xml version="1.0" encoding="utf-8"?>
    <appwidget-provider   xmlns:android="http://schemas.android.com/apk/res/android"
        android:description="@string/app_widget_description"
        android:initialLayout="@layout/simple_widget"
        android:previewLayout="@layout/simple_widget"
        android:minWidth="250dp"
        android:minHeight="110dp"
        android:resizeMode="horizontal|vertical"
        android:widgetCategory="home_screen"
        android:previewImage="@drawable/appwidget_preview"
        android:maxResizeWidth="1050dp"
        android:maxResizeHeight="787dp"
        android:targetCellWidth="5"
        android:targetCellHeight="3"
        />

Final step: Register component in AndroidManifest.xml

    <receiver
        android:name=".resizeable.widget.SimpleGlanceAppWidgetReceiver"
        android:exported="true">
        <intent-filter>
            <action android:name="android.appwidget.action.APPWIDGET_UPDATE" />
        </intent-filter>

        <meta-data
            android:name="android.appwidget.provider"
            android:resource="@xml/simple_glance_widget_info" />
    </receiver>

Stateful widget

Each GlanceAppWidget maintains its own preference to store data as key-value pair using Datastore preference.

To read the widget state use currentState method from local composition (i.e LocalState.current). currentState has two overloaded methods:

currentState with no argument returns a Preferences.

currentState with key as argument(i.e currentState(key)) returns a value associated with the key.

To update data into the preference we can use updateAppWidgetState()

Once the preference is updated using updateAppWidgetState() we have to manually call GlanceAppWidget.update() method to recompose the UI with latest data.

Let’s look at the below code to see how we are updating the boolean preference value to toggle the widget theme.

`Stateful widget code`

`Stateful widget demo`

User interaction

As we discussed earlier Glance provides more intuitive APIs to handle user interaction and actionRunCallback is one of them.

actionRunCallback method returns an Action that can be attached to the onClick method of a button or any other Glance component with onClick attribute.
actionRunCallback method takes ActionCallback class as a type parameter and optional ActionParameters as method argument.

Let’s look at the below code whenever the button is clicked an instance of ToastActionCallback will be created and onRun method will be called on that with context, glanceId and the parameters we passed (i.e ActionParameters).

PS: glanceId is a unique id assigned to each GlanceAppWidget.

Handler user interaction with actionRunCallback (with action parameters)

Just like actionRunCallback we have other API to start a service (i.e actionStartService), start an activity (i.e actionStartActivity) or send a broadcast (i.e actionSendBroadcast) also.

Different size

SizeMode.Single

When the widget size mode is SizeMode.Single then the GlanceAppWidget provides a single UI. The width and height of the app widget will be the minimum width and height given in app widget info.

Single size mode widget demo

SizeMode.Exact

When the widget size mode is SizeMode.Exact then the GlanceAppWidget provides a UI for each size the App Widget can be. (i.e any one of the possible size from supported grid. click here for more detail).

Exact size mode widget demo

SizeMode.Responsive

When the widget size mode is SizeMode.Responsive then the GlanceAppWidget provides a UI for a fixed set of sizes.
SizeMode.Responsive takes a set of fixed sizes from it's constructor.

Responsive size mode widget demo

Other updates on the widget framework

Apart from the Glance framework the existing widget framework also got some really good updates. lets see some of those.

Scalable widget preview

In Android 11 or below android:previewImage is used to show how the widget would look like
Since it’s an image, every time we update the widget design we have to change the image as well which would require some design effort.
Starting from Android 12 the widget preview can be derived from an XML layout, which results in better accuracy in reflecting how the actual widget will look like

<appwidget-provider
    ...
    android:description="@string/app_widget_description"
    android:targetCellWidth="3"
    android:targetCellHeight="3"
    android:previewLayout="@layout/my_widget_preview">
</appwidget-provider>

Ref::https://developer.android.com/develop/ui/views/appwidgets/enhance

Other updates to widget framework

Take a look here to enhance your app-widgets and explore more updates on the widget framework starting from Android 12.

Repo with all the code samples is available here:
https://github.com/sridhar-sp/android-playground/tree/main/

An important thing to notice here is that even though this change seems like. a breaking change none of the existing android widget frameworks was modified this entire Glance framework works on top of the existing android widget framework.

References

https://android-developers.googleblog.com/2021/12/announcing-jetpack-glance-alpha-for-app.html

Build a Modern Android Splash Screen

Sridhar Subramani — Sun, 29 Dec 2024 08:54:47 +0000

Android released official support to show the splash screen.

This new splash screen support is added in Android 12, but the same can be used in earlier versions of Android using the splash screen support library.

To demo various aspects of the splash screen API, I’ve created a sample app with Jetpack Compose (final splash screen preview).

Let’s begin!

Step 1

Let us start by adding the splash screen dependency.

implementation 'androidx.core:core-splashscreen:1.0.1'

Step 2

The next steps would be to create a splash screen icon and an optional brand image.

We will discuss later on how to create the splash screen icon and make it appear center on the screen—in the Extras section at the bottom of the screen.

Step 3

Once we have the image asset ready, we can apply the same using the splash screen theme.

    <style name="Theme.Splash.Starting" parent="Theme.SplashScreen">
        <item name="windowSplashScreenBackground">
            @color/splash_screen_background
        </item>
        <item name="windowSplashScreenAnimatedIcon">
            @drawable/ic_splash_icon
        </item>
        <item name="windowSplashScreenAnimationDuration">
            @integer/splash_screen_animation_duration
        </item>
        <item name="postSplashScreenTheme">
            @style/Theme.App.NoActionBar
        </item>
        <!--Android 12 specific styles (put this in values-v31) -->
        <item name="android:windowSplashScreenBrandingImage">
            @drawable/ic_brand_icon
        </item>
        <!--Android 12 specific styles (put this in values-v31) -->
    </style>

Anatomy of splash screen

Let’s take a look at the style attributes.

windowSplashScreenBackground — As you have probably guessed, it’s the background colour that will occupy the whole screen.

windowSplashScreenAnimatedIcon — This can either be a normal vector icon or an animated vector icon. Note: An animated vector icon will only show animation on Android 12+ devices, older API devices will simply show the static icon without any animation.

windowSplashScreenAnimationDuration — The duration of the animated icon. The recommended duration is 1,000 milliseconds.

postSplashScreenTheme — This theme is used once the app is loaded. It’s required because we will set the launcher activity theme as Theme.SplashScreen in the app manifest — which works great for showing a splash screen, an animated logo, and a brand icon. However, once the app is loaded, we would get an exception if we didn’t use Theme.AppCompat or Theme.MaterialComponents . Hence, this attribute comes to the rescue.

windowSplashScreenBrandingImage — Brand image to show bottom of the screen (only available from Android 12).

Step 4

Now set the launcher activity theme as Theme.Splash.Starting

    <activity
        android:name=".MainActivity"
        android:exported="true"
        android:label="@string/app_name"
        android:theme="@style/Theme.Splash.Starting">
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />

            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>

Step 5

And finally, inside MainActivity onCreate method add installSplashScreen()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        installSplashScreen()

        setContent {
            AndroidSplashScreenTheme {
                 Greeting("Android splash screen demo")
            }
        }
    }

Other features

Now that we have completed setting up our new Android splash screen, we can take a look at the other features that come with it.

Control splash screen visibility.

The splash screen API provides support to keep the splash screen visible as long as we want it.

Let’s say we need to fetch some resources that are crucial to rendering our screen, and without those resources, there is no use showing the UI. In this case, we can defer showing our application’s UI until our resources are fetched and ready.

    installSplashScreen().setKeepVisibleCondition {
        mainViewModel.isScreenLoading.value
    }

setKeepVisibleCondition

This method takes a callback which returns a boolean to tell whether to keep the screen on or not. True value indicates the splash screen should remain as is, and False would indicate dismissal of the splash screen.

SplashScreen API will regularly call this callback to check whether to keep the splash screen or dismiss it.

Animate screen content when the splash screen is dismissing

    installSplashScreen()
    .setOnExitAnimationListener { splashScreenViewProvider ->
        // Animation code
    }

Extras

Let us discuss how to create the splash screen image.

As we can see in the splash screen icon, section 1 is masked by section 3

If we apply our icon as is, it will zoom out and stretch out.

So how do we fix this? We need to create an icon that caters to this masked padding.

Let’s say we have a splash screen icon of 54x54, then we would be creating a wrapper layer with a size of 108x108 (double the actual icon) and placing our icon content in the centre of it.

Example

    <?xml version="1.0" encoding="utf-8"?>
    <vector
        xmlns:android="http://schemas.android.com/apk/res/android"
        android:name="vector"
        android:width="108dp"
        android:height="108dp"
        android:viewportWidth="108"
        android:viewportHeight="108">
        <!--Optional background spanning full 108x108 dp-->
        <path
            android:name="background"
            android:pathData="M 0 0 L 108 0 L 108 108 L 0 108 Z"
            android:fillColor="@color/splash_icon_background"
            android:strokeWidth="1"/>
       <!--Splash screen icon placed in the centre of the screen-->
        <group
            android:name="group_icon"
            android:pivotX="54"
            android:pivotY="54">
            <path
                android:name="path_pi"
                android:pathData="M 30 44.591 L......."
                android:fillColor="@color/splash_icon_color"
                android:strokeWidth="1"/>
        </group>
    </vector>

That’s it, folks. Thanks for reading.

Source Code

https://github.com/sridhar-sp/android-splash-screen-demo

DEV Community: Sridhar Subramani

AI Needs More Than Just a Model: The Missing Role of Context, Orchestration, and Agents

Solving the AI Puzzle: Why External Context, Orchestration, and Agents Are Key to Intelligence

Disclaimer:

Analogy

Importance of Agents in AI

What are Agents

Can LLM Directly Call Agents?

Example: Output Agent

How Agents Extend the Capabilities of LLMs

Flow of Request Handling

Example:

The Need for an Orchestrator

List of Components in the Orchestrator System

Registration Process

Example Query Flow

Agents & Their Responsibilities

[1] Camera Agent

[2] Photo Editor Agent

[3] Email Agent

How the Orchestrator Uses LLM to Execute the Plan

Will AI Replace Humans?

AI's Role in the Workforce

Summary

Annexure

Getting Started with Android Testing: Building Reliable Apps with Confidence (Part 3/3)

Learn the Fundamentals of Android Testing, One Step at a Time (Part 3/3)

Previous article

Target Audience for This Blog

Integration testing

Integration Testing Frameworks

Robolectric

System Under Test

Test

Dependencies

Setup

Android JUnit test

System Under Test

Test

Dependencies

Setup

UI Automator

System Under Test

Test

Dependencies

Command

Gradle Managed Devices

Setup

Command

Source Code

Test Your Code, Rest Your Worries

Getting Started with Android Testing: Building Reliable Apps with Confidence (Part 2/3)

Learn the Fundamentals of Android Testing, One Step at a Time (Part 2/3)

Previous article

Target Audience for This Blog

UI Testing

Famous UI Testing Frameworks

Compose UI + Interaction Unit Test

Example

System Under Test

Test

Dependencies

Setup

Command

Source Code

Next Article

Test Your Code, Rest Your Worries

Getting Started with Android Testing: Building Reliable Apps with Confidence (Part 1/3)

Learn the Fundamentals of Android Testing, One Step at a Time Part 1/3

Target Audience for This Blog

Different Types of Test

Place of Execution

Unit Testing

Famous Unit Testing Frameworks

Simple Test Without Mocks

System Under Test

Test

Simple Test With Mocks

System Under Test

Test

Step 1: Create the `build-logic` Folder

`Player ‘X’ is a human, and Player ‘O’ is a computer.`