EditTextPreference should use AppCompatEditText about android-support-preference-v7-fix HOT 32 CLOSED

does that fix incorrect padding?

from android-support-preference-v7-fix.

To be honest, I didn't pay attention to the padding. In my app, the underline of the EditText should be orange, but on a device on API level 17, it was blue. When I changed the EditText to an AppCompatEditText, it went to the proper orange color.

I'd be willing to bet that would fix padding issues too.

from android-support-preference-v7-fix.

Screenshots from an emulator (api level 17):

With EditText:

With AppCompatEditText:

from android-support-preference-v7-fix.

my implementation if you're interested: https://github.com/ubergeek42/weechat-android/blob/master/weechat-android/src/main/java/android/support/v7/preference/EditTextPreferenceFix.java

from android-support-preference-v7-fix.

Thanks, fixed it.

from android-support-preference-v7-fix.

@Gericop thanks :)
@oakkitten Thanks for the link. If you're interested, you can see if using an AppCompatEditText removes the need for the padding fix. I see you also did a fix to put the cursor at the end. I can say that switching to AppCompatEditText doesn't fix that, so that's a nice additional fix :)

from android-support-preference-v7-fix.

@caarmen but the padding is still wrong in your second screenshot. "jdoe" is supposed to have as much padding on the left as "Username", at least judging by other google apps

from android-support-preference-v7-fix.

I have a doubt about the padding. Here we have the same edit text pref on an API 17 emulator, then on an API 21 emulator. This is a system setting, not one of the Google apps though. On API 21, the label isn't aligned with the entered text.

Do you have an example of an edit text pref in a google app which has the label aligned with the entered text?

(For info, I also noticed in both emulators, the cursor is placed at the beginning of the edit text...)

from android-support-preference-v7-fix.

Also updated the code to set the cursor position to the end of the EditText.
Thanks @oakkitten for the idea!

from android-support-preference-v7-fix.

I never checked how it looks outside AppCompat, but Gmail looks like this (also note the vertical padding)

while we are at it, when edit text dialog pops up, do you get the software keyboard automatically? this should probably be managed by needInputMethod() but i don't think it has any effect

from android-support-preference-v7-fix.

As for the software keyboard automatically, I do see that on both the 17 and 21 emulators, in this APN system setting, but NOT in my own app using app compat :/

Thanks for the gmail screenshot. Indeed, the padding looks better there. They should port that fix to AppCompat :)

I do notice that the text underline is blue (similar to the widgets in the other gmail preference dialogs), but the ok and cancel buttons are "teal" colored :)

from android-support-preference-v7-fix.

hehe yeah.

+i just checked various dialogs on my cyanogen. apparently some paddings are correct and some aren't, but then one can't expect any consistency from cyanogen. also, some apps like reddit sync have incorrect padding.

also, the padding is incorrect when using a dialog with an adapter that uses android.R.layout.simple_list_item_1.

so.. are you saying you do get that software keyboard? if you do, something must be wrong on my side

p.s. thanks for the repo, it helped out a lot!

from android-support-preference-v7-fix.

To clarify: On my own app I must explicitly tap on the edit text to get the software keyboard.

In the system setting, it's automatic.

from android-support-preference-v7-fix.

