إعداد SqlDriver للمنصة

SQLDelight generates queries, but it needs a SqlDriver to actually talk to SQLite. Each platform ships its own driver.

Android and iOS open SQLite differently, so there is no single shared driver. This is exactly the job for expect/actual.

In commonMain you declare an expect function that promises a SqlDriver, without saying how each platform builds it.

Each source set pulls in its own driver artifact: an Android driver in androidMain and a native driver in iosMain.

On Android you build an AndroidSqliteDriver, passing the generated schema and a Context to open the file.

The Android driver needs a Context. Pass the application context in so the database survives the whole app lifecycle.

On iOS you build a NativeSqliteDriver from the same schema. No Context needed; it stores the file in the app sandbox.

Both drivers take AppDatabase.Schema. SQLDelight generated it from your .sq file, and it creates the tables on first launch.

With a driver in hand you create the database instance. This AppDatabase is your typed entry point to every query.

Creating many databases wastes file handles. Build the driver once and reuse a single AppDatabase across the app.

Pass the driver in from each platform rather than hardcoding it. This keeps shared code testable with a fake or in-memory driver.

How does SQLDelight get a platform-specific database driver into shared code?

You declared an expect driver factory, supplied AndroidSqliteDriver and NativeSqliteDriver, and built one AppDatabase. Now you can run queries. ✅