Блог

Главная - Вопросы по программированию - добавить прослушиватель против установить прослушиватель

добавить прослушиватель против установить прослушиватель

#java #android

#java #Android

Вопрос:

В чем разница между добавлением прослушивателя и настройкой прослушивателя.

например

 addTextChangedListener(textWatcher);
setOnClickListener(clickListener);

Ответ:

После ответа aioobe я протестировал это в своем проекте. Итак, мы можем это сделать.

 editText.addTextChangedListener(textWatcher1);
editText.addTextChangedListener(textWatcher2);

но мы не можем этого сделать.(В данном случае будет установлен только последний прослушиватель clickListener2)

 button.setOnClickListener(clickListener1);
button.setOnClickListener(clickListener2);

Еще одно сомнение

Я не могу придумать ни одного варианта использования, в котором мне нужны два TextWatcher для одного EditText. Кто-нибудь может привести такой вариант использования. (должен ли я задавать этот вопрос как отдельный вопрос?)

Ответ №1:

Если у вас есть set -метод, обычно есть только один прослушиватель. (Лично я предпочитаю называть их «обработчиками», хотя).

С помощью add -methods вы обычно можете иметь произвольное количество прослушивателей.

Комментарии:

1. @aioobe то есть вы имеете в виду, что я могу установить только один ClickListener, но я могу добавить более одного TextWatcher к одному представлению в моем примере.

2. ДА. Это была бы моя интерпретация, учитывая имена методов. Вы должны прочитать документацию по API, чтобы быть уверенным.

3. @aioobe можете ли вы привести пример настройки только одного прослушивателя и добавления более одного прослушивателя?

4. Если вы используете set метод, то вы устанавливаете прослушиватель в качестве прослушивателя, который вы предоставляете в качестве аргумента (последующие вызовы set метода переопределят ранее установленный прослушиватель). Если вы используете add метод, вы можете вызывать метод снова и снова, и вы бы добавляли все больше и больше слушателей.

Ответ №2:

aioobe, конечно, прав. Но есть дополнительное соображение:

В соответствии со стандартом JavaBeans

  • getX / isXyz и setXyz определить свойства (см. PropertyDescriptor ), но
  • addXyzListener , removeXyzListener и getXyzListeners также являются стандартными соглашениями об именовании для прослушивателей событий (см. EventSetDescriptor )

Итак, setXyzListener() это недопустимое имя метода для установки прослушивателя в соответствии со стандартом JavaBeans! Конечно, вы можете намеренно нарушить стандарт JavaBeans, но я пытаюсь уберечь вас от непреднамеренного выполнения 🙂

Ответ №3:

addListener — это стандарт Java beans, а setListener — стандарт Android, оба используются в разных контекстах. addListner используется только в случае настольного и веб-программирования, потому что здесь нам приходится иметь дело со многими компонентами в целом. В Android используется setListener, потому что здесь у нас есть одно действие. В какой-то момент мы используем addListiner, подобный addTextWatcher, потому что в одном действии нам приходится иметь дело со многими редактируемыми текстами.

Ответ №4:

На мой взгляд, нет веской причины для использования методов setXxxListener вместо addXxxListener. Я уверен, что эти методы «set» существуют просто из-за лени программиста. На самом деле это печально, потому что поддерживать список прослушивателей не намного сложнее, чем поддерживать одного прослушивателя. Может быть правдой, что обычно вы ожидаете только одного заинтересованного слушателя, но в любом случае есть много веских причин для поддержки их списков.

Мой любимый пример необходимости использования списков прослушивателей — это поддержка отладки. Возможно, вы захотите добавить диагностический прослушиватель для мониторинга некоторой активности, но только с методами setXxxListener процесс отладки может привести к поломке вашего кода! Суть в том, что при написании наблюдаемого класса вы не хотите делать ненужных предположений о том, как он будет использоваться.

Вот шаблон для некоторого наблюдаемого класса под названием MyModel:

 public interface MyModelChangeListener { public void changed(MyModel model); }
private ArrayList<MyModeChangeListener> listeners = new ArrayList<MyModeChangeListener>();
public void addMyModeChangeListener(MyModeChangeListener tcl) { listeners.add(tcl); }
public void removeMyModeChangeListener(MyModeChangeListener tcl) { listeners.remove(tcl); }
protected void fireMyModeChange() { for(MyModeChangeListener mmcl : listeners) mmcl.changed(this); }

Заинтересованные стороны добавляют прослушивателей по мере необходимости, а реализация MyModel и любые подклассы просто вызывают

 fireMyModeChange(this) whenever their observable states change.

Я создал issue 5711 в Android project средство отслеживания проблем с этой проблемой. Пожалуйста, отметьте это и, возможно, добавьте туда свои комментарии, если вы согласны, что это должно быть исправлено во всем Android SDK.