Develop Reference

Should I use Android SharedPreferences or SQLite for persistence in my app?

When a user logs in to an app I'm developing, the back-end sends back information about the user. I want to persist the information so it can be used in other activities and when there is no network access.
The two main persistence options I'm aware of for Android are SharedPrefereces and SQLite, and I'm trying to determine which would be more appropriate for my use case. There are three requirements:
The data to store are mostly a small number of primitive data types or simple reference types, but an array or an object of a derived type may also need to be stored.
Reading and writing the data should be as simple as possible.
Data that is written must be available on any subsequent read.
Here is my attempt to compare SharedPreferences and SQLite along these dimensions. (Note that there are other questions on StackOverflow that ask for comparisons of SharedPreferences and SQLite -- "Pros and Cons of SQLite and Shared Preferences", "Saving data on Android : File Storage vs SQLite Database vs Shared Preferences" -- but the answers do not address all three dimensions.)
SharedPreferences
Works most naturally with primitive and simple reference types, but GSON can be used to store data of any type.
Data can be written and read from the UI thread.
Due to a race condition, there is no guarantee that data written to SharedPreferences will be available on any subsequent read.
SQLite
Can be used in a natural way to store structured data of any degree of complexity.
Data should be written and read in a thread separate from the UI thread.
Using a singleton DatabaseHelper guarantees that data written to the database will be available on any subsequent read.
If my assessment is correct, it looks like the SharedPreferences race condition means I have to use SQLite instead to satisfy the requirements even though doing so is more involved. But is my assessment correct?

You said :
a small number of primitive data types or simple reference types
Then definitely SharedPreferences is preferred. If you can image to have a lot of similar rows of data which are all unique rows then use SQLite. You have three requirements and none of them need to store big amount of similar, nevertheless unique, data.
On the other hand:
an array or an object of a derived type may also need to be stored.
i would suggest to store these data in private text files and with every app launch try to decode the data (if it exists).

How to store this into SQLite Android?

Hey so I am new to using sql dbs, (mongodb / nosql fan here)... and I am trying to create an app on Android and store the information usually stored in a db for a website on the device, from what I understand I should use SQLite? (any objections let me know). When wanting to show info on a website would I be calling a get or can I just make the query calls right on the activity screen?
Lastly, this is an example of the information, and I wanted to know how I would store this as I heard that it only accepts integers, strings, and doubles?
Here is the db info needed to be stored:
Stored: {
id: 2322d2ej2j2k, (unique)
name: Animals, (unique)
languages: [english, spanish],
order: [a, b, c, d, e, f, ...],
words: [{english: hello, spanish: hola}, {english: thanks, spanish: gracias}, ...],
date_created: new Date()
}
Also, for the order of letters, I want to be able to say that the order can be for letters in other languages too.

I'm unsure what you mean with "wanting to show info on a wesbite would I be calling a get", as the SQLite database would be stored in a sandboxed location belonging to your app, you wouldn't be making HTTP requests but talking directly to the database.
I can suggest looking into : android.database.sqlite.SQLiteOpenHelper and extend it to create a wrapper for android.database.sqlite.SQLiteDatabase for the most common CRUD operations.
While it's true that SQLite is more limited in data types (and querying operations) as full-on SQL, I find it more than adequate for most data operations. For complex Objects / nested values (like the "words"-property you describe in your question) I'd serialize these types of data into a String/JSON and reassemble it back into an actual Java Array/Object when reading it back from the database.
I prefer to think of records as entities in this sense and create a Model (extending your SQLiteOpenHelper implementation) which wraps the QSL CRUD functions to work with Java Objects and convert these to and from the data types supported by the SQLite database (i.e. create an abstraction layer such as "saveRecord" which accepts a Java value Object described the properties you posted in your question, but internally converts it to a more friendly format for storage, likewise a "getRecord" which returns a Java value Object created from the stored data).

How to write to and read data from Android's ApplicationContext?

In my app I need a central storage object that will be accessed from different parts of the application (like a singleton data holder).
AFAIK the clean way to implement singletons in Android is to use the ApplicationContext.
How can I
put data (like instance of List<MyPieceOfInformation>) in the ApplicationContext and
get them out of it
?
Is it correct that the only way to store more or less complex data in Android is to use the built-in SQLite database?

