- Java 双重比较
- java - 比较器与 Apache BeanComparator
- Objective-C 完成 block 导致额外的方法调用?
- database - RESTful URI 是否应该公开数据库主键?
我成功地使用了 Qualified field injection construct injection 和 method injection,我期望从 dagger 2.10 开始将依赖注入(inject)到 Qualified 方法,如下代码:
public class MainActivity extends AppCompatActivity {
@Override protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
DaggerMainActivityComponent.create().inject(this);
}
@Named("firstName")
@Inject
void initFirstName(String firstName){
}
@Named("lastName")
@Inject
void initLastName(String lastName){
}
@Module public class UserModule {
@Named("firstName")
@Provides
String provideFirstUserName() {
return "Nasser";
}
@Named("lastName")
@Provides
String provideLastUserName() {
return "Khosravi";
}
}
@Component(modules = { UserModule.class})
public interface MainActivityComponent {
void inject(MainActivity mainActivity);
@Named("firstName")
String getFirstName();
@Named("lastName")
String getLastName();
}
}
但是当我使用这段代码时,我得到:
java.lang.String 不能在没有 @Inject 构造函数或 @Provides- 或 @Produces- 注释的方法的情况下提供。
网上有很多关于 Dagger 的简单教程,但它们都是一样的,我找不到任何关于合格方法注入(inject)的示例。
我更喜欢方法注入(inject)而不是字段注入(inject),因为它是:
是否有可能在 Dagger 2 中注入(inject)合格的方法?或者我对方法注入(inject)的期望是错误的?
如果可能,我该如何实现?
感谢您的任何建议。
最佳答案
您快完成了,但您可能需要弄清楚一些事情:
什么由 @Named
限定注解?依赖项(不是方法)是合格的。
谁可以接收合格的依赖项?构造函数、字段或方法。
方法如何接收合格的依赖项?
与构造函数接收合格依赖项的方式相同:
@Inject
void initFirstName(@Named("firstName") String firstName) {
//
}
注意方法本身是不合格的,但是方法接收的参数是合格的。
为什么我们应该使用方法注入(inject)?
您的用例可能不太适合方法注入(inject)。一个好的用例是您希望在调用构造函数后立即执行方法(例如设置监听器)。您可以这样做以避免 this
在构造函数中转义的引用。参见 this question寻求解释。
you can simply set breack point and debug value injected
如果你想调试,你总是可以在调用 inject()
之后设置一个断点。组件的方法并使用 Alt-F8 检查注入(inject)点的字段。
Android 的最佳实践是在 Activity、Fragment 和其他操作系统实例化的类中使用字段注入(inject)。然后对存储库、数据源等依赖项使用构造函数注入(inject)。
如果您遵循注入(inject)的最佳实践,那么您的代码将更容易被其他程序员遵循,您也将更容易在 StackOverflow 上获得帮助。
相关:
关于java - Dagger 2 中的合格方法注入(inject),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45860217/
我是 DDD 的新手,正在考虑在我的项目中使用这种设计技术。 然而,让我对 DDD 印象深刻的是这个想法是多么的基本。与 MVC 和 TDD 等其他设计技术不同,它似乎不包含任何突破性的想法。 例如,
我正在尝试理解 elementFormDefault="qualified/unqualified" 的含义在嵌入 WSDL(SOAP 1.1、WSDL 1)的 XML 模式中。 例如,我在 WSDL
我有一段代码,它使用 iostreams 的 xalloc 和 pword 将各种类型的标志存储为指针。由于 pword 公开了一个 void*&,我有一个简单的包装器来通过旧的 C 转换公开存储的类
我是一名优秀的程序员,十分优秀!