App Updater

Language

This project was written using the RealBasic programming language. A current Realbasic IDE must be used to properly read and build the project.

Platforms 

The project should compile and work on Win32, Linux+GTK, and Mac OSX. Extensive testing has only been performed under Win32.

Requirements

To fully use this project in a program, you will need to be able to upload files to a web server which can be accessed by anyone via HTTP.

Additional Downloads

• RB2009-XML Source
• Program flowchart (PNG/32KB) (outdated)

Internal Properties And Their Meanings/uses

• cancel
  • This property is instantiated as false and gets set to True if the user clicks on the cancel button in updateWin.

• currentversion
  • The numeric version number of the current app. This value is a double so that decimal numbers like 1.005 can be used. Version numbers like 1.21.32 or 1.43a cannot be used unless you change the datatype to Variant or String. If you change the datatype, you will need to change how the class compares the currentversion value with the newversion value in the checkforupdate method.

• isSilent
  • This is a Boolean value which is set by passing a boolean in to the checkVer method (which is how you should call this class, see the MainWin.Pushbutton1 & 2 Action event). When set to False, the updateWin is shown throughout the process. When set to True, the updateWin is only shown if a new version is available and the user is prompted to download the new version. Set this to True if you plan on using some method which will call this class periodically, as in an automatic update scheme.

• update
  • This Boolean value is used by the class in the DownloadComplete event to decide which set of code to execute. You should not alter this property.

• updateaddress
  • This is a string value that needs to be changed to point to the small text file on your web server that contains information about the latest version that is available. Throughout this class, that file is named myapp.upd. As this is merely a text file, it can be called anything you want. However, if you choose a name other than myapp.upd, you will need to change all references to myapp.upd accordingly. In the comments throughout this class, I refer to this file as the update file. This should not be confused with the upgrade file, which is the actual updated version of the program. so, update = text file, upgrade = executable (or archive)

• usebrowser
  • This is a Boolean value which is by default set to False. Set this value to True if you want to launch the updInfo(3) address in the user's browser rather than directly download it. This is useful if you host your upgrade file on a third party server that doesn't allow direct downloads like File Hippo or Download.com. If you set this value to True then make sure that the updInfo(3) value points to the appropriate web page.

Definitions

Throughout the comments I try to use a uniform set of terms to discuss various things. Here's the word list:

update, upd I use the term "update" or the abbreviation "upd" to refer to the act of checking for an updated version of the app. I also use it to refer to the small text file that's downloaded containing the version information (called "myapp.upd" throughout) The property called "update" is used to determine whether the current file being downloaded is the update file or the upgrade file. It starts out as false and then is changed to true in the checkforupdate method.

upgrade, upgrd I use the term "upgrade" or the abbreviation "upgrd" to refer to the actual file that will upgrade the app. This could be an executable file, an archive file, whatever.

The myapp.upd File Notes

The myapp.upd file is the core of this entire excercise. It contains the necessary information to compare the latest version number to the current version number, the location to download the latest version from, the name of the program, plus options to display a customized message to the user before downloading and controlling how the upgrade file is handled.

The basic structure of the myapp.upd file is like this:

//Begin Update File
Name=My Super App
Version=1.1
URL=http://www.boredomsoft.org/Test/update.rar
Require Confirm=Yes
Confirm Title=Please Read This
//Blah blah blah
Confirm Message=You must agree to give me your soul before downloading. Click OK to agree
Filetype=arc
CheckMD5=yes
//Blah!
MD5Sum=b5eb1515c9246d07c9e500a2d2d57ea3

Basically this is a key=value system. Key names musn't be changed, but the values can contain any data in string form (strings cannot contain equals signs, though.) Comment lines are denoted by double slashes: //

The key=value pairs can be given in any order, interspersed with any number of comment lines. One key=value pair or comment per line!

Of the nine key=value pairs, six are optional and three are mandatory. The mandatory ones are:

• Name=
• Version=
• URL=

The four optional parameters that you can use are:

• require confirm: if you include the Require=Yes key=value pair, then the program will display a message box prior to downloading the upgrade
• confirmTitle: if the "require=Yes" pair is present, this is the title of the message box that will be presented
• confirmMessage: if the "require=Yes" pair is present, this is the text of the message presented
• filetype: defines how the program should handle the upgrade file. Currently, only the "exe" option is honored. The other option, "arc", is the default behavior anyway.
• CheckMD5: yes, or no. Whether or not to check the file's MD5Sum
• MD5Sum: The hex representation of the files MD5 checksum.

