Introduction

There is no single best mechanism for sharing data between Android activities. The right choice depends on how much data you need to move, whether the data should survive process death, and whether the second activity is just a detail screen or part of a larger workflow.

For most navigation flows, Intent extras are the correct default. When the data is large, shared by many screens, or needs to outlive an activity instance, move the data into a repository, database, or other persistent store and pass only an identifier.

Use Intent Extras for Small, Immediate Data

If one activity launches another and the target only needs a few values, use extras on the Intent. This is simple, explicit, and works well with Android lifecycle rules.

Primitive values and strings are straightforward:

1// SenderActivity.kt
2val intent = Intent(this, DetailActivity::class.java).apply {
3    putExtra("user_id", 42L)
4    putExtra("user_name", "Ava")
5}
6startActivity(intent)

1// DetailActivity.kt
2override fun onCreate(savedInstanceState: Bundle?) {
3    super.onCreate(savedInstanceState)
4
5    val userId = intent.getLongExtra("user_id", -1L)
6    val userName = intent.getStringExtra("user_name").orEmpty()
7
8    check(userId != -1L) { "Missing user_id extra" }
9    renderUser(userId, userName)
10}

This approach is best when the receiving activity can render itself entirely from the values in the extra bundle. It is also easy to test because the contract is visible at the call site.

Prefer Parcelable for Structured Objects

When you need to pass a small structured object, use Parcelable rather than Java serialization. Parcelable is the Android-native option and avoids much of the cost of reflective serialization.

1@Parcelize
2data class UserSummary(
3    val id: Long,
4    val name: String,
5    val isAdmin: Boolean
6) : Parcelable

1val intent = Intent(this, DetailActivity::class.java).apply {
2    putExtra("user", UserSummary(42L, "Ava", true))
3}
4startActivity(intent)

val user = requireNotNull(intent.getParcelableExtra<UserSummary>("user")) {
    "Missing user payload"
}

Keep payloads small. Passing a deeply nested object graph, a bitmap, or a large list through extras can trigger transaction size problems and makes activity launches brittle.

Pass Identifiers for Large or Shared Data

If the second activity needs a full domain object, send only the stable key and reload the data from a repository. This keeps navigation lightweight and avoids stale copies of mutable state.

1class UserRepository(private val dao: UserDao) {
2    suspend fun getUser(id: Long): User = dao.findById(id)
3}
4
5class DetailViewModel(
6    private val repository: UserRepository
7) : ViewModel() {
8    suspend fun loadUser(userId: Long): User = repository.getUser(userId)
9}

val intent = Intent(this, DetailActivity::class.java)
intent.putExtra("user_id", user.id)
startActivity(intent)

This pattern is usually the most maintainable when multiple screens can update the same record. Instead of copying state from activity to activity, every screen reads from the same source of truth.

Returning Data Back to the Caller

If activity B needs to send a result back to activity A, use the Activity Result API instead of older callback patterns.

1private val editProfileLauncher =
2    registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result ->
3        if (result.resultCode == Activity.RESULT_OK) {
4            val updatedName = result.data?.getStringExtra("updated_name").orEmpty()
5            binding.nameView.text = updatedName
6        }
7    }
8
9fun openEditProfile() {
10    val intent = Intent(this, EditProfileActivity::class.java)
11    editProfileLauncher.launch(intent)
12}

This keeps the request and response flow explicit and lifecycle-aware.

When to Use Shared Storage Instead

Not all cross-screen data should travel through intents. Use shared storage when the data should be available after process death, app restart, or across many destinations:

• 'Room or another database for durable business data'
• 'DataStore or SharedPreferences for small settings'
• A repository layer for shared cached objects

Passing a database key through the intent and reading the latest value from storage is often the cleanest design.

Common Pitfalls

• Sending large objects in extras can exceed binder transaction limits. Pass an ID instead.
• Using Serializable for convenience works, but it is usually slower and less idiomatic on Android than Parcelable.
• Depending on a singleton for screen-to-screen state often creates hidden coupling and stale data problems.
• Forgetting null handling for missing extras can crash the receiving activity. Validate inputs early.
• Using hard-coded string keys in many places is error-prone. Centralize them in constants or helper methods.

Summary

• 'Intent extras are the best default for small, immediate navigation data.'
• Use Parcelable for compact structured payloads that genuinely need to cross activity boundaries.
• For large or shared state, pass an identifier and load from a repository or database.
• Use the Activity Result API when the launched activity must return data.
• Avoid singletons and oversized extras because they create fragile activity contracts.