This will be an additional question to my previous question: Storing password for an offline app
If I store my password in a file in external storage and it's encrypted, is the file editable?
I'm just thinking for example, I set a pass "hello" and stored it in a file. Then to login, I will call that encrypted string.
What if you open the file where your password is stored and edit that encrypted string and save it and you try to login again in your app, will the "hello" still work?
Sorry, I'm kinda new to this thing.
Why don't you use SharedPreference for this kind of data saving. If your data is not quite big you can use SharedPreference for that. Save the data in SharedPreference so it wont be editable explicitly. And the data is only editable by your app. Documentation for SharedPreferences
The SharedPreferences class provides a general framework that allows you to save and retrieve persistent key-value pairs of primitive data types. You can use SharedPreferences to save any primitive data: booleans, floats, ints, longs, and strings. This data will persist across user sessions (even if your application is killed).
Yes, the file is editable. The only way you can make it uneditable is storing in internal storage using mode_private.
The encryption prevents people from reading what the password is and editing into a format readable by your application only.
Related
I read shared preference is used as a session for small data storage. I would like to know , what are the way to manage session in android and which is more efficient and useful way to use session. please guide me.
It can be as simple as storing a datetime string lastUsedDate in SharedPreferences, and looking up lastUsedDate everytime the app's onCreate() is called and calculate the time passed since.
you can manage your session via api, you can store a value in shared preference when your app is lunched. This start a session when you store a value , when you need to close this session or log out just change your share preference value and update your api and your api return a value which define your app state
you can use your sqlite to store sessions..you can also make use of Bundle.
Before you can talk about the one most efficient in storing session, the data size will have to be considered.
Your data storage options are the following:
Shared Preferences
This stores private primitive data in key-value pairs.
Internal Storage
This stores private data on the device memory.
External Storage
This stores public data on the shared external storage.
SQLite Databases
This stores structured data in a private database.
Network Connection
This stores data on the web with your own network server.
you can also check here for more explanation
I wanna save a user's score that is retrieved from a server, locally, in order to reduce number of calls to the server.
However if I use SharedPreferences, it could be easily edited by the user. If I use a local database, it could also be changed if user has root access.
So is there any way to safely store data? Should I encode it?
Note that I can't check if local score equals server score, because it may be modified by the app.
A better way to enforce security while saving data in either to save it on your server and enforce security there. But, if you want it to be saved on local; then encrypt them and save them.
For sqlite encryption; https://guardianproject.info/code/sqlcipher/
is great. (link to project)
For saving files or blob data https://github.com/facebook/conceal may
help.
For saving simple key-value pairs in sharedprefs -
https://github.com/scottyab/AESCrypt-Android is useful
It is not good to save sensitive data such as user's personal information and/or passwords in shared preferences or raw sqlite database without encryption.
I have to store some data (string) in my Android app and I'm a dilemma. What is better solution ? Use Set Collection and keep it at SharedPreferences or I should save data to File and when I need it I have to read data from file and put it for example on ArrayList.
Depends on the quantity & complexity of the data. There is no straight answer to your question.
General approach: If the data are not too sensitive, small in quantity and more frequently used then you should go with SharedPreferences.
If your data is quite large lets say few hundred KBs of String then you should go with File.
SharedPreferences ultimately stores data into a file. The advantage of using SharedPreferences is that, the data is stored as a key value pair and can be retrieved easily using a key.
It depends on what you want to store.
Use SharedPreferences when you want store simple, prmitive data. Keep in mind that SharedPreferences will be available only for your app, so anothers apps cannot get data from it.
Use File when you have more complex data. You have to take care about how file is available to others. If you put it in sdcard root directory for example it will be available for everyone. If you put it in app package it will behave like SharedPreferences.
I have an android project in which I need to save small amount of data. Either 3 tables with 1-20 entries each or 2 dictionaries with nested dictionaries inside (so not only primary data types) or something close to that. These are simply user preferences and login(s) for the server.
I already read about the options for storing data but I don't know which one is the best for my case. I would like to use shared preferences but I am not quite sure that I can store my nested information there. Does it work? Is there a better solution?
My data (example):
Server logins: Some keys, including data key. Data contains URL, user, password etc.
Favorites: Different info for the items, including server key/data.
The data will be updated rarely, so I can also store some info redundantly to avoid connecting tables or reading from multiple files. The data has to be persistent across sessions and securely stored, not available to any other applications...
I would recommand to use the sqlite Database. This storage is persitent across killed processes and is only private accessable from your App. Have a look here for a first introduction.
SharedPreferences are desigend to store primitive data types, so you cannot easily store nested dictionaries.
Cite from the docs:
The SharedPreferences class provides a general framework that allows
you to save and retrieve persistent key-value pairs of primitive data
types. You can use SharedPreferences to save any primitive data:
booleans, floats, ints, longs, and strings. This data will persist
across user sessions (even if your application is killed).
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.