electron Autoupdater - progress and download choice

sxissh06  于 4个月前  发布在  Electron
关注(0)|答案(5)|浏览(97)

我所做的

我使用 electron-packager 将我的 Electron 应用打包,并使用 electron-winstaller 构建其安装程序。
我使用了 autoUpdater (来自 electron) 进行更新过程。
所以我得到了:

  • RELEASES
  • myapp.exe-1.0.0-full.nupkg
  • myappinstaller.exe

我将它们放在一个带有标签 v1.0.0 的 GitHub 发布中。然后我用 v2.0.0 做了同样的操作,下一次重启时,v1.0.0 的应用会自动更新到 v2.0.0。

问题和请求的功能

虽然它起作用了,但我觉得如果我们能在其中找到下载进度以向用户展示就很有用了。Electron 应用确实相当重,需要花费很多时间才能下载。
此外,在找到新版本后不久就会下载更新。问题是用户没有机会在他想继续使用旧版本时丢弃更新。

替代方案

有一个第三方包,electron-updater 非常强大,允许通知下载进度,并选择何时安装更新或是否安装它。
它唯一的问题是它只与 electron-builder 兼容,而且不符合我的实际情况,因为我正在使用 electron-winstaller

2nc8po8w

2nc8po8w1#

你好!感谢在这里发布第一个问题!如果你在报告一个🐞 bug,请确保你包括重现它的步骤。我们在这个仓库里收到了很多问题,所以请耐心等待,我们会尽快回复你。
为了帮助我们更容易地调查你的问题,请按照 contributing guidelines 进行操作。

clj7thdc

clj7thdc2#

这个问题已经死了一段时间,但我只是想同意这在默认的electron autoUpdater中会非常有用。

fhity93d

fhity93d3#

认真地说,是的。给予更多的控制权。有很多有效的用例不需要隐藏那么多。

cu6pst1q

cu6pst1q4#

抱歉,我只是想引起对一个低垂的水果特性的关注,如果实施了这个特性,将会有一个很大的积极影响。我相信这个特性在其他electron自动更新器上也有实现。

hkmswyz6

hkmswyz65#

我认为在更新之前询问用户是否要更新是很愚蠢的。如果他们不想更新,那么更新就不应该被下载。此外,我们也无法控制下载发生的时间。

autoUpdater 是平台相关的,我无法轻松地跟踪 native one 的去向,但幸运的是 Windows one 是“简单明了”的。它调用来自 a squirrel adapter 的函数,这些函数会生成 Update.exe(Squirrel.exe)来执行命令。

从文档和 Squirrel.exe 帮助中,我们可以看到希望 Squirrel 同意检查和下载是可以分开的。此外,squirrel适配器是一个真正的适配器,因此命令也已经在那里分开了。

electron/lib/browser/api/auto-updater/squirrel-update-win.ts
第67行:export async function checkForUpdate(updateURL: string): Promise{

electron/lib/browser/api/auto-updater/squirrel-update-win.ts
第79行:export async function update(updateURL: string): Promise{

这有点令人困惑,因为 Squirrel --update 似乎对我们的使用场景来说意味着“下载”。无论如何,在 autoUpdater.checkForUpdates 中,我们似乎决定将这些函数背靠背调用,尽管它们之间有明显的分离,因为 --update 似乎需要 --checkForUpdate 的返回值。

electron/lib/browser/api/auto-updater/auto-updater-win.ts
第47行到第58行:const update=await squirrelUpdate.checkForUpdate(url);
if(update==null){ return this.emit('update-not-available'); }
this.updateAvailable=true; this.emit('update-available');
await squirrelUpdate.update(url); const{ releaseNotes, version }=update; // Date is not available on Windows, so fake it. const date=newDate(); this.emit('update-downloaded',{},releaseNotes,version,date,this.updateURL,()=>{

我建议在 API 中添加另一个函数,结果类似于 private checkForUpdatesWithoutDownloadingdownloadUpdatecheckForUpdates(真希望这个函数不叫这个名字),其中 checkForUpdates 是类似这样的东西:

// the update object is not well-typed, this is what I immediately see
interface Update {
  releaseNotes: unknown;
  version: unknown;
}

async function checkForUpdates(ops = { download: true }): Promise<void | Update> {
  const update = checkForUpdatesWithoutDownloading();
  if (ops.download) {
    downloadUpdate(update);
  } else {
    return update;
  }
}

我认为这个函数只需要拆分,而不会造成破坏性的更改,这样就可以在功能发布中实现(尽管改变签名可能会引起争议)。然后用户可以使用现有的方法或类似

const update = await checkForUpdates({ download: false });
downloadUpdate(update);

的东西。请注意,如果实现了进度功能,它应该是 (某种类型的流?) downloadUpdate 的返回值,当 checkForUpdates 为 true 时,可能还包括 download 的返回值。特别是在这一点上,checkForUpdates 的返回值变得相当混乱,因此一个非常有说服力的替代方案是完全不改变 checkForUpdates 的签名,而是额外添加 checkForUpdatesWithoutDownloading 到公共 API 中。然后要获取进度,目前必须分别进行调用。
有人能评论一下原生更新器会导致什么吗?我们需要检查这是否需要对 Windows 版本进行等效的更新。
另外,谁有权审查/批准这个 PR?从一些 git 历史记录中看,也许是 @miniak 、@MarshallOfSound?如果你认为其他人更合适,请让他们参与讨论,否则我们可以继续寻找/讨论。

相关问题