Лучший способ обработки событий в Android - программирование
Подтвердить что ты не робот

Лучший способ обработки событий в Android

Я знаю, что это похоже на дублированный вопрос, но я действительно не смог найти хороший ответ по соответствующей теме.

Есть много вопросов о том, как лучше всего обрабатывать событие OnClick Button.
Вот некоторые из вариантов, с которыми я столкнулся:

1 - программно программировать метод прослушивания OnCreate:

button.setOnClickListener(new OnClickListener(){
    @Override
    public void onClick(View v) {
        //do stuff
    }
});

2 - Установка свойства android:OnClick в XML:

<Button android:id="@+id/btnDelete"
    ...
    android:OnClick="btnDelete_OnClick"/>

3 - Внедрение интерфейса OnClickListener в классе Activity и передача собственной ссылки на кнопку:

public class MainActivity extends Activity implements OnClickListener{
    @Override
    public void onClick(View v) {
        //do stuff
    }

    protected void onCreate(Bundle savedInstanceState) {
        ...
        button.setOnClickListener(this);
    }
}

4 - Создайте поле с типом OnClickListener:

private OnClickListener onClickHandler = new OnClickListener(){

    @Override
    public void onClick(View v) {
        //stuff
    }
};

protected void onCreate(Bundle savedInstanceState) {
    ...
    button.setOnClickListener(onClickHandler);
}

Когда дело доходит до события Button и OnClick, я всегда предпочитаю его определять в XML, он просто более чистый.

Но как насчет других событий, таких как OnItemClick из ListView или OnTimeSet из TimePickerDialog? Нет свойства, которое я могу увидеть для его настройки в XML. Я считаю, что реализация интерфейса Listener - довольно чистое решение, но это означало бы, что я могу только реализовать его один раз, и если у меня будет два равных представления, мне придется обрабатывать их события в одном и том же месте. Если я использую опцию 2 или 4, она, вероятно, будет довольно запутанной при обработке нескольких событий из разных представлений из пользовательского интерфейса.

Я хотел бы видеть другие мнения по этому вопросу, если есть другие варианты реализации для обработки событий. Есть ли альтернатива, которая может быть определена как лучшая, или это просто личное дело каждого программиста?

4b9b3361

Ответ 1

Позвольте мне объяснить в каждом случае:

Случай №1 Таким образом, вы создадите анонимные кланы так же, как вы создаете кнопки (каждая кнопка будет нуждаться в новом слушателе), а ее менее читабельна и дорогостоящая.

Случай №2 Фактически, если вы прочитаете код, стоящий за этим, вы найдете в нем отражение, чтобы найти ваш слушатель (метод) обратного вызова и его менее читаемый, и смущает других разработчиков.

Случай № 3 Этот путь трудно проложить, потому что вы не можете определить тип слушателя, который используете с текущей кнопкой (я знаю, что eclipse будет выделять методы this, указывающие на, но с огромным кодом, я думаю, это будет сложно найти).

Дело № 4 Я думаю, что это лучший способ реализовать слушателей, легко ориентироваться, читать больше, один слушатель может обрабатывать все связанные события (и с помощью eclipse, просто ctrl+click вы можете перейти к слушателю), поэтому я рекомендую это (я использую только этот способ на работе)

Я надеюсь, что это поможет

Ответ 2

  • Мне нравится этот метод, если у меня есть только один или два слушателя в классе. Например, listview onItemClickListener. С несколькими видами он действительно очень запутан.

  • Я вообще не использую android:onClick, просто потому, что мне нравится сохранять код в коде.

  • Мне нравится это, когда у меня есть несколько видов для обработки. Тем не менее, мне все же нравится сохранять мой onClick() код разреженным. Обычно он заканчивается switch по id, а группы похожих представлений вызывают дополнительные методы для обработки, например handleDownVote() или аналогичные. Таким образом, все мои основные "обратные" вызовы выполняются в одном месте.

  • Я не знал, что люди это сделали. Я полагаю, что это дает лучшую возможность группировать подобные представления, чем # 3, но я никогда не думал об этом. Может быть, я дам ему какое-то время.

Когда все сводится к этому, это очень субъективный вопрос, потому что на самом деле нет "правильного" или "оптимизированного" способа сделать это. Как вы можете видеть, каждый ответ до сих пор был другим. Не обижайтесь, но голосуйте, чтобы закрыть.

Ответ 3

Лучший способ обработать событие OnClick кнопки зависит от нескольких вещей:

1. нет кнопок, которые у вас есть.

Ans: если у вас есть только одна кнопка, вы можете пойти с 1-го уровня создания класса annonymoous. но если у вас несколько кнопок, не рекомендуется создавать несколько анонимных onClicklisteners. но пойти с другими опциями

2. оптимизация memmory

Ans: Если вы выполняете интерфейс OnClickListener в классе Activity и передаете самоназвание Button, а прослушиватель onclick сохранит ссылку на этот объект активности, поэтому будет тяжело хранить в нем весь объект активности, так что локальная переменная с типом OnClickListener более оптимизирована.

Таким образом, наилучшей практикой является создание локальной переменной с типом OnClickListener - лучший способ обработки любых типов событий не только событий onClick на Button.

Ответ 4

Есть еще одна возможность

class MyListener implements onClickHandler{
    public MyListener(SomeType parameter)
    {
       m_parameter = parameter;
    }
    @Override
    public void onClick(View v) {
        // do some stuff based on the value of m_parameter
    }
    private SomeType m_parameter;
};

protected void onCreate(Bundle savedInstanceState) {
    ...
    findViewById(R.id.Button1).setOnClickListener(new MyListener(parameter1));
    findViewById(R.id.Button2).setOnClickListener(new MyListener(parameter2));
    ...
}

Это позволяет избежать необходимости выяснять, что делать на основе щелчка мыши (кнопки). Очевидно, что у вас может быть более одного параметра конструктору для поддержки указания еще более богатых действий без "жесткого кодирования" идентификатора ресурса или идентификаторов кнопок в объекте MyListener.

Ответ 5

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

Тем не менее, я бы выбрал # 1, потому что он локализован - вы видите, что вы добавляете в качестве слушателя к кнопке, которой вы занимаетесь, в том месте, где вы ее добавляете. Он позволяет прослушивать несколько кнопок (против реализации слушателя на уровне класса).

По стилю я рекомендую, чтобы анонимные внутренние классы с едиными методами выполнялись следующим образом:

button.setOnClickListener(new OnClickListener(){
    @Override
    public void onClick(View v) {
        //do stuff
    }});

"}}); является основным бельмом для глаз - это намеренно. Он торчит как старый" больной палец". Это захватывает ваши глаза и заставляет вас понять, что происходит нечто особенное - конец анонимного определения внутреннего класса. Анонимные внутренние классы могут быть трудными для чтения - это уродство действительно помогает читабельности.