Альтернатива передаче активности в хранилище

Question

Согласно этому изображению в Руководстве по Android Архитектура приложения и некоторых других материалах, которые я наблюдал и / или читал, объекты на более высоком уровне иерархии архитектуры должны иметь экземпляры для ( и только для) объектов, которые находятся ниже в иерархии. Например, Activity может создавать экземпляр ViewModel, а ViewModel может создавать экземпляр Repository. Я также понимаю, что хранилище должно взаимодействовать с источником данных и предоставлять чистый API для всех приложений. Кроме того, ViewModel (или даже repository в этом отношении) никогда не должно иметь экземпляра для Activity, которую он обслуживает.

В своем приложении я использую Firebase Cloud Firestore для хранения своих пользовательских данных и хочу обновить свои данные в режиме реального времени. FireStore API предоставляет хороший способ очистить слушателей, когда базовая активность останавливается, то есть метод addSnapshotListener(Activity activity, EventListener<DocumentSnapshot> listener для класса DocumentReference. Согласно моему пониманию руководства по архитектуре, все эти слушатели должны присутствовать в классе репозитория. Поэтому, чтобы заставить слушателя остановиться, когда действие останавливается, мне нужно передать экземпляр действия в хранилище. Это не рекомендуется, так как если конфигурация активности изменяется, это вызывает утечку памяти.

Другим решением было бы создание слушателя в классе Activity, но это нарушает принцип Разделение проблем и в целом делает вид деятельности неуклюжим.

Третье решение состоит в том, чтобы вручную удалить слушателя из метода действия OnDestroy() (или OnStop() как угодно). Но это кажется плохой идеей, потому что, что произойдет, если есть несколько слушателей данных, которые должны быть активны одновременно? Мне придется следить за всеми ними и всем, что кажется большой работой, которую FireBase API уже обработал для меня.

Как мне go об этой проблеме? Могут ли классы LifeCycle предоставить решение? Или мне просто прикрутить руководство по архитектуре?

Answer 1

Интересный вопрос и после рассмотрения Обработка жизненных циклов с компонентами, поддерживающими жизненный цикл Я могу вспомнить, как слушатель передается из Activity / Fragment в ViewModel и оттуда в хранилище, где вы сможете получить события жизненного цикла и действовать соответствующим образом.

К сожалению, поскольку хранилище должно знать об изменениях жизненного цикла, у вас не может быть полностью отделенного хранилища, поскольку оно должно знать о событиях жизненного цикла (LifecycleOwner).

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

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