Android: возможность просмотра / рисования пользовательских стилей?

1

Что бы я хотел сделать, это изменить состояние (на самом деле, фон) EditText, чтобы отразить правильность его содержимого. Например. если пользователь входит в 999, где 999 является контекстуально недействительным, EditText должен иметь красную рамку вместо оранжевой границы по умолчанию, аналогично тому, как текст действителен, она должна иметь зеленую границу.

Методы, которые я изучил:

  • Изменение стиля EditText программно через нечто вроде editor.setStyle(R.styles.SomeID). Кажется, это невозможно в андроиде.
  • Добавление пользовательских состояний (state_valid, state_invalid) в R.attr, связывание их с красными/зелеными 9-патчами, а затем вызов drawable.setState() с одним из этих состояний. Это работало в том смысле, что состояние можно было прочитать через getState(), но граница не изменила цвет.
  • Установка фонового ресурса непосредственно при обнаружении (in) действительности. Это работает нормально, вызывая правильный визуальный эффект, но кажется немного хоккеем и позволяет только одно состояние (например, мне нужно вручную проверить, нажата ли кнопка EditText, включена ли она и т.д.).

Учитывая ограниченный потенциал пользовательского интерфейса, я не решаюсь ввести отдельный элемент пользовательского интерфейса для визуальной обратной связи с текстом для пользователя, поэтому мое желание отобразить его в самом EditText.

Итак... это что-то, что даже возможно? Это похоже на довольно распространенный случай использования, так кто-нибудь достиг того, что я пытаюсь сделать в простой и элегантной манере?

Теги:
coding-style
drawable

3 ответа

2

Я бы рекомендовал изменить цвет текста, чтобы указать правильность, а не изменять цвет кольца фокусировки с помощью любого из описанных вами методов (из которых только # 3 кажется практичным).

Другая возможность - попробовать setCompoundDrawablesWithIntrinsicBounds() изменить значок слева или справа от содержимого EditText для указания действительности. Я помню, как обсуждал эту технику с кем-то несколько месяцев назад и забыл, получили ли они ее работу или нет.

И, конечно, другой вариант - не допускать недопустимый ввод, через настраиваемый фильтр ввода или прослушиватель или что-то в этом роде.

Поделиться
  • 1
    Спасибо за ваш ответ. Изменение цвета текста является вариантом, конечно, но приводит к менее тонкому эффекту IMO. Аналогичным образом, изменение значка для обозначения (недействительности) означает, что обратная связь не возникает в момент любого расхождения, что является плохим пользовательским интерфейсом. Наконец, применение фильтра на самом деле не вариант здесь, так как ввод может быть действительным с другими символами, такими как частично полный номер телефона.
  • 1
    «Аналогичным образом, изменение значка для обозначения (недействительности) означает, что обратная связь не возникает в момент любого расхождения, что является плохим пользовательским интерфейсом». Это не то, что я написал. Мое предлагаемое решение (если оно работает) предлагает превосходный интерфейс IMHO - вместо того, чтобы пользователям приходилось догадываться, что изменение цветов кольца фокуса означает изменение достоверности, вы можете использовать более визуально мощный значок прямо внутри EditText, который вы считаете недействительным.
1

Хорошо, я бы просто расширил класс EditText и построил желаемую функциональность сверху (используя третий подход, который вы предлагаете, потому что он работает:-)). Выполняя это, вы должны идти только один раз и открываете для изменения своей реализации, как только вы знаете лучший способ (я бы лично решил это, используя третий подход, кажется мне хорошим).

Поделиться
  • 0
    Спасибо за ответ. Моя проблема с третьим подходом заключается в том, что мне нужно выполнить большую работу для проверки каждого состояния или комбинации, например, EditText может быть нажат-включен-действителен, или не-нажат-включен-недействителен и т. Д., Что заставляет мой подкласс необходимо проверить каждую возможную комбинацию, чтобы отобразить правильный фон. Это кажется неуклюжим и не элегантным, не говоря уже о нарушении СУХОЙ.
0

Я думаю, что вызов invalidateDrawable (yourDrawable) будет работать с подходом номер 2. я не пытался... но это имеет смысл

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню