Https://Www.Youtube.Com/Watch?V=NhBXnpK19mc

Question

Android Architecture

Kostya Tskhovrebov

Https://Www.Youtube.Com/Watch?V=NhBXnpK19mc

#it #programming #russian #software

0

11.02.2019

5 ответов

13 просмотров

Кирилл Романенко

> мы не хотим переносить между платформами Котлин мультиплатформ не согласился бы. :)

0

11.02.2019

Anton Shynkaretskyi

Опа, гляну ближайшее время, спасибо

0

11.02.2019

Volodymyr Riznyk

Почти все посмотрел, вставлю свои пять копеек. Сразу оговорюсь, что у меня не клиенты для облачного сервиса, а IoT-устройства, которые должны уметь в офлайн, роботу с серверным менеджмент-софтом и имеют свой веб-интерфейс, так что presentation-слой у меня делится на UI (MVP) и web (REST API). Я пошел подобным путем как в докладе, только общение между фичами (модулями?) я решил на уровне интеракторов. У меня интеракторы делятся грубо говоря на два типа - менеджеры(глобальные, не имеют своего сопутсвующего представления, реализовывают интерфейс SingletonInteractor, имеют конкретную ответсвенность, e.g. NetworkManager, СallManager, SipManager, SoundManager, NotificationManager, LogManager) и интеракторы, которые используются в слое представлении(обычно имеет свой скоуп на уровне di). И по большему счету задача вторых сводится в агрегировании первых, чтобы получить доступ к нужным частям системы. Т.е, разбирая пример с баннерами, у меня был бы AdRepo, AdManager, AdScreenInteractor, где AdScreenInteractor не имел бы своего репозитория, но выступал агрегатором/фасадом/делегатом в примитивном случае, или делал определенные манипуляции с другими менеджерами, например, насчитал виртуальную валюту за просмотр рекламы через AppCoinManager. И в случае BannerScreenInteractor, он бы инкапсулировал AdManager, DraftManager, WeatherManager. В большинстве своем Manager-ы занимаются делегированием к репозиториям, а так же делают Rx-обертки, но иногда и выполняют какие-то фоновые бизнес-задачи (например, перерегистрация на сервере телефонии, если она отвалилась больше 30 секунд) . Инжектить в один инерактор несколько репозиториев неплохо себя показывало, когда они с одним датасорсом работали, например, репы под капотом с Room работают, и самое геморное - это M:N связь организовать. Но в кейсах, когда по дефолту одно поведение, а в зависимости от пользовательских конфигов, другое/третье, то проще эту логику инкапсулировать в одном месте.

0

11.02.2019

𝕊 ℍ 𝕎 𝔸 ℝ ℤ

Штормили эту тему. Если идет вложенность Repo -> Repo -> Repo это просто где-то ошибка в проектировании, аналогично ошибкам в проектировании Бд. Небольшой пример если Banner зависил от 4 репозиторий, то ему проще сформировать свой Repo типо BannerRepository и из нужных storage - ов вытянуть все что необходимо и наполнить нужный Entity. Если Banner это некая сущность которой достаточно к примеру AdvertisingRepository то для этого слоя предоставляете уже имеющийся репозиторий. в DI смотрится отлично. На уровне моделей видите какая фича какие репозитории использует. Если у след фичи необходимость показать не Banner, а Advertising то у этой фичи тоже AdvertisingRepository, отлично работает с cacheStorage и удобно менеджить скоупы. ПРимер из жизни например ContactRepository у которых свои авы, инфа, ChatRepository IM, который по сути огромная сущность, которая всегда живет, так как мессенджер а при этом переходы постояные с чата в группы, звонки, видео звонки и тд. Такая структура себя показывает очень надежно. В прошлом проекте делали возможность ViewModel иметь разные интеракторы, и также некторые репозитории могли общаться между собой. Архитектура начниает раскачиваться, а хендлить сложней ИМХО канеш, но по мне так. ВОт такая небольшая заметочка. Спасибо за видео, по моему все обсуждения довольно объективны и масштабируемость данного подхода очень высока.

0

11.02.2019

Кирилл Романенко · Accepted Answer

Кирилл Романенко

О, топово, спасибо.))

0

11.02.2019

214 похожих чатов

Https://Www.Youtube.Com/Watch?V=NhBXnpK19mc

5 ответов

Похожие вопросы