2016-08-16 65 views
2

虽然与火力地堡发展,我手动在控制台添加了一个数据记录,但忘记一个条目,从而导致应用程序崩溃。我已在控制台中更正了问题,但由于我使用的是Firebase的数据持久性,原始数据错误仍然存​​在,导致崩溃再次发生。如果我关闭持久性,一切都很好,但缓存存储没有被更新。有没有人有这个问题,并找到了解决办法?复位火力地堡缓存

回答

0

缓存应自动更新。由于这发生在没有后台线程的情况下,当它在主线程上调用你的代码时,我希望它能够更新磁盘缓存,即使你的应用程序代码崩溃了。

但如果做不到这一点,找回良好的状态最快的方法是清除应用数据,您的应用程序或完全卸载/重新安装。

+0

谢谢弗兰克,我设法解决这个问题,通过使db调用获取正确的数据有条件。这意味着一开始缓存启用时什么都没有发生。额外的重新启动后,我可以让缓存再次同步。看起来Firebase正在异步刷新缓存,但这比我的代码开始时慢。有什么我可以添加到我的代码来防止这种问题?我正在考虑一种可能的解决方案,在发生崩溃时切换缓存并在数据库同步后启用持久性。 –

0

我也面临这个问题,并陷入无尽的碰撞上,启动循环已经失去了失眠用户的想法。

至于建议,对于对出现的问题,在时间窗口开始之间创建了一个应用程序,并缓存更新从火力地堡服务器随后到来的机会。如果在此时间窗口中从缓存中读取数据,然后如果数据碰巧缺少预期值,并且如果应用程序以假定数据不为零的方式使用数据,则应用程序崩溃。如果应用程序在缓存更新之前崩溃,则缓存永远不会有机会更新,并且用户将陷入无限循环(没有从应用程序的内存中擦除应用程序的数据)。

至此,我已经对它们是在启动时调用代码零值的可能性更加发奋守着处理这个问题。如果nil被检查并且发现不方便,那么根据情况,或者(1)如果可能并且如果它不会导致进一步的数据损坏,则应用用适当的值代替零,否则(2)应用进入等待模式几秒钟,然后从问题节点开始重新读取,然后重新尝试启动例程。

或许这个故事的寓意是永远不会假定值不为零或以其他方式在预期范围之内。验证接收时的值或在预期使用时检查该值或两者,然后相应地处理错误。