Introduction

SharedPreferences is a practical way to remember whether an Android screen has already been shown. A common example is a welcome screen, onboarding flow, or permission explanation that should appear only once, then be skipped on future launches.

Store a Boolean Flag for First Run

The core pattern is simple: read a boolean when the app starts, and if it is false, open the one-time activity. After the user finishes that activity, save true.

Here is a straightforward Kotlin example in a launcher activity:

1import android.content.Intent
2import android.os.Bundle
3import androidx.appcompat.app.AppCompatActivity
4
5class MainActivity : AppCompatActivity() {
6
7    override fun onCreate(savedInstanceState: Bundle?) {
8        super.onCreate(savedInstanceState)
9
10        val prefs = getSharedPreferences("app_prefs", MODE_PRIVATE)
11        val onboardingShown = prefs.getBoolean("onboarding_shown", false)
12
13        if (!onboardingShown) {
14            startActivity(Intent(this, OnboardingActivity::class.java))
15            finish()
16            return
17        }
18
19        setContentView(R.layout.activity_main)
20    }
21}

This code checks the preference before loading the normal main screen. If onboarding has never been completed, the user is redirected immediately.

Mark the Activity as Completed

The one-time screen should usually set the flag only after the user finishes it successfully. That avoids marking the flow as complete before the user has actually seen or completed it.

1import android.content.Intent
2import android.os.Bundle
3import androidx.appcompat.app.AppCompatActivity
4
5class OnboardingActivity : AppCompatActivity() {
6
7    override fun onCreate(savedInstanceState: Bundle?) {
8        super.onCreate(savedInstanceState)
9        setContentView(R.layout.activity_onboarding)
10    }
11
12    private fun finishOnboarding() {
13        val prefs = getSharedPreferences("app_prefs", MODE_PRIVATE)
14        prefs.edit()
15            .putBoolean("onboarding_shown", true)
16            .apply()
17
18        startActivity(Intent(this, MainActivity::class.java))
19        finish()
20    }
21}

Using apply() is usually the right choice here because it writes asynchronously and does not block the UI thread.

Keep the Preference Key and File Consistent

This pattern fails surprisingly often because the read and write sides do not match. If one activity uses "app_prefs" and another uses "prefs", or one reads "onboarding_shown" while the other writes "tutorial_seen", the app behaves as if the preference was never saved.

That is why many teams centralize the preference keys in one object or helper:

1object PrefKeys {
2    const val FILE_NAME = "app_prefs"
3    const val ONBOARDING_SHOWN = "onboarding_shown"
4}

Even for a tiny app, centralizing those names reduces accidental mismatches.

SharedPreferences Is Fine for a Small Flag

For a one-time activity, SharedPreferences is a good fit because the data is tiny and the read path is simple. For new Android apps, DataStore is often the more modern persistence option, but SharedPreferences remains perfectly reasonable for a single boolean gate like this.

The important design choice is not the storage API itself. It is deciding exactly what event counts as "done." Some apps mark the flag when the onboarding screen opens. Others wait until the last page is completed. The second option is usually safer because it avoids permanently skipping a flow the user never finished.

Common Pitfalls

The most common mistake is setting the flag too early, such as when the onboarding activity starts instead of when it finishes. If the app closes mid-flow, the screen may never appear again.

Another issue is using different preference file names or keys on the read and write paths. That makes the logic look correct while silently failing.

People also sometimes use commit() on the main thread for no reason. For a simple boolean write, apply() is usually the better default.

Summary

• SharedPreferences can store a simple boolean that controls whether an activity is shown only once.
• Read the flag in the launcher or entry activity and redirect when needed.
• Set the flag after the one-time flow is actually completed.
• Keep the preference file name and key consistent across reads and writes.
• For this small use case, SharedPreferences is usually sufficient and easy to maintain.