Why understanding lifecycle prevents bugs in Android Kotlin - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to override the onCreate method in an Android Activity.

Android Kotlin

override fun [1](savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
}

Drag options to blanks, or click blank then click option'

AonResume

BonStart

ConCreate

DonPause

Attempts:

3 left

💡 Hint

Common Mistakes

Using onStart instead of onCreate

Forgetting to call super.onCreate

The onCreate method is called when the activity is first created. Overriding it allows you to set up your UI and initialize components.

2fill in blank

medium

Complete the code to save data when the activity is about to be destroyed.

Android Kotlin

override fun [1](outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString("key", "value")
}

Drag options to blanks, or click blank then click option'

AonDestroy

BonSaveInstanceState

ConStop

DonPause

Attempts:

3 left

💡 Hint

Common Mistakes

Saving data in onDestroy which is not guaranteed to be called

Not calling super.onSaveInstanceState

The onSaveInstanceState method is called before the activity may be destroyed. It allows saving UI state to restore later.

3fill in blank

hard

Fix the error in the lifecycle method to properly release resources.

Android Kotlin

override fun [1]() {
    super.onDestroy()
    mediaPlayer.release()
}

Drag options to blanks, or click blank then click option'

AonResume

BonPause

ConStop

DonDestroy

Attempts:

3 left

💡 Hint

Common Mistakes

Releasing resources in onPause which may be called multiple times

Not calling super.onDestroy

The onDestroy method is the right place to release resources like media players to avoid memory leaks.

4fill in blank

hard

Fill both blanks to correctly handle UI updates when the activity becomes visible.

Android Kotlin

override fun [1]() {
    super.[2]()
    updateUI()
}

Drag options to blanks, or click blank then click option'

AonStart

BonResume

ConPause

DonStop

Attempts:

3 left

💡 Hint

Common Mistakes

Using onStart instead of onResume for UI updates

Forgetting to call super method

The onResume method is called when the activity is ready to interact with the user. Updating UI here ensures the latest data is shown.

5fill in blank

hard

Fill all three blanks to correctly manage a media player across lifecycle events.

Android Kotlin

override fun [1]() {
    super.[1]()
    mediaPlayer.start()
}
override fun [2]() {
    super.[2]()
    mediaPlayer.pause()
}
override fun [3]() {
    super.[3]()
    mediaPlayer.release()
}

Drag options to blanks, or click blank then click option'

AonStart

BonPause

ConDestroy

DonStop

Attempts:

3 left

💡 Hint

Common Mistakes

Starting media in onResume but releasing in onStop

Not releasing media player in onDestroy

onStart starts the media player when the activity becomes visible. onPause pauses it when the activity loses focus. onDestroy releases resources to prevent leaks.

Practice

1. Why is it important to understand the Android activity lifecycle when developing an app?

easy

A. Because it helps manage app behavior during screen rotations and backgrounding

B. Because it allows you to write code without any functions

C. Because it makes the app run faster without any changes

D. Because it automatically fixes all bugs in the app

Solution

1. Step 1: Understand lifecycle role

   The lifecycle tells the app when to start, pause, resume, or stop activities.

2. Step 2: Connect lifecycle to bug prevention

   Managing these states properly avoids bugs like data loss or crashes during screen rotation or app backgrounding.

3. Final Answer:

   Because it helps manage app behavior during screen rotations and backgrounding -> Option A

4. Quick Check:

   Lifecycle management = Prevent bugs [OK]

Hint: Lifecycle controls app states; manage them to avoid bugs [OK]

Common Mistakes:

• Thinking lifecycle fixes bugs automatically
• Ignoring lifecycle causes data loss
• Believing lifecycle only affects UI speed

2. Which of the following is the correct Kotlin lifecycle method to save data before an activity is destroyed?

easy

A. onCreate()

B. onSaveInstanceState()

C. onStart()

D. onDestroy()

Solution

1. Step 1: Identify saving data method

   onSaveInstanceState() is called before the activity might be destroyed to save UI state.

