小编Le2*_*410的帖子

我已经看到这种特殊的技术用于启动活动,在我看来,由于静态上下文,我觉得这是一个坏主意,但我希望有人可能有这种方法背后的合理理由.

要启动的活动实现静态启动(Context context)方法,该方法设置intent,flags等,最后启动活动.

public static void launch(Context context){
   Intent i = new Intent(context, SomeOtherActivity.class);
   // flag stuff
   context.startActivity(i);
}

然后,DifferentActivity可以用一行启动SomeOtherActivity.

SomeOtherActivity.launch(DifferentActivity.this);

我喜欢它如何允许你在活动中设置标志,而不是启动它的DifferentActivity,但它似乎不足以合理地将该活动的上下文传递给静态方法.

这不会导致DifferentActivity不被垃圾收集,因为现在静态方法有引用吗？这似乎是一个内存泄漏给我,可能不是一个好主意,只是为了能够保持正在创建的活动中包含的标志.

我在这里缺少哪些东西使这成为一个好习惯吗？

我有几个我想注入的课程.例如,我有一个APIContentLoader类,用于从端点下载JSON,然后将其存储到数据库中.我想将我用于读/写数据库的DatabaseManager类注入到APIContentLoader中.为了将DatabaseManager注入此类,我首先需要对ApplicationContext的引用,对吗？

这就是我现在设置的方式:

public class APIContentLoader{
    @Inject DatabaseManager dbm;
    @Inject BaseApplication app;

    public APIContentLoader(){
        app.getAppComponent().inject(this);
        // dbm now is ready for use
    }  
    ... // rest of class stuff
}

我的BaseApplication类扩展了标准的Application类.以这种方式向这个类注入BaseApplication引用是不好的做法？我知道对ApplicationContext进行静态引用并不是将它们提供给这些非活动类的好方法.

我想最重要的问题是,这种方法是否存在与内存管理相同的静态引用问题,并持续存在这些辅助类的生命周期？

随着Oreo中引入的新后台服务限制，我很难找到一个地方来澄清在后台运行应用程序时是否仍然可以从JobScheduler启动IntentServices。

我有一个基于地理围栏的非常重要的功能，该功能需要在篱笆断开后运行intentService。我花了很长时间设置它，以便在篱笆破损且应用程序处于“牛轧糖”的“打for”状态时排队等待工作。当重新打开网络连接窗口时，作业最终由操作系统运行时，我在intentService中一个接一个地剥离每个作业。从技术上来说，当应用程序不在前台时正在启动服务，或者由于使用JobScheduler而仍然允许这样做时，我现在可以不再执行此操作吗？