只是想知道在活动之间传递信息、将其添加到捆绑包或使用单例类来存储和访问这些数据的更好做法是什么。我过去曾将两者用于各种 android 端项目,但我现在正在开发一个规模更大的 android 项目,因此更愿意从一开始就做事。
我的应用程序对用户进行身份验证,然后必须根据它的 id 进行各种查询。为了最大限度地减少活动之间的耦合,我认为只是将 id 添加到捆绑包中,然后让每个活动查询它需要的信息,这将是最好的选择;然而,为了提高响应能力,我倾向于使用单例类来存储持久性信息,以防止查询超出需要。
只是想知道在活动之间传递信息、将其添加到捆绑包或使用单例类来存储和访问这些数据的更好做法是什么。我过去曾将两者用于各种 android 端项目,但我现在正在开发一个规模更大的 android 项目,因此更愿意从一开始就做事。
我的应用程序对用户进行身份验证,然后必须根据它的 id 进行各种查询。为了最大限度地减少活动之间的耦合,我认为只是将 id 添加到捆绑包中,然后让每个活动查询它需要的信息,这将是最好的选择;然而,为了提高响应能力,我倾向于使用单例类来存储持久性信息,以防止查询超出需要。
就个人而言,我会创建一个扩展Application
来存储您的应用程序的状态并在不同的活动之间共享数据。Application
充当整个应用程序的上下文,Android 保证在您的应用程序中始终只有一个实例。因此,它的工作方式类似于定义您自己的 Singleton,但使用Application
将允许 Android 控制您共享数据的生命周期并基本上为您进行内存管理。
这里有更多细节。如果你沿着这条路走,你可以简单地将任何 getter/setter(或其他)方法添加到应用程序扩展中,以存储/检索数据并对其进行操作。Bundle
尤其是后者在使用s 在活动之间来回传递时会变得非常难以管理(并保持一致) 。如果仅Bundle
在活动流中相邻的一两个地方需要数据并且不需要在其上运行任何(复杂)操作,则仅使用 a。
我唯一一次通过 bunlde 在活动之间传递数据是如果它是我暂时不需要访问的东西(即我只想在调用活动中使用一次的资源的 resID 等)。我还认为响应能力的差异非常小,因此不必担心。我建议单例方法
对您来说更好的方法是使用 SharedPreferences 来保留您需要保留和重用的 userId。当然你可以使用单例方法甚至Application类,但是应用程序被杀死后数据会丢失。
传递捆绑包是一项乏味的工作。您必须为活动中的每个更改传递一个包,以确保该值不会丢失,即使您没有在调用的活动中使用该值。
单例模式有一些不好的结果。例如:从主要活动中,您称为次要活动。电话打断了您的工作。结束电话后,Android 正试图将辅助活动显示在屏幕上。这是我的噩梦——许多用户抱怨异常——谷歌向我报告了我的单例中的 NULL 指针。所以你不仅要提供单例,而且单例中的所有数据也必须是单例的。这让事情变得非常复杂:(