Develop Reference

Disable Button Permanently in android

I have three button in my activity when I click any of two both will get disable but when I went back to my activity they won't restore the previous state.I have tried to achieve this using shared preference but Couldn't hold button state .Can anyone tell me about the mistake that I'm doing in shared preference.
Here I'm sharing my code with you.
on create method
spStateButton= getApplicationContext().getSharedPreferences("Button_State", 0);
spEditor = spStateButton.edit();
In Activity
public void setButtonState(boolean enabled) {
spEditor.putBoolean("btn_state", enabled);
spEditor.commit();
}
public boolean getButtonState(){
return spStateButton.getBoolean("btn_state", true);
}
button place in my activity
holder.btn_Fwd.setEnabled(getButtonState());
setButtonState(false);
holder.btn_Rec.setEnabled(getButtonState());
setButtonState(false);

You used method setButtonState(boolean enabled) for saving value to shared preference and you always call that method with parameter as false. So in shared preference the key "btn_state" having value always false.
So if you want to enable button for next time activity starts, call something like
setButtonState(true);
You can also use Singleton class to save a status value across app. Create class as below
public class SingleTon {
private static final SingleTon instance = new SingleTon();
private Boolean buttonState = true //initially visible
private SingleTon(){}
public static Boolean getButtonState(){
return buttonState;
}
public void setButtonState(Boolean buttonState){
return instance;
}
public SingleTon getInstance(){
return instance;
}
}

SharedPreferences.getBoolean returns true everytime

I made a class for handling important data changes such as App Purchase Status and other stuff .
For this goal I have created a class which does the setting and reading of the values. but the problem is whenever I call the appIsPurchased() method, the result is true while it hasen't been changed since app installation and its first initial launch.
This is my code:
/**
* Created by neemasa on 5/29/14.
* This class handles more crucial data values within app.
*/
public class AppCore {
private SharedPreferences settings;
private String keyPurchase = "app_purchased";
private Context context;
public AppCore(Context context){
this.context = context;
settings = PreferenceManager.getDefaultSharedPreferences(context);
}
public void setAppInPurchasedMode(String status){
if (status.equals("successful")){
settings.edit().putBoolean(keyPurchase, true).commit();
}else if (status.equals("failed")){
settings.edit().putBoolean(keyPurchase, false).commit();
}
}
public boolean appIsPurchased(){
boolean purchased = false;
if (settings.getBoolean(keyPurchase,true)){
purchased = true;
}
return purchased;
}
}
Question 1st: is there something wrong with my code? if there is then why appIsPurchased() always return true?
Question 2nd: do all values in the shared preferences are true by default?
Meanwhile when I use this class in my code the toast "Purchased!" runs even when app is running for the first time.
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
AppCore appCore = new AppCore(getApplicationContext());
if (appCore.appIsPurchased()){
Toast.makeText(getApplicationContext(),"Purchased!",Toast.LENGTH_SHORT).show();
}else {
Toast.makeText(getApplicationContext(),"Not Purchased!",Toast.LENGTH_SHORT).show();
}
}

