For those not using Kotlin, or using Kotlin and Java, check out Room:<p><a href="https://developer.android.com/topic/libraries/architecture/room.html" rel="nofollow">https://developer.android.com/topic/libraries/architecture/r...</a><p>It's in their list, at half the size and method count of Anko (with no need to pull in the Kotlin runtime if you're not using Kotlin). It offers all the same features, really awesome migration testing, and RxJava integration.<p>For me these days the options that make sense in Android's world of infinite DBs/Orms/Wrappers are down to SQLBrite+SQLDelight, Realm, or Room depending on what you want
SQLite is such a fantastic database. I've always wondered, is anyone using it at scale in a client server application? How do people handle syncing online/offline in mobile apps?
I really wish the android team would create an officially supported ORM package to wrap sqlite like CoreData on iOS. Global data access is even more important on android since Activities are stateless, and data access always seems to be to failure point in so many of our projects.
There's also Room from Google that tries to solve the same problems:<p><a href="https://developer.android.com/topic/libraries/architecture/room.html" rel="nofollow">https://developer.android.com/topic/libraries/architecture/r...</a>
I am planning to do a blog post on SQLite pitching it as one of modern engineering marvels. With SQLite4 things might be even better from performance perspective due to LSM engine under the hood (Shameless plug I have ported the engine to windows <a href="https://github.com/maxpert/lsm-windows" rel="nofollow">https://github.com/maxpert/lsm-windows</a> ). SQLite was never <i>uncool</i>!
These type of libraries are cool for small and non-complicated things. None of them can compete with the expressiveness of SQL, as it is based in relational algebra.
One more dsl for SQL is cool, but not maintainable, not approachable or scalable.<p>SQL scripts in assets/ folder would be not cool or sexy, but everybody knows what are they.
I really think trying to create ORMs is a misguided endavour.<p>Instead what we really need is a way to map a row from an sql query to a struct (or similar).<p>Luckily, the SQLite helpers from Anko do provide this ability, and it's pretty much the only part I use.<p><pre><code> data class UserRow(val id: Long, val name: String);
// .... open db .. etc
var users = db.query<UserRow>("select id, name from users where ....."); // where clause content omitted
// now users is a list of structs (as close to structs as you can get in Kotlin).
</code></pre>
Where I have an extension method `query`:<p><pre><code> inline fun <reified T : Any> SQLiteDatabase.query(sql: String, vararg args: String): List<T> {
this.rawQuery(sql, args).parseList(classParser<T>())
}</code></pre>
You don't have to close your database every time if you manage it with a ContentProvider.
I've used SQLite on Android like that without many issues, although the boilerplate can be too much using SQLite as is.
You can also create views to avoid including queries in java code.
<p><pre><code> database.use {
insert(Book.TABLE_NAME, Book.COLUMN_ID to 1, Book.COLUMN_TITLE to "2666", Book.COLUMN_AUTHOR to "Roberto Bolano")
}
</code></pre>
That's pretty bad design: you're throwing out type safety with this API.