Я не предлагал реальное api тестить, я предлагал внутри Dagger заменять реализацию сервера

Но как я понял, Dagger оказывается используется не для этого, но для чего тогда?

тогда я не так тебя понял )

но да, даггер не нужен )

Я не предлагал реальное api тестить, я предлагал внутри Dagger заменять реализацию сервера

Я кстати почему-то раньше тоже думал, что так надо делать. Но señor сказал, что не, херня

Для реализации паттерна DI

Для реализации паттерна DI

Зачем?

Зачем?

понты

Бля я же выше писал

Вот

Для того что-бы код был тестируемый необходимо кодить следуя неким правилам, например: Принципы инверсии управления 1. Модули верхних уровней не должны зависеть от модулей нижних уровней. Модули обоих уровней должны зависеть от абстракций. 2. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций. Недостатки дизайна, которые устраняются с применением Инверсии управления 1. Жесткость. Изменение одного модуля ведет к изменению других модулей. 2. Хрупкость. Изменения в одной части приводят к неконтролируемым ошибкам в других частях программы. 3. Неподвижность. Модуль сложно отделить от остальной части приложения для повторного использования и тестирования P.S. плюс не забывать по максимуму абстрагироваться от Android фреймворка

Бля я же выше писал

Так это без Dagger реализуется в разы легче используя обычный паттерн DI

Но если вы считаете что это все херня то мне нечего добавить)

как это делать расскажи?

Так это без Dagger реализуется в разы легче используя обычный паттерн DI

И скоупы? + Весь код по созданию и прлвайдингу зависимостей отдельно вынесен

как это делать расскажи?

Разделитель - "|" текст слева будет слева прижат, справа - справа если RTL - то наоборот

здорово, спасибо

здорово, спасибо

Пожалуйста, там кроме этого, вроде ничего не задето, так что все любимые темы,стили,размеры работают как обычно...единственное но! осторожнее с арабским, помнится с ним иногда чп происходили, даже крэши

И скоупы? + Весь код по созданию и прлвайдингу зависимостей отдельно вынесен

Я ещё не прочуствовал всю значимость скоупов

Я ещё не прочуствовал всю значимость скоупов

Ну и код по созданию и провайдингу зависимостей вынесен отдельно, что тоже очень удобно

А использование в тестах и подмена модулей - это уже больше как приятный бонус

Я ещё не прочуствовал всю значимость скоупов

Что-то вроде завязки продолжительности жизни элемента в зависимости от того, куда провайдится, вроде. Поправьте, если не прав

Что-то вроде завязки продолжительности жизни элемента в зависимости от того, куда провайдится, вроде. Поправьте, если не прав

Да, я знаю, что они контроллируют время уничтожение объектов, просто не ощущаю никакой пользы от них

Пока что моё понимание Dagger 2 такое: для абстракции

Ну и код по созданию и провайдингу зависимостей вынесен отдельно, что тоже очень удобно

То, что ты скидывал мне кажется касается больше DI нежели конкретно Dagger 2

Так dagger это не DI фреймворк?

Все, я устал

В некоторых случаях можно использовать lazy инициализацию зависимостей

Что я не могу сделать без Dagger? Какие преимущества он предоставляет относитьльно классического DI паттерна?

Я применял

Просто раньше я воспринимал Dagger как связку паттернов Factory + DI, тогда я её реально высоко ценил

Что я не могу сделать без Dagger? Какие преимущества он предоставляет относитьльно классического DI паттерна?

Он нужен становится когда большой граф зависимостей. Всё

Он нужен становится когда большой граф зависимостей. Всё

Ооо, вот это уже больше похоже на правду

Он нужен становится когда большой граф зависимостей. Всё

Но все же по возможности нужно использовать lazy Это ускоряет холодную загрузку приложения

Он нужен становится когда большой граф зависимостей. Всё