Actually there is a problem in your code!! thats why its always showing purchased!!
if (settings.getBoolean(keyPurchase,true)){
purchased = true;
}
in this lines if the keyPurchased tag if not used , u are passing true value by default
so when u call
if (appCore.appIsPurchased()){
it always return a true value.. The solution is that make sure that the preference values are set before u call them.. hope this helps

Found It, the problem is that I was thinking
settings.getBoolean(keyPurchase,false)
returns the value of keyPurchased variable but the fact is it only returns the variable itself not its value so I fixed the problem by changing the method of my class to this:
public boolean appIsPurchased(){
return settings.getBoolean(keyPurchase,false);
}

you are setting the default value to true, so either your sharedpreference does not contains an entry for key_purchased or setAppInPurchasedMode is never called or is called wit status successful. On the minor side, your
public boolean appIsPurchased(){
boolean purchased = false;
if (settings.getBoolean(keyPurchase,true)){
purchased = true;
}
return purchased;
}
can be implemented like:
public boolean appIsPurchased(){
return settings.getBoolean(keyPurchase, false);
}
about setAppInPurchasedMode, if I were in you I would change the way you compare status, this way:
public void setAppInPurchasedMode(String status){
if ("successful".equals(status)){
settings.edit().putBoolean(keyPurchase, true).commit();
} else if ("failed".equals(status)){
settings.edit().putBoolean(keyPurchase, false).commit();
}
}
the difference is that if status is null, the way you implemented will crash your application with NPE. With my implementation you'll get false, because "successful" instanceof null is always false, and instanceof is the first check for equals

For those still having a problem, remember to apply the changes to your preferences.
private SharedPreferences sharedPreferences ;
private SharedPreferences.Editor sharedPreferencesEditor;
sharedPreferencesEditor.putBoolean("myVariable", false);
sharedPreferencesEditor.apply();

Android intercept paste\copy\cut on editText

How can I intercept this kind of events ?
I need to add some logic when the user trying to paste some text into my EditText i know i can use TextWatcher but this entrypoint not good for me becuase i only need to intercept in case of paste and not every time the user press my EditText,

Seems there isn't much you can do by using the API: android paste event
Source reading to the rescue!
I dug into the Android Source of the TextView (EditText is a TextView with some different configuration) and found out that the menu used to offer the cut/copy/paste options is just a modified ContextMenu (source).
As for a normal context-menu, the View must create the menu (source) and then handle the interaction in a callback-method (source).
Because the handling method is public, we can simply hook into it by extending EditText and overwriting the method to react on the different actions. Here is an example-implementation:
import android.content.Context;
import android.util.AttributeSet;
import android.widget.EditText;
import android.widget.Toast;
/**
* An EditText, which notifies when something was cut/copied/pasted inside it.
* #author Lukas Knuth
* #version 1.0
*/
public class MonitoringEditText extends EditText {
private final Context context;
/*
Just the constructors to create a new EditText...
*/
public MonitoringEditText(Context context) {
super(context);
this.context = context;
}
public MonitoringEditText(Context context, AttributeSet attrs) {
super(context, attrs);
this.context = context;
}
public MonitoringEditText(Context context, AttributeSet attrs, int defStyle) {
super(context, attrs, defStyle);
this.context = context;
}
/**
* <p>This is where the "magic" happens.</p>
* <p>The menu used to cut/copy/paste is a normal ContextMenu, which allows us to
* overwrite the consuming method and react on the different events.</p>
* #see Original Implementation
*/
#Override
public boolean onTextContextMenuItem(int id) {
// Do your thing:
boolean consumed = super.onTextContextMenuItem(id);
// React:
switch (id){
case android.R.id.cut:
onTextCut();
break;
case android.R.id.paste:
onTextPaste();
break;
case android.R.id.copy:
onTextCopy();
}
return consumed;
}
/**
* Text was cut from this EditText.
*/
public void onTextCut(){
Toast.makeText(context, "Cut!", Toast.LENGTH_SHORT).show();
}
/**
* Text was copied from this EditText.
*/
public void onTextCopy(){
Toast.makeText(context, "Copy!", Toast.LENGTH_SHORT).show();
}
/**
* Text was pasted into the EditText.
*/
public void onTextPaste(){
Toast.makeText(context, "Paste!", Toast.LENGTH_SHORT).show();
}
}
Now, when the user uses cut/copy/paste, a Toast is shown (of course you could do other things, too).
The neat thing is that this works down to Android 1.5 and you don't need to re-create the context-menu (like suggested in the above linked question), which will keep the constant look of the platform (for example with HTC Sense).

There is a much simpler way, although not 100% reliable.
Add TextChangedListener to your editbox:
EditText et = (EditText) mView.findViewById(R.id.yourEditText);
et.addTextChangedListener(new TextWatcher() {
#Override
public void onTextChanged(CharSequence s, int start, int before, int count) {
if (count > 2) toast("text was pasted");
}
#Override
public void beforeTextChanged(CharSequence s, int start, int count, int after) {
}
public void afterTextChanged(Editable s) {
}
});
If the text changes for more than 2 characters, you can assume it was pasted (some smileys take up two characters).
Of course it will not detect pasting when the user pastes 1 or 2 characters, and it will falsely report pasting if the change in text was triggered by something else.
But for most purposes, it gets the job done 👍

How could I use the same set of preference screens for all Android versions from 2.X to 4.X?

NOTICE: Please save yourself some time and refer to the accepted answer, no need to read all the quesiton.
You may read the rest of the question and the answer I provided for an alternative (although less sophisticated) method.
Also, you may want to take advantage of the fix for the background glitch in Android 2.X, by adding the related piece of code to your preference activity class.
Background
Being a newbie to Android coding, but somewhat experienced in other programming languages/frameworks, I was expecting my walk to Android application coding would be a rather pleasant one. It was so, until I stumbled upon this problem:
Eclipse wizard for Android projects suggested I could reach a 95% of devices if I set my minimum API to 8 (Android 2.2). I didn't need to do any fancy things with my app anyways, so I thought, "sure, why not?". Everything was okay, except occasionally I'd find several methods/classes that were deprecated in most recent API versions, and so I had to devise ways to keep using the old ways for old devices, and try to use as much as possible the new ways for newer Android versions. This is one such occasion.
After using the Eclipse wizard for creating a preference activity, I realized that the Eclipse precompiler/parser/checker(or whatever it's called) Lint, would complain about not being able to use the new ways of creating/managing preferences in older API versions. So I thought, "all right, screw the new ways. Let's do it old way and since new API versions are supposed to be backward-compatible, it should be okay", but it wasn't. Old way used methods/classes that are marked as deprecated; which, to me, means, even though they'd still work in current API, they'd stop working at some point in future releases.
So I started searching for the right way to do this, and finally hit this page: What to use instead of "addPreferencesFromResource" in a PreferenceActivity? where Garret Wilson, explains a way to use old preference screen resources in a way compatible with the new ways. It was great, and finally had the feeling I could move on with my app coding, except it wouldn't work when targeting older APIs, as it was using newer APIs code. So I had to devise a way to make it work for both old APIs and newer. After tinkering with it for a while I managed to find a way, by using precompiler(or whatever it's called) annotations and the great getClass().getMethod() along with exceptions.
Everything seemed to work flawlessly until I created a preference sub-screen. It was displaying correctly in newer Android versions, but when I tried in older ones, I could merely see a black screen. After much searching, I found this page which explains the issue: http://code.google.com/p/android/issues/detail?id=4611 This is apparently a known glitch that's been around several Android versions for a good while. I read the whole thread and found several proposed solutions to the problem, but I really didn't like entirely any of them. I, for one, prefer to avoid as much static stuff as I can, and do things programmatically. I prefer automation over repetitive work. Some solutions suggested to create sub-screens as parent screens, then adding them onto the manifest file, and calling them from the parent screen through an intent. I'd really hate having to keep track of those things: entries in manifest, separated screen resource file, intents... So that was a no-no for me. I kept looking and found a programmatic approach I liked much better... only to find that it didn't work. It consisted of iterating through the whole view tree of the preference screen and assigning a proper background to preference sub-screens, but it just didn't work because, as I later found out after much debugging, preference sub-screens views are not a child of preference screen views. I had to find a way to achieve this myself. I tried as many things as I could think of, researched and researched to no avail. I was at the verge of abandoning at several occasions, but after some two weeks of continued effort and much debugging I found a workaround, which I posted in comment #35.
Opinion
It really isn't the perfect solution/approach, and I'm aware of several of its drawbacks, but it's one that works, so I decided I would share it. Hopefully I'm not being too ridiculous in my enthusiasm to share what has taken me what I'd consider quite a lot of effort, as I'm aware it's not that great of an issue, that any experienced coder could solve. But hey, I think sharing knowledge makes me a bit better, no matter how much I brag, than an experienced coder who keeps everything to himself. Just sharing my opinion, because I can't believe nobody ever had this problem before, but I do believe many have had it and didn't bother to share their knowledge.
I present you in the answer with a proposed class to use over several versions of Android, and some suggestions on its usage. I'm open to discussion and contributions to make it a better class.
Known issues:
Parent screen Decor view background is cloned onto child screen Decor view background, which apparently isn't the normal behavior.
Status: dismissed until somebody comes up with a good reason to fix this
Crashes upon screen rotation
Status: Fixed.
Probably related to resource visibility by newer API implementation (inner class PF)
Apparently inherited classes from preferenceFragment need to have all their members static. I guess it makes sense if you're supposed to inherit every time you need to use a new fragment

If you are on the latest ADT plugin, there is an option to easily create a preference Activity that supports most older Android versions as well as all the new ones.
Right click on your project -> Other -> Android Activity
Then choose SettingsActivity
The Activity created will take take care of working with both high and low API versions since it uses if statements to choose the appropriate method of displaying the preferences.
EDIT
A good point was brought up: Phone-Sized devices, regardless of API version use the old PreferenceActivity methods.
The quickest way to get API 11+ devices to use Fragments is to remove !isXLargeTablet(context); from isSimplePreferences()
private static boolean isSimplePreferences(Context context) {
return ALWAYS_SIMPLE_PREFS
|| Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB;
}
However, now the user has more navigation to do.
This is because onBuildHeaders() is called.
To get rid of this, we will need to make our own PreferenceFragment that adds each xml resource.
#TargetApi(Build.VERSION_CODES.HONEYCOMB)
public static class AllPreferencesFragment extends PreferenceFragment{
#Override
public void onCreate (Bundle savedInstanceState){
super.onCreate(savedInstanceState);
addPreferencesFromResource(R.xml.pref_general);
// Add 'notifications' preferences, and a corresponding header.
PreferenceCategory fakeHeader = new PreferenceCategory(getActivity());
fakeHeader.setTitle(R.string.pref_header_notifications);
getPreferenceScreen().addPreference(fakeHeader);
addPreferencesFromResource(R.xml.pref_notification);
// Add 'data and sync' preferences, and a corresponding header.
fakeHeader = new PreferenceCategory(getActivity());
fakeHeader.setTitle(R.string.pref_header_data_sync);
getPreferenceScreen().addPreference(fakeHeader);
addPreferencesFromResource(R.xml.pref_data_sync);
// Bind the summaries of EditText/List/Dialog/Ringtone preferences to
// their values. When their values change, their summaries are updated
// to reflect the new value, per the Android Design guidelines.
bindPreferenceSummaryToValue(findPreference("example_text"));
bindPreferenceSummaryToValue(findPreference("example_list"));
bindPreferenceSummaryToValue(findPreference("notifications_new_message_ringtone"));
bindPreferenceSummaryToValue(findPreference("sync_frequency"));
}
}
If you can determine the screen size from outside the Activity that launches the settings, you can specify a fragment for it to launch via EXTRA_SHOW_FRAGMENT
i.putExtra(SettingsActivity.EXTRA_SHOW_FRAGMENT, "com.example.test.SettingsActivity$AllPreferencesFragment");
Or you can have the SettingsActivity determine whether or not to show this Fragment (assuming you're happy with the isXLargeTablet() method.
Change onBuildHeaders() to:
#Override
#TargetApi(Build.VERSION_CODES.HONEYCOMB)
public void onBuildHeaders(List<Header> target) {
if (!isSimplePreferences(this) && isXLargeTablet(this)) {
loadHeadersFromResource(R.xml.pref_headers, target);
}
}
Add this method:
#TargetApi(Build.VERSION_CODES.HONEYCOMB)
private void setupNewApiPhoneSizePreferences() {
if (!isXLargeTablet(this) && Build.VERSION.SDK_INT > Build.VERSION_CODES.HONEYCOMB){
getFragmentManager().beginTransaction().replace(android.R.id.content, new AllPreferencesFragment()).commit();
}
}
And in onPostCreate() add the method call.
setupNewApiPhoneSizePreferences();
This should now use non-deprecated calls from API 11 onwards.

You can use this class to display a preference screen in all Android versions from 2.X to 4.X, by feeding it with a preference screen resource.
You may use it directly by renaming it if you like, but I'd suggest you to add it to your project as is, and inherit from it, which is much cleaner if you need to work with several parent preference screens.
If you'd like to use it directly, just replace prefs value with your preference screen resource ID.
If you'd like to inherit from it, you should do it like this:
import android.os.Bundle;
public class MyPreferencesActivity extends CompatiblePreferenceActivity
{
#Override
protected void onCreate(final Bundle savedInstanceState)
{
setPrefs(R.xml.mypreferencesactivity);
super.onCreate(savedInstanceState);
}
}
ALWAYS call setPrefs(int) before calling super.onCreate(Bundle)
If, for some reason, you'd just like to take advantage of the glitch-fix and create preferences on your own, you may either just copy the glitch-fix code into your own preference activity, or inherit from the class and catch the PrefsNotSet exception as follows:
import android.os.Bundle;
public class MyPreferencesActivity extends CompatiblePreferenceActivity
{
#Override
protected void onCreate(final Bundle savedInstanceState)
{
try{
super.onCreate(savedInstanceState);
}catch(PrefsNotSetException e){};
}
}
And finally, the class:
import android.annotation.TargetApi;
import android.os.Bundle;
import android.preference.Preference;
import android.preference.PreferenceActivity;
import android.preference.PreferenceFragment;
import android.preference.PreferenceScreen;
public class CompatiblePreferenceActivity extends PreferenceActivity
{
private int prefs=0;
//Get/Set
public void setPrefs(int prefs)
{
this.prefs=prefs;
}
//Exception
protected static class PrefsNotSetException extends RuntimeException
{
private static final long serialVersionUID = 1L;
PrefsNotSetException()
{
super("\"prefs\" should be set to a valid preference resource ID.");
}
}
//Creation
#Override
protected void onCreate(final Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
if (prefs==0)
throw new PrefsNotSetException();
else
try {
getClass().getMethod("getFragmentManager");
AddResourceApi11AndGreater();
}
catch (NoSuchMethodException e) { //Api < 11
AddResourceApiLessThan11();
}
}
#SuppressWarnings("deprecation")
protected void AddResourceApiLessThan11()
{
addPreferencesFromResource(prefs);
}
#TargetApi(11)
protected void AddResourceApi11AndGreater()
{
PF.prefs=prefs;
getFragmentManager().beginTransaction().replace(
android.R.id.content, new PF()).commit();
}
#TargetApi(11)
public static class PF extends PreferenceFragment
{
private static int prefs;
#Override
public void onCreate(final Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
addPreferencesFromResource(prefs);
}
}
//Sub-screen background glitch fix
#SuppressWarnings("deprecation")
#Override
public boolean onPreferenceTreeClick(PreferenceScreen preferenceScreen,
Preference preference)
{
super.onPreferenceTreeClick(preferenceScreen, preference);
if (preference!=null)
if (preference instanceof PreferenceScreen)
if (((PreferenceScreen)preference).getDialog()!=null)
((PreferenceScreen)preference).getDialog().
getWindow().getDecorView().
setBackgroundDrawable(this.getWindow().
getDecorView().getBackground().getConstantState().
newDrawable());
return false;
}
}

Well, working with the autogenerated SettingsActivity got pretty old pretty quickly. One has to scroll up and down past boilerplate code - moreover it's full of yellow warnings and I hate yellow (deprecated warnings can't be avoided altogether though - see What to use instead of "addPreferencesFromResource" in a PreferenceActivity?, where also the matter of how to make cross API PreferenceActivity is touched also - and Was PreferenceFragment intentionally excluded from the compatibility package? for a discussion). And also you may easily get an NPE - did you know that onPostCreate() is actually onPostStart() - so findPreference() returns null in onStart().
Now there are solutions involving reflection but reflection is to be avoided (like hell it is) - and since we are not interested in pre 2 versions of android reflection can be avoided (see Is checking SDK_INT enough or is lazy loading needed for using newer android APIs ? Why?). Also there are solutions involving choosing a class at runtime - but having 2 classes sucks and is not OOP anyways (for those and other solutions see the answer to related question: PreferenceActivity Android 4.0 and earlier).
So I came up with an abstract base class, which is the correct Java and OO way of doing things (except if you need Eclair and below where you do need reflection and/or lazy loading of classes to avoid VerifyErrors), where I moved the autogenerated boilerplate code:
import android.annotation.TargetApi;
import android.content.Context;
import android.content.res.Configuration;
import android.os.Build;
import android.os.Bundle;
import android.preference.PreferenceActivity;
import android.preference.PreferenceFragment;
import java.util.List;
/**
* A {#link PreferenceActivity} that presents a set of application settings. On
* handset devices, settings are presented as a single list. On tablets,
* settings are split by category, with category headers shown to the left of
* the list of settings.
* <p>
* See <a href="http://developer.android.com/design/patterns/settings.html">
* Android Design: Settings</a> for design guidelines and the <a
* href="http://developer.android.com/guide/topics/ui/settings.html">Settings
* API Guide</a> for more information on developing a Settings UI.
*
* Defines two abstract methods that need be implemented by implementators.
*/
public abstract class BaseSettings extends PreferenceActivity {
/**
* Determines whether to always show the simplified settings UI, where
* settings are presented in a single list. When false, settings are shown
* as a master/detail two-pane view on tablets. When true, a single pane is
* shown on tablets.
*/
private static final boolean ALWAYS_SIMPLE_PREFS = false;
/**
* Helper method to determine if the device has an extra-large screen. For
* example, 10" tablets are extra-large.
*/
#TargetApi(Build.VERSION_CODES.GINGERBREAD)
private static boolean isXLargeTablet(Context context) {
return (context.getResources().getConfiguration().screenLayout &
Configuration.SCREENLAYOUT_SIZE_MASK)
>= Configuration.SCREENLAYOUT_SIZE_XLARGE;
}
/** {#inheritDoc} */
#Override
public final boolean onIsMultiPane() { // never used by us
return isXLargeTablet(this) && !isSimplePreferences(this);
}
/**
* Determines whether the simplified settings UI should be shown. This is
* true if this is forced via {#link #ALWAYS_SIMPLE_PREFS}, or the device
* doesn't have newer APIs like {#link PreferenceFragment}, or the device
* doesn't have an extra-large screen. In these cases, a single-pane
* "simplified" settings UI should be shown.
*/
private static final boolean isSimplePreferences(Context context) {
return ALWAYS_SIMPLE_PREFS
|| Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB
|| !isXLargeTablet(context);
}
#Override
protected final void onCreate(Bundle savedInstanceState) {
// disallow onCreate(), see comment in onPostCreate()
super.onCreate(savedInstanceState);
}
#Override
protected final void onStart() {
// disallow onStart(), see comment in onPostCreate()
super.onStart();
}
#Override
protected void onPostCreate(Bundle savedInstanceState) {
// onPostCreate() probably is needed because onBuildHeaders() is called
// after onCreate() ? This piece of err code should be called
// onPostStart() btw - so yeah
super.onPostCreate(savedInstanceState);
setupSimplePreferencesScreen();
// findPreference will return null if setupSimplePreferencesScreen
// hasn't run, so I disallow onCreate() and onStart()
}
/**
* Shows the simplified settings UI if the device configuration if the
* device configuration dictates that a simplified, single-pane UI should be
* shown.
*/
private void setupSimplePreferencesScreen() {
if (!isSimplePreferences(this)) {
return;
}
buildSimplePreferences();
}
/** {#inheritDoc} */
/*
* Subclasses of PreferenceActivity should implement onBuildHeaders(List) to
* populate the header list with the desired items. Doing this implicitly
* switches the class into its new "headers + fragments" mode rather than
* the old style of just showing a single preferences list (from
* http://developer
* .android.com/reference/android/preference/PreferenceActivity.html) -> IE
* this is called automatically - reads the R.xml.pref_headers and creates
* the 2 panes view - it was driving me mad - #inheritDoc my - It does not
* crash in Froyo cause isSimplePreferences is always true for
* Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB - #Override has
* nothing to do with runtime and of course on Froyo this is never called by
* the system
*/
#Override
#TargetApi(Build.VERSION_CODES.HONEYCOMB)
public final void onBuildHeaders(List<Header> target) {
if (!isSimplePreferences(this)) {
loadHeadersFromResource(getHeadersXmlID(), target);
}
}
// =========================================================================
// Abstract API
// =========================================================================
/**
* Must return an id for the headers xml file. There you define the headers
* and the corresponding PreferenceFragment for each header which you must
* of course implement. This is used in the super implementation of
* {#link #onBuildHeaders(List)}
*
* #return an id from the R file for the xml containing the headers
*/
abstract int getHeadersXmlID();
/**
* Builds a pre Honeycomb preference screen. An implementation would use the
* (deprecated)
*{#link android.preference.PreferenceActivity#addPreferencesFromResource(int)}
*/
abstract void buildSimplePreferences();
}
And a sample implementation:
public final class SettingsActivity extends BaseSettings implements
OnSharedPreferenceChangeListener {
private static final int PREF_HEADERS_XML = R.xml.pref_headers;
private static CharSequence master_enable;
private OnPreferenceChangeListener listener;
private static Preference master_pref;
private static final String TAG = SettingsActivity.class.getSimpleName();
private SharedPreferences sp;
/** Used as canvas for the simple preferences screen */
private static final int EMPTY_PREF_RESOURCE = R.xml.pref_empty;
private static int PREF_RESOURCE_SETTINGS = R.xml.pref_data_sync;
// abstract overrides
#Override
int getHeadersXmlID() {
return PREF_HEADERS_XML;
}
#Override
void buildSimplePreferences() {
// In the simplified UI, fragments are not used at all and we instead
// use the older PreferenceActivity APIs.
// THIS is a blank preferences layout - which I need so
// getPreferenceScreen() does not return null - so I can add a header -
// alternatively you can very well comment everything out apart from
// addPreferencesFromResource(R.xml.pref_data_sync);
addPreferencesFromResource(EMPTY_PREF_RESOURCE);
// Add 'data and sync' preferences, and a corresponding header.
PreferenceCategory fakeHeader = new PreferenceCategory(this);
fakeHeader.setTitle(R.string.pref_header_data_sync);
getPreferenceScreen().addPreference(fakeHeader);
addPreferencesFromResource(PREF_RESOURCE_SETTINGS);
}
// here is the work done
#Override
protected void onPostCreate(Bundle savedInstanceState) {
super.onPostCreate(savedInstanceState);
master_enable = getResources().getText(
R.string.enable_monitoring_master_pref_key);
listener = new ToggleMonitoringListener();
// DefaultSharedPreferences - register listener lest Monitor aborts
sp = PreferenceManager.getDefaultSharedPreferences(this);
sp.registerOnSharedPreferenceChangeListener(this);
master_pref = findPreference(master_enable.toString());
}
#Override
protected void onResume() {
super.onResume();
master_pref.setOnPreferenceChangeListener(listener); // no way to
// unregister, see: https://stackoverflow.com/a/20493608/281545 This
// listener reacts to *manual* updates - so no need to be active
// outside onResume()/onPause()
}
#Override
protected void onDestroy() {
// may not be called (as onDestroy() is killable), but no leak,
// see: https://stackoverflow.com/a/20493608/281545
sp.unregisterOnSharedPreferenceChangeListener(this);
super.onDestroy();
}
/**
* Toggles monitoring and sets the preference summary.Triggered on *manual*
* update of the *single* preference it is registered with, but before this
* preference is updated and saved.
*/
private static class ToggleMonitoringListener implements
OnPreferenceChangeListener {
ToggleMonitoringListener() {}
#Override
public boolean
onPreferenceChange(Preference preference, Object newValue) {
if (newValue instanceof Boolean) {
final boolean enable = (Boolean) newValue;
Monitor.enableMonitoring(preference.getContext(), enable);
final CheckBoxPreference p = (CheckBoxPreference) preference;
preference.setSummary((enable) ? p.getSummaryOn() : p
.getSummaryOff());
return true;
}
return false;
}
}
/**
* This fragment is used when the activity is showing a two-pane
* settings UI.
*/
#TargetApi(Build.VERSION_CODES.HONEYCOMB)
public final static class DataSyncPreferenceFragment extends
PreferenceFragment {
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Log.w(TAG, "onCreate");
addPreferencesFromResource(PREF_RESOURCE_SETTINGS);
master_pref = findPreference(master_enable.toString());
}
}
#Override
public void onSharedPreferenceChanged(SharedPreferences sharedPreferences,
String key) {
if (master_enable == null || master_pref == null) return;
if (master_enable.toString().equals(key)) {
refreshMasterPreference();
}
}
/**
* #param key
*/
private void refreshMasterPreference() {
final Boolean isMonitoringEnabled = AccessPreferences.get(this,
master_enable.toString(), false);
Log.w(TAG, "Stored value: " + isMonitoringEnabled);
final CheckBoxPreference p = (CheckBoxPreference) master_pref;
final boolean needsRefresh = p.isChecked() != isMonitoringEnabled;
if (needsRefresh) {
p.setChecked(isMonitoringEnabled);
p.setSummary((isMonitoringEnabled) ? p.getSummaryOn() : p
.getSummaryOff());
}
}
}
So the main idea is you provide an xml for preferences with headers:
public final void onBuildHeaders(List<Header> target) {
if (!isSimplePreferences(this)) {
loadHeadersFromResource(getHeadersXmlID(), target);
}
}
where:
#Override
int getHeadersXmlID() {
return PREF_HEADERS_XML;
}
and PREF_HEADERS_XML:
<preference-headers xmlns:android="http://schemas.android.com/apk/res/android" >
<!-- These settings headers are only used on tablets. -->
<header
android:fragment=".activities.SettingsActivity$DataSyncPreferenceFragment"
android:title="#string/pref_header_data_sync" />
</preference-headers>
and setting up the simple preferences in buildSimplePreferences()
I am interested into making this into a more general API - probably including the sBindPreferenceSummaryToValueListener - so ideas welcome.
Ah, yes, the sBindPreferenceSummaryToValueListener fluff:
// FLUFF AHEAD:
// the fluff that follows is for binding preference summary to value -
// essentially wrappers around OnPreferenceChangeListener - just so
// you get an idea of the mess this autogenerated piece of, code, was
// formatter:off
/**
* A preference value change listener that updates the preference's summary
* to reflect its new value.
*/
/* private static Preference.OnPreferenceChangeListener
sBindPreferenceSummaryToValueListener =
new Preference.OnPreferenceChangeListener() {
#Override
public boolean onPreferenceChange(Preference preference,
Object value) {
String stringValue = value.toString();
if (preference instanceof ListPreference) {
// For list preferences, look up the correct display value
// in the preference's 'entries' list.
ListPreference listPreference = (ListPreference) preference;
int index = listPreference.findIndexOfValue(stringValue);
// Set the summary to reflect the new value.
preference.setSummary(index >= 0
? listPreference.getEntries()[index] : null);
} else if (preference instanceof RingtonePreference) {
// For ringtone preferences, look up the correct display
// value using RingtoneManager.
if (TextUtils.isEmpty(stringValue)) {
// Empty values correspond to 'silent' (no ringtone).
// preference.setSummary(R.string.pref_ringtone_silent);
} else {
Ringtone ringtone = RingtoneManager.getRingtone(
preference.getContext(), Uri.parse(stringValue));
if (ringtone == null) {
// Clear the summary if there was a lookup error.
preference.setSummary(null);
} else {
// Set the summary to reflect the new ringtone
// display name.
String name = ringtone
.getTitle(preference.getContext());
preference.setSummary(name);
}
}
} else if (preference instanceof CheckBoxPreference) {
boolean b = (Boolean) value;
Log.w(TAG, "::::value " + b);
final CheckBoxPreference p =(CheckBoxPreference)preference;
preference.setSummary((b) ? p.getSummaryOn() : p
.getSummaryOff());
Log.w(TAG, p.getKey() + " :: " + p.isChecked());
} else {
// For all other preferences, set the summary to the value's
// simple string representation.
preference.setSummary(stringValue);
}
return true;
}
}; */
/**
* Binds a preference's summary to its value. More specifically, when the
* preference's value is changed, its summary (line of text below the
* preference title) is updated to reflect the value. The summary is also
* immediately updated upon calling this method. The exact display format is
* dependent on the type of preference.
*
* #see #sBindPreferenceSummaryToValueListener
*/
/* private static void bindPreferenceSummaryToValue(Preference preference) {
// Set the listener to watch for value changes.
preference
.setOnPreferenceChangeListener(sBindPreferenceSummaryToValueListener);
// Trigger the listener immediately with the preference's
// current value.
sBindPreferenceSummaryToValueListener.onPreferenceChange(
preference,
PreferenceManager.getDefaultSharedPreferences(
preference.getContext()).getString(preference.getKey(), ""));
} */

