Autoupdater > Programmernotes > Programmer Notes (All Contents)
This section delves into programmer level information about AutoUpdater.
These notes cover things like class structure, class responsibilities, and how AutoUpdater works from a programmer's point of view.If AutoUpdater was a locked library, the only external class would be:
Consider the AutoUpdater Startup_Task to be the Application Programmer Interface to the AutoUpdater library.
Most of the Startup_Task methods forward messages they receive to oStartupTaskDefaultMethods.
The oStartupTaskDefaultMethods methods work mostly with the instance of oUpdater that has been instantiated using the startup task variable updater.
There are lots of classes inside AutoUpdater, but wherever possible they should call oUpdater through the updater startup task variable.
When passing lists of packages and files around inside AutoUpdater do not worry about parsing the packagefilename or the serverfilename for user friendly display purposes. The only time you need to think about parsing those names is when you display them to the user. The oUpdaterTools object has methods for adding display columns and parsing the packagefilename and the serverfilename info to those display columns. Don't confuse the GUI display information and related code with the files server names and code.AutoUpdater is designed to work either a database or an FTP site for the files server.
FTP is the most limiting so AutoUpdater must work within the constraints of the file name for storing the release information of each file that is uploaded to the files server.
The syntax for the server file name is as follows:
TargetFileName___ReleaseDateTime[ReleaseType][_EnvironmentVariables].FileExtension
TargetFileName is separated from the ReleaseDateTime by a triple underscore.
ReleaseDate is in the format: YYYYMMDD_HHNNSS
ReleaseType is optional: b=Beta. The absense of a ReleaseType indicates a final release.
The EnvironmentVariables are separated from the ReleaseDateTime/ReleaseType by a single underscore. Each environment variable is prefixed with a single underscore, so the there is really a double underscore between the ReleaseDateTime/ReleaseType and the first environment variable.
Environment variables are optional. Each variable begins with an underscore character, and a single lowercase letter prefix indicating the environment variable type, followed by uppercase letter(s) indicating the environment variable value.
The following is a list of environment variables:
: _pM=MacOS9, _pX=MacOSX, _pN=Win32, _pU=Linux
: _uU=Unicode, _uN=Non-Unicode
Version: v4 = Omnis version 4.0 or greater, v41 = Omnis version 4.1 or greater
The absense of an environment variable indicates that the file is compatible across all environments of the non-specified variable. If no environment variables are specified for a file, the file is compatible for all platforms, both unicode and non-unicode versions of Omnis Studio, and all release versions of Omnis Studio which your client has runtime versions of.
More environment variable can be added to AutoUpdater with relative ease.The AutoUpdater folder structure on an FTP server is as follows:
An AutoUpdater root folder is required on the FTP server, the root folder name is lowercase autoupdater
A package subfolder is created inside the autoupdater root folder for each package that you declare and create. The package folder name matches the package name.
When you upload a package to the server, the package description text file is stored inside the package folder.
A files subfolder is created inside each package subfolder. All of the files for a package are stored inside the files subfolder. As you upload newer versions of different files for a package, the number of files in the files subfolder increases. The file names are unique because each newer version file has a different ReleaseDateTime in the server file name.If a database is being used for the files server AutoUpdater creates the following tables in the database:
The serverpackage table has 3 columns
The serverfile table has 3 columns
The files server classes are subclassed from oFilesServer_abstract which provides the public methods that must to be supported by each subclass.
oFilesServer_DB handles requests to the database files server.
oFilesServer_FTP handles requests to the FTP files server.
The files server classes ignore any GUI related columns which may have been added to lists. The files server classes only look at and calculate files server related columns.