问题
Simply put, how would you design an application that supports straightforward and reliable auto-updating?
I'm interested in how it could be cut up and the various operations involved.
Edit: This is linked to this question: Self-destructing application
回答1:
Concerns that need to be dealt with:
If the app that does the updating is itself being updated, a restart is going to need to occur, or a stub would need to be executed to move the file into place (to avoid a file-in-use error.)
Whatever service you're communicating with to retrieve files via a web request would need to know what current version of installed package you're running. It would dynamically build the file URL list and maybe even zip up a file and put it out at a single URL for the client. Otherwise, have the client walk through the URL list, pulling each file. Each URL would be associated with an operation, such as 'copy' or 'execute'.
Process each retrieved file and install it to the client.
Update needs to be atomic (ability to rollback if any part of the operation fails.) You don't want to be left in a partial state.
回答2:
Java Network Launch Protocol does a great job of making it easy to deploy auto-updating software. Some people on this site have reported issues with it, but that may be due to using older versions of Java or not correctly setting up the JNLP file. I have found that it works great on Mac and Windows and on a PC at work without logging in as an administrator, I was able to effectively "install" my software. From the user's persepctive, it is just like I gave her a new desktop app. There is a program icon on the desktop and files saved by my program are associated with it - windows gives them the right icon and when you double-click them they open. But every time she runs the program, JNLP first checks her locally stored JAR files against what is on my server and if her files are older than the ones on my server, the software gets updated. The programs still launches as fast as a native windows app, except for the first time when it has to download everything.
Now to make the program self-destruct, here are two options:
Change you jar files on the server to be short and useless. The user launches the program, it updates, and then they see a dialog box telling them that the program is no longer available. You can also disable features this way. But this will affect ALL the users at once. You could create several different JNLP files, each for a different class of users with the same time line for your app to live, you could even have a service generate the JNLP file. But the control to disable it will still come from you changing the jars on your server.
When the program starts it first contacts a web service to verify that the program should still be running. You can create a database table associating your users with which features they can use now. If your users do not register, you would need to somehow create an id for them when they first run the program, place it on the db table and store it on the client's computer using the preferences api.
If you are unfamiliar with using JNLP to autonate updates, here is some background to help you get started:
A JNLP file is an XML file that describes where your application is stored on-line and which JAR files it needs to run. Various properties of the app are also specified, like a splash screen, desktop icon, the updating style (always ask, just upate without prompting, update in the background) and which files to associate with the program.
Read the JNLP developer guide for detailed insturctions on how to get it working.
You can also see numerous examples on-line. In Chrome the default behavior of a JNLP file is to just save it, in other browsers you may need to right-click and save as, but that only works if there is a direct link to the file and not a fancy javascript button. You can then open the JNLP file in your favorite text editor as an exmaple.
The swing tutorials use JNLP files to demonstrate the code.
来源：https://stackoverflow.com/questions/10109340/design-of-auto-updating-software