IssueTracker

This issue is assigned to an engineer for further evaluation.

I should mention I originally had a string array for the entries and an integer array
for the values. I tried various other combinations but anything other than string and
string resulted in a crash for me.

Using holiday ADP1.1.

Opps...to be more precise, when I said string and string I really mean string array
and string array. Just so we're clear, I was using arrays in all of my tests.

This stupid bug just hit me as well... using a string array for the entries, and an
integer array for the entryValues.  I can go ahead and use string values and
valueOf() to get the ints, but it's annoying...

hi, I confirm this bug if it helps here the BT :

Thread [<3> main] (Suspended (exception NullPointerException))  
        ListPreference.findIndexOfValue(String) line: 169      
        ListPreference.getValueIndex() line: 178        
        ListPreference.onPrepareDialogBuilder(AlertDialog$Builder) line: 190    
        ListPreference(DialogPreference).showDialog(Bundle) line: 291  
        ListPreference(DialogPreference).onClick() line: 262    
        ListPreference(Preference).performClick(PreferenceScreen) line: 810    
        PreferenceScreen.onItemClick(AdapterView, View, int, long) line: 182    
        ListView(AdapterView).performItemClick(View, int, long) line: 283      
        ListView.performItemClick(View, int, long) line: 3132  
        AbsListView$PerformClick.run() line: 1620      
        ViewRoot(Handler).handleCallback(Message) line: 587    
        ViewRoot(Handler).dispatchMessage(Message) line: 92    
        Looper.loop() line: 123
        ActivityThread.main(String[]) line: 3948        
        Method.invokeNative(Object, Object[], Class, Class[], Class, int, boolean) line: not
available [native method]      
        Method.invoke(Object, Object...) line: 521      
        ZygoteInit$MethodAndArgsCaller.run() line: 782  
        ZygoteInit.main(String[]) line: 540    
        NativeStart.main(String[]) line: not available [native method]  

I am changing to a feature request, because the current code is providing the
functionality that was intended.  This is a low priority improvement for the core
platform, so the fastest way to get such a feature implemented is to offer a patch.

Also happening for me here.

this happens on for me in Android 1.5.

has the fix been planned for 2.1?

I'm using 2.1 and just stumbled on to this.

This is the exception I got in the 2.1 SDK. Worked fine after switching to string array and using valueOf()

01-17 12:33:00.541: ERROR/AndroidRuntime(512): java.lang.NullPointerException
01-17 12:33:00.541: ERROR/AndroidRuntime(512):     at android.preference.ListPreference.onDialogClosed(ListPreference.java:218)
01-17 12:33:00.541: ERROR/AndroidRuntime(512):     at android.preference.DialogPreference.onDismiss(DialogPreference.java:384)
01-17 12:33:00.541: ERROR/AndroidRuntime(512):     at android.app.Dialog$ListenersHandler.handleMessage(Dialog.java:1058)
01-17 12:33:00.541: ERROR/AndroidRuntime(512):     at android.os.Handler.dispatchMessage(Handler.java:99)
01-17 12:33:00.541: ERROR/AndroidRuntime(512):     at android.os.Looper.loop(Looper.java:123)
01-17 12:33:00.541: ERROR/AndroidRuntime(512):     at android.app.ActivityThread.main(ActivityThread.java:4363)
01-17 12:33:00.541: ERROR/AndroidRuntime(512):     at java.lang.reflect.Method.invokeNative(Native Method)
01-17 12:33:00.541: ERROR/AndroidRuntime(512):     at java.lang.reflect.Method.invoke(Method.java:521)
01-17 12:33:00.541: ERROR/AndroidRuntime(512):     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:860)
01-17 12:33:00.541: ERROR/AndroidRuntime(512):     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618)
01-17 12:33:00.541: ERROR/AndroidRuntime(512):     at dalvik.system.NativeStart.main(Native Method)

personally I don't see how it is possible at compile to add integer array to
entryValues as the method gets CharSequence[] as parameter.

but I think it should be changed into Object[] so as to be able to provide any value,
and use it afterwards with getLong() etc.

Might I offer a patch for the _documentation_ so developers are more aware of this
intended feature? E.g.

android:entryValues - The <edit>string</edit> array to find the value to save for a
preference when an entry from entries is selected.

In a mathematical sense (which is closely related to computer science) a value is:

magnitude; quantity; <strong>number</strong> represented by a figure, symbol, or
the like: the value of an angle; the value of x; the value of a sum. (dictionary.com).

Hence, I feel this issue is related to the ambiguity of the documentation (though the prototype functions are quite clearly CharSequences).

