(
Под конструктором я подразумевал использование фабрики.
Которая андроидная FragmentFactory?
Size: a a a
2020 August 10
KD
Которая андроидная FragmentFactory?
Да. Других вариантов, к сожалению, я не знаю.
AA
положим, экран профиля пользователя
в одном случае - это новый пользователь, который при нажатии «назад» выходит из приложения и разлогинивается
в другом случае - это переход авторизованного пользователя для редактирования данных о себе, токен авторизации уже где-то на диске
в таком кейсе нужно обеспечить экрану две разных реализации для:
- хранилища токена авторизации (префы или ин-мемори)
- координатора, который по-разному обработает нажатия на кнопку назад - в одном случае закроет весь экран, в другом - вернет пользователя на предыдущий
в одном случае - это новый пользователь, который при нажатии «назад» выходит из приложения и разлогинивается
в другом случае - это переход авторизованного пользователя для редактирования данных о себе, токен авторизации уже где-то на диске
в таком кейсе нужно обеспечить экрану две разных реализации для:
- хранилища токена авторизации (префы или ин-мемори)
- координатора, который по-разному обработает нажатия на кнопку назад - в одном случае закроет весь экран, в другом - вернет пользователя на предыдущий
ну да, это логично
(
Да. Других вариантов, к сожалению, я не знаю.
Я просто тогда не вижу смысла делить виды фрагментов на фрагмент-диайконтейнер и фрагмент-инжектируемый, типа, один чёрт их всех можно через фактори инжектить
KD
Я просто тогда не вижу смысла делить виды фрагментов на фрагмент-диайконтейнер и фрагмент-инжектируемый, типа, один чёрт их всех можно через фактори инжектить
Так, а зачем эта лишняя головная боль с фабрикой, если она лишняя?
KD
Могу понять, если у вас одна фабрика на всё приложение с огромным
when, тогда да, может быть. Добавить туда быстренько фрагмент ещё один не составит труда, хотя тоже непонятно зачем.(
Ну как лишняя, процесс инъекции же одинаковый для всех фрагментов, нет?
AD
Могу понять, если у вас одна фабрика на всё приложение с огромным
when, тогда да, может быть. Добавить туда быстренько фрагмент ещё один не составит труда, хотя тоже непонятно зачем.затем, чтобы из разных родителей можно было передать разные реализации зависимостей
KD
затем, чтобы из разных родителей можно было передать разные реализации зависимостей
У тебя в каждом фрагменте больше двух реализаций зависимостей?
A
Вот вы флудильщики 😂
A
Сижу на собесах, а вы трям, трям, трям
KD
Ну как лишняя, процесс инъекции же одинаковый для всех фрагментов, нет?
Да, но снова таки — это надо сделать фабрику под фрагмент и, по хорошему, тесты, чтобы в рантайме не обосраться случайно.
Если у меня фрагмент-экран (родитель), который сейчас никоем образом не должен меняться от своих зависимостей, то на кой хер мне всё это, если я могу прямо взять какой-нибудь репозиторий и пробросить его дальше в презентер\фичу\вм\куда-угодно?
Если у меня фрагмент-экран (родитель), который сейчас никоем образом не должен меняться от своих зависимостей, то на кой хер мне всё это, если я могу прямо взять какой-нибудь репозиторий и пробросить его дальше в презентер\фичу\вм\куда-угодно?
AD
У тебя в каждом фрагменте больше двух реализаций зависимостей?
от случая к случаю попадается
KD
Если вдруг придут дяди маркетологи и скажут, что пора в этом месте сделать вторую реализацию, то, если я прямо увижу, что здесь всё можно переиспользовать и обойтись лишь зависимостями, я за 15 минут переделаю получение зависимостей.
KD
Но зачем мне это делать везде заранее? Просто чтобы было? Нет, спасибо
AI
Да, но снова таки — это надо сделать фабрику под фрагмент и, по хорошему, тесты, чтобы в рантайме не обосраться случайно.
Если у меня фрагмент-экран (родитель), который сейчас никоем образом не должен меняться от своих зависимостей, то на кой хер мне всё это, если я могу прямо взять какой-нибудь репозиторий и пробросить его дальше в презентер\фичу\вм\куда-угодно?
Если у меня фрагмент-экран (родитель), который сейчас никоем образом не должен меняться от своих зависимостей, то на кой хер мне всё это, если я могу прямо взять какой-нибудь репозиторий и пробросить его дальше в презентер\фичу\вм\куда-угодно?
Фабрика одна на всех. Одна у каждого родителя. Если это single activity, то у той Активити будет одна фабрика, которая умеет создавать все фрагменты-экраны
AD
Да, но снова таки — это надо сделать фабрику под фрагмент и, по хорошему, тесты, чтобы в рантайме не обосраться случайно.
Если у меня фрагмент-экран (родитель), который сейчас никоем образом не должен меняться от своих зависимостей, то на кой хер мне всё это, если я могу прямо взять какой-нибудь репозиторий и пробросить его дальше в презентер\фичу\вм\куда-угодно?
Если у меня фрагмент-экран (родитель), который сейчас никоем образом не должен меняться от своих зависимостей, то на кой хер мне всё это, если я могу прямо взять какой-нибудь репозиторий и пробросить его дальше в презентер\фичу\вм\куда-угодно?
кажется, пора сделать дисклеймер, что обсуждаемые подходы имеют смысл тогда, когда этого требует продукт) а то тебя опять в степь «зачем делать так, если можно проще»
KD
Фабрика одна на всех. Одна у каждого родителя. Если это single activity, то у той Активити будет одна фабрика, которая умеет создавать все фрагменты-экраны
Выше написал — в таком кейсе это просто сделать, ибо достаточно добавить ещё одно ветвление. Но далеко не все делают так.
AD
Фабрика одна на всех. Одна у каждого родителя. Если это single activity, то у той Активити будет одна фабрика, которая умеет создавать все фрагменты-экраны
ну тоже спорно, фрагмент-сценарий может иметь свою фабрику, если внутри несколько фрагментов живет, например)
AI
Выше написал — в таком кейсе это просто сделать, ибо достаточно добавить ещё одно ветвление. Но далеко не все делают так.
Так по-другому никак. У фрагмент менеджера может быть только одна фабрика