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.
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.
Currently I have developed an android application that uses a local sqlite database per installation. The database comes pre-populated with static tables, and the entire point of the application is to allow the user to assign dates/comments with the pre-populated information in each table.
I am looking to bring this online, and move the database to a mysql format, allowing access via desktops and other mobile devices. Is the best way to handle this to assign each new user a new database?
I would strongly avoid creating multiple databases, and instead add relationships to the existing database structure you have with a users table. Each user has an association to each existing object. Keep in mind sharing with other users in the event that you may want to allow one user to see another user's info.
My suggestion is provide an update to the app where after the first launch after updating it pushes their information to your MySQL database and inform the users that they can access their data via other methods now.
how many user to you expect? I would use only one database with a user table instead of hundreds/thousands of databases.
One table for all users (only with user info like id, email, password, etc).
Another table with comments (with user id and his comment), so that you can add as many comments per user as needed. If dates are related to comments put them on this table, else another table for dates as well.
We've got an android app and an iPhone app (same functionality) that use sqlite for local data storage. The apps initially come with no data, then on the first run they receive data from a remote server and store it in a sqlite database. The sqlite database is created by the server and the apps download it as one file, which is then used buy the apps. The database file is not very large by today's standards, but not a tiny one either - about 5-6 MB.
Now, once in a while, the apps need to refresh the data from the server. There a few approaches I can think of:
Download a new full database from the server and replace the existing one. This one sounds like the simplest way to deal with the problem were it not for a repeated 5-6 MB downloads. The apps do prompt the user whether they want to download the updates, so this may not be too much of a problem.
Download a delta database from the server, containing only the new/modified records and in some form information about what records to delete. This would lead to a much smaller download size, but the work on the client side is more complicated. I would need to read one database and, based on what is read, update another one. To the best of my knowledge, there's not way with sqlite to do something like insert into db1.table1 (select * from db2.table1) where db1 and db2 are two sqlite databases containing table1 of the same structure. (The full sqlite database contains about 10 tables with the largest one probably containing about 500 records or so.)
Download delta of the data in some other format (json, xml, etc.) and use this info to update the database in the app. Same as before: not to much problem on the server side, smaller download size than the full database, but quite a painful process to do the updates.
Which of the three approaches you recommend? Or maybe there's yet another way that I missed?
Many thanks in advance.
After much considerations and tries-and-errors, I went for a combination of options (2) and (3).
If no data is present at all, then the app downloads a full database file from the server.
If data is present and an update is required, the app downloads some database from the server. And checks the content of a particular value in a particular table. That value will state whether the new database is to replace the original or whether it contains deletions/updates/inserts
This turns out to be the fastest way (performance-wise) and leaves all the heavy lifting (determining whether to put everything into one database or just an update) to the server. Further, with this approach, if I need to modify the algorithm to, say, always download the full database, it would only be a change on the server without the need to re-compile and re-distribute the app.
Is there a way you can have a JSON field for each of the tables? For instance, if you got a table named users, have a column named "json" that stores the JSON for each of the users. In essence, it would contain the information the rest of the fields have.
So when you download the delta in JSON, all you got to do is insert the JSON's into the tables.
Of course with this method, you will need to do additional work in parsing the JSON and creating the model/object from it, but it's just an extra 3-4 small steps.
I will recommend approach 3, because app will download the json file more fast and local db will be updated more easily avoid overhead of more internet usages.
Just create a empty db initially according to server db and then regularly updated the same by fetching json
I know there are similar responses so I am going to make this very succinct. I am planning on developing an app which has 18 chapters and each chapter has 30 or 40 hymns. Now, Im planning on using an SQLite command, insert each hymn individually but after the insert, and after the APK file is generated, would the data on the database still be present? Or Does it need to inserted in on each install? What are my options?
If you use sqlite database for you app...every time the app is installed.. new database will be created(of course the old one will be deleted).. and so the hymns will be inserted on each install..(but once you install.. on running your app wont create new database and insertions..).. hope this is clear..
I am not Clear with your question..but if you r inserting data through your code..than on each installation your records would be inserted once..if you provide condition to do so for only once.
You have to code the insertion of the hymns at the start/launch of the application, so that the database is ready for retrieval for the application. But the next time, the application is started, check whether your database exists and has the hyms (size of database), if yes, dont populate the database again, if no, populate it. I hope you want to read from a file/array and insert the records to the database.Once you insert the records to the database, they are available for the reference until the application is uninstalled or the database is re-created. Sqlite database is a persistent storage. Now, Im planning on using an SQLite command, insert each hymn individually but after the insert, and after the APK file is generated, would the data on the database still be present? Yes it would be present. Once the application is installed, the code of database would be executed and the database would be created.
My suggestion to you is use the XML parsing to show the Hymens in place of sqllite. Simply create the xml file with the hymen tag then get the tag and show the data on screen.