статический метод.

даю приложение с некоторыми функциями: ContentProvider, SyncAdapter, сервис Job и связанная логика персистентности. Сверху на них есть Действия с пользовательским интерфейсом. Я пытаюсь поместить все упомянутые функции в отдельный библиотечный модуль, потому что в теории их логика является автономной и может быть повторно использована любым приложением.

Теперь идет Dagger2. Первый узел (основной Компонент) графа зависимостей моей библиотеки должен обеспечивать Контекст, и этот Контекст должен быть внедрен из Приложения, потому что область действия библиотеки имеет тот же жизненный цикл приложения. Очевидно, что моя библиотека не должна напрямую использовать мой класс Application.

Вот те возможности, о которых я подумал:

Создайте основной компонент библиотеки в моем приложении и сохраните его в глобальном статическом классе / перечислении, как это предлагаетсяВот но я обеспокоен тем, что использование такой статической ссылки может быть анти-паттерном.Запакуйте в библиотеку класс Application, который создает компонент уровня библиотеки, приведите контекст приложения к этому классу в библиотеке, чтобы использовать компонент, а затем расширьте этот класс Application в основном приложении. Это работает, но если есть больше чем одна библиотека, это больше не жизнеспособно.Используйте шаблон фабрики: поместите методы обеспечения в компонент библиотеки, которые предоставляют фабрику, которая в свою очередь получает локально доступный контекст в качестве параметра. (Как объяснилиВот). Это кажется жизнеспособным, хотя и добавляет дополнительную сложность.И последнее, но не менее важное: откажитесь от попыток модульности компонентов, поскольку зависимость от контекста приложения нарушает концепцию модульности.

Как правильно это сделать?

Ответы на вопрос(1)

Ваш ответ на вопрос