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).
Related
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).
Creating android financial manager application with using of SQLite.
My question is how to deal with the database in terms of object oriented programming?
Say I want to write information about a purchase into the database.
Should I:
1) Get user information from EditTexts, put it into an object say "Purchase", which contains fields: productName, ammount, price...
And only than put information from the object into the database?
2) Or put data from EditTexts directly straight into the database?
3) Another way?
I've used many different frameworks available out there, from SQLite to ORMLite. But, in terms of speed, there is no alternative to Realm.io. You can basically create your data models and define them as Realm Objects. Then the rest is easy, you can read, write and query among the data models you created.
If you want to know, what is a better way to use SQLite, than you can check this article
Option 1. Create objects that does represents your data.
Create your Database Class to use the objects instead of methods with multiple arguments.
I would make a container class that you use as a way of keeping the code clean.
I am coming from a Sencha Touch background into Android/ Java programming.
For a simple List based application (say a Note, that has a Note Title, Note Text, Note Author, Note Date Created, Note Comments),you could define a Note model with Title, Text, Author, Date Created and a Comments model, that has the Comments Text and Linked Note object/instance. (the basic way to make a database design)
You can then define a Data Store (a local database) that knows which endpoint to fetch the serialized Notes data from (essential a JSON array of Note objects, with embedded comments objects inside them), and define functions to draw out useful info out of the JSON array and put it into the Notes object
The View (the actual list display of notes) then accesses the Notes Stores and anytime the Store is changed the ListView is updated automatically.
Is there such an elegant mechanism in Android? I experimented with ORMLite (which is somewhat similar to stores), but is there a way to achieve this tight external endpoint -- local store -- list view binding in Android?
Out of the box, Android offers but one type of database, SQLite. While there are other storage options (file system, preferences, etc) it sounds like you def want a DB. Android has a nice write up for all storage options, and here's the SQLite section.
To bind that data with a ListView, you'll need to use a CursorAdapter. If you don't want to handle the view generation part, you can instead use the SimpleCursorAdapter. However they are more or less the same thing. As the name implies, these adapters work with Cursors. Cursors just expose the results of running a query on a database.
To achieve the automatic updates, you'll need to use a CursorLoader. Basically this guy handles querying for data on a background thread, then feed you the results on the UI thread. When there is a relevant change in the DB, it'll re-run the query and return you the latest data. Android has a nice write up explaining how to do this.
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.
Looking to store android.location.Address to a SQLite database. I am using ORMLite to persist my objects. ORMLite can persist Serializable items (as a BLOB I believe) but I think the only way to get something Serializable from an Address is to write it into a Parcel. Then I took a look at Parcel here: http://developer.android.com/reference/android/os/Parcel.html and it says it should not be used for general purpose Serialization mechanism. So I am just wondering what the best practice for doing this would be. I do not want to store the Address in contacts, strictly in my SQLite database. I am currently doing this with my own Address class (very simple) but would prefer to use the built in Android class for this.
thanks
The answer from the user list was to define a companion object that will be stored to the database and do the translation to/from the android.location.Address object by hand -- unfortunately. This will allow you to manager the storing of the various Address fields to the database without worrying about forwards and backwards compatibility with other Android versions.
Here's the discussion on the ormlite-user mailing list.