0

这是一个直截了当的问题，但我找不到任何明确的信息来帮助我做出决定。

我有一个包含 2 个表格（2 个活动）的应用程序，这些表格为给定对象填写，清除，然后为下一个对象填写。在给定应用程序的运行期间，这可能会完成 100 次以上。因此，backstack 可以填充 100 多个活动。

所有这些数据都保存到一个 sqlite 数据库中，所以我应该允许 backstack 像那样填充吗？性能影响是什么 - 存储数百个表单实例肯定会开始产生影响。这些实例是否足够有效地存储以至于我不必担心这一点，或者后台堆栈是否有某种限制？有没有办法让 backstack 只存储输入的数据，或者保存的“实例”是否仅由输入的数据组成？查询一个 sqlite 数据库 onbackpressed 而不是比允许 backstack 加载以前的表单效率低得多？有没有办法重新加载现有实例 alaFLAG_ACTIVITY_SINGLE_TOP并清除现有输入的数据，但将其（数据）保存在后台堆栈中？

我一直在阅读/告诉我修改后退按钮的行为、backstack 和 android 的活动管理是一个坏主意，这让我作为一个 android 新手尝试这样做。

我认为这两种形式的数据的大小不会超过这个问题的第 2 段，仅供参考。

感谢您的帮助。

编辑以回应 JoxTraex：

fill -> add -> fill -> add -> n -> commit

那么可能是

fill activity A and then instantiate and fill B -> transact to DB -> REinstantiate and fill A then REinstantiate and fill B -> transact to DB -> n -> commit

我理解正确了吗？

如果是这样，重新加载而不是实例化 A 和 B 的新实例应该可以解决 backstack 问题，因为其中只会有 2 个活动。

这导致人们对onbackpressed将要做什么感到困惑——它会重新加载先前输入的数据还是工作不超过两次，因为后台堆栈中只有 2 个活动？

4

1 回答 1

0

您不应该使用堆栈来跟踪数据，也不应该有 100 个活动实例！

您应该根据需要从数据库动态加载数据。此外，如果您将该活动完成 100 次，那么您的设计已经存在问题，请使其更容易，以便用户不必执行此模式：

fill -> commit -> fill -> commit

而是将其更改为：

fill -> add -> fill -> add -> N -> commit

通过这种方式，您可以简化设计并更有效地使用表单。

fill在我的情况下，填充所有相应的数据（理想情况下在一个屏幕上）add意味着将该数据推送到事务中，并commit意味着完成事务并推送所有内容。N意味着重复fill -> add模式。完成交易后，返回新的相应数据的主菜单/视图。另外，我建议改为使用一个 ListView 填充所有条目，而不是使用活动堆栈。

于 2013-04-04T22:55:05.853 回答