I am building an application which is a form generator (it creates a form with a SQLite database based on a configuration file). The problem is that the database will never be the same, so I need to make it dynamic meaning that I want to be able to specify all the table rows and tables of the database.
The problem I have is that, since it's a configuration file, when I create the database I dont know yet what are the tables and/or the table rows so I am not able to rely on the onCreate() of the database.
I was wondering if there would be a better way to proceed other than overriding the onCreate() to do nothing and making my own tableCreate() function.
I don't know if this is clear enough since english is not my native language but I will edit my question if I need to. And by the way I am new to android so snipet + explications are appreciated.
When the application loads, it creates the database using the configuration file (a simple text file) that is pushed to the application (only if the database does not exist).
Then it creates the tables based on the configuration file again (the name of the table rows and type of data).
The application builds the form based on the configuration file with an attribute which will allow me to save the answer in the database created previously.
This application's goal is to be able to create new forms efficiently and in a really quick way in order to gather some informations on given person.
Ok so I managed to build a workaround:
what I came up with is that I have a db with 4 fields (_id, farmerId, fieldName and fieldValue) this allows me to have some kind of value key for a specific farmer.
Then I builded some functions that generate a JSONObject with the different rows concerning a specific farmer and returns it to my activity. This way, it does not really matters if an "object" would need 5 or 6 fields.
Related
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.
I am currently developing a health app on android.
There would be a need to store personal data like gender, height and settings for app.
I plan to create a table with different columns.
My question is about creating the table with default values and editing the database.
My first thought is to create table and add a row with default values in onCreate().
But it seems to be wrong usage of onCreate() as i see multiple examples that only db.execSQL(SQL_CREATE_ENTRIES) is onCreate().
Second thought is to make use of DEFAULT in SQL but still i have to find somewhere to run add row.
What's the good practice to do so?
About editing those data, i put multiple public get and set function in sqliteopenhelper class.
Is it right to do so?
As multiple tables are created, the sqliteopenhelper class seems to be a bit messy since there are a lot of functions.
Welcome to any suggestions and criticism.
Thanks all.
Does your data really need an entire SQL Database? From your question I understand that you store data (gender, height) for a single user. If it so, you can use Android's SharedPreferences. SharedPreferences are a simple Key-Value store system where you have functions for both setting and getting you values based on a key (similar to a single SQL Table with two columns, key and value).
I am developing an android app that allows users to create notes and save the notes in the android sq lite database.
The notes can contain elements I call UI elements, and each UI element has a corresponding table in the database and is linked to the 'note' table using the foreign key of the saved note.
Whenever the user saves a note, I save the note with all its elements in their appropriate tables.The user may choose to continue editing after a save action is performed.
Now, when the user tries to save again, I am presented with two options.
Delete the note record and related records (UI elements) from the database and save the note again (re-insert). I consider this an easier method.
Try and update the note table and tables related to the note, deleting UI elements that has been deleted and adding UI elements. I consider this as more tedious but logically correct.
I want to find out if there are any other methods that I can use to update an already saved record rather than these or if there is an improvement that can be made to these two models suggested.
Thanks.
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.
I need to store an retrieve a vector of an unknown number of objects in an android sqlite database.
Essentially, the setup is this: I am developing a task management app, where the user can add as many notes as they like to their tasks. My current setup uses one database, with one row per task. This presents a problem when I need to associate multiple notes and their associated information with one task. I can see two approaches: try to store an array of notes or a vector or something as a BLOB in the task's row, or have another notes database in which each row contains a note and it's info, as well the id of the task which the note belongs to. This seems a little easier to implement, as all I would have to do to retrieve the data would be to get a cursor of all notes matching a particular id and then iterate through that to display them to the user. However, it seems a little inefficient to have a whole new database just for notes, and it makes syncing and deleting notes a little more difficult as well.
What do you think? Is it worth it to have a separate notes database? Should I use a BLOB or go for the separate database? If a BLOB, are there any good tutorials out there for storing and retrieving objects as BLOBs?
It sounds like you need another table in your database (not another database). You already have a table for Tasks. Now make one for Notes. Make a column be a foreign key into the Tasks table. That is, Notes.Task_ID would hold the ID of the Task that the Note is for. Then when you want to get all of the notes for a task, query the Notes table.
I think the answer to this question really lies in how you're going to go about updating things should they change. For now, the BLOB route probably seems like a really good idea, but what happens if you want to add some new functionality and you want to store some new property of notes (think of things like starred or importance). What would you need to do in order to update the notes object to add this new field? If it's just a database table, it's quite easy to change the layout of the table and even add a default value. If it's a BLOB, you're going to need to go through each entry, de-serialize the BLOB object, fix it, and re-serialize. That could get tricky.
Also, and this probably isn't as important to a small application using an embedded database, but it's easier to modify the database outside of the application if the object isn't a BLOB. Not to mention the queries you'll be able to write with the separate table. For example, how might someone calculate the number of notes that are attached to a task? If it's separated out in the database, it's a simple query.
Just my two cents.