Sparkle

How to migrate from SUStatusChecker to SUProbingUpdateDriver?

Asked by dwood

We're using SUStatusChecker delegate methods from SparklePlus. Your 1.5b1 release notes say "SUStatusChecker is dead. Use SUProbingUpdateDriver." This is really not clear, because SUStatusChecker is still there (for backwards compatibility?) so I wouuldn't call it "dead" ("I'm not dead yet!") ... And I don't really see what the migration path would be to SUProbingUpdateDriver and its delegate methods are. It would be helpful to get this documented.

Question information

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

Call checkForUpdatesWithDriver: on SUUpdater, providing a SUProbingUpdateDriver. Like:

[[SUUpdater sharedUpdater] checkForUpdatesWithDriver:[[SUProbingUpdateDriver alloc] init]].

Right now, the delegate methods between that and SUUpdater are duplicated, which sucks. They may change around in my efforts to fix them.

Revision history for this message
dwood (dwood-karelia) said : 		#2

OK, thanks -- I'm making a static variable on the SUProbingUpdateDriver so that I don't leak every time somebody chooses our CheckForUpdates menu item.

There are some other migration tasks I'm trying to accomplish, and the things to change are not obvious from the headers or even the source code:

* In my prefs dialog, I used to call -[SUUpdater scheduleCheckWithInterval:0.0] to cancel the checking if somebody chooses no checking. Not clear how to do this now...

* I would call [SUUpdater checkForUpdatesInBackground] myself to force the updater to silently do a check (for betas, right after an expiring beta has just warned the user of expiration, or right after the user has launched the application for the very first time and specified that they want the application to check for updates. This method is no longer exposed in the headers. Should it be?

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

I'm very sorry about the total lack of documentation. Keep asking questions if you have them; I'll answer as quickly as I can.

The update driver will be released by the SUUpdater when it's completed, though, so you don't have to worry about the leak.

If someone chooses that they don't want to check, just set the preferences key for that (SUEnableAutomaticChecks) to NO. SUUpdater will pick up on it. So long as you're using a normal .app. If you're using some weird bundle thing, call [[SUUpdater sharedUpdater] updatePreferencesChanged] to let it know.

I think I'll probably expose that method again, since it's a useful convenience method, but it's equivalent to [[SUUpdater sharedUpdater] checkForUpdatesWithDriver:[[[SUScheduledUpdateDriver alloc] init] autorelease]].

Revision history for this message
dwood (dwood-karelia) said : 		#4

Thanks Andy Matuschak, that solved my question.

Revision history for this message
Hofman (cmhofman) said : 		#5

> The update driver will be released by the SUUpdater when it's completed, though, so you don't have to worry about the leak.

No, it won't (unless you use GC). The leak is in your example, it should be (note the extra autorelease):

[[SUUpdater sharedUpdater] checkForUpdatesWithDriver:[[[SUProbingUpdateDriver alloc] init] autorelease]]

> OK, thanks -- I'm making a static variable on the SUProbingUpdateDriver so that I don't leak every time somebody chooses our CheckForUpdates menu item.

Don't do that, SUUpdateDrivers are one-shot objects, they can't be reused.
This illustrates why SUPdateDriver classes should not be exposed publicly.

BTW, for clarity it is probably better to rename updatePreferencesChanged to something like resetUpdateCycle, as you may want to use this also in other situations where you want to restart the update cycle (when no pref has changed). E.g. for a bundle that is loaded after the app was already launched.