What Is the Activity Result API and Why Google Replaced startActivityForResult()?

Android development is constantly advancing, and with it, the frameworks and APIs developers rely on. A pivotal recent change is Google's introduction of the Activity Result API, designed to replace the long-standing but often problematic startActivityForResult() mechanism. This article explores what the new API entails, the reasons behind this transition, and practical steps to adopt it in your Kotlin projects.

The Journey from startActivityForResult()

For a long time, startActivityForResult() was the standard method to launch another activity and receive results asynchronously. The process required overriding onActivityResult() in the calling component and handling various request codes manually:

• Manual Request Codes: Developers needed to manage unique integer codes to identify different requests.
• Complex Result Handling: All results routed to a single onActivityResult() method, which could grow unwieldy and difficult to maintain.
• Lifecycle Vulnerabilities: Callbacks could be lost during configuration changes or if the component was not in the right lifecycle state.
• Fragment Challenges: Handling results in fragments required intricate delegation between activity and fragment methods.

These limitations often caused bugs and convoluted code. Google recognized that a more robust, lifecycle-aware approach was necessary.

Understanding the Activity Result API

The Activity Result API was introduced in AndroidX Activity 1.2.0 and Fragment 1.3.0 as a modern alternative. It centers on two main components:

• ActivityResultContract: Defines the contract of what input the launcher accepts and what output it returns. Android offers predefined contracts such as StartActivityForResult() and GetContent(), but you can also create custom contracts.
• ActivityResultLauncher: Represents a launcher you register with a callback. You use it to initiate an activity and receive results without overriding global methods.

This design is lifecycle-aware, meaning callbacks are guaranteed to be called only when the component is in a suitable state, elegantly handling configuration changes and fragment contexts.

Rationale Behind Google's Decision

Replacing startActivityForResult() with the Activity Result API aligns with modern Android architecture idioms. The key motivations include:

1. Lifecycle Integration: Eliminates bugs arising from configuration changes by tying result handling into the component lifecycle.
2. Better Code Organization: Callback logic is declared at the point of registering the launcher rather than being bundled into a global handler method.
3. Type Safety: Contracts enforce precise input and output types, reducing runtime errors caused by incorrect intent extra handling.
4. Simplified Fragment Support: Fragments now handle results natively without extra boilerplate.
5. Extensibility: Custom contracts enable encapsulating common patterns, promoting code reuse.

Practical Kotlin Implementation Examples

Let's explore how to adopt the Activity Result API with Kotlin code samples.

Example 1: Selecting an Image from the Gallery

This use case lets users pick an image and display it in an ImageView:

// Step 1: Register the launcher with a callback to handle the result
private val pickImageLauncher = registerForActivityResult(ActivityResultContracts.GetContent()) { uri ->
    if (uri != null) {
        imageView.setImageURI(uri)  // Display selected image
    } else {
        Toast.makeText(this, "No image selected", Toast.LENGTH_SHORT).show()
    }
}

// Step 2: Launch the picker on button click
buttonPickImage.setOnClickListener {
    pickImageLauncher.launch("image/*")
}

This concise declarative approach keeps the callback logic encapsulated and lifecycle-safe.

Example 2: Starting an Activity for a Result

When starting a custom activity to receive results, use the following pattern:

// Register a launcher with the traditional contract
private val launchSomeActivityLauncher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
    if (result.resultCode == Activity.RESULT_OK) {
        val data = result.data
        // Safely extract data from Intent extras
        val returnedString = data?.getStringExtra("result_key")
        Toast.makeText(this, "Result: $returnedString", Toast.LENGTH_SHORT).show()
    }
}

// Launch the activity at the appropriate moment
val intent = Intent(this, AnotherActivity::class.java)
launchSomeActivityLauncher.launch(intent)

You can handle multiple launchers with their own callbacks without polluting a single method.

Best Practices for Using the Activity Result API

• Register launchers before the lifecycle reaches STARTED: Usually inside onCreate() or as a property initializer to avoid missing callbacks.
• Leverage existing contracts: Use AndroidX predefined contracts whenever possible to reduce boilerplate and potential bugs.
• Create custom contracts when needed: For complex or repeated result patterns, encapsulate input-output logic in contracts.
• Keep launch and handling code close: This improves readability and reduces the chance of errors.
• Handle null results gracefully: Always prepare for the user canceling or no data returned to avoid crashes.

Backward Compatibility and Migration Tips

The Activity Result API works on older Android versions as it is AndroidX based, enabling smooth migration:

• Replace startActivityForResult() calls with ActivityResultLauncher.launch().
• Move result handling code out of onActivityResult() into callbacks registered via registerForActivityResult().
• Eliminate manual request codes and switch-case constructs previously used in onActivityResult().

This shift greatly simplifies your codebases and aligns with modern lifecycle-aware practices without losing compatibility.

Conclusion

The Activity Result API represents a fundamental improvement over the legacy startActivityForResult() pattern by coupling result handling to component lifecycles with strong typing and modular callbacks. Adopting this API increases stability, readability, and maintainability of Android applications, making it an essential update for developers in 2024 and future releases.

If your projects still use startActivityForResult(), migrating now will improve your development experience and reduce bugs, allowing you to focus on creating rewarding user interfaces.

Happy coding!

Subscribe to Techno Stack