My app is currently using a subclass of PreferencesActivity for its preferences.
I am in the process of adding widgets, where each instance has its own preferences (I also offer multiple widget sizes, which means multiple subclasses of AppWidgetProvider).
The widgets and the app share most of their preferences, the widget actually supporting a few items less.
In the process of writing the widget configurator activity, I am realizing that I need to access a preferences layout which does not exist.
As I understand it, is not possible to access the PreferencesActivity layout in the configurator activity. Does this means that I must create a sepecific preferences layout for the configurator activity ? Do you have any tips on optimizing the overlap between app and widget preferences ?
Your configuration activity does not to have to be a PreferenceActivity. Make it a normal Activity and use the SharedPreferences.Editor class to change the preferences the widget uses.
Related
I have a preference activity and some list preferences whose options I need to populate dynamically so:
Can I populate these list preferences dynamically or do I need to create the whole thing (activity) dynamically?
If I do create the whole thing manually will the sharepreferences be update with my choices? (getDefaultSharedPreferences) and if not how can I get the choices I made?
Thanks!
If you want to provide settings for your app, you should use Android's Preference APIs to build an interface that's consistent with the user experience in other Android apps.
More information here.
I have a preferences.xml, containing various settings for my app - their possible values\names, defaults, etc.
It was previously used simply in a PreferenceActivity with addPreferencesFromResource().
Now I am creating a completely customized settings UI, and I want it to have nothing to do with PreferenceActivity.
All I ever want is to have my preference hierarchy from the XML (as PreferenceScreen), so I can use it to construct my own UI.
I don't want Android's list adapter, I don't want the dialogs, etc. Only the data model.
Sadly, I haven't found a nice way to do that.
The only close thing I can think of is extending PreferenceActivity, providing a custom "R.id.list", and setting its visibility to GONE, so no one will see Android's preference UI.
Any good, clean way to accomplish that?
You can accomplish this by using the PreferenceManager directly. First you would call the setDefaultValues which does the loading of your preferences XML resource. Next you can get access to the SharedPreferences by calling getDefaultSharedPreferences and perform any preference changes through the SharedPreferences object. To edit your preferences you will need to get the Editor from your SharedPreferences object. Make sure to call commit on the editor to actually save the changes you have made.
A mockup is below that probably explains better than words. Essentially, I want a list where items can be added/removed dynamically by the user, and each item has configurable settings screen.
So there are two keys here:
Adding to the main preferences screen
Starting an
activityForResult when an item is pressed. This activity will show
another preferences view (sliders, checkboxes, etc) where the user
can manipulate these and then return the new values to be stored in
a data structure.
Image:
I would suggest heading down the road of Fragments - specifically PreferenceFragment: http://developer.android.com/reference/android/preference/PreferenceFragment.html
Why I think this will work well for you:
Furthermore, the preferences shown will follow the visual style of
system preferences. It is easy to create a hierarchy of preferences
(that can be shown on multiple screens) via XML. For these reasons, it
is recommended to use this fragment (as a superclass) to deal with
preferences in applications.
Your question is a little bit vague, but probably this is best solved by storing the user's data in a database (and using standard CursorAdapter and CursorLoader instances to show this data to the user) rather than trying to force everything into the Preferences framework. The CursorAdapter is optimized for dealing with arbitrarily large result sets, while PreferenceActivity and friends really work better with a fixed set of data.
The Preferences stuff is designed to be easy to implement for its specific use case, but if your use case falls out of that scope — and it sounds like it does — it's going to be a hassle to squeeze your data into a preferences model.
If you just like the Preferences UI, you can of course peek at the Android source code to see how it is implemented while still letting your own logic drive a variant of that UI.
Actually creating the preference screens dynamically is easy. You can do it in code (search the API Demos sample app for PreferenceFromCode.java) or by expanding an XML file that you can write (PreferencesFromXml.java). What's going to be hard is coming up with a sensible UI and storage back-end for the user to compose and store these dynamic preference collections.
I am calling a PreferenceActivity from another activity and then updating the application state (ie: changing the font size) on onActivityResult, based on the preference changes.
I was thinking it would be better to put the state update logic in the PreferenceActivity. That way I don't have the duplicate the logic in each activity that calls the PreferenceActivity.
What's the best or correct way to do this?
Have any Activity (or other component) that cares about preference changes register a preference change listener via registerOnSharedPreferenceChangeListener(). Then, when the preferences change by any means, they will find out about it and can react accordingly.
The PreferenceActivity should handle all the preference setting. Your other activities should read what those settings are when they run and adjust themselves accordingly.
I'm developing my first Android application, and I'd like to create a settings screen.
I'd like the screen to have a similar look-and-feel as the native phone-settings screens and the native "create/edit alarm" screen. Thus with different kinds of (statically defined) items vertically stacked with a thin line between them.
How do I define such screen?
I understand I can use the ListView, but this seems to be primarily meant for serving dynamic data using a ListAdapter, where each item is served in the same format. It seems to be possible to create different items (that is, some with checkbox, some with two text-lines, some with an icon) by creating my own ListAdapter and overriding getView but this seems like overkill. Should I be using a ListView for this purpose?
There's no need to manually create and format a ListView - there are ways in the API to create Preference screens.
The most obvious is PreferenceActivity.
You can define all your preferences in an XML file, a bit like a layout, and then load them with addPreferencesFromResource() or you can create a number of PreferenceScreen objects in code and populate them with Preference objects that way.
The best thing do would be to look at the API Demos application provided with the Android API. This contains lots of good examples of managing preferences. Here's how it creates preferences from code and here's a sample preferences XML file. There are other examples showing more advanced things like preference dependencies and preference listeners.
Actually in the built-in alarm application, for edit and create alarms, there are two activities, one for create and one for edit.
The Create Alarm activity is the first one with the digital clock.
The Edit Alarm activity is started by clicking on a listed alarm from the Create Alarm activity.
Edit Alarm implements PreferenceActivity, but Create Alarm is more complex (custom cursor adapter to list the alarms).
Have a look at the sources:
Create Alarm activity
Edit Alarm activity