Sparkle

Changing SUFeedURL before instantiation

Asked by Jeremy Sequoia

I'd like to use different feeds for different levels (beta, release candidate, production). I see that this is possible using SUUpdater's setFeedURL: method.

Question #50424 indicated that this is the preferred method, but I am worried about a possible race condition. When the application starts up, the SUUpdater class is instantiated using the default URL, so it may tell the user about updates from the default feed before I have a chance to set the correct one.

Is there a way, instead, to set this in NSDefaults, so SUUpdater can have the correct value when it instantiates?

Question information

Language:
English Edit question
Status:
Solved
For:
Sparkle Edit question
Assignee:
No assignee Edit question
Solved by:
Hofman
Solved:
Last query:
Last reply:
Revision history for this message
Best Hofman (cmhofman) said : 		#1

The first update check will never be performed before the app has finished launching (because it's triggered by the main run loop, which does not start till after -finishLaunching). For an app the preferred place to change updater settings is the NSApplication delegate method -applicationWillFinishLaunching:, which is guaranteed to be called before that time.

If you first instantiate the updater in code (as you'd to do for a non-app bundle), there's really no problem, because the first update check will never be performed before the methods in which you instantiate the updater has finished (because it waits till the next step in the main run loop).

So in short, when you do things right, you don't have to worry. This is true for any of the available settings.

Directly changing the defaults, though possible, is not officially supported, so you shouldn't do that. Pref keys are left private for good reasons. Moreover, it doesn't solve anything (you could ask the same timing question).

Revision history for this message
Andy Matuschak (andymatuschak) said : 		#2

This behavior is not very clear or intuitive, though, and I can see why it doesn't feel "safe".

Sparkle's API needs some overhauling, but that'll have to wait until a distant release because I promised I wouldn't change it any more for 1.5. :)

Revision history for this message
Jeremy Sequoia (jeremyhu) said : 		#3

Thanks Hofman, that solved my question.