IOS为复杂应用程序保存状态

时间:2011-06-16 14:26:18

标签: ios state save

我正在iPad IOS 4.2:4选项卡上构建一个相当复杂的业务应用程序,每个选项卡上都有可能很深的导航路径。

一些经验丰富的IOS开发人员认为,用户的一般期望是在启动之间保存应用程序状态(即应用程序完全终止并随后重新启动后)?我正在使用Core Data并且涵盖了所有数据问题,但我担心应用程序的导航树。如果用户已经离开屏幕3上的第一个选项卡,屏幕4上的第二个选项卡,屏幕2上的第三个选项卡,他在那里留下了半完成的新记录条目,并且在应用程序进入后台时在屏幕3上的第4个选项卡上工作......你认为普通用户会希望应用程序在下次启动时记住所有内容吗? (我的直觉说是的,虽然我不确定多长时间。)

如果答案是肯定的,你能否建议一个处理这个问题的一般策略(而且,我在这里谈的是导航树,而不是Core Data的东西)?例如,如果将导航控制器用作每个选项卡的根视图控制器,那么记录足够的有关其导航堆栈的信息以便以后能够恢复它们将非常简单。但是像弹出窗口,警报/动作表或动态创建的模式VC这样的东西呢?每个视图控制器是否应记录其UI对象的状态,如果是,建议的方法是什么?

我知道很多事情取决于用户,但我要求对这些问题有一般看法,即体验的声音。

4 个答案:

答案 0 :(得分:6)

原则上它非常简单,但在实践中它可能会非常复杂,需要通过导航层次结构并存储无法从数据模型中派生的内容。

这是一个名为DTResurectionKit的开源实现。我也在我网站上的应用中documented how I do it。它类似于DTResurectionKit(但比DtresurectionKit简单。

答案 1 :(得分:4)

  

一些经验丰富的IOS开发人员认为,用户的一般期望是在启动之间保存应用程序状态?

考虑这一点的最佳方式是确保用户永远不必弄清楚他们为什么或如何在应用首次打开时达到目标。

这完全取决于您拥有的应用类型以及自上次打开以来的时间长度。听起来你有一个相当复杂的下钻应用程序,所以我认为最好在预定的时间范围内记住导航堆栈。我使用three20框架自动为我做这个,但如果你要实现它,它将是这样的:

  1. 如果用户在过去24小时内打开,请打开左侧的确切位置
  2. 如果用户在一周内打开,请打开他们所在应用的主“部分”或区域
  3. 如果用户在一周过后打开,请打开根屏幕。
  4. 当然,这些值会根据您的应用功能和用例而有所不同,但您会明白这一点。通过您对人们如何使用您的应用程序进行一些广泛的假设,以及何时,您可以通过在他们不记得他们如何到达那里的时候在他们的应用程序中如此深入地推断他们来增加用户体验。

    至于实现,它只是数据..您不需要序列化活动对象来存储堆栈,只需实现在下次启动时重新创建状态所需的数据。您需要存储的内容在很大程度上取决于您自己的设置...里程会有所不同。我使用NSUserDefaults通过Three20存储所有实例变量和导航堆栈。查看TTNavigator以获得更好的实施。

答案 2 :(得分:1)

我建议保持每个标签视图的状态。仅在“页面”级别。不要担心弹出窗口或不完整的数据输入(希望在将它保存到核心数据存储之前没有太多的临时状态。)

就像你说的那样,很容易记住你所使用的标签,以及你在每个标签中导航到的控制器。更多是没有必要的。

听起来你已经掌握了它,但是为了别人的利益:1)当你更改标签时,保存“活动标签”,2)当你在标签中导航时,保存“标签中的活动控制器” ,3)当您启动应用程序时,设置“活动选项卡”,4)更改选项卡时,设置/确认“选项卡中的活动控制器”。

4)的原因是选项卡的视图/控制器在加载时会延迟,或者可能永远不会加载。您不希望为不可见且可能永远不会加载到应用程序的选项卡设置“选项卡中的活动控制器”,这只会导致不必要的加载。它经常发生(在应用程序加载后)你不需要更改它,因为它已经处于正确的状态。

答案 3 :(得分:0)

我认为你的时间最好花在其他地方。当然,您的应用程序可能非常适合这一点,但在我们的情况下,数据部分在线,可能已经过时,在不同的选项卡中同时影响不同导航视图中的视图状态等等。这不是一个不可逾越的挑战,但绝对是很难和一个巨大的时间沉。

我们决定花时间修复错误并改进功能。如果你必须做出同样的选择,我很确定你的用户会选择哪个选项。特别是现在您的应用程序将在后台通话。