Upgrade to support library v24.0.0 about android-support-preference-v7-fix HOT 14 CLOSED

Reported the issue to Google: https://code.google.com/p/android/issues/detail?id=213297

from android-support-preference-v7-fix.

Just about to report this issues. Thank you for reporting this. Is there any "hack" can be done, like what you had done on 23 support library?

from android-support-preference-v7-fix.

Okay, I found the bug (it is more of an Android View-handling thing though).

In PreferenceGroupAdapter's onCreateViewHolder(...) after inflating the layout, the paddings are good. Right after this, there's a setBackgroundDrawable(...) call which resets them all to zero. It is a known behavior as per Romain Guy:

The reason why setting an image resets the padding is because 9-patch images can encode padding.

The solution would be the following:

1. Save the paddings after inflating the layout.
2. Set the background drawable.
3. Set the saved paddings on the layout.

Since the Android devs decided to make a lot of things private in this class (including an inner static class), it'd be extremely difficult to fix it only by overriding a few things...

from android-support-preference-v7-fix.

Tried a lot of "nice" things (i.e. not rewriting layouts / classes), nothing worked and I don't really get the reason why.

Here's a piece from the v17 preference_category_material.xml layout file:

android:paddingStart="?android:attr/listPreferredItemPaddingStart"
android:paddingEnd="?android:attr/listPreferredItemPaddingEnd" />

And this solution should work (it's in v17 styles.xml; the test app uses PreferenceFixTheme.Light.NoActionBar which inherits its attributes from PreferenceFixTheme.Light):

<style name="PreferenceFixTheme.Light" parent="@style/Theme.AppCompat.Light">
    <item name="preferenceTheme">@style/PreferenceThemeOverlay.v14.Material</item>
    <item name="colorAccent">@color/preference_accent</item>
    <item name="dialogTheme">@style/PreferenceFixTheme.Light.Dialog</item>
    <item name="alertDialogTheme">@style/PreferenceFixTheme.Light.Dialog.Alert</item>
    <!-- Padding fix -->
    <item name="android:listPreferredItemPaddingStart">16dp</item>
    <item name="android:listPreferredItemPaddingEnd">16dp</item>
</style>

The funny thing is that in the preference_material.xml file (notice the difference), there's also this attribute:

android:minHeight="?android:attr/listPreferredItemHeightSmall"

If I override it by defining its value in the same PreferenceFixTheme.Light style, it works:

<item name="android:listPreferredItemHeightSmall">100dp</item>

So I guess the padding is really just preferred and gets overridden by either a direct piece of code or the measurements done during layout.

from android-support-preference-v7-fix.

Thanks, In your previous workaround, I already include

<!-- Padding fix -->
<item name="android:listPreferredItemPaddingStart">16dp</item>
<item name="android:listPreferredItemPaddingEnd">16dp</item>

in v17. It works fine all time till recently when we switch to support library 24.

I also observe same problem in device with v16. But, android:listPreferredItemPaddingStart and android:listPreferredItemPaddingEnd are not found in v16.

Hope Google can deliver a fix on this. Without library 24, we can't take advantage of Firebase.

from android-support-preference-v7-fix.

It was just an example, all the API levels below 21 are affected by it. API 7-14 uses android:listPreferredItemPaddingLeft and android:listPreferredItemPaddingRight, but the problem persists.

from android-support-preference-v7-fix.

I did some experiments with it on API 14 by copying the preference_material.xml to the project and hard-coding the padding into it and still no success, so I'm guessing that it is being overridden in a class. Moreover, I set the height of the layout to the right padding's attribute and it worked which confirms my theory...

from android-support-preference-v7-fix.

Interesting, I've already had the PreferenceCategory class because it still messes up the accent color without it, so I decided to get the padding of the title view in onBindViewHolder(...). It returns plain 0 for all of the padding values. It pretty much seems like the inflater just doesn't care about the paddings anymore and sets(?) them to 0. The category itself has a hard-coded 16dip paddingTop, which is also ignored, while the bottom margin (also set to 16 dip) is there normally. If I set the paddings from code, they take effect and show just how normally they would.

from android-support-preference-v7-fix.

I found a way to hack in the left and right paddings, but the top one is still messed up.

from android-support-preference-v7-fix.

Seems that with reflection I've been able to fix this ridiculous bug. I'll release the v24.0.0.0-beta version soon...

from android-support-preference-v7-fix.

The fix has been released. Use compile 'com.takisoft.fix:preference-v7:24.0.0.0-beta' in your projects.

from android-support-preference-v7-fix.

Thanks for your work. Going to try it out tonight.

from android-support-preference-v7-fix.

Hi @Gericop

Thanks for the hard work.

However, I realize, it is not work perfectly with inner preference yet.

Here's the screnshot

Here's the XML for the preference screen - https://gist.github.com/yccheok/4172d782249757b1153cee9edd4c566b

Thanks.

from android-support-preference-v7-fix.

Sorry. The inner preference bug I mentioned is not valid anymore. Please ignore it.

#27

from android-support-preference-v7-fix.