dagger упрощает вам задачу реализации DI у себя в приложении. Иначе вам придется вручную создавать и прокидывать зависимости. Это значительное уменьшение boilerplate кода. Вот, что самое главное.
Конечно, никто не запрещает вам подменять код через flavors. Но dagger — это не только лишь возможность подмены кода.
Тут уже больше вопрос по архитектуре.
Презентер и зависимый презентер. Почему так? Почему вы решили так разделить? Вообще зачем презентерам знать друг о друге? Их можно связать через локальный «EventBus».
Ну, конечно же. В сабкомпонентах все зависимости от родительского компонента будут доступны автоматом, и не придется тянуть AppComponent, будете только соответствующим сабкомпонентом работать.
Может эта статья прояснит больше — https://habrahabr.ru/company/tcsbank/blog/312196/
То? Или вы несколько про другое?
По поводу «вне Android» не могу сказать, так как не знаю.
Вызовы эти вставлять в зависимости от вашей логики. Обычно в onCreate() Активити или фрагмента.
В любом более-менее серьезном приложении =)
Вы и заметить не успеете, как обрастете классами и разными зависимостями.
Для домашнего проекта, конечно же, это все можно опустить.
К сожалению, ссылку на свои бывшие проекты я дать не могу, NDA. Но уверен, вы бы оценили =)
Если проект небольшой, то все норм. Но если он развивается не первый год, меняются разработчики, то обычно сопровождать код, который черезчур использует паттерн «Наблюдатель», становится тяжко.
Но это сугубо мой опыт.
Все хорошо, если в меру =)
Но раньше было модно все приложение строить на паттерне «Наблюдатель». И все покрывалось сплошным «ЭвентБасом». И часто потом получалась ситуация, когда стреляешь в руку, а попадаешь в ногу. И почему, совсем непонятно.
Высокая связность кода впридачу еще получается. И просто ли такое дело тестировать?
А плохо у вас это в приложение или нет, я не могу сказать :)
Архитектура для мобильного приложения, а конкретно под Андроид — это далеок не архитектура какого-то сложного высоконагруженного сервиса.
Андроид — это все-таки просто клиент, который слушает сервис. Раньше вообще считалось, что под мобильные приложения архитектура так таковая не нужна. Но как показывает жизнь, все-таки нужно грамотно продумывать проект.
Всем минусующим просьба аргументировать, что вам не нравится.
Я написал эту статью не ради рекламы, а ради подготовки к выступлению. Чтобы оно было максимально интересно и полезно.
И если у вас есть то, чем вы недовольны, то поделитесь, пожалуйста.
Либо же создание компонент можно вынести с activity и тому подобных. И все компоненты инициализировать через Application (или вспомогательный класс для Application).
Тогда нам вообще не нужно будет подстраиваться под ЖЦ, и все компоненты будут сосредоточены в специальном классе.
Например, в Application будет такое поле:
private ComponentStorage componentStorage;
А доступ к этому полю будет открыт из любого класса, и примерное обращение к конкретному компоненту будет такое:
Распространена реализация, когда прямо во фрагменте создается компонент и там хранится. Если нужна обработка ЖЦ, то фрагмент делается setRetainInstance(true). Как раз для screen-orientated.
Просто не представляю, как это через Presenter будет выглядеть. Плюс на Presenter ложиться новая ответственность — создание и контроль ЖЦ компонент.
А вы читали первые две статьи? Там я в принципе раскрываю, зачем нужен Даггер и как его готовить.
Конечно, никто не запрещает вам подменять код через flavors. Но dagger — это не только лишь возможность подмены кода.
Презентер и зависимый презентер. Почему так? Почему вы решили так разделить? Вообще зачем презентерам знать друг о друге? Их можно связать через локальный «EventBus».
Может эта статья прояснит больше — https://habrahabr.ru/company/tcsbank/blog/312196/
То? Или вы несколько про другое?
Вызовы эти вставлять в зависимости от вашей логики. Обычно в onCreate() Активити или фрагмента.
Вы и заметить не успеете, как обрастете классами и разными зависимостями.
Для домашнего проекта, конечно же, это все можно опустить.
Попробую разные варианты и добавлю к статье.
Спасибо большое!
FirstModule, а не HelperModule. Абстрактный модуль подключается точно также, как и обычный. Никаких отличий.
Если проект небольшой, то все норм. Но если он развивается не первый год, меняются разработчики, то обычно сопровождать код, который черезчур использует паттерн «Наблюдатель», становится тяжко.
Но это сугубо мой опыт.
Но раньше было модно все приложение строить на паттерне «Наблюдатель». И все покрывалось сплошным «ЭвентБасом». И часто потом получалась ситуация, когда стреляешь в руку, а попадаешь в ногу. И почему, совсем непонятно.
Высокая связность кода впридачу еще получается. И просто ли такое дело тестировать?
А плохо у вас это в приложение или нет, я не могу сказать :)
Андроид — это все-таки просто клиент, который слушает сервис. Раньше вообще считалось, что под мобильные приложения архитектура так таковая не нужна. Но как показывает жизнь, все-таки нужно грамотно продумывать проект.
Я написал эту статью не ради рекламы, а ради подготовки к выступлению. Чтобы оно было максимально интересно и полезно.
И если у вас есть то, чем вы недовольны, то поделитесь, пожалуйста.
Тогда нам вообще не нужно будет подстраиваться под ЖЦ, и все компоненты будут сосредоточены в специальном классе.
Например, в Application будет такое поле:
А доступ к этому полю будет открыт из любого класса, и примерное обращение к конкретному компоненту будет такое:
Но на нас ложиться полностью\контроль ЖЦ компонент. Хотя этот контроль на нас в любом случае.
Но как-то по мне непривычная немного схема. Надо будет пообдумать.
Просто не представляю, как это через Presenter будет выглядеть. Плюс на Presenter ложиться новая ответственность — создание и контроль ЖЦ компонент.