我的手上有一个相当特殊的情况，我很惊讶似乎没有人写过关于它/类似Android的东西（或我的Google技能很糟糕）
情况＃1：
RecyclerView）每当用户进行任何编辑时，UI都已显示更新的数据（例如，编辑field1将在用户键入时显示文本，并且项目列表将以新用户的顺序显示它们 - 安排他们）。
立即保存数据将触发UI刷新（显示相同的内容）并给用户带来不良体验（field1焦点将转移到第一个字母，如果用户快速恢复，应用程序可能会崩溃安排清单项目。）
因此，存储编辑并在以后执行它们是有意义的。
情况＃2：
与上面的情况＃1一样，编辑该字段的UI已经处于更新状态。但是，在这种情况下 - 点击加号/减号按钮也会更新数据，但UI不会更新（除非保存数据，并且查询再次运行......）。
问题：
我正在使用MVVM，因此所有已执行的操作都会发送到viewmodel，并决定要执行的操作。我发现自己正在寻找一种解决方案，它可以在应用程序的不同屏幕上以不同的方式工作，但我知道这只是在脚下射击然后从桥上跳下来。当然，必须有人遇到这个挑战，并围绕它有一些见解？
理想的解决方案 适用于所有不同屏幕的正常工作的解决方案。你有吗？请告诉我。
/绝望的Android Dev
答案 0 :(得分：1)
首先，让我首先说明我认为这里没有正确的答案，但您应该考虑自己的应用程序做什么，然后确定您需要做什么。
让我解释一下。考虑两个应用程序，一个保存TODO项目，另一个是银行应用程序。
我现在将解释我认为对您的应用程序有用的内容，因为您没有明确提及任何与此相矛盾的要求。
在这种情况下，我认为乐观是一个好主意。假设事情不会失败，当他们这样做时，试着退出。这是什么意思？
这意味着，例如，在您提到的场景中，用户在字段中输入内容。您应该让UI自动更新（我们在这里做什么，这只是Android），当发生这种情况时，您将这些更改保存在本地或服务器上并不重要。
当然，您可以优化，而不是保存每个字母，以某种方式限制输入，但你明白了。
这可能是成功也可能是失败，因为我们乐观，我们让UI更新，用户感觉我们的应用程序快速点亮。您无需重新加载任何内容或刷新任何内容。用户界面现在应该与您的Model状态匹配。
如果事情向南，并且您的HTTP请求或数据库更新由于某种原因失败，那么您需要采取措施。但要尽量保持适当的反应。
您可以再次以多种方式处理失败，具体取决于您在应用中所做的事情的重要程度。
现在，这种方法不仅让人感觉应用程序真的很快，而且还能让事情变得简单。
另一个建议是不要尝试解决尚不存在的问题，这意味着不要开始为一些永远不会超过视图的本地持久性作业实现后台服务和作业队列，而且永远不会。
相反，使用测量，使用某些工具记录这些错误和失败，并使用这些统计数据来了解需要修复的内容 - 如果有的话 -
回到我们的两个应用程序，这种方法对于TODO应用程序可能是完美的，但对于银行应用程序来说这可能不太好。
假设用户转账，我们马上说，好吧！然后请求失败了，你的用户的房东因为从未支付租金而将他踢出去。
所有这一切都与你正在进行的操作有多敏感。