Paul Lynch's Pages

I have created two Amazon booklists, one for WebObjects, the other for Cocoa.

They should show up if you do a search on Amazon (UK only, I think), for “Cocoa Programming”, or “WebObjects”. I don’t get any referral fees from these lists, so they are a labour of love, and I intend to keep them updated should any new books be released on either topic. On most classes I carry in most of the books on the list, and talk a little about them in the wrap up session; for the last couple of classes, since I made the lists, I am also mentioning the lists, and showing them on the screen.

I may make a similar list for classic Unix books, my main problem with that is finding them all in the garage.

It seems that almost every new app you see out there has an on-line version checking system. I remember when the first ones started to appear in Cocoa land (probably from Omni), and I sort of coasted and ignored them. Anyway, this week I was running a Cocoa class, and the question arose. There’s an article on CocoaDevCentral on the subject, but I didn’t like the way it was written – the author starts by assuming that he’d have to write some PHP server side code to handle it, and shows that first, before moving on the the real meat.

Thinking about the problem, we have to be able to uniquely identify our app and recognise its version (that’s easy), and access data over the Internet using a URL. So let’s start with these two.

All Cocoa apps include a Resource called Info.plist; we can edit it directly, or use Xcode inspectors to change values. These include an app identifier, and a version string, which are used for storing user defaults uniquely, and in the standard About panel, respectively. This file is used in all bundles, and we can access the bundle for your application by:

[NSBundle mainBundle]

NSBundle returns bundleIdentifier, which is suggested should be in a unique form like that recommended for Java classes; eg com.plsys.MyApp. It also returns infoDictionary, which is a dictionary of all Info.plist values. The key used to store the version string is CFBundleVersion. So far we have:


NSBundle *app = [NSBundle mainBundle];
NSString *ident = [app bundleIdentifier];
NSDictionary *infoDict = [app infoDictionary];
NSString *myVersion = (NSString *)[infoDict valueForKey:@"CFBundleVersion"];


The next step is to find out how to retrieve our current version information over the Internet. You are going to need a place to store this – any web site that you can update will do: for my example, I just used my .Mac homepage. I need a very small amount of space to hold a text file with the version information, and extra if I want (optionally) to have the user download the latest version of my app from there as well – or from any URL.

Foundation provides a useful class for dealing with Internet content, called NSURL. So we could implement all we need using NSURL, but several other classes make use of NSURL as part of an initialiser. One that is very convenient for us is NSDictionary:

NSDictionary *plist = [NSDictionary dictionaryWithContentsOfURL:[NSURL URLWithString:[self versionURL]]];

The NSURL acts as a holder for our URL string, which can supply the contents of that location to NSDictionary’s initialiser. NSDictionary requires a string in a valid plist format, which can be the property list version of XML that Apple have adopted, or the traditional property list format. I find the latter easier to read and sufficient for the purpose. Property lists are composed of expressions, which are C-like values. If these are a ; separated list of assignments enclosed in {}, then the assignments are keys for a dictionary; if they are a comma separated list of values enclosed in (), they represent an array.

A dictionary, keyed by our application identifier, should be sufficient. If the contents of the dictionary are themselves dictionaries, this is a flexible system we could expand for any new ideas we get. Initially, I will use two keys to this dictionary: version, and url. Version will return a version string to compare against the bundle version, and url will be an optional location that will contain the latest version of our application.

NSDictionary *versionDict = (NSDictionary *)[plist valueForKey:ident];
NSString *currentVersion = (NSString *)[versionDict valueForKey:@"version"];
NSString *downloadURL = (NSString *)[versionDict valueForKey:@"url"];

At this point, we have enough information to perform a version check. The only remaining problem to solve is to start a download of the latest version. Again, this is easy to do, using NSWorkspace, which has the ability to open any file/URL for us.

[[NSWorkspace sharedWorkspace] openURL:[NSURL URLWithString:downloadURL]];

That’s all.

