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).
Related
What is the best practice to store user data separately from the actual app data? The user data is a statistic and it will be collected during app usage. The database must be always updated but I have to keep the user statistic untouched. Can I store for example the statistic on one table? but can I keep this table when the App will be updated?
Update:
Sorry, I think my question was misunderstood. What is the best practice to manage two kinds of Data?
Save all data in one database and save the User-Data in seperetly tables? or
Create two Databases, one for App-data and one for User-data?
I'm not sure exactly of your question, but yes, you can have multiple tables in SQLite. So you can have one table for the user, call it tblUserStatistics and then other tables for the app, or depending on the data, the app information could be stored in preferences.
Yes, you can store your statistics in one table, but it's structure depends on what you want to save. If you want to save only numbers, you can create a table with 2 columns (1st one an ID and the second one the value you want to save), and update your rows when your data changes. If you've got multiple types of data to be saved (numbers, text, dates, whatever), you must create different columns with different data types, but still, you can do it. For your other questions the answer is yes, your table will be kept after you update your app, because it gets saved in a database which doesn't get modified when the user updates the app, just make sure that when you create the new version you don't change the name of the database.
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.
I want to make a simple database model for sms messages , i have the following model is it good or is there a better way to model them .
sms_message(_id,conversation_id,sender_id,time,text)
conversations(_id,last_msg_id,opposite_user_id,msges_counter_inside,has_new_msg_flag)
contacts(_id, display_name)
phone_numbers(user_id,phone_no)
I want to make it as sms message app on android
When designing databases, it is a good practice using singular names for the tables and columns. Otherwise it may cause confusion because when you retrieve records, you do not know if it is for just one object or many, and remember that the columns should be atomic (just one value). So, for example, use phone_number instead of phone_numbers.
Without knowing the hole scenario, the rest of the design seems good, as you separate the different elements in separate tables and relate them. (Do not forget to use foreign keys, primary keys and so on to keep your integrity ok!)
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 :)
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.