В моих проектах я используюBroadcastReceivers как обратный вызов из долго работающего потока (например, уведомить активность о завершении загрузки и отправить некоторые данные ответа от WorkerThread, чтобы действие могло отображать соответствующее сообщение для пользователя ..). ИспользоватьBroadcastReceiver s Я должен быть осторожен, чтобы регистрировать и отменять регистрацию приемника вещания каждый раз, когда я его использую, а также должен заботиться о том, какие сообщения отправлять, особенно когда я использую этот метод для более различных действий (таких как загрузка, выполнение вызовов WebService и т. д.). .). А также для отправки пользовательских объектов через намерения Broadcast мне нужно также сделать объектыParcelable.

В отличие от этого подхода, я видел также подход методов обратного вызова, который кажется более простым, чем метод, который я использую. Методы обратного вызова - это простая реализация методов интерфейса, которая может быть использована для достижения того же эффекта, что и BroadcastRecaiver в приложении обмена сообщениями. Этот подход не требует реализации Parcelable для возврата сложных объектов и не использует ключи, такие какBroadcastReceiver .. Я думаю, что плохая часть в том, что мне нужно проверить объект обратного вызова на нулевое значение, прежде чем я хочу вызвать метод обратного вызова ... а также чтобы убедиться, что я запускаю код из реализации в потоке пользовательского интерфейса, чтобы я мог обновить интерфейс без ошибок.

Хорошо, я надеюсь, ты понял, что я хотел сказать

Теперь вопрос в том, считаете ли вы, что метод обратного вызова лучше (легче, чище, быстрее ...), чемBroadcastReceiver подход, когда используются только внутри одного приложения? (Обратите внимание, что я не использую AndroidService для фоновой работы .. простоAsyncTask а такжеThreads)

Спасибо