Должен ли я использовать интерфейс слушателя или обработчик для обратных вызовов событий в разработке Android?

Question

Я новичок в Java, портирую через нашу библиотеку Windows Phone 7 для работы на Android.Из-за сходства синтаксиса это пока очень просто.Наша библиотека представляет собой абстрактную очередь сообщений http, которая обеспечивает постоянство и целостность данных на мобильных платформах.Он предоставляет только асинхронные методы, которые являются выбором дизайна.В WP7 я использую делегатов для вызова предоставленного пользователем обратного вызова, когда асинхронное сообщение было обработано и сервер получил ответ.

Чтобы добиться того же в Android, я нашел два способа: простой интерфейс прослушивания Java, содержащий методы OnSuccess и OnFailure, которые должен реализовать пользователь, или использование класса обработчика Android, который предоставляет очередь сообщениймежду потоками (http://developer.android.com/reference/android/os/Handler.html).

На этом этапе я работал с обработчиком, как если бы я был честен, он наиболее похож на делегат C #. Это также кажется меньшей работой для пользователя нашей библиотекиПример некоторого пользовательского кода для использования нашей библиотеки:

connection.GetMessage("http://somerestservice.com", GetCallback);

Handler GetCallback = new Handler() {
    public void handleMessage(Message message){
        CustomMessageClass customMessage = (CustomMessageClass)message.obj;

        if(customMessage.status == Status.Delivered) {
           // Process message here, 
           // it contains various information about the transaction 
           // as well as a tag that can contain a user object etc. 
           // It also contains the servers response as a string and as a byte array.
        }
    }
};

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

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

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

Я могу быть немного предвзятым из-за приходаиз C #, но слушатель кажется немного запутанным, и мне больше нравится реализация обработчика, есть ли у разработчиков Java какие-либо мысли / советы?Это будет высоко ценится.

Ура!

Answer 1

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

Кстати, я большой поклонник AsyncTask. Вы пробовали использовать?

Answer 2

Я не думаю, что у вас там компилируется ... вам нужно определить реализацию обработчика, прежде чем вы ее используете?

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

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

Кроме того, обычно в Java имена функций и переменных начинаются со строчной буквы.Только имена классов начинаются с верхнего регистра.