Silent829
у меня ж везде стоит @Provides, в чем дело? Подскажите
Silent829
Silent829
Silent829
Silent829
Vitaly
Где стоит Provides у UserLocalApiService?
Vitaly
На будущее Тебе не нужен Provides для создания объектов через конструктор Используй Binds
Silent829
Где стоит Provides у UserLocalApiService?
я думал тут, не? я добавил скрин с ремоутом потому что там также все написано
Silent829
На будущее Тебе не нужен Provides для создания объектов через конструктор Используй Binds
везде поменять сейчас? и почему @Binds предпочтитетельней @Provides?
Vitaly
везде поменять сейчас? и почему @Binds предпочтитетельней @Provides?
Сейчас не стоит менять везде на Binds, лучше сначала решить проблему Но на будущее Binds предпочтительнее, так как он вносит больше структуры в код А сам Binds выглядит проще, чем куча Provides
Vitaly
UserLocalDataSource
Silent829
Какой тип возвращает метод?
интерфейс UserLocalDataSource
Vitaly
А Dagger ждёт UserLocalApiService
Vitaly
А Dagger ждёт UserLocalApiService
Напиши метод который будет возвращать в точности этот тип
Silent829
блин я вообще намудрил сильно с этими датасорсами, репозиториями и ApiService-ами
Vitaly
Тебе кроме Room Dao, Retrofit Service, Repository больше ничего не нужно для получения данных Мне кажется, что у тебя приложение поменьше, чем Сбербанк, чтобы использовать DataSource'ы В большинстве случаев они не нужны
Silent829
@infinity_coder У меня вообще такие мысли - вьюмодель получает откуда-то данные, ей неважно откуда ведь да? Это может локальный источник, а может быть удаленный источник. Но локально вообще тоже можно по-разному получать данные, как и удаленно. Поэтому тут идет разветвление следующее: DataSource < == RDataSource < == RDataSourceThis, RDataSourceThat ^ || LDataSource ^ || LDataSourceThis, LDataSourceThat
Silent829
https://bit.ly/2GQRdzz вот тут у чувака зависимость дао как интерфейс (локально), а RemoteDataSource (удаленно) - класс, а не интерфейс. Странно
Vitaly
Я понимаю, что в статьях написано много умных мыслей и они даже обоснованы Когда был джуном сам часто кидался всякими умными статьями Но на практике надо писать максимально просто То есть сделай сначала базовое ветвление, отделив данные, логику приложения и View На этом этапе у тебя получилось MVVM, где на уровне View - Activity/Fragment, на уровне логики приложения ViewModel, которая хранит состояние, на уровне Model - Retrofit Service, Room Dao Важно, что пока ничего покрывать интерфейсом не надо! Это только путает Идём дальше, нам понадобилось кешировать данные. Например, у нас такая логика: получаем данные из БД, показываем эти данные, грузим из сети, сохраняем в БД, показываем из БД Появилась логика получения данных Отлично, значит мы можем заюзать Repository и работать через него Нам нужно всё приложение покрывать тестами? Хорошо, а какие конкретно объекты мы будем заменять на моки? Repository? Значит его покроем интерфейсом. Если не будем писать юнит тесты, значит оставляем Repository в виде object Приложение не просто тонкий клиент, а ещё и хранит много бизнес-логики? Значит добавляем Interactor В приложении есть необходимость постоянно менять реализацию хранения БД? Например, вместо Room использовать GreenDao? Значит можно заюзать DataSource Или заюзать DataSource, когда есть очень много логики в Repository. Например, ты реализуешь пагинацию И так далее. В общем принцип такой, что нужно максимально упрощать код, не забывая про здравый смысл
Vitaly
https://bit.ly/2GQRdzz вот тут у чувака зависимость дао как интерфейс (локально), а RemoteDataSource (удаленно) - класс, а не интерфейс. Странно
Да, я читал эту статейку Но лучше научиться сначала работать с чем-то более простым
Silent829
Я понимаю, что в статьях написано много умных мыслей и они даже обоснованы Когда был джуном сам часто кидался всякими умными статьями Но на практике надо писать максимально просто То есть сделай сначала базовое ветвление, отделив данные, логику приложения и View На этом этапе у тебя получилось MVVM, где на уровне View - Activity/Fragment, на уровне логики приложения ViewModel, которая хранит состояние, на уровне Model - Retrofit Service, Room Dao Важно, что пока ничего покрывать интерфейсом не надо! Это только путает Идём дальше, нам понадобилось кешировать данные. Например, у нас такая логика: получаем данные из БД, показываем эти данные, грузим из сети, сохраняем в БД, показываем из БД Появилась логика получения данных Отлично, значит мы можем заюзать Repository и работать через него Нам нужно всё приложение покрывать тестами? Хорошо, а какие конкретно объекты мы будем заменять на моки? Repository? Значит его покроем интерфейсом. Если не будем писать юнит тесты, значит оставляем Repository в виде object Приложение не просто тонкий клиент, а ещё и хранит много бизнес-логики? Значит добавляем Interactor В приложении есть необходимость постоянно менять реализацию хранения БД? Например, вместо Room использовать GreenDao? Значит можно заюзать DataSource Или заюзать DataSource, когда есть очень много логики в Repository. Например, ты реализуешь пагинацию И так далее. В общем принцип такой, что нужно максимально упрощать код, не забывая про здравый смысл
ну я просто заранее хочу быть готовым поэтому скейлю, легче опять же тестить, мокать, одним движением заменять и ничего не давит на нервную систему. Согласен, нужно находить баланс и ставить деплой в приоритет
Silent829
Получилось добавить Provides?
я еще не билдил пока
Silent829
Получилось добавить Provides?
Виталий, а мне же для этого надо будет все модули сделать абстрактными классами, а не объектами и у моих функций не будет реализаций
Silent829
я же скипать буду ее. ну да хилт сам поймет как ее биндить нужно. сейчас сделаю
Silent829
тем более все эти сервисы и остальное в моих сорсах.
Vitaly
Виталий, а мне же для этого надо будет все модули сделать абстрактными классами, а не объектами и у моих функций не будет реализаций
По поводу реализаций не понял Но если хочешь юзать Binds, то нужно использовать абстрактный класс или интерфейс
Vitaly
У функций с Binds реализаций не будет
Silent829
У функций с Binds реализаций не будет
а вот когда она нужна как быть?
Silent829
в абстрактном классе могут же быть оба @Binds и @Provides? Или только @Binds без реализации?
Vitaly
а вот когда она нужна как быть?
Вот когда нужна реализация, тогда используешь Provides Например, для создания Retrofit экземпляра
Vitaly
в абстрактном классе могут же быть оба @Binds и @Provides? Или только @Binds без реализации?
В Java может В Kotlin есть какие-то свои особенности, сейчас не смогу точно подсказать
Vitaly
Точнее именно касательно Dagger у Kotlin свои особенности
Silent829
@infinity_coder :D
Nikita
в котлине надо выносить @Provides в компаньон и его помечать как @Module, а сами методы как @JvmStatic
Dmitry
в котлине надо выносить @Provides в компаньон и его помечать как @Module, а сами методы как @JvmStatic
это же требование в последнее версии даггера появилось? кстати а без компаньона никак нельзя теперь, да?
Nikita
@infinity_coder :D
Ну так логично же, если методы абстрактные, то класс модуля абстрактный. Даггер не создаст инстанс абстрактного класса => нет смысла не от статических
Nikita
это же требование в последнее версии даггера появилось? кстати а без компаньона никак нельзя теперь, да?
Не подскажу в какой версии даггера появилось, но помню что уже довольно давно так делал) Поэтому просто стараюсь писать всякие модули на джаве и делать их по максимуму абстрактными
Vitaly
Вообще действительно Dagger больше для Java В Kotlin он совсем не юзаюельный, поэтому перестал его использовать
Nikita
в таком случае лучше на джаве переписать или как выше сказано было в companion object вынести все?
Ну лично я не вижу смысла в модулях на котлине, так что писал бы их на джаве)
Vitaly
а что там юзабельно?) хилт на даггере построен
Koin, Kodein, Toothpick поприятнее выглядит, но я DI руками пишу
Silent829
Koin, Kodein, Toothpick поприятнее выглядит, но я DI руками пишу
понял) но печально конечно что гугловые решения так скозатб из коробки нерабочими считаются
Vitaly
Почти весь Jetpack 😂
Silent829
я тупой, я же сделал это же в своем наследнике RoomDatabase( )
Nikita
внутри @Module abstract class @Module companion object, я же правильно понял?
Видимо зависит от версии даггера, с 2.26 больше не нужен модуль у компаньона
Nikita
https://github.com/google/dagger/releases/tag/dagger-2.26
Nikita
ага, удобно!
Silent829
благодарю Никита!
RgiN✙
работает на всех устройствах кроме китайских
Что ты подразумеваешь под Китайскими, андроид везде один, прошивки как обвертки от конфет только меняются А человек не может тебе логкат скинуть?)
M
Тут мужик про RecyclerView рассказывает. https://youtu.be/GZkTwgetUWI. На 3:20 говорит про setHasFixedSize. “Список сообщений на весь экран, поэтому можем выставить true”. Разве можно? На экране чата ведь еще клавиатура появляется и размер списка меняется.
Денис
M
работает на всех устройствах кроме китайских
Ты не проверяешь есть ли в системе кто-то, кто может обработать твой Intent
Adam-Nurbol
Всем привет! Есть локейшн сервис. Как можно не дать ему умереть в фоне?
Adam-Nurbol
Foreground.
А мне надо чтобы работал в фоне. Потому что пользователь может свернуть апп.
M
хм.
Но я, четно говоря, не помню должно ли приложение из-за этого крашиться. Вот тут показано как проверять https://stackoverflow.com/questions/15407502/how-to-check-if-an-intent-can-be-handled-from-some-activity
M
Вот та модель
А крашлитики нет?
Денис
Вот та модель
Хоть и стоит intent.putExtra(Intent.EXTRA_ALLOW_MULTIPLE, true); а у него как будто false, не выбора нескольких фото