КР
извне не ясен ЖЦ фрагмента
А что у тебя зависит от жц фрагмента такого, что ты передаешь при этом в конструктор? Всякие аргументы для вьюмодели/презентера/фичи или юзкейсы/интеракторы аллоцируются один раз же.
Size: a a a
2020 August 10
AI
Я вижу только один случай, это если надо зависимость передать во ViewModel. Тогда надо передать не саму зависимость, а функцию её возвращающую: dataSource: () -> DataSource
AI
Или Lazy<DataSource>
AD
я видимо вам двоим отвечу
любой интерактор/репозиторий/кто угодно, переданный в конструктор фрагмента, будет предварительно создан
из фабрики фрагментов не ясно, какую зависимость передать - свежесозданную или сохранённую для переживания смены ориентации
потому мне видится логичным, что передавать в конструктор стоит фабрику зависимости, а не зависимость
любой интерактор/репозиторий/кто угодно, переданный в конструктор фрагмента, будет предварительно создан
из фабрики фрагментов не ясно, какую зависимость передать - свежесозданную или сохранённую для переживания смены ориентации
потому мне видится логичным, что передавать в конструктор стоит фабрику зависимости, а не зависимость
AI
я видимо вам двоим отвечу
любой интерактор/репозиторий/кто угодно, переданный в конструктор фрагмента, будет предварительно создан
из фабрики фрагментов не ясно, какую зависимость передать - свежесозданную или сохранённую для переживания смены ориентации
потому мне видится логичным, что передавать в конструктор стоит фабрику зависимости, а не зависимость
любой интерактор/репозиторий/кто угодно, переданный в конструктор фрагмента, будет предварительно создан
из фабрики фрагментов не ясно, какую зависимость передать - свежесозданную или сохранённую для переживания смены ориентации
потому мне видится логичным, что передавать в конструктор стоит фабрику зависимости, а не зависимость
Верно, фабрика конкретной зависимости: функция или Lazy
AD
Я вижу только один случай, это если надо зависимость передать во ViewModel. Тогда надо передать не саму зависимость, а функцию её возвращающую: dataSource: () -> DataSource
хм, да, не подумал это уточнить)
казалось, что наличие в фрагменте чего-то по типу VM, которое переживает смену ориентации - по умолчанию подразумевается)
казалось, что наличие в фрагменте чего-то по типу VM, которое переживает смену ориентации - по умолчанию подразумевается)
AI
хм, да, не подумал это уточнить)
казалось, что наличие в фрагменте чего-то по типу VM, которое переживает смену ориентации - по умолчанию подразумевается)
казалось, что наличие в фрагменте чего-то по типу VM, которое переживает смену ориентации - по умолчанию подразумевается)
В общем стало понятно)
AK
я всё таки не до конца вдупляю когда нужно использовать фрагменты ,а когда нет. на тестовых заданиях люди требуют делать все на фрагментах в приложениях с 3-4 экранами, хотя как по мне, это бессмыслено. Дак стоит ли в них упарываться если приложение не большое?
AG
Anatoliy Kernokus
я всё таки не до конца вдупляю когда нужно использовать фрагменты ,а когда нет. на тестовых заданиях люди требуют делать все на фрагментах в приложениях с 3-4 экранами, хотя как по мне, это бессмыслено. Дак стоит ли в них упарываться если приложение не большое?
Почему бессмысленно? Альтернатива какая?
AK
Почему бессмысленно? Альтернатива какая?
в приложениях с 3-4 экранами можно пилить тупо на активностях.особенно если приложение не нагруженное.или это не так?
AO
AO
но мне вот интересно чем таким фрагменты сложнее в использовании чем активности что в них прям надо упарываться?
ES
Anatoliy Kernokus
в приложениях с 3-4 экранами можно пилить тупо на активностях.особенно если приложение не нагруженное.или это не так?
Ну вот возьми боттом нав или дровер и попробуй замутить активности
AG
Anatoliy Kernokus
в приложениях с 3-4 экранами можно пилить тупо на активностях.особенно если приложение не нагруженное.или это не так?
В чём преимущество активностей в этом случае?
AK
Ну вот возьми боттом нав или дровер и попробуй замутить активности
c этим согласен
AK
В чём преимущество активностей в этом случае?
с такой логикой от противного можно кучу заключений сделать. у активностей проще жизненный цикл и не нужно запариваться насчет связи между ними как у фрагментов внутри одной активити.в чем тогда преимущество использования фрагментов в случае с 3-4 экранами?
AO
а зачем у фрагментов запариваться насчет связи?)
AK
я задал вопрос в качестве холивара,а не с тем,что бы в меня стрелками тыкали
PA
Anatoliy Kernokus
с такой логикой от противного можно кучу заключений сделать. у активностей проще жизненный цикл и не нужно запариваться насчет связи между ними как у фрагментов внутри одной активити.в чем тогда преимущество использования фрагментов в случае с 3-4 экранами?
Как раз-таки ЖЦ всего приложения получается привязанным ровно к 1 активности при использовании single activity application. При использовании нескольких активностей же ты не сможешь грамотно управлять ЖЦ приложения. Например, при восстановлении приложения происходит загрузка только последней активности, все остальные же исчезнут, если отдельно не сохранить их
AK
Как раз-таки ЖЦ всего приложения получается привязанным ровно к 1 активности при использовании single activity application. При использовании нескольких активностей же ты не сможешь грамотно управлять ЖЦ приложения. Например, при восстановлении приложения происходит загрузка только последней активности, все остальные же исчезнут, если отдельно не сохранить их
согласен,но это только с single activity application.