То есть при большом графе зависимостей с Dagger мне не придётся копаться в лишних строчках кода, если я хочу посмотреть зависимости, а просто захожу в модули Daggerа

То есть при большом графе зависимостей с Dagger мне не придётся копаться в лишних строчках кода, если я хочу посмотреть зависимости, а просто захожу в модули Daggerа

Ну типа. Видел даже утилитку для визуализации, но не юзал

Сегодня перевернулся мой мир видения Dagger

Спасибо вам

А какой смысл все оборачивать? Если у вас на экране три кнопки и на каждую из них нужно выполнить отдельное действие, то действие можно инкапсулировать в объект и заинжектить как lazy Вы же не знаете что юзер нажмёт на все три кнопки..

всем привет. Щепитильный вопрос возник. Кто знает бест практис по загрузке средних, скажем так, битмапов в нотификацию?

Ну типа. Видел даже утилитку для визуализации, но не юзал

Да, плагин есть для студии

Сегодня перевернулся мой мир видения Dagger

Хз. Насколько я прав. Но я для себя именно с целью унификации инициализации всякой фигни взял. Ибо команда начала плодить синглтоны и статики

Да, плагин есть для студии

Это который на ноде или новый завезли?

Это который на ноде или новый завезли?

Я других не видел

Это который на ноде или новый завезли?

Не понял что имеется ввиду на ноде? В студии на джаве работает

Не понял что имеется ввиду на ноде? В студии на джаве работает

А. Ну я видел утилиту на node.js для визуализации графа

Надо ставить через npm и т.п.

А. Ну я видел утилиту на node.js для визуализации графа

А, не, я про плагин для быстрого перехода по графу Но без визуализации

Тестить отправку результата на сервер (на ТЕСТОВЫЙ сервер) нужно в JUnit тестах, верно?

Я подменяю реализацию сервера через DI без Daggerа и получаю результаты из тестового сервера, верно?

Может у меня ещё раз перевернётся картина видения этого мира)

Кстати, интересно. Как люди делают интеграционные тесты. Ведь надо чистый сервер развернуть, создать на нем нужные данные и потом андроид к нему приводить

Что нет?

То есть я должен использовать Dagger в JUnit тестах?

Presenter

Он создаёт зависимости внутри Presenter

Логично ведь

Нужно инжектить зависимости в конструктор

Он создаёт зависимости внутри Presenter

Вот ты их все должен мокнуть

Вот правильно)) А теперь что я говорил в начале...

Я подменяю реализацию сервера через DI без Daggerа и получаю результаты из тестового сервера, верно?

Смотря где он впервые вызывается Если в onCreate то нет смысла использовать lazy

Слыхали за продюсеров в даггере? Я так понял это не к мобилкам на вооружение.. Или же есть смысл использовать?

Походу я лишь на словах не пойму, нужен пример

Буду очень благодарен

Подскажите, пожалуйста, в чем может быть проблема, он же уже умеет на русском говорить)

Я подменяю реализацию сервера через DI без Daggerа и получаю результаты из тестового сервера, верно?

Если это юниттест - да

“Instrumentation testing with MockWebServer and Dagger2” https://medium.com/mindorks/instrumentation-testing-with-mockwebserver-and-dagger2-56778477f0cf

“Instrumentation testing with MockWebServer and Dagger2” https://medium.com/mindorks/instrumentation-testing-with-mockwebserver-and-dagger2-56778477f0cf

Вот тут даггер уместен

Что такое флейвор?

Это вообще высший пилотаж

Понятно, спасибо)

Ну да Но я о таком даже не думал)) Флевор для тестового сервера. Кулл в модуле типо if (BuildConfig.DEBUG) return одно else return другое?

Кул спс за идею

Билд type

Бля Точно билд)

Сырые ресурсы, которые будут переданы в Dagger и mock, который я буду передавать в тестах - это разные вещи?

А есть пример такого на каком нибудь проекте?

А зачем.. есть же полиморфизм..