-5

I want to write an Android application which has an SQLite database.

I have seen this question, but it (as well as the answer) is 7 years old, which has also been pointed by CommonsWare in a comment, in which they have also suggested to use this library. But the comment is also from 2013. The last commit in the library is also in Dec. 2014.

On the other hand, in this official guide, they are saying that the recommended method for creating an SQLite database is to subclass SQLiteOpenHelper, from which one can infer that Google is now recommending the use of native Android API to create and work with databases.

So my question is what way should I follow? That is, now as of 2016, what is the recommended way of creating and working with and shipping an SQLite database in an Android application?

Community
  • 1
  • 1
Solace
  • 8,612
  • 22
  • 95
  • 183
  • 3
    How about the dead simple way- copy the db from assets to the file system, and then use the normal SQLite classes to read/write it. Isn't this the pretty obvious way of doing things, rather than downloading some third party library is god knows what state of repair? – Gabe Sechan Mar 02 '16 at 13:00
  • 1
    @GabeSechan Well, it seems that Mark really loves that library... ;) – Phantômaxx Mar 02 '16 at 13:01
  • 2
    @GabeSechan: Because that library is fine (I use it frequently), and it is a far cry better than the drooling-idiot-level code that I usually see people use for unpacking a database from assets. If you have better code for it, post it somewhere, or publish your own library to solve the problem. – CommonsWare Mar 02 '16 at 13:01
  • 2
    @CommonsWare I'd rather have drooling idiot level code I wrote myself than a 3rd party library for something this trivial. If it was a more complicated task I might use a library, but by the time I read and understand the library code I could have written it myself twice over. – Gabe Sechan Mar 02 '16 at 13:05
  • Would that fall under "reinventing the wheel" or "not invented here" anti-pattern @GabeSechan ? – Shark Mar 02 '16 at 13:06
  • 2
    Reinventing the wheel isn't always a bad thing. Cobbling together an app form hundreds of libraries to do trivial tasks that you then can't debug because you don't understand them and who knows the quality of them is a far worse antipattern. Use libraries when either the complexity is too high for you to understand without significant time (like OpenCV for computer vision) or when you can understand it but the effort to replicate it is far greater than the effort to read and understand the code and debug it in the future. This doesn't make either bar. – Gabe Sechan Mar 02 '16 at 13:10
  • 1
    Really. It's like using a third party library for simply importing a CSV file (and believe me, there's still people who use a library for this!!) – Phantômaxx Mar 02 '16 at 13:15
  • 1
    @BobMalooga: I would use a third-party library for reading a CSV, for the simple reason that the library author has a better chance of having caught and dealt with edge and corner cases that I'd have to chase down myself (e.g., how are nested quotes handled?). I have plenty of other yaks that need shaving; I don't need to waste time shaving the database-packaging or CSV-reading yaks. If, at some point, I find that the library is unsuitable (e.g., fails at edge cases, is too big and I need something smaller), *then* I'll roll my own stuff. – CommonsWare Mar 02 '16 at 13:20
  • 1
    Commonsware I'd use a library when I have to import a SVG file or draw a Chart. This would give me headache, if I were to write this code myself. But for **trivial** tasks... no libs, thanks! – Phantômaxx Mar 02 '16 at 13:23
  • 2
    @CommonsWare Depends on the library. When you're talking about a big library that's frequently used, you're probably right. If you're talking a random library on git hub, I actually assume the opposite- that I'm better than the author and I'm more likely to find the edge cases, plus I can tailor it to my usecase. Experience has held that I'm right. Unless a task will take me days, I'm doing my own. Also that finding and evaluating libraries is a non-trivial task. You do actually read the code of the library before you use it, to ensure it isn't malware and has no obvious flaws, right? – Gabe Sechan Mar 02 '16 at 13:32
  • 1
    @GabeSechan: "Experience has held that I'm right" -- for you. Please do not assume that everybody has your talent and experience level. I work to help the masses of Android developers, and there is a wide range of talent and experience levels. Most would be better off using a library, as even if they have equivalent talent and experience to the library author, as the library author will have put more thought into the domain area being addressed by the library. That's why we aren't all writing in assembler, after all. – CommonsWare Mar 02 '16 at 13:43
  • 2
    @CommonsWare I disagree. Even if they don't have that level of skill, they'd be better off doing it on their own so they can improve their level of skill. It may change where the bar is, but their effort shouldn't be in avoiding complexity, but in learning how to do it better. In fact this is the number one reason why the talent level of developers seems to be going downhill as the years go by- they know how to string together libraries but not write their own code, and are useless when the libraries don't work right. – Gabe Sechan Mar 02 '16 at 13:45

1 Answers1

2

The last commit in the library is also in Dec. 2014.

That library does not do very much, and so I would not expect it to be changing. SQLiteAssetHelper works just fine.

However, SQLiteAssetHelper is a solution for a specific problem: shipping a database with an app.

On the other hand, in this official guide, they are saying that the recommended method for creating an SQLite database is to subclass SQLiteOpenHelper, from which one can infer that Google is now recommending the use of native Android API to create and work with databases.

Um, SQLiteAssetHelper extends SQLiteOpenHelper, and it uses the "native Android API to create and work with databases".

Furthermore, SQLiteOpenHelper, on its does, does nothing for a specific problem: shipping a database with an app.

now as of 2016, what is the recommended way of creating and working with and shipping an SQLite database in an Android application?

Given the "and shipping" bit, I strongly recommend SQLiteAssetHelper.

Conversely, if you are not shipping a database with your app — which computer programmers would define as "having a database with a schema and data that you want to include in the shipped app to use as a starting point" — then just use SQLiteOpenHelper and define your database on the fly.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491