KT
fun params(arg: String) = FragmentParams(
cls = FeatureFragment::class,
args = Bundle(arg)
)
Size: a a a
2021 February 23
AD
так, а где выигрывает сущность screen?
KT
не нужно плодить сущности почем зря, FragmentParams тянуть незачем, когда на самом деле нужен просто фрагмент
AD
не нужно плодить сущности почем зря, FragmentParams тянуть незачем, когда на самом деле нужен просто фрагмент
так если нужен просто фрагмент, то и оперировать нужно фрагментами 🤔
KT
так только с ними и идет работа
KT
а вы хотите вместо этого новый класс с полями класса и бандлом внутри
AD
а вы хотите вместо этого новый класс с полями класса и бандлом внутри
так у меня вместо нового класса AppScreen имеется. шо то, шо это)
KT
нет, AppScreen позволяет вам не тянуть абстракции библиотеки на сторону фрагментов
KT
не надо никого заставлять возвращать какой-то FragmentParams из фабричного метода
AD
не надо никого заставлять возвращать какой-то FragmentParams из фабричного метода
так не нужон никак фабричный метод
в моем понимании FragmentParams == AppScreen
в моем понимании FragmentParams == AppScreen
KT
тогда в обратную сторону, в части отвязанной от понимания вашей реализации экранов надо тянуть Bundle() вместо нормальных типов
KT
а то что вам надо вот
AD
ну как же, тот же код, что и
AppScreen по сути, только никаких страшных лямбд и FragmentManager’ов 🤔
fun CustomParams(id: UserId) = FragmentParams(
cls = CustomFragment::class,
args = newBundleOf {
putSerializable(‘’id’’, id)
}
)AD
типизация на месте даже!
AD
да, да, вижу, что здесь эмуляция этих парамсов сделана
AD
не очень актуально для навигации, но такую лямбду хрен сериализуешь, а FragmentParams сериализуемы 🤔
KT
вот ровно то о чем вы говорите