I want to save user progress in my game which is essentially all saved in a sharedprefrences file.
So, instead of using third party services, I am wondering if I can simply save the whole file on my server
and in time just pull it and apply it locally?
So the question is - can a sharedprefrences file be saved as a bulk?
for saving progress locally you can use SQLite database or Room Database so you can easily update in the future if you want to update ... I will recommend room database rather than sqlite3 because that is consuming more time and room database easily you can work on crud operation without taking too much time ...and sharedpreference for getting issue if you want to update value and more time to take your job and confusion so use room database...easy and less time
Usually, you can find SharedPreferences xml file in /data/data/<your.package.name>/shared_prefs/ directory. But it depends on manufacter, so it's not guaranteed.
(For more information see this answer).
For getting shared pref file Context has folowing methods - new File getSharedPreferencesPath(String name); and depercated File getSharedPrefsFile(String name);
(According to source )
You can use one of them(or both for different Android versions) via reflection.
But, actually, it's not reccomended approach. Better choice is write your own prefs synchronization by copying all values with all keys.
Or just store preferences in your own database.
Related
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
I need to store some config predefined information in my Android app such as the list of the servers, logins and passwords. This information should be stored permanently and be editable. For some reason, I think SharedPreferences isn't what I'm looking for. Maybe using internal Android SQLite db would be better?
What do you think?
You can store predefined data in a .db file under R.raw and copy it to your app's working directory then use it with SQLite.
You can specify these setting values in program as variables and insert in sqlite on first launch of application, By this way you can edit these values later in sqlite, I hope this can help you.
I have generally found SharedPreferences to be more easier to implement (also demands less resources than any kind of database). In your case, in my opinion, you should go for SharedPrefences, by loading your required information on first launch through some predefined keys, example, URL + i, where i can be run from zero to the number of URLs. This can be then later retrieved and edited. You can save the initial values in arrays as suggested by others above.
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 want to build an android application which has static content. I dont know where should I keep my static content. Shall I keep it in my xml file or use sqlite db. Or shall I keep my data in xml file and create the table when the application loads . Data wont change much over the period of time and only fetch operation has to be performed on the data.
It depends on the data which you want to store..If it is some small key value king of data use
SharedPreferences otherwise you can use sqlite database if you relational data..Files are generally used to store non-relational data.
Refer http://developer.android.com/training/basics/data-storage/index.html. to learn how to implement each of these techniques.
Personally, I'd opt for an XML file structure. The data handling code will be comparable but updates from the host database will be infinitely more efficient. Good luck with your project.
i have to make an android application in which i need to download a lot of data from the server which is sent to me via XML. i then need to parse the XML and then display the extracted information.
To avoid making the application slow, i have decided to break my XML down into small parts.. so that i can only call the part that i want, this would limit the information that i am receiving.
My question is once that i have parsed the XML data where do i store it ( except for a db ) until my UI is rendered? On the iPhone there is something called user default where in we can store such information. What would be the equivalent in android?
thank you in advance.
Every thing you need should be right here: http://developer.android.com/guide/topics/data/data-storage.html. Internal storage is the closest to the iPhone equivalent.
You can use application preferences to store data as shown here (if the data is small enough).
Their code sample shows:
SharedPreferences gameSettings = getSharedPreferences("MyGamePreferences", MODE_PRIVATE);
SharedPreferences.Editor prefEditor = gameSettings.edit();
prefEditor.putString("UserName", "Guest123");
prefEditor.commit();
I wouldn't do this for large datasets but it's a handy place to store data.
This gets removed when the application is removed too.
If you've got a lot of data, I'd suggest storing it on disk.
You could store it in a file.
You could store it in SharedPreferences
You could use a ContentProvider --> not recommended for temporary storage.
You could use a SQLiteDB --> I know you said you do not want to use this.