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

Question

Я изучаю Android и AFAIK, стандартный механизм Android для передачи данных между Activity - это использование Intents, которые, в свою очередь, реализованы как IPC на более низком уровне (возможно, я ошибаюсь).

Кажется, что в последнее время появилось множество библиотек, которые облегчают жизнь разработчикам Android. Между ними знаменитый Event Bus («Гринробот», «Отто»). Я пытался использовать оба (почти точную семантику интерфейса) и видел некоторые сообщения о том, как использовать шину событий Greenrobot для отправки событий в активность с использованием .postSticky, которая позволяет потреблять или вытягивать событие в новом действии, когда это готовый к приему этих данных.

Но из-за моего понимания с тех пор основная цель использования намерений (и, следовательно, утомительная работа по использованию сериализуемых/устранимых объектов при работе со сложными объектами) заключается в том, чтобы позволить Android воссоздать эти данные после того, как система убивает приложение из-за ограничений ресурсов, обычно, когда вы переключаетесь на другое приложение и начинаете играть. Поэтому, когда в этой ситуации, когда вы переключаетесь обратно на приложение yor, вы получаете NULL-указатель по данным, которые были переданы с использованием шины событий.

Есть ли у меня что-то? Или просто этот подход (шина событий для передачи данных в действия), даже очень чистая по коду, совершенно неверна?

Answer 1

основная цель использования Intents (и, следовательно, кропотливая работа использования сериализуемые/parcelable объектов, когда вы имеете дело со сложными объектами), чтобы позволить Android воссоздать эти данные после того, как система убивает приложение из-за нехватки ресурсов, обычно, когда вы переключаетесь на другое приложение и начинаете играть около

Это особенность Android. Я бы не назвал его «основной целью использования намерений». Основная цель использования Intents заключается в том, чтобы иметь возможность вызывать функциональные возможности (например, запускать деятельность), независимо от того, выполняет ли эта функция в вашем текущем процессе, какой-то отдельный процесс, в каком-то другом запущенном приложении или в каком-то процессе, который пока не существует (поскольку данное приложение не работает в данный момент).

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

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

Или просто этот подход (шина событий для передачи данных в действия), даже очень чистая по коду, совершенно неверна?

Я бы не рекомендовал подход. Это, как говорится, ИМХО, это тоже не «совершенно неправильно». «Совершенно неправильно» означало бы, что создать технически подходящее приложение для Android невозможно. Приложения для Android имеют широкий спектр вариантов использования, и поэтому некоторые из них могут выживать, используя этот метод даже в изоляции. И, используя этот метод в сочетании с другими вещами (например, постоянство данных), в некоторых случаях может быть отлично.

postSticky() - это просто кеш в памяти, связанный с шиной событий. Кэширование является важной частью многих приложений для Android, чтобы свести к минимуму повторный диск или сетевой ввод-вывод. До тех пор, пока postSticky() используется только в качестве кеша в памяти, приложения не должны попадать в неприятности.Приложения, которые полагаются на postSticky() завершение процесса завершения процесса , являются проблемой, хотя это не является уникальным для postSticky(), а скорее является общей проблемой с кэшами в памяти. Приложения, которые полагаются на any вид завершения процесса хранения в кэше в памяти.