Update checker
Contents
Overview
Every now and then, new versions of programs are released. Those who use old versions must be aware of the fact that a newer version is available.
You can expect them to visit your site every now and then, or to subscribe to your newsletter; but the best way to let people know about an update is to let the program do the check automagically.
Keywords
update, notification, changelog
Objectives
- Design and develop a mechanism that enables a program to verify if a newer version of itself is available.
- Let people know what's new in the fresh version.
- Help them make the update in a minimal number of clicks and with a reduced amount of pain
Requirements
There are no specific requirements for this assignment, you will have to devise them yourself.
Take a look at the grading policy, to make sure you get the result you want.
Grading policy
Assuming that everything works right,
- 7 - check for an update and return TRUE if an update exists;
- 8 - retrieve the changelog of the new version;
- 9 - download the update;
- 10 - install the update, taking care of the details such as:
- the current version may be running already
- the new version can have some unsatisfied dependencies
I will also take into account these details when grading the project:
- the beauty of your API
- the design of your protocol
Notes
Mechanism vs living example
Your task is to create a mechanism that verifies for updates, not an ad-hoc implementation for a program. Ideally, it should be a DLL that exports a few functions:
- VerifyUpdates (returns TRUE if updates exist, otherwise FALSE)
- GetChangeLog (if an update exists, returns a string that represents the changelog, or a HTML-formatted page with a prettified changelog)
- DownloadUpdate (downloads the update file[s])
- ApplyUpdate
After this is done, just include this DLL into your project and call its functions. You will have to write a few high-level functions on top of the ones above, to achieve this functionality:
- define the frequency of update checks
- the servers and ports that are used to look for updates
- something else that is specific to your application
Consider that in some cases the update checker must be extended, to do something else, or to provide some other information, ex:
- is the update free of charge?
- if it is not, what is the cost of the update?
- if the update is a huge file, can the download be paused/resumed? Can it quietly run in the background without eating all the bandwidth?
- is the update going to change something in the data storage format and break compatibility with old versions?
Web based applications
A case in which things may not make sense is if you are building a web-based application. If that applies to you, take this into consideration.
Web based applications are also applications, and they get updated from time to time.
You must write an update script that will conduct the same operations as the 'regular update checker' described above. It can be invoked in different ways, ex:
- called at regular intervals as a Cron job (on *NIX), or a scheduled task (if you're on Windows); in this case it would be wise to make your installer create that job/scheduled task.
- called every time a user with admin privileges logs on; if an update is available they can be shown a pop-up window, which displays the necessary information.
A web-based application can also retrieve files from remote servers, and depending on the circumstances, it can also modify files in the local file system.
In other words, there is nothing special about writing an update checker for web-based applications.