Я использую внедрение зависимостей, координаторов и шаблон проектирования MVP.
Как только пользователь входит в мое приложение, я получаю его объект учетной записи из Firestore в моем AppCoordinator. Этот объект учетной записи и другие службы вводятся в мой TabBarCoodinator, который вводит их во всех дочерних координаторов, и они делают то же самое с докладчиками, и т. Д. c.
init(_ navigationController: UINavigationController,
_ firestoreRepository: FirestoreRepositoryProtocol,
_ firebaseCloudStorageService: FirebaseCloudStorageServiceProtocol,
_ firebaseCrashlyticsService: FirebaseCrashlyticsServiceProtocol,
_ notificationService: NotificationServiceProtocol,
_ account: FIRAccount,
_ alertHandlerService: AlertHandlerServiceProtocol) {
self.navigationController = navigationController
super.init()
self.coord1 = Coord1(
firestoreRepository,
firebaseCloudStorageService,
geoLocationService,
alertHandlerService,
account,
delegate: self)
self.coord2 = Coord2(
firestoreRepository,
notificationService,
alertHandlerService,
account)
self.coord3 = Coord3(
firestoreRepository,
firebaseCloudStorageService,
firebaseCrashlyticsService,
geoLocationService,
alertHandlerService,
account,
delegate: self)
}
Я настроил слушателя в AppCoordinator, чтобы отслеживать изменения в объекте учетной записи. Когда происходят изменения, я хочу, чтобы это распространялось на все другие классы, в которые вводится учетная запись, чтобы ни у одного объекта не было устаревшего объекта учетной записи.
Проблема, с которой я столкнулся, заключается в том, как распространить изменения объекта учетной записи на все дочерние классы.
Каждая часть приложения, например EditProfilePresenter, воспроизводит роль в редактировании части объекта счета. В объект учетной записи конкретного докладчика вносятся изменения, и изменения передаются в Firestore.
Это приводит к огромной проблеме: все объекты учетных записей, которые были введены другим координаторам и презентаторам из AppCoordinator, теперь устарели. Единственный актуальный объект - это объект учетной записи EditProfilePresenter и объект, который хранится в AppCoordinator из-за прослушивателя.
Как я могу либо распространить обновленную информацию на все объекты с помощью объекта учетной записи, либо, как мне настроить мои объекты так, чтобы они имели единый источник истины для объекта учетной записи пользователя? В идеале я хочу, чтобы внедренная учетная запись ссылалась на оригинал, хранящийся в AppCoordinator, а не на его копию или клон.
Я учел:
Настройте три индивидуальные слушатели для трех основных частей приложения. Каждый слушатель будет управлять этим фрагментом объекта учетной записи приложения. Однако это приводит к 3 операциям чтения для одного обновления, что совсем не способствует масштабируемости.
Сохраните объект учетной записи в FirestoreRepositoryService. Большинство классов, требующих этой службы, используют объект учетной записи, и его экземпляр создается в координаторе приложения, поэтому он должен использоваться всеми классами. Однако это звучит плохо, поскольку это нарушает ответственность службы, просто выполняя запросы, связанные с Firestore.
Используйте синглтон для управления состоянием учетной записи, которое совместно используется и используется всеми классами, которые в нем нуждаются. Это означает, что объект учетной записи всегда обновляется в одном месте с помощью одного слушателя. Однако это резко снизит тестируемость и удобочитаемость из-за того, что объект учетной записи больше не будет внедряться, а также создаст тесную связь во всем приложении с одним объектом, состояние которого используется повсюду.
Обратите внимание на реструктуризацию объекта учетной записи, при которой информация разбивается на определенные c разделы объекта учетной записи. В идеале одна вкладка должна иметь дело только с назначенным ей фрагментом информации, а не со всем объектом учетной записи. Скорее, у него будет подколлекция внутри объекта учетной записи. Однако общая информация, которая обычно используется повсюду, например имя, будет храниться либо в объекте учетной записи, либо в подгруппе, что приведет к еще большему количеству операций чтения, необходимых для сохранения данных, и к некоторым другим недостаткам.
Настройте уведомление, которое будет отправляться каждый раз, когда координатор приложения получает обновление учетной записи, и зарегистрируйтесь для этого уведомления в каждом объекте, который использует объект учетной записи. Однако это снова кажется действительно плохим способом решения проблемы из-за накладных расходов, связанных с необходимостью гарантировать, что каждый объект зарегистрирован в этом уведомлении, иначе данные будут несогласованными.
I я действительно не уверен, что делать, любая помощь о том, как с этим справиться, будет оценена!