Thumbnail color not refreshed

[baldapps]

Step to reproduce: 1) Open activity with a settings fragment 2) Go home 3) Change the preference color via intent/broadcast receiver 4) Come back home

The thumbnail shows the old color. Restarting the activity fix the problem. It would be great to have a public method to refresh/invalidate the thumbnail color.

[martin-stone]

What happens to a standard preference item in this situation? (E.g. a CheckBoxPreference.)

If it updates automatically it would mean there's something in the Preference system that the ColorPreference needs to hook into.

If it doesn't update, then whatever workaround is necessary for the CheckBoxPreference should also work (or be made to work) for ColorPreference. (That might mean adding a setColor() function, I suppose.)

Essentially I aim to have ColorPreference behaving the same as any other preference wherever possible.

[baldapps]

Usually I can catch the change in onPreferenceChange listener and then I can change the preference according to the new value. It's reason why I asked a public method to invalidate/restore/refresh the thumbnail color.

[martin-stone]

OK. Sounds like I need to add a setColor() function.

[baldapps]

Currently I'm using this code but reflection should be avoided.

        Field f;
        try {
            f = cp.getClass().getDeclaredField("thumbnail");
        } catch (NoSuchFieldException e) {
            return;
        }
        f.setAccessible(true);
        View thumbnail;
        try {
            thumbnail = (View) f.get(cp);
        } catch (IllegalAccessException e) {
            return;
        }
        thumbnail.setVisibility(View.VISIBLE);
        cp.setSummary("");          
        thumbnail.findViewById(R.id.colorPreview).setBackgroundColor(sharedPreferences.getInt(s, getResources().getColor(R.color.colorAccent, null)));

Another suggestion: since this is a (great) public library, you should use "private" only where strictly needed. You should prefer "protected" in this way each user, if he wants, can extend the library without any problem. In this way instead, you need to modify the library or I need to create a branch just for few lines of code. However thanks for the answer and for the quick support ;)

[martin-stone]

Version 1.6.0 has getColor() and setColor() on the ColorPreference class.

I'm going to stop short of exposing the guts of the class -- One day I might want to change how the internals work and I won't be able to do that confidently if applications have come to depend on it. Better to keep the interface well-defined.

As you point out, it is open source and anything's possible if you just clone your own copy. (Pull requests are welcome too.) :-)