＆QUOT;持续状态＆QUOT;与＆QUOT;当前状态和QUOT; [英] "persistent state" vs. "current state"

问题描述

试图决定（我的应用程序）时如何保存在的onPause（）以及如何保存<一href="http://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState%28android.os.Bundle%29"相对=nofollow>的onSaveInstanceState（），我梳理了整个所以对提示和明确的指导方针。

Attempting to decide (for my application) what to save in onPause() and what to save in onSaveInstanceState(), I combed the entire SO for hints and clear guidelines.

如果我理解正确，的onSaveInstanceState（）是最好的保存运行时更改或当前状态（无论这意味着），同时的onPause（）是最好的保存持久状态（知道是什么意思）。

If I understand correctly, onSaveInstanceState() is best for saving "runtime changes" or "current state" (whatever that means), while onPause() is best for saving "persistent state" (whatever that means).

我仍然有困难的决定在我的应用程序什么构成持久状态与当前状态。例如，当用户preferences显然是持久的，我需要将它们保存在的onPause（）时，他们总是通过Android的UI框架，当用户自动保存改变了他们？

I am still having difficulty deciding what in my application constitutes "persistent state" vs. "current state". For example, while user preferences are clearly persistent, do I need to save them in onPause() when they are always saved automatically by the Android UI framework when the user changes them?

别类的数据成员需要被保存在的onSaveInstanceState（）？我需要做的的每次的类在我的应用程序？

Do class data members need to be saved in onSaveInstanceState()? Do I need to do that for every class in my application?

我很困惑。

您可以带来什么样必须保存在的onPause（），什么必须保存在的onSaveInstanceState（）？ 除了了解设备配置更改，即

Can you bring real-world examples of what must be saved in onPause() and what must be saved in onSaveInstanceState()? Except for device configuration changes, that is.

-

一些新的见解，的在的我的问题已经回答：

Some new insights, after my question has been answered:

• 的onSaveInstanceState的捆绑是不写任何东西，这不是执着以任何方式。
• 的onSaveInstanceState的捆绑数据只在内存中被举行，直到应用程序关闭。

• onSaveInstanceState's Bundle is not written to anything, and it's not persistent in any way.
• onSaveInstanceState's Bundle data will only be held in memory until the application is closed.

推荐答案

您不需要存储用户preferences中的onPause，因为就像你说的，框架会替你。

You do not need to store user preferences in onPause because as you say, the framework does that for you.

要持久数据VS的状态信息加以区分，认为一个文本编辑器应用程序。

To distinguish between persistent data vs state information, think of a text editor application.

持久数据

比方说，用户键入几个单词，然后退出应用程序。用户没有明确告诉我们，这些数据保存到一个文件，但它肯定会是不错的存储数据离开时，他们回来了。这是持久性数据，并要保存它走在的onPause（）。

Let's say the user has typed a couple words and then exits the app. The user didn't explicitly tell us to save that data to a file, but it sure would be nice to store that data away for when they come back. This is persistent data and you want to store it away in onPause().

状态数据

同样，说你有2个选项卡，并跟踪哪个选项卡当前选择的变量。这是国家的数据，你会在存储的onSaveInstanceState（）。

Similarly, say you have 2 tabs and a variable that tracks which tab is currently selected. This is state data that you'd store in onSaveInstanceState().

灰质

最后想象有一个类中，用于跟踪的字符在编辑器的行数和号码的编辑。这是国家的数据，你可以将其存储在的onSaveInstanceState（），或者你可以把它扔掉，只是重新计算它，当你再次启动。无论你把它扔掉，可能取决于需要多长时间来计算，例如，如果你能prevent网络请求通过存储数据，这样做的。

Finally imagine you have a class in the editor that keeps track of the number of characters and number of lines in the editor. This is state data, you could store it in onSaveInstanceState() or you can throw it away and simply recalculate it when you start up again. Whether you throw it away might depend on how long it takes to calculate, for instance if you could prevent a network request by storing data, do so.

的再认识

通过与您的应用程序发挥它应该是显而易见的，如果有一个，你没有松鼠正确的数据远区。请务必不喜欢的东西击中主页按钮，然后从设备管理器关闭了您的应用程序。这将让你打，你的应用程序被关闭，而不仅仅是暂停角落的情况。

By playing with your app it should be obvious if there's an area where you failed to squirrel the right data away. Be sure to do things like hit the home button and then close out your app from the device manager. This will let you hit the corner cases where your app is shut down rather than just paused.

如果你的用户界面的状态是在整个生命周期事件一致，用户数据仍然存在，好工作。

If your UI state is consistent across lifecycle events and your user data remains, good job.

根据意见修改

我认为有2个在这里的标准来确定什么时候/什么保存。

I think there are 2 pieces of criteria here to determine when/what to save.

首先是相当主观的 - 你要保存的数据呢？有没有真正强迫你保存状态或数据。将保存此信息基础上做出了更好的用户体验？如果你正在写一封电子邮件，并试图从另一个应用程序复制/粘贴文本，失去你的一半每个应用程序被关闭的将是令人沮丧的时间类型的电子邮件。

The first is quite subjective - Do you want to save data at all? There's truly nothing forcing you to save state or data. Will saving this information make for a better user experience? If you are writing an email and trying to copy/paste text from another app, losing your half typed email every time the app gets closed would be frustrating.

第二件，确定要保存取决于你是否能根据您拥有的数据重构你的UI状态。例如，如果你已经保存的文本数据，那么必定意味着用户在编辑文本。所以，现在我们知道切换到编辑文本选项卡，并填写保存的文本。

The second piece, determining what to save depends on whether you can reconstruct your UI state based on the data that you have. For instance, if you have saved text data then that must mean that the user was editing text. So now we know to switch to the edit text tab and fill in the saved text.

一般来说，如果愿望是要用户返回到他们离开，那么你需要考虑到回到那个点所需的状态数据在同一个地方。想象一下，你的应用程序的原始版本加载

Generally speaking, if the desire is that you want to return the user to the same place they left off then you need to think about the state data required to get back to that point. Imagine a pristine loaded version of your app

• 需要什么样的数据更改为把它转换成最后的状态的用户 锯？
• 在什么数据需要存储回到这里？

• what data needs to change to turn that into the last state the user saw?
• what data do you need to store to get back here?

这是有多么的android的作品，你的活动被破坏并重新创建，它是你的工作（如果你选择这样做），再设置在运动件。

This is really how android works, your activity is destroyed and recreated and it is your job to set the pieces in motion again (if you choose to do so).

这篇关于＆QUOT;持续状态＆QUOT;与＆QUOT;当前状态和QUOT;的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！