Before releasing a desktop application, a question that must be considered is: how to update (iterate)? It is impossible for an application not to be updated unless no one uses it or maintains it. From human updates to automatic updates to complex update schemes, there are many designs of products and technologies...
This is the third article in the Electron series, and it is also the first article "From Requirements to Design" of the Electron Application Automatic Update Solution, and the next article will talk about "From Design to Implementation".
Why talk about from requirements to design? Isn't this the life of the product?
Don't be so careful to distinguish between product and development. For some technology-driven functions, development needs to undertake the work of the product. Automatic update is such a function. Moreover, the functional design in the early stage directly affects the realization method of the development. Only on the basis of fully understanding the early stage design, can the development make a reasonable realization.
I have designed and implemented a complete set of automatic update solutions for Electron applications, and they have been applied to products, so I wrote this article to share with you how to design and implement automatic updates of Electron applications, and our considerations for automatic update requirements Might be a little more complicated than you think.
This article will first start with whether or not to update, and then talk about how to step by step from human flesh update to painless automatic update. Then, I'll show you what a well-established auto-update requirement (and what these 2 articles will implement) can look like. The last and most critical part - what kind of update ideas should we adopt and how should we design our product logic.
Note: The automatic update scheme implemented in this article is only one of the many update schemes for reference. You can either do it completely by reference, or get some inspiration from it. Going further, if you have implemented automatic update, you can compare this article The similarities and differences of the program you adopted, welcome to leave a message to exchange .
1. Do you really need automatic updates?
First of all, let's pick a word. "Update" includes but is not the same as "automatic update". Before considering the automatic update of an application, you must first clarify your application characteristics and distribution strategy, which determines whether to implement the automatic update function or not, and "Automatic degree".
1. Update is a pursuit, and living applications need it
The purpose of updating is to deliver better products to users. This is the pursuit. Living applications are all needed, because living needs to have a hope. Of course, if "the product is alive" is your pursuit, when I didn't say it.
2. The nature of the application and the release strategy determine whether to automatically update
"Update" is necessary, but "Auto Update" is not necessarily. Updates to your Office suite, Adobe suite (installed without Creative Cloud) are mostly a huge experience upgrade, and they don't have a notification popping up every now and then asking you to update like some other apps.
Such applications are generally high-complexity, offline-running, long-release, and old-fashioned applications. Design software such as Sketch is of the same nature, but it uses an online automatic update mechanism, so whether to automatically update or not is also related to the application issuer's strategy.
3. Automatic updates are an essential requirement of modern desktop applications
First of all, the way of software iteration has generally changed. The development method of modern software emphasizes "rapid iteration and continuous delivery". This is because in the context of modern technology, rapid adjustment and iteration can be achieved at a very small cost. Like Electron The iteration of the application can even achieve low cost and rapid iteration across platforms, which means that better products can be delivered to users faster. And the technical guarantee to do this is - automatic update.
Furthermore, automatic update is the user's demand, but also the issuer's demand. For users, it is convenient to obtain better applications at the first time; for publishers, it can quickly promote version upgrades, obtain product feedback as early as possible, and acquire more users.
2. From human flesh update to automatic update
How automatic is Auto-Update? This is a good question. Automatic updates can be "fully automatic", but fully automatic is not necessarily good. Just like making a perfect cup of espresso, the results of using a fully automatic coffee machine are unsatisfactory. Only a semi-automatic coffee machine plus A barista can do it.
1. The most powerful update method
The most powerful way to update is to hold a press conference, or send a notice of a new version of the software, and then there will be a large number of users competing to download the new version of the application, and they will also rush to inform, attracting more people to download and update. , this is the most powerful update method, and it is also the best way to update human flesh, such as Adobe series products.
And if your product is not so provocative, you also plan to let users go to human flesh to update, let users pay attention to your download page or email every day, and hope that after the new version is released, users can consciously download and update, Then you might end up disappointed, and you'll have a "spread version distribution" problem that brings up a whole bunch of other problems.
So, don't expect users to always pay attention to your product updates, let users actively discover new versions (especially in places outside the application, such as websites) and then update them with human flesh, which is a dream for most products.
2. Fake automatic updates: in-app notifications, out-of-app downloads, manual installations
Then go a little further and automate a little bit. Instead of users actively discovering new versions, they tell users in the app that this is a big improvement compared to the human flesh update above.
In this update method, once the publisher releases a new version of the app, the user will receive an update message push of the new version available in the app , and then you may need to click a link, then the download page will be opened with a browser, you need to Manually download the new version of the app and install it manually when done.
But note that this is only a notification function. Although it has made great progress, it has not reached the level that can be called "automatic update", so I call it "fake automatic update".
3. Automatic update: in-app notification, after downloading, evoke the installation process
Naturally, we would expect to notify the user within the app, and the app itself can help us download the new version of the app installation package. After downloading, the app can also help us evoke the installation process (and the specific installation method of your app has a strong relation).
Under such an update method, we can only be considered as automatic update. The application itself can notify, download and evoke the installation program. This set of logic is possessed by the application itself. From the user's point of view, every time there is an update, you will receive a notification. Just click "Update Now", and the application will download the reading bar. After the download is complete, it can be installed automatically without any extra operations.
4. Painless automatic update: the next time you open the new version
Humans, they tend to take an inch, can I "secretly" update my application without the user's perception? The answer is yes.
An update is nothing more than checking for updates, notifying users, downloading files, and installing. If you hide these steps in the background, users will naturally be unaware. If there is an update without notification, download it directly. As for the installation, the overwritten installation must be exited from the application, then the installation will be aroused when the user exits the application, and the installation process will be invisible, then it will be realized, and the user will open it next time. It's time for a new version.
However, it is not recommended to update the user completely and transparently. It is generally not recommended. It is better to inform the user, but it is possible to provide the user with the option of "update after exiting the application". item.
3. A perfect automatic update requirement
In this section, I will describe a complete automatic update requirement on which the update scheme we are currently using is built on.
1. Basic requirements for automatic updates
No matter how different the details of the automatic update of each application are, there are some basic requirements (or links) that must be implemented.
- Check for updates : Check if a new version is available, when to check, and what methods to trigger the check, you can customize
- Notify the user : When an update is available, the user needs to be notified. It can be notified when an update is available, or it can be notified after the update file is downloaded. The former user can see the download process, while the latter user cannot feel the download process.
- Download updates : The application has the ability to download updates, and the integrity of the download is guaranteed. It can be downloaded in the background or in the foreground.
- Install update : The app can evoke the downloaded new version of the application installer, and then exit itself. As for when to evoke the installation, it can be designed as needed
2. Distinguish between strong and weak updates
If the above basic requirements are achieved, the automatic update is complete, but some designs can be made in terms of the timing of each step above, interaction with the user, vision, etc. In a nutshell, the automatic update requirement can be split.
2.1 Why should we divide the strong and weak update methods
We divide the automatic update into two types of update methods: strong and weak. The starting point behind it is our characterization of an update.
If an update is only an improvement of functional features, the launch of small functions, the repair of common bugs, or an update that allows you to " keep your emotions stable ", then this is classified as a weak update. Our expectations for this update are , users are expected to update, but not mandatory.
If an update includes the launch of killer features, major bug fixes, major revisions, and in short an update that makes you " unable to keep calm ", then this is classified as a strong update. Our expectations for a strong update are , it is strongly recommended that users update, and it is mandatory.
We call "weak update" as "automatic update", which corresponds to "Update" in English, and "strong update" as "automatic upgrade", which corresponds to "Upgrade" in English.
2.2 What is the difference between weak update and strong update
- Different forms of notification
- Weak updates are reminded in a lightweight form, reminded after downloading, do not interrupt user operations, and attach to existing windows
- Strong upgrade is reminded in the form of weight, reminding before downloading, interrupting user operation, it is a new window
- Different user options
- Under weak updates, users can choose to install the next time every time
- Under the strong upgrade, the user can only choose "Exit the app and then upgrade" in addition to "Upgrade Now", which generally cannot be skipped.
- different download methods
- Under the weak update, the download is in the background, which is transparent to the user, and the notification is aroused after the download is completed.
- Under the strong upgrade, the download is in the foreground, visible to the user (download progress bar), and a notification is aroused before the download
- different installation times
- Under weak update, the user clicks "Update Now" to start the installation program
- Under the strong upgrade, select "Upgrade Now", then the installation will start automatically after the download is completed; select "Exit the app and then upgrade", then wait for the app to exit and then automatically run the installer (and it is silent)
3. Exception handling
An update must ensure that the exception will not cause problems with the update, and in an update process, there are mainly two types of exceptions.
3.1 Exception during download
This will cause the problem of incomplete download, so it is necessary to ensure that the application is completely downloaded when the application is downloaded. If the user quits the application due to the user's reasons, such as the download process, then the next time the update is checked, it should be restarted. download.
However, if the update is checked and found that the user already has the latest update package available locally, there is no need to download it.
3.2 Exceptions during installation
The installation process is generally left to the installation program to ensure that if the installation process exits, the installation program should ensure the atomicity of the installation. If the installation method does not use an installer, such as applications distributed in the form of dmg under Mac, the installation process can generally be avoided by handing over the installation process to the user. The action of the application folder overwriting the original application" is left to the user to operate.
Four, updated ideas
This section briefly talks about what the update is, what it does, and what we've tried.
1. Incomplete update: replace some files online
I have seen an update method on Zhang Xinxu's blog before, which is to request the core js file online, and then replace the old file. The starting point of this is a good one, because most of the updates are only changes to some files, so the files requested to be changed can be replaced.
But there are two problems here. The first problem is that this is an incomplete update and can only replace part of the files. There is also a way to solve this. Request a compressed package, and then start a subprocess to decompress and overwrite the original application folder. At the same time, exit the application to prevent file occupation, but how do you ensure its reliability; the second question, if the user installs in some folders, there is a permission problem for writing, and the running of the application itself is not under the administrator's permission. The invoked process inherits the token of the parent process by default, so there is no administrator privilege. For some folders, privilege escalation is required, which is another difficulty.
2. Full update
Also based on the consideration of automatic update implementation, we have redesigned the installation method of our application, from "decompression" to "build installer" (only for Windows), so that we distribute the application into the distribution installation package, the installation we use The program is Inno Setup.
Inspired by the update method officially recommended by Electron and @Qquanwei's github (thanks to this developer), combined with the official information of Inno Setup, we finally considered the update idea.
- We distribute the application installation package built with Inno Setup, run to use the installation process provided by Inno Setup to install our application
- We deploy a json file on the server, which contains the application information we released, including the version number, release date, update summary, and download link of the new version of the installation package for each version.
- Every time the user opens the app, the app will request the json file, compare the latest version number with the current version number to check for updates
- Downloading an update is to download the latest version of the application installation package
- To install an update is to evoke a subprocess to run the installation package and exit itself. The installation package will handle the privilege escalation.
- Once installed by the user, one update is complete
5. Design product logic for automatic upgrade/update
In the stage of product logic (process design), it can be divided into 3 major blocks: weak update logic, strong update logic, and logic for checking updates to decide to enter the strong update/weak update process.
1. Check for updates
There are two problems with checking for updates, the first is what are we checking for? Here we can implement the check without relying on the back-end interface. As mentioned in the previous section, we record each version release in a json file, and then deploy the json file to the server. To check the update is to go to the server to request the json file. Then analyze and compare the latest version inside with the currently used client version to know if there is an update.
The second question is, what is the basis for judging whether it is a strong update or a weak update? Based on the above requirements split, we need to divide the strong and weak updates. The logic of strong and weak updates is different, so how to determine which update logic to enter in the update check phase?
The first method is to indicate in the json file whether each version is a strong upgrade or a weak update compared to the previous version, for example, there is an updateType field. The advantage of this method is that it is simple and clear. Even if the user's current version and the latest version are separated by several versions, as long as any one of the spanned versions is a strong upgrade, then this update is a strong upgrade , otherwise it is a weak upgrade. renew.
The second method, everything comes from the version number, the version number of "XYZ", compare the current client version and the latest version, we can keep X, Y unchanged, only Z (revised version number) changes as a weak Update, if the comparison finds that either X or Y is higher than the current one, then it is defined as a strong upgrade. This method does not require additional fields, nor does it need to compare the intermediate versions, only the current version and the latest version need to be compared.
Assuming we use the second way, the flow of checking for updates is as follows:
2. Strong upgrade logic
According to the previous requirement analysis, our strong upgrade logic is as follows:
Under the strong upgrade, once an available update is released, the user will be notified directly before downloading, and the notification method is to create a new notification window, which is a new rendering process in Electron.
Users cannot choose "next time reminder" or "skip", but only have two options: upgrade immediately or exit the app and upgrade again. It is worth noting that we use the "silent installation method" for the installation and update under the application exit and then upgrade process . From the user's point of view, when exiting the application, a Windows UAC pop-up window will appear (system level, unavoidable). , as for what UAC is, it will not be expanded here), after UAC, the subsequent installation process is transparent to the user, and the next time the user opens it, it will be the new version . This is because since the user has opted out, we assume that the user no longer needs to see the app install and then launch it, and then the user closes it again, but instead sees the new version the next time it is opened.
Instead of a silent installation method, the installation process and progress are visible to the user, and the application will automatically open after installation.
So how is this done? This is a feature provided by Inno Setup. When running the installation package, you can give command line parameters to control the performance of the installation program. We will talk about the specific implementation in the next article.
3. Weak update logic
Our weak update logic is simpler than strong update, and it is a more frequently used update method:
It can be seen from the process that weak updates are like updates that we often see. First of all, it should not disturb the user's operation, so we choose a lightweight reminder method. In practical applications, we use the same method as VS Code. The update reminder method is a reminder in the form of a floating bar attached to the main application window.
And we hide the download process. After the download is complete (that is, there is a fully downloaded installation package locally), the user is reminded that when the user clicks the update, in fact, it just runs the downloaded installation program, and the new version of the application is automatically opened after installation. The next reminder function means that the application will not be reminded again during the opening of the application.
4. Extension
How to solve the exception in the above update? Take a look at the most likely exceptions (referring to user operations, called BUG caused by programming), that is, the download process is aborted and the installation process is aborted. This is easy to solve. The download is suspended. For the sake of safety and simplicity, we do not use the method of continuing the download, but if the download is suspended, it means that the download is incomplete. We treat this situation as "no download", that is download again. And the installation aborted, the installer will help you.
There are also some applications where we can see the option to "skip this version", which is actually easy to achieve. Our "next time reminder" above is not reminded during this use. In fact, it is implemented by giving the program a global variable flag. For "skip this version", this version is no longer displayed every time it is opened. Update reminder, naturally we think of local persistence of data. To put it bluntly, put a mark in the user's local (or browser storage), and before each update reminder, go to the local to take it out and check it again.
6. Summary
This "Electron automatic update scheme: from requirements to design" ends here. I hope the above design scheme can give you some reference. For general application updates, it is enough to implement the above weak update logic. The logic of strong upgrade is actually It is to leave an opening for us to quickly push the update and iteration of the big version. In addition, again, each application has its own particularity. The update method of this article is only one of the many solutions for reference. The next article will talk about how we implemented it based on such a design.