Using multiple SQL databases - android

I'm creating an Android app that will download XML data from my website, parsed xml data will be inserted into 5 separate SQL Lite tables. I have successfully logged into my website, got the XML data & parsed. I not sure how to layout the database code for multiple tables(opening, closing, inserting, selecting).
Also I would like (is this possible) these tables to stay on the device if the user needs to logout and come back to the app at a later time.
Any help or direction would be appreciated.
Thanks

Question title says "multiple databases", body says "multiple tables". I take it to mean "multiple tables".
Just use SQLiteOpenHelper. Create all the tables in onCreate(). Do the opening/closing and CRUD operations the same way you would do on a SQLiteOpenHelper hosting a single table.
Use a search engine to find tutorials about SQLiteOpenHelper in case you need them.

Related

How can I handle updating the database in my application and at the same time retaining user scores and settings?

I have a phone application that uses a database of words and tests a user to see which words they know. I have a SQLite database with the words that I populate using a console application and this is then deployed as a resource to phones etc.
When the user runs the application then it stores pass fail data in the same database but in different tables.
When I update the application a fresh copy of the words database is installed on the phone and all the user data is lost.
How is this typically handled? Do phone applications that use SQLite have multiple databases with one being used to store user data and the other holding data which can be brought in when the application is first installed or updated?
If multiple databases are used then is it possible to create a look up from one database to the other?
Thanks in advance for any help, advice or links that point me in the right direction.
I would use a file (JSON, or plain text) to ship the words with the app. Then, when the app runs, it reads that file and adds the new words to the database. This won't affect the other tables.
Instead of having to deal with that, we hard code the values into a static method in code. Then at runtime, we see if there is any data in the table and, if not, we grab the hard coded data and do an insert.
In your case, I would also just add a version number of some kind so then, if the version was lower or the table was empty, you do a delete all and then insert your new static data.

Android SQLite database lifecycle

I'm new to android. I want to ask about SQLite database lifecycle. Basicaly, I want to include the insert data method and viewing data method in the main class (which basicaly called 1st when we open the app). Then I'm going to make some update to the database in another activity. What I want to ask is, when I'm going to open the app for the next time, which data that will be showed? Is it the 1st data that I inserted with insert method OR the updated one?
I don't understand exactly your question. So I hope this will answer it. There are 4 operations, you should implement: create, read, update, delete. For example when you have a contact table with id, name, phone number then you can create (John, 012345). If you then call the read method with id 1, you will get (John, 012345). But if you update this before you read it, you obviously get the updated item - the database didn't delete anything when you close the activity. I highly recommend you to create a new class to handle those crud-operations, because you will get crazy, when you wanna change the update operation and must search it in every single line from your app. I also recommend you to read this blog. It saved me a lot of time:
http://www.androidhive.info/2011/11/android-sqlite-database-tutorial/
As far as I understand your question,
my answer is -> You should see the updated data, because Db is same throughout the app.
The data that will be shown is the updated one , because SQL operations are immediate. It is very unlikely that onUpdate() will not update the database until and unless it encounters any error. you can see that itself using a CursorLoader attached with your cursor after running a query command. This can be done in an activity just displaying the contents of the database.
For database operations, It is beneficial to use Content Providers cause then you can extend your apps to widgets, share data with other apps etc.

Creating multiple databases in Android

I am trying to create multiple database tables in android where each table will represent an account. I am struggling to get more then one table per database
Would anyone have any sample code they could show me? Or any suggestions?
Thanks
I don't know anything about your app, but the way you're designing your database schema sounds a little questionable. Does creating a table for every account (whatever an "account" might be) really make the most sense?
Regardless, creating tables in SQLite is pretty straightforward. In your SQLiteOpenHelper class, you can call db.execSQL(CREATE_TABLE_STATEMENT) to create a table, where CREATE_TABLE_STATEMENT is your SQL statement for a particular table. You can call this for every table you need created. This is typically going to be called in your SqliteOpenHelper's onCreate method when the database is initialized, but you can call it outside of the helper as well.
If you are going to use a fair amount of tables and data, including a prepopulated database in your assets folder is another way to go.
When I started to use databases on android I found this very helful.
http://developer.android.com/resources/tutorials/notepad/index.html
ps now that you mentioned that there are only 2-3 accounts, creating one table/account sounds much more reasonable than first expected.
But it really depends on what you are planning to do with the data and where your performance requirements are. One could even use one single table or as well multiple tables for each (fixed) type of transaction - if the data for transaction types have very different structure.
Creating database table in Android is pretty straghtforward:
db.execSQL(CREATE_TABLE_STATEMENT);
where db is SQLiteDatabase object and CREATE_TABLE_STATEMENT is your create table sql statement
As in your question you did not explain clearly the requirement of your app, but I can see a few cons in your approach of creating one table for each user
If there are many users created, u will have many tables in ur database
If later on you have some information, settings that would be shared across some users or all user, you will have to replicate them in every user single table.
My recommendation would be you have one table for users, and another table for transactions with one column is user_id to link back to the user table. It would be easier to expand or maintain your database later.
Hope it helps :)

