In my grocery app,I was saving products selected by users in Singleton Class.Now according to new requirement, these products(cart) should be retrieved again whenever user reopens the app.
Class Product has many fields :
{
"imageDisplay",
"categorySpecial",
"_id",
"name_ch",
"name_en",
"origin_ch",
"origin_en",
"description_ch",
"description_en",
"specification_ch",
"specification_en",
"unit_ch",
"unit_en",
"priceOriginal",
"price",
"stock",
"sold",
"isOnShelf",
"processingPriority",
"imageCover"
}
1) My First question is should I just be saving all product field or just product Id.In case, if I save product Ids,I will have to retrieve detail of all cart products when app starts ,but If I save all fields of product then it will occupy a lot of memory.
Which one is the preferred way to save products?
There are 3 options as per my knowledge
1) storing in shared Preference
2) storing in File
3) storing in sql
You could also use a simple SQLite Database. Since you only need to store grocery items, I don't think you would need more than one table with 2-3 rows. Android has pretty good documentation on it. If you have any struggles with it you can ask here or see some step-by-step tutorials.
Android documentation:
https://developer.android.com/training/data-storage/sqlite
To retain the state of an app upon app death, SharedPreferences is to be used. If you need a database, you can use SQLite.
For your intention, SharedPreferences is the best as all you need do is to retain what the user sees before killing the app. Hence, all you need concern yourself are those fields in your data that are presented to the user (those data that users sees or interact with before killing your app) one of which may be id or origin_ch.
For database you need all necessary data saved but for SharedPreferences, you need only the data the user sees or interact with before the app death.
If you are storing Products in SQLite database better decision will be to store product ids in SharedPreferences. To retrieve products cart you first obtain ids from SharedPreferences and then find your products by that ids. Imagine the situation when product options changed - you will required to change both SharedPreferences and Database product instances stored, so just storing id's will be better decision.
Related
I'm creating an app where I'm going to be storing data that the user enters. Let's say for instance it's someone weight. I have created an SQLite database that is able to store this information. However, I want the user to be able to update the value if the weight changes, but I don't want to lose the previous data. Would I have to create a separate database to store this past information? Or is there a more effective approach? Thanks for your time.
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.
Can I use a column in table to check if user has logged in.
When user logs in I set value to 1. When he logs out I set to 0.I dont want to use SharedPreferences. Is using it like this inefficient.
I used sharedpreferences first. I set username in the sharedpreference along with other preferences and display username in the nav drawer. When I install the app in another device, I think even the sharedpreference file will be installed and I saw that in the new device the username is displayed in the from the sharedpreference file though that user doesn't exist in the table in that device's database
When user logs in I set value to 1. When he logs out I set to 0
Here, what will happen is when you set values to 0 or 1 you have to open and close database everytime and will be a hastle to maintain. you have to check it each time what flag is. while in SharedPreferences it will be globally accesible and easy to set flag.
I would suggest you to use SharedPreferences because
SharedPreferences is a key/value store where you can save a data under certain key. To read the data from the store you have to know the key of the data. This makes reading the data very easy. But as easy as it is to store a small amount of data as difficult it is to store and read large structured data as you need to define key for every single data, furthermore you cannot really search within the data except you have a certain concept for naming the keys.
To give an example, SharedPreferences are useful for storing user preferences, where there are just a handful of variables that need storing. SQLite on the other hand would be better for storing data where there is a large set of items, such as song titles in a music library which need to be searched through
Check SharedPreferences and SQLite.
Better to use Shared Preferences instead of using Database for such a small thing.
Refer this : http://www.androidhive.info/2012/08/android-session-management-using-shared-preferences/
I know this topic has been discussed before on Stack Overflow. But there are still some things that are not clear when I read previous posts about it. So here they are:
I know that we use shared preference for small datasets and sqlite for large data manipulation, so if we just want to save a username and password should we use shared preferences?
Won't shared preferences be lost when user uninstalls the app? For example I download an app called abc and save my username and password. Then I uninstall this app from one phone and try to access it from other phone using the same username and password. Will this be saved using shared preferences or the data be lost?
What are the main reason we use one over the other beside large and small datasets?
You can think of the difference between shared preferences and an SQLite database in terms of data size but that isn't entirely accurate. A better way to think of it is in terms of the structure of the data you want to store.
Shared preferences can only store key-value pairings whilst an SQLite database is much more flexible. So shared preferences are particularly useful for storing user preferences, e.g. should the app display notifications etc. Whilst an SQLite database is useful for just about anything.
Both data sources are local but something you should be aware of is the ability to backup your application data to cloud storage that is linked to the user's Google account. This makes it much easier for your users to change devices and for their applications to easily transfer to the new device. For more info take a look here.
In the situation you described about you will lose the user name and password in both situations. The data is stored on the phone, when you uninstall the application, the data that some with it will also be lost. The user will have to re-enter this information.
You can save the user name and pass in either the shared Preferences or a DB, that is personal preference. Just make sure you lock either down, i.e. don't share the DB or Shared Preferences that you keep this information in.
As for the difference... shared Preferences should hold well... shared Preferences... here is an example:
If I create an option to change the background color, I will store all available options in a DB that can be loaded into a adapter view for the user to choose from. But I will store the color that they have selected in the Shared Preferences. This way when the application load I can get the Shared Preference value of the background color that should be used.
SharedPreferences is used for just that, storing user preferences shared application-wide. You can use it, for example, to store a user's username, or perhaps some options he or she has configured in your app in which you want to remember.
SQLite is a relational database. It's used to store your application's data, not preferences or configuration information.
Both are stored locally on the device.
1.SharedPreferences stores only Boolean, int, float, long, String five kinds of simple data types, such as can not be conditional query. So, whether SharedPreferences data storage operation is how simple it can only be a supplement of storage, but can not completely replace other data such as the SQLite database is stored.
2.SharedPreferences based on the XML file to store key-value key used to store configuration information(mainly user preference for your application).
3.Sharedprefrece just like cookies in web which store some basic information at client side.
both store their data locally, so uninstalling the app will delete both. other than that, SharedPreferences is easier to program, and you're right about the data amounts.
In general, shared preferences should be used if you want to allow your user to directly manipulate certain data fields. Shared preferences are basically user preferences; if you would like the user to reconfigure the app to behave in different ways, you should expose that functionality as a shared preference. On the other hand, the SQLite database should be used if you want to limit the visibility of the data to just the application, if you want a stronger guarantee that the data be persistent, and if you want the application to behave independently of what is stored in the database. Of course, you can use both in one application.
Shared preferences and the database are part of local data that the application stores. If you uninstall the application, both of the data stores will be removed.