Well, Google really messed up a few things which is a result of - in my opinion - multiple teams / people working on different parts of the library and the material design guideline was still developing when they started working on this. If I have some time later (and the guys don't fix it by the time), I'll get the real repo and just fix the things myself so the fixes could be part of the official lib finally.

from android-support-preference-v7-fix.

It's interesting, on my HTC One M7 (Android 5.0.2), the Gmail (version 5.6.103338659) padding is not the same as yours.

from android-support-preference-v7-fix.

huh, it's the same version here, altho it has ".release" at the end. 5.1.1 (cm 12.1.-20150927 falcon)

from android-support-preference-v7-fix.

I also have the ".release" at the end, just thought it's obvious ;)

from android-support-preference-v7-fix.

heh this is just crazy. :D google, wtf

from android-support-preference-v7-fix.

23.1.0 is out!
After a quick test, if you just use the support lib without any workarounds:

• password fields still don't mask characters
• edit text preferences seem to use the appcompat theming now (the underline appears in my app's color)
• the selector is broken again :( It appears as blue instead of my app's color, on an API 17 emulator. Solution (?): set the attribute android:selectableItemBackground on api 11+. activatedBackgroundIndicator seems to not be needed anymore.

from android-support-preference-v7-fix.

I like how here they recommend using onAddEditTextToDialogView yet remove it in 23.1.0

from android-support-preference-v7-fix.

Indeed, I made this change to my hack PasswordPreferenceDialogFragmentCompat class to get the password masked:

     @Override
-    protected void onAddEditTextToDialogView(View dialogView, EditText editText) {
-        super.onAddEditTextToDialogView(dialogView, editText);
+    protected void onBindDialogView(View view) {
+        super.onBindDialogView(view);
+        EditText editText = (EditText) view.findViewById(android.R.id.edit);
         editText.setInputType(InputType.TYPE_CLASS_TEXT | InputType.TYPE_TEXT_VARIATION_PASSWORD);

from android-support-preference-v7-fix.

Doesn't my EditTextPreferenceFix fix this password-masking problem? It passes the EditText related arguments to the AppCompatEditText from the EditTextPreferenceFix you write in your XML.
You just write your XML like you normally would using EditTextPreference, so you can use the autocomplete and other nice features, then, when you're done, add the Fix ending to the tag's name.

from android-support-preference-v7-fix.

it does fix the password-masking problem!

btw i made preferences work very consistently down to api 10 (probably 7 but it'd be rather cumbersome to tweak code to lower minsdk to test).

from android-support-preference-v7-fix.

@Gericop I used this repo as a guideline, but I didn't actually use the exact files. In my project I did the passwords a bit differently: I made a password preference.

from android-support-preference-v7-fix.

@oakkitten Weird, I was sure I tried to remove all my edit text/password preference hacks, and my password field wasn't masked...

from android-support-preference-v7-fix.

@caarmen That is also a good solution if you need only that one. Mine is a more generic one as you can use any of the EditText arguments so you can use numbers, multiline field, etc. without creating new classes.

from android-support-preference-v7-fix.

@Gericop yes, I agree, your solution is more generic :) Anyway, I'm not proud of my hacks in general hehe

from android-support-preference-v7-fix.

@caarmen check out my implementation. In addition to Gericop's fixes, you can do <EditTextPreferenceFix android:summary="%s" android:password="true"> and you'll get •••••• in the summary if the password is set.

from android-support-preference-v7-fix.

@oakkitten I think I know what I did wrong... when I did my custom password preference, I removed the inputType attribute from the xml :P I just have to put it back.

from android-support-preference-v7-fix.

I checked again... without any hacks for EditTextPreference, the password isn't masked. My preference xml:

        <EditTextPreference
            android:defaultValue=""
            android:icon="@drawable/ic_pref_email_password"
            android:password="true"
            android:inputType="textPassword"
            android:key="PREF_SPEED_TEST_UPLOAD_PASSWORD"
            android:title="@string/pref_title_speed_test_upload_password" />

Maybe I wasn't clear. I didn't mean that it wasn't masked with EditTextPreferenceFix. I meant in the support lib, it's still not masked (hence some sort of workaround is still needed).

I updated my first comment of today to say "After a quick test, if you just use the support lib without any workarounds...." followed by the issues :)

from android-support-preference-v7-fix.

I think it's a won't fix in their issue tracker. As per the changelog:

Changes for v7, v14, and v17 Preference Support library:

• Removed APIs for controlling EditText dialogs.

from android-support-preference-v7-fix.

Updated to the latest version (23.1.0) of the support lib and it does fix some of the issues, but messes up a little bit more the EditText things so you might have to upgrade the custom classes as the android.support.v7.preference.R.id.edittext_container ID is no longer valid.

from android-support-preference-v7-fix.