I was playing around with the SharedPreferences thing (2.2 in this case), with the idea of centralizing the definition of the keys so that they could be referenced by both the stuff in preferences.xml for the preference activity and in code via R.string.blah.
I'm loading the preferences for the preference activity via addPreferencesFromResource In playing around with this, exploring how to get an xml-defined TextEditPreference to do whatever validation for a number it can do, an "<int>" element was inserted for the relevant key into the apps preferences.xml in /data/data/app... Probably because I was envisioning the value as an int, despite the fact that the TextEditPreference was hooked into it, and so I maybe had done a putInt or something (I'm new here). This now apparently completely breaks the inflation of the preference activity via addPreferencesFromResource because the TextEditPreference will only read in <string> things. Do folks mess with trying to code against this? By that I mean perhaps catching the potential ClassCastException in addPreferencesFromResource and then - I guess - going one-by-one through the keys finding out which one is causing the problem so it can be deleted (and the default value reloaded). I guess this shouldn't happen in general, but the fact that it did for me and so completely hoses the app is a tad unnerving. I mean, what if you had an old putInt somewhere that somehow survived some refactoring somewhere, and then it gets called... Of course, I could be misinterpreting what I've seen so far... -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
