inject LockManager в AuthManager и на оборот. Как можно решить данную проблему?
[Dagger/DependencyCycle] Found a dependency cycle:
public interface ApplicationComponent {
^
com.example.data.AuthManager is injected at
com.example.di.ApplicationModule.provideLockManager(�, authManager)
com.example.data.LockManager is injected at
com.example.data.AuthManager.mLockManager
com.example.data.AuthManager is requested at
com.example.di.ApplicationComponent.authManager()
Может быть, сделать объект, который содержит оба этих класса? Вот его и инжектить куда попало, чтобы не было circular reference.
Как альтернатива у меня есть решение. Я не буду inject LockManager в AuthManager. Мне LockManager в AuthManager нужен для очистки данных при logout. Место этого я просто очищу его на примую через PreferencesHelper. Я просто хотел узнать можно ли как-то такие случаи решить ?
Не могу подсказать, я пока обхожусь без даггеров.
ОК, спасибо
Обходиться без даггеров к примеру? Даггер не нужен (с)
Даже без дагера не очень идея. А то что он ругается понятно и логично.
Может быть, я не умею готовить даггеры, но у меня ни разу не возникло необходимости что-то куда-то инжектить с помощью подобных библиотек.
Я так понял аутх менеджер сообщает о логауте и другой менеджер чистит базы например. То зачем инектить аутх в логаут менеджер?
LockManager есть свои методы разные в одном из них он узнает через AuthManager авторизован ли пользователь. Так же у AuthManager есть разные методы в одном из них он вызывает clear у LockManager.
А аутх разве не должен сам знать это (судя по его названию). А лок менеджер исполнитель скорее команды на очистку. Ну я просто вижу, что локманаджер слишком много умеет, а аутх не умеет то, что должен. Но эт моё имхо.
Ну как по мне LockManager исполнитель. AuthManager говорит при logout LockManager что нужно очистить данные.
Да. Тогда зачем ему аутх как зависимость. Пришла команда на логаут, чистим и выходим. Это не его задача там чёт проверять его задача очистить.
LockManager есть метод isShowLockScreen в котором есть условие, что есть ли у пользователя pin code или pattern и авторизован ли он. Именно авторизован ли пользователь берётся через AuthManager
Я же не отрицаю, что там есть такие методы я просто предложил мейби стоит подумать над зависимостями и над задачами которые решают классы.
Sergey у меня как вариант есть вот это идея
Ну просто если по вопросу Di то получается даггер должен создать сущность прокинуть ей зависимость для которой требуется эта же сущность для которой... И тут мне кажется сразу становится видно, что взаимоотношения чёт как то не очень.
Да, согласен. Надо подумать
Обсуждают сегодня