Android: prevent preference dialog for preference which must be loaded over the network

My app has a ListPreference, whose entries come from a network API. In my PreferenceActivity's onCreate(), I spawn a background thread which makes the API call and then populates the entries of the ListPreference after one or two seconds.
If the user clicks the ListPreference button on the preference screen before the options have been downloaded, I want to prevent the preference dialog from showing and instead notify the user that the list of options is still being loaded.
I suspect that correct approach is to override the OnPreferenceClickListener, like this:
ListPreference dpref = (ListPreference) findPreference("debug");
String[] s = {"one", "two", "three"};
dpref.setEntries(s);
dpref.setEntryValues(s);
dpref.setOnPreferenceClickListener(new OnPreferenceClickListener() {
#Override
public boolean onPreferenceClick(Preference preference) {
Toast.makeText(this, "hi there", Toast.LENGTH_SHORT).show();
return true;
}
});
The toast gets shown, but the ListPreference chooser dialog is shown as well. The OnPreferenceClickListener documentation says that onPreferenceClick should return true if the click was handled, but returning false has the same result.
How do I prevent the preference dialog from showing?
Is there a better way to handle preferences whose options must be downloaded before viewing?

I was struggeling with the same problem but in a more simple environment. My PreferenceScreen is defined in an xml file. There is one Preference I want to handle myself. So I simply put a "Preference" object into the xml file instead of a "ListPreference" or "EditTextPreference"
<Preference android:title="#string/preloadmaps1" android:summary="#string/preloadmaps2"
android:key="preloadMaps" />
Now there is no more Editor connetcted with the Preference and I can savely handle the editing myself in "OnPreferenceClickListener"