Android database approach for future updates

What is the best way to work with the sqlite database in android?
The sqlite database file (copy it for the first time into the application environment)
OR
Creating the tables in code (in database helper's onCreate())
My database has 6 tables and it is empty for the first time. I ask this because I want to update my database in the future and would want to know the best approach for this.
Thank you!
You should create (in code) it the first time it is used. Android offers the SQLiteOpenHelper class that should be used for it. SQLiteOpenHelper defines the following methods:
onCreate(SQLiteDatabase db): invoked when the database is created, this is where you can create tables and columns to them, create views or triggers.
onUpgrade(SQLiteDatabse db, int oldVersion, int newVersion): Invoked if the used database is older than the current version. Handle here the upgrade stuff (data migration, table creation/deletion)
See here for a good tutorial: http://www.codeproject.com/KB/android/AndroidSQLite.aspx
If you don't expect to have your db updated by user interaction, the file might be the best option, especially in the case that you have a lot of data to insert (file copying vs a bunch of inserts).
On the other hand, if you expect to have some data altered or added by the user, the file approach will work only in the first release.
Any time you will need to update your schema or add new data (releasing an upgrade), you will need to consider that the existing data might be changed or enriched by some stuff that the users will expect to find AFTER the upgrade.
So replacing the file is not an option anymore.
In case you need to use the sqllite helper approach, I'd love to hear some feedbacks on my sqllite helper code generator that you can find here: github
Not specific to SQLLite or android, however I have worked on a Windows trading application where users could save down Xml 'documents' - ie: a custom view saving their reporting preferences and various other flags which could then be shared around the team. On startup a user's profile was loaded and their documents parsed to customize the UI.
The application was to have a release every 3 weeks and existing documents needed to work with the new application. This was a problem as occasionally the XML schema changed resulting in new or deleted fields.
The solution we came up with was to create an abstract type called Patcher. Each release could have one or more DerivedPatcher types with it which were run on the first load after an update. The Patcher would have an abstract method to patch the XMl documents. Meaning an XML document would be loaded in with the old schema and upgraded, saved back in-place using the new schema. The Patcher would also have a rollback method to allow unrolling if an error occurred.
The same approach could be applied to tables in a database. Basically if you can create a patcher or PatchManager to serialize key tables to XML in memory, then apply the DB changes and write the data back, you can achieve database migration in a generic, re-usable way.
A key benefit of this method is it can be tested on developer PCs before deployment, so long as you have access to some sample SQLLite data. Knowing how your users use your application is key here.
For large amounts of data you might want to consider this kind of solution: Create an empty database in code and provide an activity which responds to an intent with this action: android.intent.action.SEND. Respond by parsing the sent file and populate the database with the contents. Design a format which can be easily parsed (XML is not needed for everything ;-) so the code to parse the file and fill the database is small (my binary for this including an UI to show progress (which is the larger part of the activity) is less than 12 kB in size).
The file may be distributed separately (extra apk, download, whatever). The benefit of this approach is that you do not need to store your initial database content within the apk and thus the data is only stored once on the device (after the file has been deleted). Otherwise you have the data in the database plus the source code or asset in the apk.

Downloading data/content into Sqlite database

I want users to be able to get additional content from my website which means I will insert the downloaded data into the device's SQLite. I am wondering if I am approaching this the right way..
My current approach is to create a REST web service which returns data in JSON format, parse the JSON and insert it row by row into the Sqlite db on the android device.
Is this the right approach? Will it be too slow if there are many table rows to be inserted at one time? Or is there a way to download another SQlite db and merge it with the local one?
I welcome any suggestion, thank you in advance for your answer.
I works, but you absolutely need to paginate : set a limit to the number of element sent by your rest service.
Another approach would be to download the complete sqlite database file at once, but that requires some tweaks. see http://www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications/ (it is about embeding the database from the assets, but the preparation of the database is the same.)
A last point: large amount of insert, as well as downloading data from a server, must to be done in a separate thread or asynctask, from a service (not an activity that can be interrupted), or even better from a SynchronizationAdapter, which is called by the system itself.

Categories

Resources