Руслан
Либо я не понял изначально вопрос.
Руслан
Тогда приношу извинения.
Руслан
Это тоже не удобно
Поэтому я написал, что ИМХО. Для меня на практике так гораздо удобнее.
Руслан
И избавляет от потенциальных проблем.
Руслан
Позволяет отделять интерфейс от реализации и инжектить альтернативные реализации одного интерфейса, например.
Руслан
С аннотацией над конструтором такое не факт что возможно, и точно не удобнее.
Sergey
Это создаёт проблемы. Чтобы создать инстанс с помощью провайд метода тебе нужно : - передать в него нужные зависимости как параметры метода - передать эти зависимости в конструктор
Sergey
Да, придётся описывать это в модуле
Руслан
Это создаёт проблемы. Чтобы создать инстанс с помощью провайд метода тебе нужно : - передать в него нужные зависимости как параметры метода - передать эти зависимости в конструктор
Для меня лично не проблема создать @Provides-метод. Зато все зависимости в проекте явно заданы, и в случае чего легко проследить, что откуда подцепляется.
Konstantin
Не совсем осилил...
Руслан
Это создаёт проблемы. Чтобы создать инстанс с помощью провайд метода тебе нужно : - передать в него нужные зависимости как параметры метода - передать эти зависимости в конструктор
Ещё такой пример: у тебя проект разделён на несколько Library-модулей. Если у тебя @Inject в конструкторе, придётся тащить даггер в каждый модуль. А так у тебя все зависимости менеджатся только в одном модуле (app).
Sergey
Инжект это jsr330 аннотация
Руслан
Ну и зачем эти аннотации в библиотеках?
Sergey
Даггер нужен только там, где граф зависимостей собирается - презентейшн модуль
Sergey
Ну и зачем эти аннотации в библиотеках?
Кек, это дефолтная аннотация
Руслан
Нет, зачем они у тебя в зависимых модулях?
Konstantin
И тем не менее что значит "нерабочий"? И почему мутабельный то?
Sergey
Нет, зачем они у тебя в зависимых модулях?
Назови хоть одну причину, почему бы им не быть там
Sergey
Ну ок, даже если так
Sergey
Хорошо Котлин показывает это. Инжект в поле - lateinit var В конструктор - Val
Konstantin
Почему отложенная инициализация это плохо?
Sergey
Ты не имеешь доступа к конструктору Активити
Sergey
Поэтому остаётся только инжектировать в поля
Sergey
Что плохо
Никита 🙃
В том же Мокси презентер же lateinit объявляется.
Никита 🙃
А что именно с lateinit не так?
Руслан
Назови хоть одну причину, почему бы им не быть там
Да хотя бы для сохранения их самостоятельности и независимости от внешних фреймворков. Зачем в классах в рандомном модуле, который по идее должно быть можно подключить к любому проекту, всякие @Inject над классами? Поправь, если я ошибаюсь, но даггеровский annotation processor всё равно придётся протащить в такие модули, если у тебя @Inject над конструтором.
Sergey
В том же Мокси презентер же lateinit объявляется.
И требует конструктор по умолчанию, как следствие
Sergey
Ну есть костыли длч таких случаев, че 😂
Руслан
Inject - для неё ничего тащить не нужно. Это не даггеровская аннотация
Был уверен, что даггер не сгенерит код для library-модулей, если в него не протащить его annotation processor
Руслан
#Singleton тоже jsr330
Я не про аннотации, а про кодогенерёжку.
Sergey
Не, у него зависимости в конструкторе. Просто он каждую зависимость провайдит в модуле
Руслан
Как раз наоборот, ты это явно определяешь, read the thread, речь не об инжектах в филды
Руслан
Вообще не понимаю, откуда это всплыло
Sergey
И часто у тебя такая потребность ?
Sergey
Для всего свой подход. Конечно в таких случаях нужно метод в модуле описывать. Но это скорее исключение, чем правило. Как и инжекты в поля
Валерий
setClickable(false) или переопределить onTouchListener
Konstantin
setEnabled
Konstantin
Альфа это прозрачность
Валерий
Нет, это логика
Konstantin
Это сделает ее не реагирующим на клики.
Валерий
А альфа — отображение
Sergey
SetEnabled(false) ну
Konstantin
Зачем тогда спрашивать
Sergey
Нужно чтобы не доходили клики до чайлдов?
Konstantin
Ты на все вьюхи внутри лейаута выставил setEnabled false?
Sergey
Попробуй ещё setClicable(false), либо тач лисенер переопредели у контейнера и верни true в методе
CH1LL
Можно как-то изменить цвет фона диалога спиннера?
Валерий
Это немного другое)
CH1LL
Не, не работает
Валерий
Проще сразу закрыть лэйаут другим таким же
CH1LL
Я немного нуб в андройдах, можно подробней?
Валерий
Ну они как бы не для такого сделаны
Руслан
Представляю эти огромные модули...
Разбиваешь по фичам или скоупам — всё становится коротко и аккуратенько. Но опять-таки главное, что всё в одном месте, легко находится, легко модифицируется.
CH1LL
Не работает. У меня не попап, а диалог
Валерий
Это да, так правильно Только не обобщённо)
Валерий
Самсунг и сяоми это вообще гроб гроб кладбище пидор
CH1LL
Какой именно?
ну стайл спиннера диалог
Руслан
Для всего свой подход. Конечно в таких случаях нужно метод в модуле описывать. Но это скорее исключение, чем правило. Как и инжекты в поля
Кстати, консистентность — ещё один довод в пользу Only Modules: у тебя не будет такого, что часть зависимостей определена в @Provides-методах, а часть — аннотациями над конструкторами, и поди ищи потом.
Валерий
Валерий
Оу, ясно Такое не трогал
Валерий
А
Валерий
Всё, туплю
CH1LL
Как создаёшь?
Да как обычно. Просто в свойствах спиннера поставил стайл спиннера как диалог
Валерий
Это который выпадающий список же? Там можно скормить любой лэйаут вроде как и оно его съест Соответственно берёшь и кормишь с нужным цветом Но я давно его не трогал, могу ошибаться
Andrew
Господа, может быть кто-нибудь подскажет, как менять цвет текста в status bar'e?
Вадим
Andrew
<item name="android:statusBarColor">@color/my_color</item> с api 23
А это разве не изменение background'а статус бара?
Вадим
А это разве не изменение background'а статус бара?
сори, не увидел, что нужен текст. он сам подстраивается, но точно не знаю
Andrew
Andrew
Мне нужно, чтобы как в инсте текст был не белый, а темный
Вадим
сделай бг такого же цвета