Reference the android dveloper document which about showDialog :
Shows the dialog associated with this Preference. This is normally initiated automatically on clicking on the preference. Call this method if you need to show the dialog on some other event.
So, when click preference will call showDialog() automatically, if you want to control to prevent to show a dialog on click preference, you need to implement a custom preference, like this,
public class MyPreference extends ListPreference {
private Context context;
// a flag to control show dialog
private boolean showDialog = false;
public MyPreference(Context context) {
super(context);
this.context = context;
}
public MyPreference(Context context, AttributeSet attrs) {
super(context, attrs);
this.context = context;
}
#Override
protected void showDialog(Bundle state) {
if (showDialog) {
// show dialog
super.showDialog(state);
} else {
// if you don't want to show a dialog when click preference
return;
} /* end of if */
}
}

I'm not sure why your way is not working, but here is a quick workaround solution:
Add stub Preference for each preference that should be downloaded. You can customize you action on click in any way you want. No dialogs will be shown.
When your preference options are ready, remove old Preference (by its name) and create new ListPreference (with the same name as just removed one) with your options.
This will give you a flexibility to add any kind of custom preferences on any event you need. Though as you can see, some extra coding is required.

I know this is an old question, but there's still no answer how to cancel those dialog.
So here's how you can cancel preference dialog:
dpref.setOnPreferenceClickListener(new OnPreferenceClickListener() {
#Override
public boolean onPreferenceClick(Preference preference) {
((ListPreference)preference).getDialog().dismiss(); <<< This will do it
Toast.makeText(this, "hi there", Toast.LENGTH_SHORT).show();
return true;
}
});
But instead of dismissing the dialog, its better to hide it to be able to show it later, when a list of options is loaded from web. So do:
dpref.setOnPreferenceClickListener(new OnPreferenceClickListener() {
#Override
public boolean onPreferenceClick(Preference preference) {
((ListPreference)preference).getDialog().hide(); <<< This will just hide the dialog and you still can show it later
Toast.makeText(this, "hi there", Toast.LENGTH_SHORT).show();
return true;
}
});
Later on, when list of options is loaded do:
...
dpref.setEntries(<array_of_options_here>);
dpref.getdialog().show(); <<< If you dismiss the dialog earlier and not hide it, then getDialog() returns null here
...

