I am making application to collect health logs for a research purpose. I wanted some architecture design advice.
My app requirement:
There would be various forms with numerous fields.
This data needs to be stored locally (next phase is to store it on server)
Also we could have new form as the user base increases
The user must also be able to update a previously entered log
Question
For eg :
Form 1 : (Name , Age, Sex )
Form 2 : (Name , Age, college, height )
The actual form has many fields related to health information
Since the data I receive from the user would have varied fields as above, how do I Store the data of multiple forms into the database. Also I want to add the functionality to add new forms to the app, thus making a database table for ever form is not a good idea (in my opinion). I was thinking to store the data as a JSON string in to the data base with the associated form ID.
Option 1. Store each field as its own column in the database, query the database for the appropriate fields to recreate the various forms.
Note - that changing the field value, changes the value for all forms, unless you specify different column names to save the data under for the different forms.
See tutorial on creating an SQlite database to get started.
Option 2. Serialize a hashmap and store the map as a blob in the database. Easy to add new fields without changing your database. Downside: Can't query for individual characteristics (age, sex, etc). When you retrieve info on a person, you retrieve all of it, and pick what you need. (simpler, but less efficient / robust).
Related
My app needs to use data from different websites. On these websites, there is a search with different chemical ingredients.
How can I programmatically copy this data from website to my realm database?
This database on Realm needs to be saved as a table which has 2 columns: ingredient name, description.
First of all, create an ID for each ingredient, receiving ID, Ingredient, Description. It's the best way to avoid conflict.
Second, you need to assemble a crawler, and this goes beyond your android application, maybe a network service that can be done even in java, identifying the information on each site and inserting into your database. So doing turn your android application get this information from the site.
I have a product page with spinner. Spinner contains list of products. Dynamic views will be create by selecting product. No.of fields will be differ for each product. Fields may contain Edittext, Spinner. After user complete columns there is a save button to save filled details. Once user press the save button all fields value should be store in local.
I tried to save details in SQLite but sqlite only for structured datas. I am confused which local storage will be support for dynamic datas.
Please suggest any solution. Thanks in advance
You may serialize the result-object into json - and then store that json everywhere (sharedstorage, sqlite etc)
Simplest and fastest solution: you can have all the possible fields in the database and then store null values.
Best solution: Have multiple tables for all the different types of products that you can have and store the data there appropriately.
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.
This question already has answers here:
Pros and Cons of SQLite and Shared Preferences [closed]
(5 answers)
Closed 2 months ago.
i am developing an apps where i have to stored 30 to 50 friend contacts, Name,phone and password, i have two option shared preference and sql lite, so which one i should use so that it got less storage and could't waste many memory and which one will be faster during searching any contacts no or item ?
You should definitely use SQLite for that kind of data and requirements.
SharedPreferences are intented for saving preferences (hence the name), not for structured data resp. large amounts of data. Also with SQL you have ways of filtering and sorting the data, e.g. select * from contact where lastname like 'A%' order by firstname to get all contacts where the lastname starts with an A and have them sorted by their first name (just for example).
I think that the best solution depends from how the app must be developed now and in the future.
If you want to develop an app that can't change in the future ( for example the contact must be ever name, phone and password ) you can use a solution "Quick and Dirty" save on the shared preferences a key-value set and don't lose any time on it.
But if the informations can change and the app can have some improvements...is more usefull to create a object contact and a data structure to manage it.
If the contacts are a few number, you don't care about the performances. 50 records direct access to the id of the user have a good performance on SQLite.
SQLite (data is complex type and data is in large amount)
SharedPreferences(data is small, data is premitive type and you don't want to share it with user)
I am currently using PHPmyadmin to store data in my mySQL database. The android application I am developing requires the user to select some data and this data along with its attributes need to be stored in my mySQL database. I know I have to create a unique table for every user who downloads my application but how do I go about doing this without having access to the program which the user downloads ?
For eg: let us say there are two phones which download my application. I would want to create two tables in my database which the particular phone knows and can access
Creating one table for every user is a terrible approach. Instead you should create a users table, with a unique ID set to auto_increment, to generate those unique IDs. Then use separate tables to store the data you might need, referencing the user ID from the users table.
It might sound a little confusing, but there are lots of good reads about this on the Internet.
You can generate unique user id in php using uniqid(”, true) function.