JF
точнее, почему он привязан к
android.os.Bundle?Size: a a a
2021 January 18
YS
Я помню, как делал Stub Bundle, по типу https://github.com/Arello-Mobile/Moxy/tree/master/moxy-android/stub-android . Но на тот момент я ещё не нашел решения про stub ) И получился какой-то дикий костыль. Но он был слишком не красив. А т.к. мы были на 99% уверены, что нигде, кроме как в Android это не потребуется, на самом деле, то тогда я на эту тему не заморочился
JF
т.е. на текущем этапе будет разумно вынести
Bundle в moxy-android?YS
Нет, потому что тогда moxy будет зависеть на moxy-android. Но этого делать не нужно. Потому что moxy-android нужен только для делегирование из android-компонент. Но кому-то нужен только androidx или ещё что-то
AD
Нет, потому что тогда moxy будет зависеть на moxy-android. Но этого делать не нужно. Потому что moxy-android нужен только для делегирование из android-компонент. Но кому-то нужен только androidx или ещё что-то
moxy + moxy-delegate + moxy-android + moxy-androidx 🤪
AD
moxy + moxy-delegate + moxy-android + moxy-androidx 🤪
причем moxy-android + moxy-androidx транзитивно тянут за собой moxy-delegate, чтобы не добовлять руками
JF
Нет, потому что тогда moxy будет зависеть на moxy-android. Но этого делать не нужно. Потому что moxy-android нужен только для делегирование из android-компонент. Но кому-то нужен только androidx или ещё что-то
я имею ввиду перенести инициализацию presenter через Bundle в moxy-android (при этом грамотно вырезать ее из moxy)
АЕ
А зачем в fx вообще заморачиваться с вьюстейтом и мокси? Там же нет проблем с ЖЦ. Можно просто руками зааттачить презентер. Если хочется прям код 1-1 переиспользовать, зависимости между пакетами библиотеки помешают, но можно форкнуть и pr потом бахнуть)
АЕ
Можешь как минимум issue на платформонезависимость основных классов создать, мож запилим.
AD
А зачем в fx вообще заморачиваться с вьюстейтом и мокси? Там же нет проблем с ЖЦ. Можно просто руками зааттачить презентер. Если хочется прям код 1-1 переиспользовать, зависимости между пакетами библиотеки помешают, но можно форкнуть и pr потом бахнуть)
так все равно Bundle стаббить придется 🙄
JF
А зачем в fx вообще заморачиваться с вьюстейтом и мокси? Там же нет проблем с ЖЦ. Можно просто руками зааттачить презентер. Если хочется прям код 1-1 переиспользовать, зависимости между пакетами библиотеки помешают, но можно форкнуть и pr потом бахнуть)
проблем нет с жц нет, не хочу заниматься дублированием.
Да и концептуально было бы верно реализовывать только ViewI
Да и концептуально было бы верно реализовывать только ViewI
JF
так все равно Bundle стаббить придется 🙄
а зачем его стабить, если можно вообще убрать?
YS
Зачем убрать? Он нужен =) Это по факту уникальное хранилище для ключа. Выкинуть не получится
AD
а зачем его стабить, если можно вообще убрать?
так Алексей быстрое решение предложил
AD
Зачем убрать? Он нужен =) Это по факту уникальное хранилище для ключа. Выкинуть не получится
перенести https://t.me/moxy_ru/27395
JF
Зачем убрать? Он нужен =) Это по факту уникальное хранилище для ключа. Выкинуть не получится
перенести в moxy-android
АЕ
А потом это всё на kmp и вообще красота)
АЕ
Короче issue хотя бы оставьте, а то не вспомним больше никогда
JF
YS
перенести в moxy-android
Так в любом случае нужно будет откуда-то взять уникальный ключ presenter. Он как раз хранится в Bundle fragment/acitivty/etc. Или вы будете просто всегда делегатом возвращать null? Вообще делегат это же не только bundle с ключем - это ещё и отслеживание, когда пора уничтожить презентер и удалить из хранилища презентеров