I'd use a proxy Activity (styled as a dialog) that downloads preferences and launches the actual PreferenceActivity once done.

you can do the following in the onResume() in your preference activity:
start an async call to...
set the preference to disabled with a hint that values are being fetched
the network to fetch the values (either when it has no values or always) - async, so it does not stop the resuming
update the preference entry with your fetched values
enable the preference and show the default hint
The drawback if this is, that your preference will either get updated too often (eg always when your preference screen starts), but with this you can handle the case when the result of the network call yields a list where the before selected value is not in anymore (eg show the user a dialog where it says his selection is not available any more).
Also, this is rather a complex task (since you have to define a Handler, because the async execution lives in another thread...)
It would look something like this (assuming you do this in your PreferenceActivity)
import android.os.Handler;
import android.os.AsyncTask;
import android.os.Message;
public class xyz extends PreferenceActivity {
...
// define a handler to update the preference state
final Handler handler = new Handler() {
public void handleMessage( Message msg ) {
ListPreference dpref = (ListPreference) getPreferenceManager().findPreference("debug");
dpref.setEnabled( msg.getData().getBoolean("enabled") );
dpref.setSummary( msg.getData().getString("summary") );
}
};
private class updatePref extends AsyncTask<Void, Void, Void> {
#Override
protected Void doInBackground(Void... arg) {
Message msg = handler.obtainMessage();
Bundle data = new Bundle();
data.putBoolean("enabled", false ); // disable pref
data.putString("summary", "Getting vals from network..." ); // set summary
msg.setData( data );
handler.sendMessage(msg); // send it do the main thread
ListPreference dpref = (ListPreference) getPreferenceManager().findPreference("debug");
String values[];
// call network function and let it fill values[]
// do things according to the returned values,
// eg check if there are any, check if the user has
// already selected one, display a message if the
// user has selected one before but the values do not
// contain them anymore, ...
// set the new values
dpref.setEntries(values);
dpref.setEntryValues(values);
data.putBoolean("enabled", true ); // enable pref
data.putString("summary", "Please choose" ); // set summary
msg.setData( data );
handler.sendMessage(msg); // send it do the main thread
return null;
}
}
public void onResume() {
....
new updatePref().execute();
}
}
Of course you can call new updatePref().execute() anywhere, so you could also bind it to a Button, onCreate() or whereever (no need to do this in onResume()).