you can use mysql and others as well.
it is all depends if you want to save the data in local or external.
as external, for example, you can use mysql and web server, then communicate using json.
for saving List, you can use static.

In my app I need a central storage object that will be accessed from different parts of the application (like a singleton data holder).
Then use a singleton.
AFAIK the clean way to implement singletons in Android is to use the ApplicationContext.
First, there is nothing in Android named ApplicationContext. You probably mean Application.
Second, in the opinion of many experts (myself included), a custom Application is less "clean" than regular singletons.
Is it correct that the only way to store more or less complex data in Android is to use the built-in SQLite database?
Comparing a singleton to a database is like comparing an apple and an asteroid, on the grounds that both are made of matter and, in English, begin with the letter "a".
A database is persistent. You use a database when you want to save data persistently.
A singleton is not persistent. You use a singleton for transient data, such as a cache of data that is backed by a database.

Android Store a Parcelable Object in SQLite

I need to store an object content in Sqlite.
I was wondering which was the best way to do it with a serialization of the object or with Parcelable.
Is it possible to store it as Parcelable? How can I do it?

You are welcome to convert your object into some sort of persistable data structure (XML, JSON, Serializable) and stuff it in some database column. Bear in mind that you will still need to deal with compatibility issues (e.g., Version 2 of your app changes a class, which now needs to deal with both Version 1 and Version 2 structures). Also bear in mind that, going this route, you lose a lot of database capabilities (e.g., querying on something in the object).
You are also welcome to experiment with object databases, or CouchDb, or storing your persistable data structure to a file, if SQLite is not a requirement.
What most certainly will not work reliably is to pour the Parcelable into a Parcel and try storing the Parcel. A Parcel is meant for IPC use only and is not designed to be persisted. This is one of the reasons why Parcelable is faster than Serializable.

If you need to persist data, use Serializable. Parcelable is meant for IPC use. It is a binary format and not recommended for persistence.

How do I combine usage of db4o to store data and Lucene to index data for fast search?

I'm new to both db4o and Lucene.
Currently I'm using db4o to persist my data on an Android app. I need the capability to perform quick searches, as well as provide suggestions to the user (e.g., auto complete suggestions).
An SO poster mentioned using Lucene to index data and db4o to store it.
Has anyone implemented this approach ? If yes, I would appreciate if they share the overall approach? What are the alternatives?

I used Lucene to extract keywords from items to be stored in the database and store what I call 'keyword extension' objects that point to the corresponding domain objects. This made the domain objects findable by keyword (also allowing for stemming), and separated the keywords concerns. The database was built from a large static dataset (the USDA food nutrient database), so I didn't need to worry about changes during runtime. Thus this solution is limited in its current form ...
The first part of the solution was to write a small chunk of code that takes some text and extracts both the keywords and corresponding stems (using Lucene's 'Snowball' stemming) into a map. You use this to extract the keywords/stems from some domain objects that you are storing in the database. I kept the original keywords around so that I could create some sort of statistics on the searches made.
The second part was to construct objects I called 'keyword extensions' that store the stems as an array and the corresponding keywords as another array and have a pointer to the corresponding domain objects that had the keywords (I used arrays because they work more easily with DB4O). I also subclassed my KeywordExtension class to correspond to the particular domain objects's type - so for example I was storing a 'Nutrient' domain object and a corresponding 'NutrientKeywordExtension' object.
The third part is to collect the user's entered search text, again use the stemmer to extract the stems, and search for the NutrientKeywordExtension objects with those stems. You can then grab the Nutrient objects that those extensions point to, and finally present them as search results.
As I said, my database was static - it's created the first time the application runs. In a dynamic database, you would need to worry about keeping the nutrients and corresponding keyword extensions in sync. One solution would be to merge the nutrient and nutrient keyword extension into one class if you don't mind having that stuff inside your domain objects (I don't like this). Otherwise, you need to account for keyword extensions every time your create/edit/delete your domain objects.
I hope this limited example helps.