I already know how to persist normal data throughout Android activities, but I'm wondering if the same methods are safe to use for Android purchase data.
I'm making a free app that uses in-app purchases to unlock all the content. This is something that I'm currently checking in the splash screen activity in order to customize the UI, however I would also need this information throughout the app.
Is it best to query in each activity, or is a Shared Pref safe enough?
As a note, I'm using v3 of Android' billing library.
Thanks
Shared Preferences are OK for this. Your data is sandboxed the same as if it were a database. (Security-wise, both are just as safe)
You will need to query either the database, or SharedPreferences to get this data in your Activity regardless. Doesn't really matter from which data store you retrieve it.
You don't have to worry about users changing your data (somehow changing their local status to 'paid') as they aren't able to change your SharedPrefs (or database values) - since they don't have access to these secure data stores.
Related
I'm using React Native to build an android/ios app. I'm using expo-secure-store with the bare React Native app and expo-secure-store saves data in SharedPreferences as encrypted on Android.
After I was updating my app, I received many reports from users that their data in SharedPreferences are reset and lost. On iOS, I didn't get such reports.
Is there any condition to reset data saved in SharedPreferences except the removal of the app?
As far as I know, data saved on SharedPreferences remains during its update. Is it wrong? I could not find any answer from the documentation. Please let me know about it.
The SharedPreferences data survives updates, but if the new app version expects different keys or value types, the new version of the app may not be able to read the information correctly.
Apart from app uninstall, the user can delete the application data which will also remove the SharedPreferences data.
I'm a new Android developer and could use some advice on a problem I've come across.
I have an app which is querying data from the Amazon Product API on almost every activity you open. I'm able to get the data, but the activities take forever to load because I'm constantly running API queries.
The app is basically a video game review app. It wouldn't be uncommon for users to load the same data for a game multiple times. I'm thinking that making api calls for the same data over and over again is very inefficient.
My question is in this scenario, should I be saving game data to a local, or even remote (Firebase) database every time data is retrieved from the Amazon API? And then whenever data needs to be retrieved, I check first to see if it's present in the database before making the API call?
If this is correct, where should I be saving the data (shared prefs, SQLlite, internal storage, etc.)? If not, what can I do to make the app pull & display data faster?
When you say that activities take forever to load, I assume that you are not making these calls from within the Activities. And lets answer your questions one by one.
1) Shared Prefs are not a good option. (Try to use Shared prefs only when you have a bunch of things to persist). While in this case if you want to save effort of writing helper classes for database you could serialize the data (Internal Storage). And its preferable to store data locally in my opinion.
2) Do not always request the data.Only update it when the user wants the data to be refreshed (hustle free, user presses a refresh button). Or you could update data after fixed time intervals. This can involve upgrading reviews in background even when the application is not running by starting Service using Alarm Manager. You will have to read about it though.
I have one app which authenticate user to access internal activity, App is having several activity which gets data from previous activity
So I am bit confused on activity life cycle
I read Bundle data into local variable in activity OnCreate and reading DB in async task based on that data. this DB data is displayed on my app.
Now if I switch to another app, will my app have that local variable/Static variable data (read from DB data) with them,
I have SingleInstance class which keeps user ticket etc informations, Is that variable keeps in memory of app if we got phone call in between.
I am bit confused on this part.
As document suggest that you need to store unsaved data in shared preferences.
It would be good if someone highlight on that..
Well, first of all you need to make sure you understand the difference between a new app and a new activity according to the sentence:
Now if I switch to another app, will my app have that DB data with them after switching back to my app
If you actually mean different apps, the answer is "NO in another app(in case is your app too)" you cannot have access to another application DB (at least not directly), the only way is if that application implemented a content provider to share its data with another application, by default android applications are like sandbox and do not share any information with other apps unless specifically declared, there's another rules between two apps signed with same key but that's a different story and a huge advance topic not related to this question...
In case that you " mean go to another app (not mine) and then try to use it from MY app again " the answer is "YES", the information in the database is accessible among all the building components like "activity, service" that belong to the same application, information in database is persisted even after closing completely the app (and so is shared preference), but there's a huge different between shared preference and DB, and knowing when to use one or another differentiates between good and excellent developers, golden rule (but not the only or the best) is that, DB is used for complex queries and relational data that needs some sort of preprocessing or postprocessing to get the proper values, mean while shared preference is just a "key/value" map that persist in the application context
Hope this Helps.
Regards!
After reading the documention it seems that onSaveInstanceStaate works per instance (as the name suggests). I am just wondering what the preffered method of storing data is so that it is available for all instances of that activity?
As MaciejGorski mentioned in his comment, there are different levels of data storage available in Android:
Shared preferences
Internal storage
External storage
SQLite database
Network
From personal experience, the lower you go down this list, the more complicated your implementation will become. Thus, if you are simply trying to save simple data for your app to be shared among different instances of an activity (or of multiple activities), shared preferences are certainly the way to go. You can even create private shared preferences, which only your app can access.
In any case, check out this SO answer for how to implement them: How to use SharedPreferences in Android to store, fetch and edit values
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.