KT
FragmentFactory заменяет историю с вызовом инжекта в поля на не менее стремную историю с передачей имени класса.
transaction
.replace(id, params.cls, params.args, params.tag)
.commit()Size: a a a
2021 February 22
KT
так удобно же получается:
в таком подходе теряется вся типизация параметров
KT
я за статически типизированный фабричный метод у фрагмента, вместо имени класса и набора аргументов в бандле
AD
я за статически типизированный фабричный метод у фрагмента, вместо имени класса и набора аргументов в бандле
в чем выигрыш?
KT
в статических проверках
KT
и явном описании контракта создания экрана
AD
но бандл-то в итоге придется писать руками
KT
но бандл-то в итоге придется писать руками
создателю этого экрана, когда он пишет фабричный метод
KT
это так и должно быть
KT
а не тем, кто хочет показать этот экран
AD
а не тем, кто хочет показать этот экран
так и я не предлагаю писать это всем
KT
так а что вы предлагаете?
AD
убрать струшное
Screen { fm -> fm.factory.instantiate(…) }KT
так для тех кто использует FragmentFactory, чтоб видели во что вписались и переставали)
KT
для остальных не надо страдать и просто возвращать фрагмент
KT
я понял о чем вы, типа сделать отдельный тип скрина, который на выход вместо фрагмента будет отдавать имя класса и бандл.
AD
я понял о чем вы, типа сделать отдельный тип скрина, который на выход вместо фрагмента будет отдавать имя класса и бандл.
тут на меня вообще не стоит равняться, на самом деле
я завис на
я завис на
5.1.1 и не вижу смысла использовать более новые версииKT
я уже понял)
2021 February 23
AD
я, правда, так и не понял, в чем принципиальное отличие из
FeatureFragment#newInstance возвращать Fragment от (Class<Fragment>, Bundle?) 🤔