Anko SQLite Wrapper
Dealing with the on-device database is still very much a headache for Android developers. Writing straight SQLite code is a nightmare of opening, closing, tries, finals, and cursors… Oh good God, no not cursors! This is why many opt for the use of an ORM, even though they are slower and add a large dependency to your codebase. The issues with using an ORM are mere grains of rice compared to the size and weight of the terror we all feel at the idea of working with cursors.
If you don’t know Anko is a Kotlin library from JetBrains that in their words “is a library which makes Android application development faster and easier. It makes your code clean and easy to read, and lets you forget about rough edges of Android SDK for Java.”
Last week I was looking through the Anko GitHub and like a brave explorer, cutting my way through some remote jungle when I stomped on something amazing. Anko… has an SQLite wrapper.
https://github.com/Kotlin/anko/blob/master/doc/SQLITE.md
The Android SQLite API seems like a perfect candidate for the magic of Kotlin’s extension functions. After playing with it a bit here is what I think. It is way easier than working directly with SQLite. However, it is not as simple as many of the ORMs out there.
For me personally, there are things that I do not like about ORMs beyond the performance hit. I am starting to think in terms of data not models. I am a believer in the reactive circular architecture of Flux over MVC/MVP/MVVM. I want a pure, preferable immutable, data structure that I pass through functions. Most ORMs are built with a model in mind. This forces me to have my data class inherit something. Sure, this gives me a lot convenience with creating tables and inserting data, but to me they are negatives. This is what the Anko SQLite Wrapper gives me, the freedom to control my data structures and app architecture with a much much simpler way of working with the database.
For others, I think it is something that each person/team would need to look at and weigh the options. But I do think it is something you or your team should look into, especially if you are starting to dip your toes in the Kotlin waters. This would be a good place to start.
The readme on the GitHub gives very good instructions on usage. Let me know if you would like me to do a more in-depth post on it and what things you would like it to cover. (Calling from Java for example.)
