何时使用而不使用android Application类？

Question

我正在考虑使用android Application类作为存储应用程序中其他（片段）活动共享的临时状态和公共代码的地方。

我想获得更多反馈，以确定它是否适合：

1. 共享常量，如ID，pref键名等
2. 全局变量（即设置者/获取者），反映当前的UI状态，导航，选定的片段，以及通常不需要保留的临时数据。
3. 在触发某些条件时保留数据的挂钩。
4. 在偏好更改后更新UI。
5. 提供一种从应用中的任何位置访问上下文的简便方法，包括getApplication()不可用的代码，例如通过静态吸气剂，如MyApp.getApp()。
6. 需要全局状态变量可见性的常用方法，以及转移到专用类会变得过于繁琐。

在活动课程中还有什么适合/有用/方便？什么不是一个好主意，留在它和什么是最好的选择？最后，您发现应用程序最适合在您的应用程序中使用？

Answer 1

  

共享常量，如ID，pref键名等

我通常会为此创建一个名为C的常量文件，因为它更易于阅读。 C.SHARED_PREFS恕我直言，Application.SHARED_PREFS更容易理解。

  

反映当前UI状态的全局变量（即setter / getters），   导航，选定的片段，以及通常的临时数据   不需要坚持。

在它关注的Activity或组件中会更好（例如，Activity的UI状态应该存储在icicle包中，或者在Activity的那个实例中）。

  

在触发某些条件时保留数据的挂钩。

这应该没问题。

  

在偏好更改后更新UI。

同样，我觉得在相应的组件中会更好。

  

提供从应用中的任何位置访问上下文的简便方法，   包括getApplication（）不可用的代码，例如通过一个   静态getter，例如MyApp.getApp（）。

这可行，但要小心内存泄漏。通常，在从Activity或Service或其他任何方法调用方法时，应将上下文作为参数传递。减少内存泄漏的可能性。

  

需要全局状态变量可见性的常用方法   如果搬到专门的地方会变得太麻烦   类。

我觉得做专门课程会更好，因为当你的应用程序在功能和大小上增长时，这将变得难以维护。

Answer 2

这可能是某些挂钩可以附着的地方。

例如，如果您使用ACRA崩溃报告库，则只需使用Application类，因为这是ACRA附加的位置。这是迫使我开始使用这个类;我以前从来不需要那个。