I just have some basic questions about the way shared preferences work with Android:
1) Are the preference files part of the application itself, or are they stored elsewhere on the user's phone?
2) If I have created and modified preference files in the course of testing my app, will those preferences be the default settings for users, or do the users start with a clean slate?
1) The preferences are stored on the user's phone, of course.
2) If you want defaults, you need to program them yourself, just setting the preferences in your emulator is not going to affect anybody installing your application.
Related
I want to create a preference set which the user will not easily be able to delete/clean...
the idea i got is to create the persistence files in the public folder as and hidden folder (this way the files wont be deleted on unnistall or if the user asks for clean apps data)
my questions:
1- does anyone knows a better way? is it possible to do that using the apps private folder and somehow tag the files for no deletion?
2- is possible to use native android preferences framework and specify another file to store the properties? how?
3- does anyone know a good, SMALL and simple to use API for persistent properties similar to androids default?
I found out that the only way to run my updated preferences.xml file on the app was to remove the app from the device before running it again.
Before that I tried:
rebuilding
cleaning
File->Invalidate cache / restart
delete ~/.gradle/cache/
delete project/.gradle
restarting my machine
and it would still run the old version.
Is it possible to automate this? Or at least make android studio un-cache the files that were edited?
Android Studio 1.5.1
You can do it just Clear data in the app setting page.
Yes you can automate it by running:
adb shell pm clear my.wonderful.app.package
There is also an IDEA plugin that does this for you.
I am going to assume that your preferences.xml is a definition of a PreferenceScreen, including your mentioned ListPreference. This is completely independent of the SharedPreferences that holds the results of the user settings values on the PreferenceScreen itself. Just because you change preferences.xml, you do not immediately affect any existing SharedPreferences. This is no different than changing the name of an <input> element on a Web page and somehow expecting that your MySQL database on the Web server will magically change.
If you change the key of a ListPreference, the next time the user goes into the PreferenceScreen, the ListPreference value will not be set. In other words, the behavior will be as if the user had never visited that preference before.
In addition, any value under the old key that the user supplied will remain in your SharedPreferences indefinitely. That may not be a big problem.
If you want to migrate existing values from the old key to the new one, you have to handle that yourself. This would be akin to implementing onUpgrade() in a SQLiteOpenHelper to modify your database schema to change a column name in a table. Android itself does not come with a SharedPreferencesHelper that assists you the way SQLiteOpenHelper does, though there may be third-party libraries that offer this.
I'm developping an app that contains some settings like server ip, sharedpreference filename and other that I would prefer save into a single file and not hard coded somewhere in the code.
So I would like to know what are the best practices nowadays concerning the deployement of these kind of settings. More, how to access it everywhere in the app ?
The android sharedpreference allows me to save it after the 1st launch but I don't know how to deploy it with the App.
regards,
A common way to deploy arbitrary data is the use of raw resources.
Create a file with your settings and save it to the raw resource folder. When your app is run for the first time, you can create your SharedPreference instance and copy the values from the raw resource to the preferences.
One option is to create a Configuration.java class and put the configuration there. You can have different build flavors for different build types (development, production etc.)
Another option would be to use the class generated by Gradle: BuildConfig.class, where you can put some configuration data from your build.gradle script.
EDIT:
Shared Preferences shouldn't be used for that if the server IP doesn't change during the lifetime of the application.
I'm using PreferenceActivity to let Android handle some persistent key/value pairs for my app.
According to the Android Preference docs :
Note that saved preferences are accessible only to the application that created them.
However, when further researching the security and permissions aspect of preferences, I come across questions like this one:
Android: Retrieving shared preferences of other application
where some users are saying that preferences may be made world readable and world writeable and that they are successfully able to access them across applications.
So my question is:
Are preferences inalienably inaccessible across applications or do I have to take precautions to make them so?
Note: I'm am not trying to use preferences to share data among apps. Quite the opposite - I want to know that any preferences my users set are secure from inspection/alteration by other apps.
From the above answers and comments, it looks to me like the android developer docs on this subject are a bit misleading.
I even found another place where the developer docs state explicitly that settings are not accessible across apps:
(Note that it is not possible to share settings data across application packages -- for that you will need a content provider.)
Reference to the above quote it here: http://developer.android.com/reference/android/app/Activity.html#SavingPersistentState
But the responses from #shruti and #raman-bhatia (thanks guys!) both support the fact that settings can be configured to be shareable across apps, as does the SO query I referenced in the question.
The clincher was finding this SO query: Difference between getDefaultSharedPreferences and getSharedPreferences which shows how it the default shared preferences file is initially configured as private.
Thanks to all. The answer is that the docs are misleading in that preferences can be coerced to being shareable across apps, but that PreferenceActivity will by default create a secure shared preferences file visible only to the components of the app from which originated.
There are modes associated with the shared preferences that you get to define when you create them.
For example, you can make them as "World Readable" or "World Writable" if you want the rest of the applications on your device to be aware of them.
You can thus use your own flags to adjust the transparency of the shared preferences that you create
I have some configuration I want to save it in my Android application and read it whenever I need , for instance, the server URL that it should try to access like that.
Is there any similar mechanism like web.config in ASP.NET available in Android?
A central configuration file that can be set up manually and then read by the application? Any help would be appreciated!
We use a .properties file in assets folder. It works out very well for us as we support multiple carriers with this, write to it (in case some values, sent from server, need to change. This is done at app start time, thus making our code configurable from server).
You can throw things like that into your strings.xml file. But, since you can't actually modify these values in real-time (since it's a distributed application rather than running on a server), throwing it into a constants class is quite acceptable.
Use Shared Preferences.
Here's a link Shared Preferences
You can use sq lite database files for it. You have a native API to read and write those and on top of that a command line tool.
If you want to create an XML file instead, then it's no different than any other xml file (unless you are thinking about the Shared Preferences, which use an xml format to save the data, but I believe it's not the best API for your application).
I was stumped on this too, but came across Managed Configurations in the Android documentation.
Managed configurations, previously known as application restrictions, allow the enterprise administrator to remotely specify settings for apps. This capability is particularly useful for enterprise-approved apps deployed to a managed profile.
It allows you to set a default value in case you rather not getting into the enterprise admistration business but leaves that option open for the future.
There is a caveat. This only works if your app is registered for EMM. Otherwise you will retrieve an empty map of restrictions.