My approach to using this code is to create a utility class that can be dropped into all my projects. all it needs is one accessor pair, for the instance variable used above called versionURL, and one action-like method to perform the version check (checkVersion: ). As defined, this class should be instantiated in a nib file so that the action method can be called from the application menu.

Then to use it:

- (void)awakeFromNib {
[versionChecker setVersionURL:@"http:////homepage.mac.com/paullynch/version"];
[versionChecker checkVersion:self];
}

Finally, the contents of my version checking plist file, which is at the URL above:

{
com.plsys.TestBed = {
version = "1.1";
url = "http:////homepage.mac.com/paullynch/TestBed.tar.gz";
};
}

This must end with a return.

You can download an example application including all the code and the utility class mentioned above.

This is more complex than it needs to be, for unobvious reasons. The problem, succinctly stated, is implementing regular expressions with Java.

For historical WebObjects reasons, I have not had easy access to a regexp library. Java people have used the open source JEdit libraries to implement regular expressions, but with WebObjects this was too much like hard work. Now, with Java 1.4, we get java.util.regex, and a couple of regex methods added in to the String class. These support full regular expression patterns, like I would expect to find in sed, awk and perl.

With WebObjects, I could use the array split and combine functions to implement a simple replace method:


static public String replace(String a, String b, String text) {
NSArray bits = NSArray.componentsSeparatedByString(text, a);
return bits.componentsJoinedByString(b);
}


As I am always frustrated by the inflexibility of Java, I had to extend this to take a dictionary of parameters – keys being the search string, values the replacement:


static public String replaceFromDict(String text, NSDictionary dict) {
String result = text;
if (dict == null) return result;
Enumeration i = dict.keyEnumerator();
while (i.hasMoreElements()) {
String key = (String)i.nextElement();
result = PLUtilities.replace(key, (String)dict.valueForKey(key), result);
}
return result;
}


This was sufficient with Java 1.3. I used it to deal with form mails, using fixed parameters to replace with user names, etc. Mostly to implement a “forgotten password” routine for my stock login procedures.

Today I had a different problem. I was creating multipart emails using WebObjects components to generate the html. I already knew that the standard WOMailDelivery routine generates emails, with just a single html content, that gets caught up in SpamAssassin. The fix for this is to convert the email into a multi-part email, and give it a text content part. This is reasonably easy, although laborious. So I needed to create a plain text counterpart to a component html; the simple solution is to write a de-html routine. This has to rely on intelligent creation of the component to work successfully.


static public String dehtml(String value) {
String result = new String(value);
NSMutableArray patternArray = new NSMutableArray();
NSMutableArray replaceArray = new NSMutableArray();

for (int i = 0; i < patternArray.count(); i++) {
result = result.replaceAll((String)patternArray.objectAtIndex(i),
(String)replaceArray.objectAtIndex(i));
}
return result;
}


This version uses the String replaceAll method, which works just fine. The only trap in creating the patterns was the second string, which replaces white space with a single space: the Java compiler requires you to write \\s rather than \s. The final pattern to remove all html tags needs to use the “reluctant” form, with the ?, as the simple </+> pattern will otherwise eat up the entire string from first tag to last.

I am used to using the old (deprecated) WebObjects NSTimestamp class to do basic arithmetic on dates; it was easy with one method call to add an arbitrary number of days/weeks and get the correct date, or even to calculate the difference between two dates. In the new (release 5.0, so not that new) world of WebObjects, these methods are deprecated, although they do still exist. I see that NSTimestamp is a subclass of Date, so that lets us into the world of pure Java. The documentation points you to GregorianCalendar for further edification. A bit of scanning around shows me that Date has an add() method; for differences, use this: double days = (toDate.getTime()-fromDate.getTime())/1000/60/60/24; Seems very crude to me. It will calculate a date interval in days, meaning 24 hour periods rather than midnight transitions. It will also round down, courtesy of the cast to (double), which is necessary to prevent a “loss of precision” compiler error.