我正在将Dagger添加到我的旧版Android应用程序中，并试图弄清楚如何处理依赖非Dagger对象的依赖关系，这些依赖关系是在正常应用初始化期间创建的，但是在后台+不活动之后的活动重新启动期间不会重新创建。

现有代码

在旧代码中，在身份验证代码路径中，我们构造了一个“会话”对象，其中包含令牌和创建经过身份验证的Retrofit对象所需的其他内容。 某些活动依赖于存在的会话对象，并且用户没有通过身份验证代码路径的常规方式无法到达它们。 但是，如果应用程序变为非活动状态，然后在以后恢复，则平台将尝试直接重新创建活动，而不经过身份验证代码路径，因此会话对象将为null。

为了避免这种情况，从历史上看，每个依赖于登录的活动都源自“ SessionActivity”，其onCreate检查我们是否已登录，是否完成活动并启动应用程序的入口点。 （这将触发“会话”对象的重新创建；用户将不得不再次导航回到该屏幕，但至少没有崩溃）

class SessionActivity {

@Override
protected void onCreate(Bundle savedInstanceState)
{
    super.onCreate(savedInstanceState);

    if( LegacySingleton.getInstance().session == null ) {
    {
        Intent intent = new Intent(this, LauncherActivity.class);
        intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
        intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        startActivity(intent);
        finish();
        return;
    }
}

}

新密码

我现在添加Dagger，并希望能够注入使用该会话对象构建的Retrofit对象。

@Provides
fun provideRetrofit(): Retrofit {
    return LegacySingleton.getInstance().session!!.authenticatedRetrofit
}

然后一个依赖于登录的示例活动将具有一个onCreate类似

@Override
protected void onCreate(Bundle savedInstanceState)
{
    ((MyComponentProvider) getApplicationContext()).getComponent().inject(this);
    super.onCreate(savedInstanceState);
}

有一个明显的问题：如果LegacySingleton.getInstance（）。session返回null（将在重新创建路径中返回），那么我们将崩溃。 是否有解决此问题的通用模式？

尝试1：

我的第一个倾向是，如果session为null，则在ProvideRetrofit中抛出IllegalStateException，然后依赖登录的活动会说

@Override
protected void onCreate(Bundle savedInstanceState)
{
    try {
       ((MyComponentProvider) getApplicationContext()).getComponent().inject(this);
   } catch (ex: IllegalStateException) {
        Intent intent = new Intent(this, LauncherActivity.class);
        intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
        intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        startActivity(intent);
        finish();
        return;
   }        
    super.onCreate(savedInstanceState);
}

（显然，这将被纳入辅助方法中，但为简单起见在此处写出）

但是，这将不起作用，因为Android要求所有对onCreate的调用都必须通过super.onCreate进行。

尝试2：

我可以说

@Override
protected void onCreate(Bundle savedInstanceState)
{
    super.onCreate(savedInstanceState);
    try {
       ((MyComponentProvider) getApplicationContext()).getComponent().inject(this);
   } catch (ex: IllegalStateException) {
        Intent intent = new Intent(this, LauncherActivity.class);
        intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
        intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        startActivity(intent);
        finish();
        return;
   }        
}

但这打破了在super.onCreate之前注入的匕首原则。 （然后确保在super.onCreate回调到派生类的情况下已经准备好依赖项，并且需要这些依赖项之一）因此，这在某些情况下可能会起作用，但是如果有人开始依赖super.onCreate中的那些依赖项，那么我将在运行时命中NPE。 不是很好。

尝试3：

我可以执行注入并跟踪其是否成功，例如

@Override
protected void onCreate(Bundle savedInstanceState)
{
    Val injectionSucceeded = try {
       ((MyComponentProvider) getApplicationContext()).getComponent().inject(this);
       true
   } catch (ex: IllegalStateException) {
       false
   }
    super.onCreate(savedInstanceState);
   If (!injectionSucceeded)
        Intent intent = new Intent(this, LauncherActivity.class);
        intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
        intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
        startActivity(intent);
        finish();
        return;
   }        
}

但是有与尝试2相同的问题； 如果注入失败，则无论如何我都将调用super.onCreate，并且并非所有依赖项都已注入。

尝试4：

我本来可以提供Nullable对象

@Provides
fun provideRetrofit(): Retrofit? {
    return LegacySingleton.getInstance().session?.authenticatedRetrofit
}

但是每个客户都需要在使用依赖项之前检查其为空性，这将是一个巨大的痛苦。 （我什至不确定这是否可行）

Codelab建议：

Google的Dagger代码实验室暗示了此问题： https : //developer.android.com/codelabs/android-dagger#12

重要提示：进行条件字段注入（就像仅在用户登录时进行注入时一样，在MainActivity.kt中进行）是非常危险的。 开发人员必须了解条件，并且与注入的字段进行交互时，您可能会遇到NullPointerExceptions的风险。 为避免此问题，我们可以通过创建一个SplashScreen来添加一些间接性，该SplashScreen可以根据用户的状态路由到Registration，Login或Main。

但这对于具有数十个SessionActivity子类想要向其注入Retrofit对象的现有应用程序似乎并不实际。

有谁有更好的主意吗？