SharedPreferences no Android com Kotlin: Guia Completo (Do Básico ao Uso Profissional)

No desenvolvimento Android, é comum precisar armazenar pequenas quantidades de dados localmente: preferências do usuário, flags de configuração, tokens, etc.

Uma das APIs mais tradicionais para isso é o SharedPreferences.

Apesar de simples, o uso incorreto pode gerar problemas como:

• perda de dados

• inconsistência entre threads

• vazamento de informação sensível

Neste guia, você vai entender:

• quando usar (e quando evitar)

• boas práticas reais de mercado

• alternativas modernas

O que é SharedPreferences?

O SharedPreferences é um mecanismo de armazenamento chave-valor persistente no Android.

Ele salva dados em um arquivo XML interno da aplicação.

Exemplos de uso comuns:

• Tema escuro ativado

• Usuário logado

• Configurações simples

Criando e acessando SharedPreferences

Forma moderna com Kotlin

val sharedPreferences = getSharedPreferences("app_prefs", MODE_PRIVATE)

Ou usando extensão do Kotlin:

val sharedPreferences by lazy {
    getSharedPreferences("app_prefs", MODE_PRIVATE)
}

Gravando dados

sharedPreferences.edit()
    .putString("username", "Matheus")
    .putBoolean("is_logged", true)
    .apply()

apply() vs commit()

• apply() → assíncrono (RECOMENDADO)

• commit() → síncrono (bloqueia thread)
  

Em apps reais, quase sempre use apply().

Lendo dados

val username = sharedPreferences.getString("username", null)
val isLogged = sharedPreferences.getBoolean("is_logged", false)

Removendo dados

sharedPreferences.edit()
    .remove("username")
    .apply()

Ou limpando tudo:

sharedPreferences.edit()
    .clear()
    .apply()

Problemas reais

1. Não é thread-safe para escrita concorrente

Se você tiver múltiplas threads escrevendo ao mesmo tempo, pode ter inconsistência.

Solução:

• centralizar acesso

• usar camada de abstração
  

2. Não é adequado para dados sensíveis

SharedPreferences armazena dados em texto (XML).

NÃO use para:

• senha

• token JWT

• dados bancários
  

Alternativa:

• EncryptedSharedPreferences

3. Performance degradada com muitos dados

Não foi feito para grandes volumes.

Regra prática:

• até poucos KB → ok

• acima disso → pense em banco
  

Boas práticas

1. Criar uma classe de abstração

class UserPreferences(context: Context) {

    private val prefs = context.getSharedPreferences("user_prefs", Context.MODE_PRIVATE)

    var username: String?
        get() = prefs.getString("username", null)
        set(value) {
            prefs.edit().putString("username", value).apply()
        }

    var isLogged: Boolean
        get() = prefs.getBoolean("is_logged", false)
        set(value) {
            prefs.edit().putBoolean("is_logged", value).apply()
        }
}

Isso evita:

• duplicação de código

• erro de chave
  

2. Centralizar chaves

Evite strings soltas:

object PrefKeys {
    const val USERNAME = "username"
}

3. Evitar lógica dentro do SharedPreferences

Ele NÃO é regra de negócio.

Errado:

if (prefs.getBoolean("is_logged", false)) {
    // lógica aqui
}

Correto:

• buscar dados → tratar em outra camada
  

Alternativa moderna: DataStore

Hoje, o Google recomenda o uso do: Jetpack DataStore

Exemplo com DataStore

val Context.dataStore by preferencesDataStore("settings")

val USERNAME = stringPreferencesKey("username")

suspend fun saveUsername(context: Context, name: String) {
    context.dataStore.edit { prefs ->
        prefs[USERNAME] = name
    }
}

Quando usar SharedPreferences?

Use quando:

✔ dados simples

✔ leitura rápida

✔ sem necessidade de reatividade

Evite quando:

❌ dados sensíveis

❌ grande volume

❌ concorrência alta