Y
а тут скорее всего с reified нужно позаморочиться как-то..kClass: KClass<T> такую штуку ещё посмотреть может можно..я точнее не подскажу, но как вектор куда копать может поможет (reified наверное тольк для функций справедлив)
Size: a a a
2020 March 02
A
а тут скорее всего с reified нужно позаморочиться как-то..kClass: KClass<T> такую штуку ещё посмотреть может можно..я точнее не подскажу, но как вектор куда копать может поможет (reified наверное тольк для функций справедлив)
ага, видел, спасибо! Вроде это только для методов
Y
ага, видел, спасибо! Вроде это только для методов
вот я уже подписала, да)
A
АЕ
Нашел интересное: https://stackoverflow.com/questions/55229374/why-dont-sub-classes-have-access-to-nested-interfaces-in-kotlin
Говорят, что тот факт, что это работает в Java - баг. Просто не стали править во имя обратной совместимости)
Говорят, что тот факт, что это работает в Java - баг. Просто не стали править во имя обратной совместимости)
A
Нашел интересное: https://stackoverflow.com/questions/55229374/why-dont-sub-classes-have-access-to-nested-interfaces-in-kotlin
Говорят, что тот факт, что это работает в Java - баг. Просто не стали править во имя обратной совместимости)
Говорят, что тот факт, что это работает в Java - баг. Просто не стали править во имя обратной совместимости)
Спасибо, интересно)
С
Я бы топил за то, чтобы у каждого слоя была своя моделька. Но если request model и response model будут всегда идентичными, и если со стороны бэкенда изменения в ответе затронут и модельку для запроса, то ок)
По сабже, примерно да. getUsers в репо будет брать данные из datasource и отправлять интерактору/презентеру уже готовые к использованию данные, и оттуда же будут отравляться ваш request model =)
По сабже, примерно да. getUsers в репо будет брать данные из datasource и отправлять интерактору/презентеру уже готовые к использованию данные, и оттуда же будут отравляться ваш request model =)
Спасибо
DK
всем драсти.
Считается ли хорошей практикой создавать Enum класс, в параметрах которого ресурсы (типа R.color.green)?
Считается ли хорошей практикой создавать Enum класс, в параметрах которого ресурсы (типа R.color.green)?
AO
всем драсти.
Считается ли хорошей практикой создавать Enum класс, в параметрах которого ресурсы (типа R.color.green)?
Считается ли хорошей практикой создавать Enum класс, в параметрах которого ресурсы (типа R.color.green)?
постоянно так делаю
V
+) хз, хорошая ли практика
AD
всем драсти.
Считается ли хорошей практикой создавать Enum класс, в параметрах которого ресурсы (типа R.color.green)?
Считается ли хорошей практикой создавать Enum класс, в параметрах которого ресурсы (типа R.color.green)?
а для чего так делать?
А
а для чего так делать?
Поди знай.
Я так делал, когда делал Enum для BottomNav. В каждом перечислении была ссылка на стрингу, которая содержит название экрана, куда юзер будет переходить.
Я так делал, когда делал Enum для BottomNav. В каждом перечислении была ссылка на стрингу, которая содержит название экрана, куда юзер будет переходить.
PA
всем драсти.
Считается ли хорошей практикой создавать Enum класс, в параметрах которого ресурсы (типа R.color.green)?
Считается ли хорошей практикой создавать Enum класс, в параметрах которого ресурсы (типа R.color.green)?
Можно в utils метод создать, который будет возвращать нужный тебе stringRes id в зависимости от значения enum.
PA
всем драсти.
Считается ли хорошей практикой создавать Enum класс, в параметрах которого ресурсы (типа R.color.green)?
Считается ли хорошей практикой создавать Enum класс, в параметрах которого ресурсы (типа R.color.green)?
Не думаю, что это по Code clean. Лучше разделять
MI
Не думаю, что это по Code clean. Лучше разделять
Ну если эти модельки относятся только к presentation слою, почему бы и нет :)
DK
спасибо друзья))
PA
Ну если эти модельки относятся только к presentation слою, почему бы и нет :)
А что если иконки айтемов?)
KD
Если речь именно о
R.color.green — т.е. об интах — то вполне себе нормально такое где угодно держать.MI
А что если иконки айтемов?)
DrawableRes, StringRes, если этот енам используется только в нужном слое, то проблем, имхо, не должно быть)
PA
DrawableRes, StringRes, если этот енам используется только в нужном слое, то проблем, имхо, не должно быть)
Речь не о проблемах. А о чистоте кода.
Проблем то не будет
Проблем то не будет