Андроид / Кинжал 2. Введение различных подклассов во фрагмент в зависимости от состояния

У вас есть, как я вижу, три решения разной степени тяжести.

Если вы заранее знаете все варианты использования вашего фрагмента, и вам не нужно изменять графики зависимостей больше, чем на одном классе, вы можете сделать это легко, используя аналогичный метод, который у вас есть сейчас. В моем варианте используются провайдеры , которые автоматически привязываются к любому объекту в вашем графе , чтобы вы не создавали без необходимости целые деревья объектов; кроме того, @ Inject методы могут принимать произвольный список параметров, так что вы можете сделать все инъекции метода в одном методе, если вы выбираете.

@Inject
public void setPresenter(
        @NonNull Provider<ContactsPresenter> contactsPresenterProvider,
        @NonNull Provider<ProfilePresenter> profilePresenterProvider) {
    if (mAdapter instanceof ContactsAdapter) {
        this.presenter = contactsPresenterProvider.get();
    } else if (mAdapter instanceof ProfileAdapter) {
        this.presenter = profilePresenterProvider.get();
    }
}

Два других решения включают в себя несколько компонентов: вместо того, чтобы сказать: "есть один способ связать мой граф вместе", вы фактически просите Dagger создать несколько вариантов для вас, что означает, что ваши графики могут сильно отличаться, но оставаться последовательными. Этот метод может быть более полезным, если вы повторно используете объекты разными способами для разных целей. разделы вашего приложения, например, если у вас есть раздел профиля и раздел контактов, каждый из которых использует общий a, вводящий общий B, вводящий общий C, вводящий другой D. Для последовательной поддержки двух глубоких графов, таких как этот, дочерние компоненты являются гораздо лучшим вариантом.

Используйте зависимости компонентов: как и в ответе rst, вы можете использовать зависимости компонентов для изоляции ваших фрагментов. Они довольно хорошо объяснили, так что я не буду повторяться. это здесь. Однако следует помнить, что зависимости компонентов могут использовать только те привязки, которые доступны для компонента, от которого вы зависите: даже если Foo и Bar связаны с DiComponent, вы не сможете получить к ним доступ из вашего ProfileComponent или ContactsComponent, если вы не поместите Foo getFoo() и Bar getBar() на свой DiComponent. (Тем не менее, зависимости компонентов не обязательно должны быть компонентами Dagger; они могут быть произвольными типами, которые вы реализуете самостоятельно или позволяете реализовать Dagger для ты.)

Использование субкомпонентов: хотя впервые упоминаются субкомпоненты , я думаю, что они заслуживают немного большего объяснения, особенно потому, что они являются основным компонентом недавно выпущенного кинжала .функциональность android, а также потому, что фрагменты и другие части пользовательского интерфейса могут быть трудно извлечь с зависимостями компонентов-субкомпоненты неявно и автоматически наследуют привязки от окружающего компонента, поэтому вам не нужно явно выставлять привязки на вашем компьютере. Дикомпонент. Смотрите другие различия в этом так называемом вопросе.

@Component
public interface DiComponent {
    ProfileComponent getProfileComponent();    // Dagger generates implementations
    ContactsComponent getContactsComponent();  // as part of DiComponent.
}

@Subcomponent(modules={ContactsModule.class})
public interface ContactsComponent {
    void inject(MyFragment myFragment);
}

@Module
public interface ContactsModule {
    @Binds MvpPresenter bindMvpPresenter(ContactsPresenter contactsPresenter);
}

@Subcomponent(modules={ProfileModule.class})
public interface ProfileComponent {
    void inject(MyFragment myFragment);
}

@Module
public interface ProfileModule {
    @Binds MvpPresenter bindMvpPresenter(ProfilePresenter profilePresenter);
}

В приведенном выше примере корневой Дикомпонент не имеет привязки к MvpPresenter, поэтому сам по себе он не может вводить MyFragment. Однако ProfileComponent и ContactsComponent могут, и каждый будет использовать различные графики, настроенные в соответствующих модулях (но молчаливо наследуя общие привязки от модулей DiComponent). Если графики изменяются по-разному дальше вниз, как с каждым MvpPresenter, использующим тот же валидатор но с другим ProfileValidationRule по сравнению с ContactsValidationRule, вы можете привязать ValidationRule к этим различным классам в ваших различных модулях, чтобы получить различное поведение.

(для полноты, вы обычно также можете использовать завод, как AutoFactory и передайте такой параметр, как presenter, в ваш конкретный контейнер, например Fragment. Тем не менее, это только действительно вариант, если вы создаете свои экземпляры, и не совсем вариант, когда Android заставляет открытый конструктор zero-arg, чтобы он мог создавать экземпляры фрагментов по своему желанию.)