6

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

我想获得更多关于它是否是一个好地方的反馈：

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

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

4

2 回答 2

2

共享常量，如 ID、首选项键名等。

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

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

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

触发某些条件时用于持久化数据的挂钩。

这应该没问题。

偏好更改后更新 UI。

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

提供从应用程序中的任何位置访问上下文的简单方法，包括 getApplication() 不可用的代码，例如通过 MyApp.getApp() 等静态 getter。

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

需要全局状态变量可见性的常用方法，并且会变得过于繁琐而无法转移到专用类。

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

于 2013-01-07T14:40:21.060 回答
2

它可能是可以连接某些挂钩的地方。

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

于 2013-01-07T14:40:55.723 回答