Local storage

Why store data on the device?

Apps should remember things: the user's language, whether they finished onboarding, a draft message, a cached product list for offline use, the login token. Storing them locally makes apps faster (no waiting for the network), usable offline, and friendlier. Different kinds of data need different tools.

shared_preferences

import 'package:shared_preferences/shared_preferences.dart';

Future<void> saveLanguage(String code) async {
  final prefs = await SharedPreferences.getInstance();
  await prefs.setString('language', code);
}

Future<String> loadLanguage() async {
  final prefs = await SharedPreferences.getInstance();
  return prefs.getString('language') ?? 'en';          // default when nothing is saved
}

All these storage calls are asynchronous because disk access is slow compared to memory. Load settings early (for example before runApp, or in a splash screen) and keep them in your state management layer, so widgets do not wait for disk reads every time they build.

Secure storage for tokens

import 'package:flutter_secure_storage/flutter_secure_storage.dart';

const storage = FlutterSecureStorage();

Future<void> saveToken(String token) => storage.write(key: 'auth_token', value: token);
Future<String?> readToken() => storage.read(key: 'auth_token');
Future<void> logout() => storage.delete(key: 'auth_token');

SQLite for structured data

import 'package:path/path.dart';
import 'package:sqflite/sqflite.dart';

Future<Database> openNotesDb() async {
  return openDatabase(
    join(await getDatabasesPath(), 'notes.db'),
    version: 1,
    onCreate: (db, version) => db.execute(
      'CREATE TABLE notes(id INTEGER PRIMARY KEY AUTOINCREMENT, text TEXT NOT NULL, created INTEGER NOT NULL)',
    ),
  );
}

Future<void> addNote(Database db, String text) =>
    db.insert('notes', {'text': text, 'created': DateTime.now().millisecondsSinceEpoch});

Future<List<Map<String, Object?>>> latestNotes(Database db) =>
    db.query('notes', orderBy: 'created DESC', limit: 20);

drift is a popular alternative built on SQLite that generates type-safe Dart code from your tables and queries, supports streams that update when data changes, and works on more platforms. It needs build_runner. For small apps sqflite is fine; for larger data layers many teams prefer drift.

On the web, sqflite is not available; drift or IndexedDB-based packages are options there.

Files with path_provider

path_provider gives platform-correct folders: getApplicationDocumentsDirectory() for files the user expects to keep, and getTemporaryDirectory() for caches the system may delete. Combine it with dart:io File to read and write (not available on the web).

Common mistakes

• Storing a login token in shared_preferences.
• Building SQL with string concatenation from user input: SQL injection risk. Use whereArgs.
• Opening the database again on every query. Open it once and reuse it.
• Forgetting that data must be migrated when the table structure changes (increase version and use onUpgrade).