2016-12-22 7 views
4

У меня есть следующие зависимости в приложении для Android. Каков наилучший подход для этого в кинжале 2?Должен ли я использовать один компонент для каждой операции в кинжале 2?

Activity A ---- Adapter A and Adapter B and SharedPreferences 
Activity B ---- Adapter B and SharedPreferences 
Activity C ---- Adapter C and SharedPreferences 

Должен ли я составлять отдельный компонент для каждой деятельности? Должны ли быть три отдельных компонента?

+0

Как 'AdapterA',' AdapterB' и 'AdapterC' связанных? Все ли они одного типа? –

+0

@DavidRawson: нет этих адаптеров не связаны – Tushar

ответ

7

Существует некоторая путаница в отношении роли компонентов и модулей в кинжале 2 в приложении для Android. Компоненты предназначены для группировки подобных жизненных циклов. Модули могут быть организованы по функциональным линиям и для тестирования (согласно official instructions for testing). Вот некоторые из лучших примеров этого: Google Android Architecture Blueprints Github repo. Если вы изучите исходный код, вы увидите, что есть один компонент с областью приложения (с жизненным циклом продолжительности всего приложения), а затем отдельные компоненты с областью действия для Activity и Fragment, соответствующие определенной функциональности в проект. Разумеется, компоненты с областью действия будут иметь жизненный цикл, соответствующий их соответствующей Деятельности.

Перейдем к вашему конкретному варианту использования. Хотя один из компонентов с областью действия, который может вводить все зависимости для действий А, В и С, может быть приемлемым для простого примера в вопросе, ситуация будет быстро усложняться, если изменения требований и активность А внезапно потребуют новой зависимости с сложный граф объектов. Затем вам нужно будет создать новый модуль для новой зависимости, который будет полезен только для одного из трех сайтов инъекций в вашем компоненте. Это, в свою очередь, усложнит тестирование, если вы используете макетный компонент для проверки активности B и активности C.

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

Для примера вы указали, я бы создать приложение-компонент: область действия

@Component(modules = { SharedPreferencesModule.class }) 
@PerApp 
interface AppComponent { 

    SharedPreferences sharedPreferences(Application app); 

} 

Вы можете иметь ваши компоненты Активности становятся зависимыми компонентами компоненты приложения. Таким образом, они не будут иметь дело с SharedPreferences, так как это связано в приложение-компоненты и подвергаются воздействию иждивенцев:

@Component(dependencies = { AppComponent.class }, modules = { AdapterAModule.class }) 
@PerActivity 
interface ActivityAComponent { 

} 
+0

Чтобы уточнить, если у меня есть ActivityB, чем я создаю ActivityComponent, ActivityBModule, но также и их область видимости PerActivity, правильно? Как насчет фрагментов? Должен ли я также создавать компоненты для каждого фрагмента, но может ли их охватить с помощью области PerFragment? – hkop

+1

@hkop да, это звучит прекрасно - посмотрите на связанную репетицию Github –