I just ran in to this issue as well.  I guess there is some other reason for being
able to declare integer-arrays in .xml other than use in ListPreferences?  It seems
kind of ridiculous to declare as integer only to have to convert from String to
Integer in the calling code.

I just encountered this issue too. Annoying.

I also faced this issue. But it's a bug IMHO, not enhancement. And it's really anoying.  
API is OK, at least in 2.1

I also stumbled upon this and spent 2 hours trying to figure out what's wrong. Hope
this get's changed!

same issue here, please fix Romain

Ditto, this seems like a strange omission

Same thing here, spent one hour to find the problem until I found this issue.

Just stumbled across the same bug! It's still there in Android 2.2 :(

Been pulling my hair out of the last several hours over this. Bump!

I'm lucky that I found this thread after 10 minutes! This could have kept me going for hours again... Please fix it!

Silly little bug - documentation should be updated as the ListPreference behaves in a surprising way now.

Come on Google Guys. I can declare something as Integer and then have to read it as String to convert it back? You are kidding, aren't you?

just got me too, not a bug but just needs to be better documented.

It isa bug, declare an int array and crashed when you try to retrieve it as an int, clear bug. As stated above:
"personally I don't see how it is possible at compile to add integer array to
entryValues as the method gets CharSequence[] as parameter.

but I think it should be changed into Object[] so as to be able to provide any value,
and use it afterwards with getLong() etc."

[Comment deleted]

Google, this is a bug, not an enhancement. It causes unforeseeable fcs. If you allow something in the API and in IDEs you should expect it to happen. It's moronic to design a list preference class expectikng values to be CharSequence... do Object and then do boxing&unboxing in a typebased way.

Can anybody submit a patch for this? I don't know enough about preferences to do that but it seems like a simple enough patch.

Lost 5 hours of my life to this.

Lost 5 hours of my life to this. gtcopeland you have been starred.

Ooof, this is obnoxious, considering how much time I spent wracking my head why I was getting a NullPointerException. I don't mind ListPreferences being forced to have String values, which seems like the intent, but the SDK should be able to detect when I'm trying to use an XML-defined integer-array.

Honestly, I think that the SDK should be changed so that people developing apps with legacy support will still get those errors. This was confusing as hell.

I wasted a load of time on this. It is NOT an enhancement requirement - this is a bug.

I agree with the majority of these statements, but what is most annoying is the fact that it has not been resolved almost two years later.

Same here. Wasted too much time on this. Should just work.

Somebody must have thought that people might only have string values as configuration parameters. Cost me hours.

Listing the workaround in the documentation would be good.  I spent a lot of time thinking this was my mistake somewhere.  I can't see how I would have an integer (or anything other than a string-array) array for my ListPreference android:entryValues.  I don't see how to get around this using the valueOf as listed above.  I suspect you need Integer.parseInt() and not valueOf()?  

I wasted a lot of time on this. I consider it as a bug.

No patch?!

I was trying to get a boolean-array, which doesn't exist, so I changed to an integer-array, then I ran into this bug. Bummer. String to boolean seems...inefficient.
Bump.

Just ran into this problem, definitely an issue that needs to be fixed. Integer.parseInt() allocates too many, causes GC that I don't want in a CPU intensive game. Manual workarounds suck.

How can this issue be of medium priority if so many people run into it? It is ridiculous.

This should be of high priority.

[Comment deleted]

To quote above, "This is a low priority improvement for the core platform...". Sadly, a bug which seems to constantly catch developers, wasting hundreds of man hours, is perceived to be a "low priority", "feature request." The bug report was filed over two years ago. Somehow I don't think they plan on fixing this core bug.

@Greg, Then they should deprecate it so no one else wanders blindly into the damn bug.

You're preaching to the choir! Honestly, I can't help but feel they are giving developer's the finger on this one. An issue which is clearly wasting hundreds, if not thousands of man hours and yet considered "low priority" and a "feature request", is hard not to view in a negative light.

We all understand that the component is not written to support anything other than Strings. The problem is that the error message doesn't even come close to referring to that fact. I would love to see the functionality, but I think it is a high priority to at least explain why the code fails here!

#50 I second that, as it's a commonly used part of the sdk, this must be cleared out in any way.

This bug just bit me as well. Wasted 3+ hours tracking it down.

Why on earth is it considered a "feature request"?

Just been bitten by this. It feels like a bug if it's unexpected.

Same problem, the application crashes when I click on the ListPreference item. Seems to be working with 2 string arrays.

