Sparkle

How to stop background checks ?

Asked by Luc Claustres

I am very new to Sparkle, Cocoa and all of this but I am testing it with my Carbon app and seems to work pretty good !

I do updates trough a C function because my app is written in C++ and I don't think it is possible to directly use Cocoa objects inside.
Moreover, I use the setHostBundle method as my app is not a Cocoa one and I don't know how to manage this another way.

The only problem I have at the present time is that when I launch a periodic check on app's start using checkForUpdatesInBackground, then if the user force a check trough the GUI with checkForUpdates, Sparkle says that the previous check is still running.

How can I force the periodic check to finish if still running ?
Actually, it seems that the check should not be running because even after minutes I still get this message, so tell me what I am doing wrong...

Thanks in advance for help.

Here is my check function :

void CheckForUpdates(bool p_Silent)
{
 if ([[SUUpdater sharedUpdater] updateInProgress])
 {
  OREALIA_LOG_WARN("Check for updates is already in progress.");
  return;
 }

 // For automatic updates (silent mode), interval is defined within plist file in seconds
 // For instance a week will be :
 //<key>SUScheduledCheckInterval</key>
 //<string>604800</string>

 // Wich bundle do we update ?
 NSString *l_BundlePath = [NSString stringWithUTF8String:GetMacBundlePath().c_str()];
 NSBundle *l_Bundle = [NSBundle bundleWithPath:l_BundlePath];
 [[SUUpdater sharedUpdater] setHostBundle:l_Bundle];

 if (p_Silent)
  [[SUUpdater sharedUpdater] checkForUpdatesInBackground];
 else
  [[SUUpdater sharedUpdater] checkForUpdates:nil];
}

Question information

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

That's interesting. The background check should time out after 60 seconds if it failed. It must have hit an exception or something which killed the updater. Anything interesting in the console?

Revision history for this message
Luc Claustres (luc-claustres) said : 		#2

Nothing special in the console. The check time out seems to be much more than 60s (many minutes). Even when it succeeds it takes many minutes before bringing the update window in front.

However, my app is a 3D rendering application that draws permanently, i.e. the CPU never idles. Maybe this can explain the extra time to check...

Anyway, how can I cancel the current background check when the user forces another one ?

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

That's very odd. Can you send me the source? (<email address hidden>)

There's no functionality in place to cancel a check, since it's supposed to resolve itself quickly.

Revision history for this message
Luc Claustres (luc-claustres) said : 		#4

Well my application is so big I can't send the source.

It is based on the Trolltech Qt framework for GUI, which is Carbon.

Can the problem comes from the fact it is not a Cocoa application ?
How do you manage the backgorund check, through a thread or using the event loop ?

Thanks for help.

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

The problem could conceivably come from that fact, but I'm not sure exactly how it would.

The fetching of the remote appcast occurs on a separate thread; the version checking logic and UI occur on the main thread.

I'm afraid without source that I can't be of much more help. I'll keep thinking about it, but in the meantime, you might just try stepping through the background check with the debugger and seeing if anything unexpected is going on.

Revision history for this message
Luc Claustres (luc-claustres) said : 		#6

Didn't try to debug right now, do I have to build a debug version of Sparkle from source for that ?

However I noticed something really strange, if I show up a file dialog before checking then it works.

My check was performed before the event loop was launched. I tried after but does not seem to be better.

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

Yeah, you'll have to build a debug version of Sparkle. The file dialog bit is interesting, but I can't think of why that might be causing this.

Revision history for this message
Luc Claustres (luc-claustres) said : 		#8

We've just found out that calling NSApplicationLoad() solves the problem.
This seems to be mandatory when using Cocoa within a Carbon application.