-
Notifications
You must be signed in to change notification settings - Fork 302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can you clarify how node-webkit-builder works? #71
Comments
node-webkit-builder itself downloads the prebuilt binaries of node-webkit. |
Wouldn't it? It would solve two pain points that would elevate app distribution above Adobe AIR. Adobe AIR is a crappy platform, but it has a really, really easy distribution mechanism because the distributables are small. It seems inefficient to ship a node-webkit binary with every single node-webkit app. Why not have the installer just download it if needed on the end user's computer (and, as you say, simply update the app if that's all that's needed)? It's much easier for the user and the developer. (Although, I respect it's a bit more of a complex problem to make that architecture. 😄 ) |
So you mean updating node-webkit itself, not the app? |
I was thinking both. I'm not sure this should be in this same project, though. |
I've put in work on node-webkit-updater and as much as I'd love a cross-over which would handle both in one, I can't see how it would work. An updater is a pretty custom thing, you want to show your own updating screen; add your own logic around it, etc. |
I don't see why either of those would be necessarily true. They are sometimes true, but for most installers, it's not a necessity. The way Adobe handled this was to set a standard for it. They set an update.xml format (which today would probably be a JSON file), where you could specify, for example, what changes were included in that update. Even if you started with the premise that a complete copy of node-webkit should be loaded for each NW app (which still seems odd, since apps could be version-locked, or version-unlocked to node-webkit, and you could just download / update only the versions of node-webkit needed), then it still seems advantageous to not include that completely copy of node-webkit in every update of my app. It looks like node-webkit-updater sort of handles this for subsequent updates, but I'm unclear how this would work if the update is a first-time install. I think there's a possible solution to make this work. I'd love to help figure it out. |
As far as updating the entire app goes, I've built node-webkit-updater into a current project and I think I wouldn't like to sacrifice the custom stuff. Like our app checks for updates (on launch, every X hours, & on open of the about screen), then downloads in the background, unpacks it and then in the UI there's a modal to alert the user (& a new button in the main menu & about screen if ignored) to install & restart. All of this is neatly tied in with our UI, etc. I don't see how anything like that is possible or why I would settle for less. I think users prefer how Chrome, for example, updates rather than Adobe stuff. Unless node-webkit-builder somehow inserts a global with a public API (like node-webkit-updater's) that the app can hook into (to trigger update checks, be told when there's an update, etc.). That would be cool. So nw-builder would handle some things out of the box; checking for updates on launch & at intervals, downloading in the background, automatically installing the new version when the app is restarted next, etc. |
@adam-lynch Okay, so would it be possible to share how you did that? It sounds like you're still pulling in the app "contents" for updates separate from the node-webkit piece. Does that mean that you bundle newer versions / builds separately from updates? I'm just trying to figure out a stack with simple priorities: 1) Small distributables, 2) small / simple updates, 3) easy build packaging. #1 I'm probably willing to sacrifice if the update process is fairly straightforward for app maintaining and the end-user experience. But it sounds like you did a custom process for that? |
@matthew-dean oh, no we don't separate it from the node-webkit piece. When we build a new release we output a ZIP for each platform containing just the new content of the app (the HTML, JS, etc.) and a manifest file (see https://github.com/edjafarov/node-webkit-updater#manifest-schema). These ZIPs and manifest need to hosted somewhere. We then manually (hoping to automate this) create installers. So for example, for Windows if you're installing the app for the first time, you use the installer Then the update process involves the existing app running the "new" app from this temporary location, the "new" temp app killing the old one, copying itself to the old location, running the "new" one from the old location and kills itself. All of this is not hard to do with node-webkit-updater. It would be nice if the node-webkit piece was seperate (to lighten the download) but not such a big deal for us. If you were doing that, it might be best to host the node-webkit downloads yourself so you wouldn't be depending on their servers in production. I do know that when your node-webkit app (let's say |
@matthew-dean At the moment our approach is to build the app using node-webkit-builder which (on windows) packages nw.exe and our app into a .exe file and we then distrubite it (and the other associated dll's etc) using an installer .msi. We also have a hosted .zip file which contains essentially the same data as the msi and that is downloaded by the updater and performs the installation. At the moment this is the easiest way to auto-update the whole of the app including node webkit. I am currently in the process of changing that approach however to something similar to what I believe you want. Basically I'm planning to no longer package the .nw file in with the .exe and rather keep them separate. This way I will have 2 update files. 1 for node-webkit and 1 that is just the .nw file. So any minor updates (i.e. any update where the node-webkit version doesn't change) I only need to download the .nw file for the update process rather than the full node-webkit + .nw file. I'm doing this through my own custom code which grabs a .json file off the server telling me essentially whether I need a full update (if the node webkit version is different) or only a minor update. Then can download the appropriate files and upgrade. So most of the time it will only be ~1-2mb update rather than ~35mb. Note with packaging the .nw separately, in windows (can't speak for the other platforms), if you want your app to run automatically by double clicking on nw.exe then you'll need to call the nw file Sorry for the long post. I wish it were as simple as having a seamless auto-update already built into node-webkit, however these tools are pretty powerful and you can get your own customized auto-updater running in a couple of hours with quite a lot of flexibility. |
Description says this:
Does that mean that a binary is made by downloading node-webkit and packaging it as part of the release binary. OR does this mean that the binary itself, when installed on an end-user's computer, will download the prebuilt node-webkit binary? And if it doesn't do the second, could it? (As that would be really awesome.)
The text was updated successfully, but these errors were encountered: