FL
ща гляну
Size: a a a
2019 January 15
FL
спасибо ))) работает
МИ
Всем привет!) можно ли в качестве презентера использовать сгенерированного наследника этого презентера?) судя по всему нет, так как в MoxyReflector-e имена классов являются ключами, так?
FL
Всем привет!) можно ли в качестве презентера использовать сгенерированного наследника этого презентера?) судя по всему нет, так как в MoxyReflector-e имена классов являются ключами, так?
работает, если я правильно опнял вопрос
МИ
то, что на скрине не показывает как) мой презентер конечный находится в папке build (файл с классов создается кодогенерацией).
FL
я не знаю как чего там генерируется под капотом )
AK
Всем привет!) можно ли в качестве презентера использовать сгенерированного наследника этого презентера?) судя по всему нет, так как в MoxyReflector-e имена классов являются ключами, так?
ну у сгенирированного класса так же есть имя класса 🙂 тут скорее проблема в том, что раньше генерироваться будет
МИ
проблема в том, что сгенеренные классы я же не могу аннотировать @InjectViewState. Хотя... могу если очень захотеть наверное?) (имею в виду подтюнить свой кодогенератор)
AK
конечно 🙂
ES
Всем привет!) можно ли в качестве презентера использовать сгенерированного наследника этого презентера?) судя по всему нет, так как в MoxyReflector-e имена классов являются ключами, так?
а какую задачу вы хотите решить таким решение?
AK
а какую задачу вы хотите решить таким решение?
вот да, тоже интересно 🙂
МИ
В проекте генерируется наследник презентера для тогглинга (Feature toggle) методов, помеченных специальными аннотациями. В наследнике переопределяются нужные методы.
МИ
Видимо не аннотейшн процессор стоило писать а плагин для студии 😅
2019 January 16
IG
@senneco
Мы тут обнаружили проблему когда пилили проект на модули.
В общем, если в app модуле поменять пакет для MoxyReflector так же как для feature-модулей, то всё сломается, т.к. Moxy ожидает хотя бы один MoxyReflector с пакетом com.arellomobile.mvp
Пока что решили не менять пакет у MoxyReflector в app-модуле.
Это баг или фича? 🙂
Мы тут обнаружили проблему когда пилили проект на модули.
В общем, если в app модуле поменять пакет для MoxyReflector так же как для feature-модулей, то всё сломается, т.к. Moxy ожидает хотя бы один MoxyReflector с пакетом com.arellomobile.mvp
Пока что решили не менять пакет у MoxyReflector в app-модуле.
Это баг или фича? 🙂
YS
хмм, даж не знаю =)
IG
Ну вроде не страшно. В дальнейшем если такой кейс кому-то понадобится можно запилить возможность указать Moxy где находится главный Reflector
EK
@senneco
Мы тут обнаружили проблему когда пилили проект на модули.
В общем, если в app модуле поменять пакет для MoxyReflector так же как для feature-модулей, то всё сломается, т.к. Moxy ожидает хотя бы один MoxyReflector с пакетом com.arellomobile.mvp
Пока что решили не менять пакет у MoxyReflector в app-модуле.
Это баг или фича? 🙂
Мы тут обнаружили проблему когда пилили проект на модули.
В общем, если в app модуле поменять пакет для MoxyReflector так же как для feature-модулей, то всё сломается, т.к. Moxy ожидает хотя бы один MoxyReflector с пакетом com.arellomobile.mvp
Пока что решили не менять пакет у MoxyReflector в app-модуле.
Это баг или фича? 🙂
Это фича, в апп модуле как раз собираются все рефлекторы из других модулей и он должен лежать в стандартном пакете, чтобы мокси в рантайме его могла найти, поэтому главный рефлектор перенести скорее всего нормально не выйдет
IG
Это фича, в апп модуле как раз собираются все рефлекторы из других модулей и он должен лежать в стандартном пакете, чтобы мокси в рантайме его могла найти, поэтому главный рефлектор перенести скорее всего нормально не выйдет
Ну почему, там всё просто достаточно)
Ну, судя по тому что я в исходниках видел. Если нет дефолтного рефлекотора, пытаемся достать те, которые руками установили. Если не нашли - падаем.
Ну, судя по тому что я в исходниках видел. Если нет дефолтного рефлекотора, пытаемся достать те, которые руками установили. Если не нашли - падаем.
IG