One more way for a collection. I believe it only works with the android.support.v7.preference library and PreferenceFragmentCompat (27.1.1 in my case). Here is an example:
public class PrefsFragment extends PreferenceFragmentCompat implements PreferenceFragmentCompat.OnPreferenceDisplayDialogCallback {
private static final int REQUEST_VIEW_PREFERENCE = 1;
#Override
public void onActivityResult(int requestCode, int resultCode, Intent data) {
if (requestCode == REQUEST_VIEW_PREFERENCE && resultCode == Activity.RESULT_OK) {
Preference preference = findPreference("preference_key");
getPreferenceManager().showDialog(preference)
}
}
#Override
public Fragment getCallbackFragment() {
this;
}
#Override
public boolean onPreferenceDisplayDialog(PreferenceFragmentCompat caller, Preference pref) {
if (pref.getKey().equals("preference_key")) {
if (canBeOpened(pref)) {
return false;
} else {
// show a fragment loading data with requestCode == REQUEST_VIEW_PREFERENCE
...
return true;
}
}
}
private boolean canBeOpened(Preference pref) {
// check whether a preference can be clicked
...
}
}
If I understood source code of Preference.java correctly, OnPreferenceClickListener returning true works only for intent based preferences, but is ignored if dialog is going to be shown.
In the example above OnPreferenceDisplayDialogCallback is used to prevent preference dialogs from showing. It is important to return a fragment implementing this interface from getCallbackFragment().