我正在开发一款移动web应用程序，该应用程序要求显示某种在线/离线指示器。该应用程序由RESTapi支持，我们在将任何本地更改存储在WebSQL数据库中时定期同步到RESTapi。我们每10分钟提取一次服务器更改，但POST会立即提取任何本地更改，尽管如果POST由于更改存储在本地而失败也没什么大不了的。
问题是：在这种情况下，在线状态指示器有多有用？为了做到这一点，我们必须在API上添加一个状态方法，我们可以每分钟ping一次（tbd），这将增加移动数据的消耗并给服务器带来负载。更重要的是，如果当我们ping REST api时，它是活动的，然后当我们在30秒后尝试同步时（因为我们认为我们"在线"），用户可以在UI中看到online = true，而REST api调用实际上失败了。
我的感觉是，我们不应该麻烦显示状态指示器——如果呼叫失败，大多数时候用户不需要担心，更重要的是，他们要知道上一次成功同步是在X分钟前。
也许比在线/离线指示器更有价值的是某种标签，指示上次成功同步的时间。例如"上次同步_分钟前"，以及在无法同步时查看任何错误状态的方法。
好吧，从您有要求添加此功能的前提开始，我认为拥有此功能对拥有该功能非常有用。但我想你真的在质疑这样一个功能的优点。
就我个人而言，我认为这是相当无用的。正如你所说，仅仅因为你能够ping并不意味着你就能推送/拉取更新。只要简单地显示一下你上次推/拉后的时间就好了。
为了清楚起见，我必须显示，所以上一次发送数据和提取数据的时间都很清楚。这让用户能够知道他们的设备上存储了多少数据，也知道他们的信息有多过时
不过，这里需要考虑的一件事是，如果用户现在知道他们上次同步已经很久了，他们可能会开始希望能够按需同步，这可能会导致负载增加。你最好还是让用户蒙在鼓里。让他们相信这个系统是有效的。