Storing user data in from api in "session" - android

I am not sure of the best way to do this, when user logs in my app i want to store his data from an api. I will be using this data trough out the app, so i dont call getUserData all the time . So i want to ask for an opinion
Do i store user data in application context so i can access it in all activites/fragments
Or
Do i store the user data in SharedPreferences as json string (User has a lot of small data name,lastname,age,email...)
Or
Do i store it in database (Since i only need storing for this i tought this way might be too much, but could be wrong)
Or
There might be a better way to do this?

SharePreferences are great, but it is stored in plain text and can be read by rooted devices. Someone with a stolen rooted phone can potentially access tons of user info.
Use a library like:
https://github.com/scottyab/secure-preferences
To encrypt the preferences or use a secret key to encrypt and decrypt the data.
You can initialized the user object on the OnCreate of your Application Object this way. Have you app instance be a singleton and you can access this user object object amongst your activities and fragments.

Related

Authendication data Store in android

I Know If the User have to Store UserName and Password then we can create Class and store the UserName and Password in Class. At get the data using SharedPreferences for that class.But That class store the data upto we can not close the Application. If we close the Application then data will be destroyed.
My Question is :
I Want to Store Data in Application if the User close the application or Restart the Mobile device. But the data are Store in the Class. How to perform this task. I am new to android. Please Help me.
You are new to Android. So, you should go through this link. You got these many Storage options in Android: http://developer.android.com/guide/topics/data/data-storage.html
In your case, You can go with SharedPreferences. Your data will be stored in key-value pair. And also, it is persistent storage.

Is Shared Preferences safe for private datas?

Im saving datas from my db/user into a gson formated ArrayList in SharedPreferences. Now my question :
Is it safe to save these datas (or data in general) into Sharedpreferences. Are users able to read these gson Arraylists out ? Maybe from SD card ,in a folder or somewhere else.
Thank you !
They are stored as xml files in your app directory, with permissions that allow only your app to access them. But on rooted device they are easily accessible. If you are concerned with security then you may use encryption, those projects might be usefull to you:
https://github.com/rtoshiro/SecureSharedPreferences
https://github.com/sveinungkb/encrypted-userprefs
still those projects does not give you 100% guarantee, hacker may decompile your apk and find keys used to encrypt shared preferences. So if your data is of use only for short time then remember to remove it from your device once user has finished using it. You may for example keep data on server and download it only when needed, caching locally only for short time - when its needed.
SharedPreferences is just a file located in phone private memory. So user can't access it but root can. Root can everything and many users have root's nowadays. You shouldn't store fragile data there
Android SharedPreference security
You can read all shared preferences Data
The SharedPreferences class provides a general framework that allows
you to save and retrieve persistent key-value pairs of primitive data
types.
To see the information in the store you need to know the important thing from the data. This will make reading through the information super easy. But as simple as it's to keep a tiny bit of data as difficult it's to keep and browse large structured data since you need to define key for every data, in addition you can't really search inside the data except you've got a certain concept for naming the secrets.
Please read Android SharedPreference security

Creating app lock for android phone

I am trying to create an android activity "Save_Password" which stores the password in a database "PasswordDB".There is another activity named "Enter_Password" in which I want to allow the user to only enter the password which is already stored in SQLite database.
When I run this for the first time "Save_Password" should open. When I again open it "Enter_Password" should open.
Is there some query which I can execute to check if table exist or not.
Or should I use Shared preferences?
You don't need a database for just storing a "password". You can use SharedPreferences for that purpose.
Its very simple to use and a much light-weight operation that database. Doesn't slow down your app even by a bit.
If you are storing passwords locally in SharedPreferences, then they can be easily read, so its better to encrypt them and store and later decrypt them.
You can do this in a very simple way by using this small library, SecurePreferences
It will handle all the encryption and decryption automatically for you.
You just need to save password right? Then use SharedPreferences.
But saving password locally is not a good design choice.At least encrypt the data before you store, and decrypt it whenever you want to read it.

Use `SharedPreferences` to store authentication token

I use token based authenticated mechanism on my server. When user logins through Android app the server returns token which needs to be sent with each subsequent request. I need to store that value on the devices. Since token is a simple string, I thought I'd use SharedPreferences to hold that value. When application starts inside MyApplication extends Application I query SharedPreferences for this token and hold it inside MyApplication as a global state so that every activity could access it when it sends request to the server.
Is this approach viable? If not, what critical drawbacks does it have? And if it's a bad idea, what's the alternative approach?
PS. This is not a subjective question - I'm not asking for the best approach, I'm validating my assumptions.
It's fairly safe. The users wont have access to the SharedPreferences unless they have rooted their devices. If you're concerned about security that much, you could encrypt the token before storing it inside SharedPreferences.
it is a valid option, if you don't want to use a database or write the token on a file. No drawbacks that I can think of
It has one fault if the device is rooted. The user can see the token from SharedPreferences from their device if the device is rooted. I suggest you to store the data to the database/SQLite using Sugar here for better approach to your server.

Difference between shared preference and sqlite

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.

Categories

Resources