Activity results in Android Kotlin - UI Render Trace

Component - Activity results

This UI component demonstrates how one Android activity starts another and receives a result back. It shows a button that opens a second screen, and when the user finishes there, the first screen displays the returned message.

Widget Tree

ActivityResultActivity
├── ConstraintLayout
│   ├── Button (Start Second Activity)
│   └── TextView (Result Display)

The root is the ActivityResultActivity which uses a ConstraintLayout as the main container. Inside it, there is a Button that the user taps to open the second activity. Below the button, a TextView shows the result returned from the second activity.

Render Trace - 5 Steps

Step 1: ActivityResultActivity

Step 2: Button (Start Second Activity)

Step 3: SecondActivity

Step 4: SecondActivity Submit Button

Step 5: ActivityResultActivity

State Change - Re-render

Trigger:User taps the button to start second activity and submits a result

Before

TextView is empty, no result shown

→

After

TextView shows the returned message from second activity

Re-renders:The TextView displaying the result is updated and re-rendered

UI Quiz - 3 Questions

What happens when the user taps the 'Start Second Activity' button?

A The app closes immediately

B The app opens the second activity expecting a result

C The text in TextView changes to 'Hello'

D Nothing happens

Key Insight

Using activity results allows one screen to get information back from another screen, enabling smooth user flows like forms or selections. The UI updates only the part showing the result, keeping the app responsive and clear.

Practice

1. What is the main purpose of registerForActivityResult in Android Kotlin?

easy

A. To create a new fragment instance

B. To start a new activity without expecting a result

C. To register a broadcast receiver

D. To safely receive data back from another activity

Solution

1. Step 1: Understand the role of registerForActivityResult

   This function is designed to handle results from activities started for a result safely and simply.

2. Step 2: Compare with other options

   Starting an activity without expecting a result or registering broadcast receivers are unrelated to this function.

3. Final Answer:

   To safely receive data back from another activity -> Option D

4. Quick Check:

   Activity result handling = A [OK]

Hint: Remember: registerForActivityResult handles returned data safely [OK]

Common Mistakes:

• Confusing it with starting activities without results
• Thinking it registers broadcast receivers
• Assuming it creates fragments

2. Which of the following is the correct syntax to register an activity result launcher in Kotlin?

easy

A. val launcher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result -> /* handle result */ }

B. val launcher = registerActivityResult(ActivityResultContracts.StartActivityForResult()) { result -> /* handle result */ }

C. val launcher = registerForResult(ActivityResultContracts.StartActivityForResult()) { result -> /* handle result */ }

D. val launcher = registerActivity(ActivityResultContracts.StartActivityForResult()) { result -> /* handle result */ }

Solution

1. Step 1: Identify the correct function name

   The correct function is registerForActivityResult, not any shortened or altered form.

2. Step 2: Check the contract and lambda syntax

   The contract ActivityResultContracts.StartActivityForResult() and lambda parameter { result -> } are correctly used in val launcher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result -> /* handle result */ }.

3. Final Answer:

   val launcher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result -> /* handle result */ } -> Option A

4. Quick Check:

   Correct function name and syntax = B [OK]

Hint: Look for exact function name: registerForActivityResult [OK]

Common Mistakes:

• Using incorrect function names like registerActivityResult
• Omitting parentheses in contract instantiation
• Wrong lambda syntax

3. Given the following code snippet, what will be printed if the launched activity returns RESULT_OK with intent data containing key "username" = "Alice"?

val launcher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
    if (result.resultCode == Activity.RESULT_OK) {
        val name = result.data?.getStringExtra("username")
        println(name)
    } else {
        println("No data")
    }
}

medium

A. Crash due to null pointer

B. Alice

C. null

D. No data

Solution

1. Step 1: Check the result code condition

   The code checks if result.resultCode == Activity.RESULT_OK, which is true in this case.

2. Step 2: Extract the "username" from intent data

   The intent data contains key "username" with value "Alice", so name will be "Alice" and printed.

3. Final Answer:

   Alice -> Option B

4. Quick Check:

   Result OK with data returns value = D [OK]

Hint: Check resultCode and safely unwrap intent data [OK]

Common Mistakes:

• Ignoring resultCode and printing 'No data'
• Assuming data is null without checking
• Not using safe call operator on intent data

4. Identify the error in this code snippet for handling activity results:

val launcher = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
    val name = result.data!!.getStringExtra("username")
    if (result.resultCode == Activity.RESULT_OK) {
        println(name)
    }
}

medium

A. Unsafe call on result.data before checking resultCode

B. Missing lambda parameter in registerForActivityResult

C. Incorrect contract used for activity result

D. No error, code is correct

Solution

1. Step 1: Analyze the order of operations

   The code force unwraps result.data!! before checking if result.resultCode == Activity.RESULT_OK.

2. Step 2: Understand potential crash

   If the result is not OK or data is null, force unwrapping causes a crash. The check should come before accessing data.

3. Final Answer:

   Unsafe call on result.data before checking resultCode -> Option A

4. Quick Check:

   Check resultCode before accessing data = A [OK]

Hint: Always check resultCode before using intent data [OK]

Common Mistakes:

• Force unwrapping nullable data without checks
• Accessing data before verifying resultCode
• Ignoring null safety in Kotlin

5. You want to start an activity to pick a contact and get the contact's URI back. Which approach correctly uses registerForActivityResult to achieve this?

hard

A. val pickContact = registerForActivityResult(ActivityResultContracts.RequestPermission()) { granted -> if (granted) println("Permission granted") }

B. val pickContact = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result -> println(result.data?.getData().toString()) }

C. val pickContact = registerForActivityResult(ActivityResultContracts.PickContact()) { uri -> if (uri != null) println(uri.toString()) }

D. val pickContact = registerForActivityResult(ActivityResultContracts.TakePicture()) { success -> if (success) println("Picture taken") }

Solution

1. Step 1: Identify the correct contract for picking a contact

   ActivityResultContracts.PickContact() is designed to pick a contact and return its URI.

2. Step 2: Check the lambda parameter and usage

   The lambda receives a URI nullable parameter, which is safely checked before printing.

3. Step 3: Eliminate other options

   val pickContact = registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result -> println(result.data?.getData().toString()) } uses a generic contract but does not check resultCode; A and D are unrelated contracts for permissions and taking pictures.

4. Final Answer:

   val pickContact = registerForActivityResult(ActivityResultContracts.PickContact()) { uri -> if (uri != null) println(uri.toString()) } -> Option C

5. Quick Check:

   Use PickContact contract for contact URI = C [OK]

Hint: Use specific contracts like PickContact for contact picking [OK]

Common Mistakes:

• Using StartActivityForResult without checking resultCode
• Confusing permission or picture contracts with contact picking
• Not handling nullable URI safely