Key=value pairs are NOT case sensitive.

Further Notes on the App Updater Project

This project, in its current form, is intended to be an easily added module to any existing RealBasic application. To an extent, I believe, it accomplishes that goal. Almost all the code in the project is contained within a single HTTPSocket class which can be copied and pasted into pretty much any kind of GUI desktop program that can be made with the RealBasic language.

The project is now also rather well documented, I think, so that even fairly novice programmers can understand, at least in principle, how the flow of the code works and what is going on. As always, any feedback is welcome.

When creating this project, I initially did not intend to make it available to other developers. It was going to be a strictly internal resource to be used in my own projects. In accordance with this, initial versions were kludgey, ugly, and completely undocumented. When I decided to make it available, I resolved myself to rectifying these deficiencies.

Documentation is one area, as I mentioned, that I have succeeded in. Almost every method, event and property has inline comments. Initially, these comments were included on the same line(s) as the code they were describing. I found that this made the code harder to read and understand rather than easier, so this was changed early on. Now most comments can be found before the code and speak in slightly more abstract terms than the original line-by-line comments did.

Kludginess and ugliness are somewhat harder to deal with, however.

I've already dealt with what I felt was the kludgiest and ugliest part of the original implementation: the structure of the .upd file and how its data are stored in the program. Initially, the structure of the file was extremely rigid, simply an exclamation point-delimited line of parameters in a specific order. This line of data was then read by a simple Nthfield line of code and fed into various propertied such as "UgradeAddress as string". I was not happy with this at all.

So, one of the first things to go was this rigid structure. I wanted to make the file more of a key=value type file and to allow the data to be ordered arbitrarily rather than rigidly. This I accomplished in a manner much simpler than I had feared necessary by simply looping through a Select statement and assigning specific values to a null-instantiated string array. Much, much cleaner in my opinion. I was even able to allow for comment lines!

The only real constraints I imposed on myself when redesigning the .upd file was that I insisted that no matter what it should fit into a single packet and the server should not be responsible for anything but delivering that packet. This is very advantageous since the update check will therefore only require the exchange of five packets total; all the logic is handled on the client side and is therefore compatible with any HTTP compliant web server: even the barest of minimalist servers can deliver a single-packet-sized text file.

Several things, however, continue to bother me about the current implementation. One, the possible values of version information is restricted to numeric doubles (that is, double-precision numbers like 1.0 or 2.5) One cannot, currently, check version information outside of this very narrow definition. A version number like 2.5.3 or 1.4b is invalid and won't work. I'm trying to think of a way to make these possible without thereby restricting the version information to yet another rigid format while avoiding writing different comparison routines for each (or every!) possible format.

Annoyance number two is rather easier to correct, I just have to get around to it. It is that all client-side information, such as the current version or the URL of the update file, must be hard coded into the program at compilation time. This will be replaced by a configuration file in the near future (I will not be storing the info in the Windows registry as this project aims to be cross-platform.)

 

Write a comment

• Required fields are marked with *.
• All comments must be approved before they get published

Name:
Email (Read Our Privacy Policy):
Subject:
Comment: *

Frie
Posts: 2

updater does not end
Reply #3 on : Tue December 13, 2011, 05:05:31

---

Mac osx 10,6
it seems that the updatewin does/is not close,
even when silent , iff you call something like "updateWin.Status.Caption" this window is opend. this will cause the app.autoquit= true to fail, because the updatewin is not closed.

ihave made changes in

checkforupdate
launchUpdate
handleException
ReceiveProgress

So i can run this at startup programme, i also build in a connect internet methode to check this the connection.

Fore me this works
thanks very much

admin
Posts: 1

Re:
Reply #2 on : Sun December 11, 2011, 05:12:19

---

@Frie Under what OS?

Frie
Posts: 2

updater does not end
Reply #1 on : Sat December 10, 2011, 04:43:09

---

the class looks fine but in silent run or when canceling the download or installation, programma hangs so you can click the closs cross it does not stop, you have to use programme stop from the menu.