Cant believe this bug is so old and never fixed :(

Correction. Its not a bug. By declaring it an enhancement, they don't feel the need to fix...err, I mean address the enhancement. Therefore its not their problem. I mean after all, thousands of wasted man hours all bumping into an extremely obvious need for "enhancement" is in no way of need for actual enhancement.

It would just be nice to see the android engineers respond personally to this. They go all out for google i/o, but can't work with the developer community when it counts.

I almost bit my tongue off, in complete agreement. Its really difficult to not find my soap box. To put it nicely, Google has a horrible track record at actually supporting the development community - unless its GIO time.

yeah, so stupid.

Wow. Agreed. I got this issue. Can't believe it's been around for over 2 years. Can't be that hard to fix.

I am patient with bugs (or I wouldn't be writing code).  But what is truly testing my patience today is that anyone can say that this is not a bug.  Judging on the comments posted, there are many valuable hours wasted.  This seems like a case of one shirking their duty.  This is years later, and I hope it is not years to come before this is fixed (and if it's "not a bug" then the sdk/documentation certainly is).  Easy to workaround, but what about the next hundred people that skip their dinner like I just did to nail this one down???

THIS IS A BUG!

Just been bitten by this. What a sack of shit.

This is a bug.  It should either be documented as string only in the docs or be setup to allow multiple data types.  I have to go through and convert all my calls to this item now because it is stored as a string.

OMG!It's a bug.

Still no love? Creating multiple objects, comeon Google I am sure you can see the harm in that. I love the platform it is great, but these little things are killing me. Invest in your Native interface.

If anyone's interested, there's an implementation for the ListArray that uses an integer-array for values here:
http://kmansoft.wordpress.com/2011/01/02/implementing-a-styleable-preference-for-a-list-of-integers/

I've tested it myself, and it works perfectly..
It's not a solution, of course, but it's an option until they fix it

Program due in 1 1/2 hours - thank you thank you thank you!

iran into this, too. I consider it as a bug, because the compiler doesn't complain, and I get a horrible NullPointer at runtime. I'm using stringArray for items and integer-array for values

Still exists in latest SDK as of 4/3/12

Hoorible Bug! I defined an SML array for "entrys" and one for entryValues.

After Changing to

<array name="settings_values">
    <item>true</item>
    <item>false</item>
</array>
I get bitten, too. I don't define an integer-array, and this could be easy considered as Strings and is still crashing during 'addPreferencesFromResources"

This BUG made my afternoon horrible, please fix it <3

THIS IS A BUG!
En efecto, es un Little Bug que no me explico como los chicos de android aún no han resuelto (tiempo han tenido desde el 2009...).
Yo trabajo sobre Xperia Play con Android 2.2, y al final he optado por manejar mi propia sharedPreference donde al guardar y recuperar el valor de mi variable le hago los Cast pertinentes... pero es demasiado engorroso y queda bastante sucio...
Lo ideal es que Android implementase el metodo ListPreference.getValue() detectando si devolver un integer o string o long o lo que sea...

Just fix it please, boggled me for three hours straight until i found an answer on stackoverflow.com. This is a bug and not an enhancement!

It will be great if there is a Lint warning when not assigning string-array to entryValues of ListPreference.

[Comment deleted]

Just wasted more than two hours trying to figure this out.

I feel there should just be something in the JavaDocs - easy fix to at least let us know so we don't work for a long time trying to get this to work.

It's just not very intuitive.

Horrible bug, especially then Android API docs state that you can use any supported preference value type as entryValues.

[Comment deleted]

Hey - coming up to the 4th anniversary of this bug. There's a book out "How Google Tests Software". You have to laugh.

[?] Happy 4th year everyone on the list!  Maybe one day they'll at least
update the documentation! [?]

This bug disappeared in version 2.3 on my Motorola X2 phone but now shows up in the 4.0 version of my Razr phone.  The bug doesn't show if you display the ListPreference right away.  I hide mine until a user logs in then I setEnabled to true, this is when the bug appears.

Hey guys-developers,

Are you pulling our legs not fixing this bug? How in the hell it may be an enhancement if even a baby child understands that this is a bug, that adds work to developers????!!!!
Four years you did nothing....it's absolutely unacceptable!

Developers friendly???? Kiss my ass!

[Comment deleted]

Just run into this bug and this thread. Pretty basic bug so really surprised still an issue on API 17!

When I saw the start of the thread I swore it took me to an old issue. Until I scrolled and saw the last post was April 1st this year. How has this not been resolved since 2009???

Could be that google doesn't find it so dismisses it.  I get a very peculiar set of circumstances to fire this one off.  The bug doesn't show if you display the ListPreference right away.  I hide mine until a user logs in then I setEnabled to true, this is when the bug appears.

[Comment deleted]

[Comment deleted]

[Comment deleted]