Most apps have some kind of preferences or user settings that can be stored via the SharedPreferences. My first implementation of an activity for the user to edit his settings was pretty straight forward: a couple of input fields and a 'Save' Button. This is neither pretty nor easily extensible.
The android system settings and many apps that I have seen tend to layout their preference editing in ListViews.
My second approach tries to imitate this: a ListActivity and every item has to supply it's own layout, since I want to store different types of values (some are numbers, some are boolean radio buttons).
I am finding it rather cumbersome to implement this and now I am wondering if I am missing some obvious design pattern here?
Just use PreferenceActivity, it will build the UI and handle the preferences persistence for you. Here you have more documentation:
http://developer.android.com/reference/android/preference/PreferenceScreen.html
http://jetpad.org/2011/01/creating-a-preference-activity-in-android/
http://www.kaloer.com/android-preferences
Related
I'm currently working on an Android app, and looking at the PreferenceActivity class and the corresponding layout elements (PreferenceScreen, etc.), it appears that it provides much of the functionality that I desire for a major component of the app. However, that component is not a Settings activity per se, and I'm not sure if using Preference stuff for things that aren't technically preferences is a good way to do things. On the other hand, I'd prefer not having to implement all the features that PreferenceActivity/etc. provides, so would it be fine to use that framework and just change the layout theme so it doesn't seem like a Settings menu?
You can definitely load/set up the preference layout using the android framework and then save the data using your own implementation of SharedPreferences. This class is a good example. Not sure why you would not make it look like a preference screen though. What's wrong with that look?
Firstly I'd like to say that I have only been working on Android for about a week now, so I guess you can consider me a newb! Therefore I apologise in advance if the solution is overly simple, but I can assure you that I have done my research before posting here, and haven't found an appropriate solution as of yet (or maybe I have and don't fully realise it!). Nonetheless, having lots of fun and just want to solve this problem and learn, so here goes...
The Application
The application I am developing is essentially a reminder service, and I am currently working on the preferences screen.
The Problem
I would like the user to be able to specifiy a time when he/she will be reminded daily. I want this selection to be done via the preferences screen. This is how my preferences screen looks so far...
My preferences screen
My Question
Ideally, whenever the user selects the "Alarm Time" preference, I would like the following to appear (this is a screenshot of a preference from another application - PillReminder).
Preference with Time Picker widget (taken from another app - "PillReminder")
My question is, what is the best way to create this? I really want to keep all the visual aspects of the application using only XML, therefore I don't want a Java solution. Is this possible or am I completely off track? Other potential solutions I have heard of are using themes, alert dialogs and extending preference classes etc. Maybe some of these are correct, but I am unsure.
Any help would be greatly appreciated, thanks! :)
My question is, what is the best way to create this?
That is probably a custom DialogPreference that happens to have a TimePicker in it.
I really want to keep all the visual aspects of the application using only XML, therefore I don't want a Java solution.
Custom preferences like this cannot be defined in XML. You will need to create a subclass of DialogPreference, define what goes in the dialog, and how the dialog's contents can be stored to (and retrieved from) a SharedPreference value.
My ColorMixer CWAC project has a ColorPreference that you may wish to examine.
When adding a "settings" screen to my app I seem to have come up with two choices:
use the PreferenceActivity that is given by Android
create a standard Activity that saves all the user's choices
Assuming I don't mind writing the code that saves the preferences (a relatively trivial task), what other advantages are there to using a PreferenceActivity? If anything, using a standard Activity provides much more flexibility with regards to UI design.
You are right, given the desired view complexity (which sometimes is not more usable - remember preferences should be easy to set), it might not make sense to implement a PreferenceActivity. The idea is to present a uniform configuration screen & visual style to the user. As such, a user will always know when he entered a preference screen.
From the docs:
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 activity (as a superclass) to deal with preferences in applications.
The docs say something about inflated views, maybe you could investigate whether complex layouts or custom views can be integrated.
I would like to have a checkbox preference that takes the user to a new (sub)preference screen if the user presses on the actual text (and not on the checkbox to the right).
Just as the control under Settings -> Wireless -> Mobile Network Settings -> Access Point Names.
Two possibilities:
1) You can get android source code and see how they do it.
2) Check options in this question.
I was trying to move to an specific DialogPreference.
I your particular case I think it's better to create and show a new Dialog.
On my Nexus One, there is no checkbox on the Access Point Names preference. It is also not on the Android 2.1 emulator, the Motorola CLIQ, the Google Ion, or the T-Mobile G1.
The pattern that you describe would seem to violate the way the preference UI is set up.
That being said, if you do find a preference built into Android that behaves the way you want, you can go find it in the open source code. Many of the preferences used by Settings are not part of the public API, but you can clone their implementation into your own project.
I have a ListView, as well as a refreshListFromDB(String searchKeywords) method which updates the adapter.
I'd like to implement search, where pressing the search key on my device will pop up the standard search box (and on-screen keyboard if required), and pass the result (onKeyDown) to refreshListFromDB() - or is this considered bad UI design?
Search is a complex beast, so can anyone recommend any bare-bones examples? I don't want to use global QSB, as it's not relavent for my type of app. Do I really need to get into Intents, searchable XML, new activities, content providers etc?
I'd like to implement search, where
pressing the search key on my device
will pop up the standard search box
(and on-screen keyboard if required),
and pass the result (onKeyDown) to
refreshListFromDB() - or is this
considered bad UI design?
I don't know about "bad UI design", but the standard search box doesn't do what you say you want it to do.
Search is a complex beast, so can
anyone recommend any bare-bones
examples?
I used to have a bare-bones example, but that was before QSB, which added another pile of bones on top of the bones I had. You can still look at the larger pile of bones here, and the pieces you seek are described in (ahem) a book.
Do I really need to get into Intents,
searchable XML, new activities,
content providers etc?
To use the "standard search box", you need the first two in your list, and possibly the third depending on how you want to do it. I have both reused existing activities and created new ones in my search experiments. You will not need a content provider, though.
You could also have a look at the Searchable Dictionary Sample Application that comes with the SDK, although I think this does integrate with the Quick Search Box.