2. Step 2: Compare other methods

   onCreate() initializes, onDestroy() is too late for saving state, onStart() is for starting UI.

3. Final Answer:

   onSaveInstanceState() -> Option B

4. Quick Check:

   Save data before destroy = onSaveInstanceState() [OK]

Hint: Save state in onSaveInstanceState() before destruction [OK]

Common Mistakes:

• Using onDestroy() to save data (too late)
• Confusing onCreate() with saving state
• Not saving state causes data loss on rotation

3. Consider this Kotlin code snippet inside an Activity:

override fun onPause() {
  super.onPause()
  saveUserData()
}

override fun onStop() {
  super.onStop()
  releaseResources()
}

What happens if the app goes to background and then returns?

medium

A. Resources are never released, causing memory leaks

B. User data is lost because onPause() is not called

C. User data is saved and resources are released when app backgrounds; resources are reacquired on resume

D. App crashes because onStop() is called before onPause()

Solution

1. Step 1: Analyze onPause() and onStop() calls

   When app backgrounds, onPause() then onStop() are called in order.

2. Step 2: Understand method effects

   saveUserData() saves data on pause; releaseResources() frees resources on stop; on resume, resources can be reacquired.

3. Final Answer:

   User data is saved and resources are released when app backgrounds; resources are reacquired on resume -> Option C

4. Quick Check:

   onPause + onStop manage data and resources correctly [OK]

Hint: onPause saves data; onStop releases resources [OK]

Common Mistakes:

• Assuming onPause() is skipped
• Thinking onStop() causes crash
• Believing resources stay allocated forever

4. This Kotlin code snippet causes a bug when the device rotates:

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

fun loadUserData() {
  // loads data from network
}

What is the main issue here?

medium

A. loadUserData() is called multiple times causing repeated network calls on rotation

B. onCreate() is not called on rotation, so data is never loaded

C. Network calls should be in onDestroy() instead

D. The app crashes because savedInstanceState is not checked

Solution

1. Step 1: Understand onCreate() on rotation

   onCreate() is called again on rotation, so loadUserData() runs multiple times.

2. Step 2: Identify bug cause

   Repeated network calls cause performance issues and bugs like duplicated data loading.

3. Final Answer:

   loadUserData() is called multiple times causing repeated network calls on rotation -> Option A

4. Quick Check:

   onCreate repeats on rotation = repeated calls [OK]

Hint: onCreate runs on rotation; avoid repeated heavy calls [OK]

Common Mistakes:

• Thinking onCreate is not called on rotation
• Placing network calls in onDestroy()
• Ignoring savedInstanceState check

5. You want to ensure your app saves user input data when the screen rotates and restores it correctly. Which lifecycle methods should you use and why?

hard

A. Use onStart() to save data and onStop() to restore it because they manage background tasks

B. Use onDestroy() to save data and onCreate() to restore it because onDestroy() is always called before rotation

C. Use onPause() to save data and onResume() to restore it because these methods run only once per app launch

D. Use onSaveInstanceState() to save data and onRestoreInstanceState() to restore it because they handle temporary UI state during configuration changes

Solution

1. Step 1: Identify correct save and restore methods

   onSaveInstanceState() saves temporary UI data before rotation; onRestoreInstanceState() restores it after.

2. Step 2: Explain why other methods are incorrect

   onDestroy() may not always be called; onPause()/onResume() run on many events; onStart()/onStop() manage visibility, not state saving.

3. Final Answer:

   Use onSaveInstanceState() to save data and onRestoreInstanceState() to restore it because they handle temporary UI state during configuration changes -> Option D

4. Quick Check:

   Save/restore UI state = onSaveInstanceState/onRestoreInstanceState [OK]

Hint: Save UI state in onSaveInstanceState, restore in onRestoreInstanceState [OK]

Common Mistakes:

• Using onDestroy() which may not be called
• Confusing onPause() with state saving
• Restoring data in onStop() instead of restore methods