Таким образом код кажется более организованным и простым в обслуживании.
Более того, говоря об отношениях "Is-a", "Has-a", последнее кажется хорошей практикой, потому что теперь подкласс Activity будет иметь отношения "Has-a" с ClickListener . В то время как в первом методе мы бы говорили, что наш Activity-подкласс "Is-a" ClickListener, что не совсем верно.
Обратите внимание, что меня не беспокоят накладные расходы на память, которые может вызвать последнее.
Кроме того, о добавлении тега onClick в xml не может быть и речи.
Итак, как на самом деле лучше всего реализовать ClickListener?
Пожалуйста, не предлагайте никаких библиотек, таких как RoboGuice или ButterKnife и т.д.
Обновить:
Я хотел бы поделиться подходом, который я, наконец, принял.
Я непосредственно реализую прослушиватель в Activity / Fragment .
Что касается дизайна ООП. Подход "ЕСТЬ-А" не дает никаких практических преимуществ и даже занимает больше памяти. Учитывая количество вложенных классов (и нагрузку на память), которые мы будем создавать для каждого аналогичного прослушивателя, которого мы реализуем, этого подхода явно следует избегать.
Переведено автоматически
Ответ 1
Во-первых, Android не определяет наилучших практик в отношении регистрации прослушивателей кликов. Это полностью зависит от вашего варианта использования.
Правильная реализация View.OnClickListener интерфейса для Activity . Поскольку Android настоятельно рекомендует реализацию интерфейса снова и снова, будь то Activity или фрагмент.
Это ваш подход. Теперь это ваш способ реализации, и в этом нет ничего плохого, если вас не беспокоят затраты памяти. Но какая польза от создания внутреннего класса и реализации View.OnClickListener, если вы можете просто реализовать это в основном классе, что также может привести к ясности и простоте кода, которые вам нужны.
Так что это просто обсуждение, а не поиск наилучшего возможного решения для реализации представления.OnClickListener потому что, если вы придерживаетесь практической точки зрения каждого, вы выберете решение, которое является простым и экономичным по объему памяти.
Поэтому я бы предпочел обычный способ. Это упрощает работу. Проверьте код ниже:
P.S : Ваш подход определенно увеличит количество строк кода : P ;)
Ответ 2
Прежде всего, давайте разберемся с основами..
Реализуя интерфейс, ваш класс не становится таким .. как вы сказали:
"Наш подкласс Activity " - это " ClickListener, что не совсем верно".
Ваш класс может иметь отношение "Is-a" только в том случае, если он расширяется, в данном случае an Activity. Реализация интерфейса означает, что он может вести себя так, как интерфейс, установивший свой контракт.
Пример:
класс Peter расширяет Human .. означает, что Peter - человек..
класс Peter также может реализовать программист, музыкант, муж и т.д. Это означает, что Питер может вести себя так, как описано выше.
Что касается наилучшей практики, вы могли бы создать совершенно отдельный класс, который реализует OnClickListener следующим образом:
classMyListenerimplementsView.OnClickListener{
@Override publicvoidonClick(View view) { // do whatever you want here based on the view being passed }
}
И в вашем основном, Activity вы могли бы создать экземпляр MyListener и вызвать onClick() и передать в нем свое представление:
Я использую button.setOnClickListener(this); where my Activityimplements View.OnClickListener, а затем получаю идентификатор Button отдельным методом. Пример смотрите ниже.:
@Override publicvoidonClick(View v) { Buttonb= (Button) v; switch(b.getId()) { case R.id.YOUR_FIRST_BUTTON: // Do something break; case R.id.YOUR_SECOND_BUTTON: // Do something break; ... } }
...
}
Ответ 4
Здесь вы можете создать объект btnClickListner, и после этого вы будете вызывать этот объект btnCLickLisner, когда когда-либо захотите выполнить действия oncleck для кнопок..
Давайте предположим, что в моей деятельности у меня есть от 5 до 10 кнопок, и писать каждую кнопку отдельно onclick listner - плохая идея. Итак, чтобы преодолеть это, мы можем использовать следующее..