在网络环境中自我更新桌面应用程序的最佳实践

Jay*_*Jay 12 client-side auto-update

我已经通过谷歌和搜索引擎优化搜索了这个问题的可能答案,但只能找到分散在该地方的一小部分信息,其中大多数似乎是个人意见.

我知道这个问题可以被认为是主观的,但我不是在寻找个人意见,而是寻找具有理由的事实(例如过去的经验),甚至是寻找描述最佳实践的博客/维基的单一链接(这是我更喜欢诚实的东西).我不想要的是如何使这项工作,我知道如何创建自我更新的桌面应用程序.

我想知道创建自我更新桌面应用程序的最佳实践.我特别好奇的那种最佳实践是:

  • 如果客户端软件已过期,您是否强制更新,但在尝试与其他版本的软件或数据库本身进行通信时不会中断?如果是这样,您如何表示这一突破性变化?
  • 您应该多久检查一次更新?每周/每日/每小时,究竟是为什么?
  • 用户是否可以看到更新,或者从UI的角度在幕后运行?
  • 如果不是重大更新,您是否应该通知用户有可用的更新?(例如,在应用程序的远程部分修复单个按钮,只有一个用户实际需要)
  • 你应该尝试修补应用程序,还是从头开始重新下载整个应用程序?
  • 您是否应该允许用户从中央位置更新或仅允许通过指定的应用程序进行更新?(对于封闭的业务应用程序).

当然有一些关于这个东西的书面规则/建议?关于许多应用程序最烦人的事情之一是更新,因为很难在"过时"和"在用户面前"之间找到良好的平衡.

如果有人认为这是用单个客户端编写的.net C#,在与更新服务器具有持续可用连接的机器上运行,所有这些机器都通过应用程序相互通信,并且所有这些机器都与中央数据库服务器通信.

gre*_*lom 7

许多软件忽略的一项最佳实践:在用户关闭您的应用程序时要求更新,而不是在它刚刚启动时要求更新。

令人难以置信的是,有多少应用程序没有这样做(例如 Firefox)。您刚刚运行了应用程序,现在想使用它,相反,它会提示您是否要更新,这当然需要 5 分钟并需要重新启动应用程序。

这是无稽之谈。最后只做更新。

  • @TheGerm 我要说的是不要在用户与应用程序的会话开始时打扰他们 - 除非您真的必须这样做。也许你认为你的更新很重要,但对用户来说你只是很烦人。所以也许一个好主意是有一个标志来将更新标记为关键。如果更新很重要,请立即告诉用户“嘿,您现在需要更新”。否则让用户使用该应用程序,并在最后更新。 (2认同)

Ita*_*man 6

很难给出一个普遍的答案。这取决于上下文:更新的重要性、它是哪种应用程序、用户首选项、#users、网络宽度等。以下是一些选项/权衡。

  • 如果客户端软件已过期,但在尝试与其他版本的软件或数据库本身通信时不会中断,您是否强制更新?如果是这样,您如何表示这种重大变化?

    作为开发人员,您的最大兴趣是让所有应用程序尽可能保持最新。这减少了您的维护工作。因此,如果用户不介意你应该更新。

  • 您应该多久检查一次更新?每周/每天/每小时,究竟为什么?

    如果更新对用户是透明的,不需要立即重新启动应用程序,那么我建议您在通信带宽允许的情况下尽可能频繁地进行更新(考虑更新检查频繁但很小 - 以及下载- 不常见但很大)

  • 从用户界面的角度来看,更新应该对用户可见还是在幕后运行?

    取决于用户偏好,但也取决于更新的类型:错误修复与功能/UI 更改(用户会很困惑地看到外观和感觉发生了变化而没有先前的警报)

  • 如果不是重大更新,您是否应该通知用户有可用更新?(例如,在应用程序的远程部分修复一个按钮,而该按钮实际上只有一个用户需要)

    与上一个问题相同的论点

  • 您应该尝试修补应用程序还是从头开始重新下载整个应用程序 Macintosh 风格?

    如果应用程序很小,请从头开始下载。这将防止因不同补丁(“DLL 地狱”)之间不匹配而产生的各种奇怪的错误。但是,这可能需要较长的下载时间或对您的网络造成沉重的负担。

  • 您应该允许用户从中心位置更新还是只允许通过指定的应用程序更新?(对于封闭的业务应用程序)。

    我认为两者