IssueTracker

+Chris/Adam

This is in fact an important problem for ActionBarCompat.
One cannot add any other action item when SearchView is included in always-expanded mode.

Having attribute app:showAsAction="always|collapseActionView" for searchView and calling MenuItem.expandActionView() in code as a workaround doesn't really have the same effect.

Please review its priority.
Forcing the user to use SearchView with 2 taps decreases the quality of user experience on our part.

I agree with #4.

[Comment deleted]

[Comment deleted]

Additional information that can be useful:
The issue only happens when SearchView is included in ActionBar menu.xml and setIconifiedByDefault(false) is applied.

SearchView item definition from menu.xml:

<item android:id="@+id/menuSearch"
        app:actionViewClass="android.support.v7.widget.SearchView"
        app:showAsAction="always"
        android:title="Search">
</item>

Including SearchView as custom view works correctly, like in this scenario:

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    SearchView searchView = new SearchView(this);
    searchView.setIconifiedByDefault(false);
    getActionBar().setCustomView(searchView);
    getActionBar().setDisplayShowCustomEnabled(true);
}

It's the same for ActionBar not only ActionBarCompat.

Ditto this is an ugly bug.  It prevents this use case:
- search is done via a REST API whenever someone types a character in
- search takes a while to happen so we should display a progress indicator to user so they don't kill the app because it's not responsive

2nd step is impossible :-(

This really should be fixed!

[Comment deleted]

Same problem over here, please fix! Android 2.3.7

Bloody annoying bug.

I found this to be the only workaround so far; onCreate() of my Application (main activity);


// These two lines are working around an android bug:
// http://code.google.com/p/android/issues/detail?id=6641
SharedPreferences prefs = PreferenceManager.getDefaultSharedPreferences(this);
prefs.edit().putBoolean(REFRESH_COUNTER_PREF, prefs.getBoolean(REFRESH_COUNTER_PREF, true)).commit();

This bug is a nuisance indeed.

The mentioned workaround will do the job, and is really only necessary for boolean initializations to "false" (not needed for "true").

If the preferences are bound to evolve a lot, then it's probably safer (to prevent human error) to re-parse the preferences XML manually to pinpoint the booleans that are still null and properly initialize all of them.

Is that right? I spend a good half hour trying to initialise my pref to true with no luck, setting defaults didn't seem to work, so what's the "fix" for that case? As you can see, my fix above is setting it true.

Just to make sure: when you call "PreferenceManager.setDefaultValues()" please ensure that you set the 3rd argument to "true". If you don't, newly added values won't get initialized at all.

Regarding the bug, personally I have seen it happening (but only with "false") on HTC Hero, Nexus One, HTC Sensation, Galaxy S2, Galaxy Nexus. On which device/firmware did you see the issue happening with "true"?

Has anyone looked at AOSP source code for this? Maybe the bug is obvious. I would be surprised if any manufacturer had modified that part of Android's code, except perhaps for fixing the bug.

[Comment deleted]

Apologies, after a data clear which it appears I missed initially, testing this on the Desire Z 2.2.1 with the following line appears to have solved my problem with an initialisation of "true";

PreferenceManager.setDefaultValues(this, R.xml.preferences, true);

For those visiting, this apparently does not solve the "false" value initialisation, which I assume, by default is designed not to write out a preference for a false.

My question, is this "false" initialisation problem existent for both an explicitly "false" preference after using the above line, or for the "assumed" implicit initialisation?

Thanks! Glad to know that it's the same for everyone (ie: the bug only happens with "false").

The problem only happens for preference keys that you want to initialize *explicitly* to "false" in the XML. It works for "true" but not for "false". If you initialize it from onCreate() in the java code, it works for both "true" and "false".

If you don't initialize the preference key (neither in the XML nor in code) then it remains "null". There is no implicit initialization of any Preferences, afaik.

By implicit, I meant that when entering a PreferenceActivity, lists will be "none" and checkboxes are "unchecked". Initialised is not exactly the correct term, but I'm sure you follow my point.

For a checkbox I need to be checked as default, this is a problem, for an "unchecked" however, an "uninitialised" is as good as a "false" in terms of visual representation within the PreferenceActivity. And since you would specify a default when loading it for the first time, it shouldn't be a problem, at least for my use case.

Oh. Yes, in terms of visual representation in Android preferences it's true that "false" is the same as "null" - but in terms of what the programmer expects, I think that's clearly a bug, as we're explicitly requesting an initialization to "false" in the XML.

Also, some programmers might have strict expectations for boolean preferences if they implement a "three-state" checkbox as in Windows for example: "true", "false", "undefined" (=null). It might be useful! In that case "false" and "null" would have a different graphical representation, and the bug would become visible for end-users too.

If you use sharedPrefs.getBoolean("Value initialised with false as default",false) you will get the right value. You get a false since the value does not exist yet. If you initialised it as true then you will get true anyways, so this is how you have to do it.

Well.. You are parially right. I'll get "false" value, but this won't solve the problem at all.

What I expect from PreferenceManager.setDefaultValues(this, R.xml.settings, true); is to INITIALIZE preferences, so I expect that they are initialized :)

Don't know if this bug was solved or not. But I find a solution:

on your onCreate() (or onResume()) main activity put those lines

            //Get this application SharedPreferences editor  
            SharedPreferences.Editor preferencesEditor = PreferenceManager.getDefaultSharedPreferences(this).edit();  
            //Clear all the saved preference values.  
            preferencesEditor.clear();  
            //Read the default values and set them as the current values.  
            PreferenceManager.setDefaultValues(this, R.layout.activity_prefs, true);  
            //Commit all changes.  
            preferencesEditor.commit();  

[Comment deleted]

Is this still broken? Are we still forced to live with the workaround?

Bump- this is an amazingly huge bug.  That or the documentation is causing so many people to run in to this problem that it is buggy.  Is there really no movement here since 2011?

Hi everyone
This is really annoying! For now I just add the line proposed by alias.ne (http://code.google.com/p/android/issues/detail?id=6641#c12) at the start of each app I write, when I need a CheckBoxPreference. I had that problem on Android 4.2.2.
The Status "Obsolete" is a real joke!
Have a nice day.

I am facing the same problem. Why is this issue marked as obsolete?

Looks like the issue still persists. Targetting API 15 with support v7.