2016-12-30 106 views
0

我已经开始学习和使用greendao ORM,并且我有这个问题。 我正在写备忘录/提醒应用程序,这意味着我需要从各种活动以及服务和接收器访问数据库。例如:在一个屏幕上,我正在设置警报的值。 在服务和接收器上,我正在阅读这些值并采取相应措施。在应用程序中使用greendao访问数据库

设置和使用对象和关系数据库的访问似乎是罚款从我的主要活动的内部工作的OnCreate()正如我刚才设置的编码器有进行测试和调试。

我想写一个单一类将处理所有的数据库访问和操作,但因为它不是一个活动它没有“上下文” 我知道传递上下文作为参数是一个坏主意。 我需要找到一种方法来从上面提到的所有数据库访问。

此外,我读过的地方,我不应该在主要活动中初始化数据库。 有人可以详细说明并解释初始化的想法和主要活动的问题吗?

希望我能够清除我的问题。 感谢您的阅读并可能回答。

+0

您可以使用应用程序上下文,这是你的进程的生命周期是独生子。 'context.getApplicationContext()' – Karakuri

+0

谢谢@Karakuri,但是在服务或帮助类中,上下文并不是立即可用的。 –

+0

我读到,通过上下文作为参数导致泄漏。 主要问题是如何在上下文不可用时访问上下文 –

回答

0

泄漏上下文意味着您在超出其正常生命周期的范围内保留对Context的引用 - 通常是已完成的Activity或已停止的Service。作为方法参数传递一个Context并不意味着有泄漏。这只是一个泄漏,如果你在一个字段中保存对该Context的引用,并且超出了系统想要销毁该引用的点(因此你的引用可以防止它被垃圾收集)。如果您保留对Context的引用(其主要示例是View)的引用,也会发生同样的情况。

有一个应用程序Context,只要你的应用程序确实是生活,始终是一个单例。提及它并不是泄漏。这意味着你可以在你的单例数据库辅助类中使用它,而不用担心它会泄漏。你的单身实际上可以接受任何Context,因为你可以简单地调用.getApplicationContext()来获得这个应用上下文实例。

子类Application是可选的。在我看来,这样做的好处是使用应用程序的onCreate()方法来执行任何一次性设置,因为这是您第一次运行应用程序代码的机会。

这里是Context s表示可能是有用的一个伟大的文章:https://possiblemobile.com/2013/06/context/