Sparkle

What's the best way to abort an update in progress?

Asked by shs

After the appcast is downloaded the delegate method updater:didFinishLoadingAppcast: is called. I peek inside the appcast and if there's a special key there, I need the update to abort _silently_.

1. I see abortUpdate in SUUpdateDriver, but it was not made accessible. Which makes me think this is the wrong approach.

2. I tried bestValidUpdateInAppcast:forUpdater:, and returning nil if the update should abort, but it puts up a dialog.

What's the best way to abort an update silently?

Thanks!

PS - 1.5b6. :-)

Question information

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

Hm. There isn’t really a method for exactly this because the methods you describe will only show a dialog if the update was user-initiated. And if the update was user-initiated, then it shouldn’t fail silently.

Revision history for this message
shs (sanford-sparkle) said : 		#2

Hi Andy,

  I'm basically looking to check whether or not an update is a paid upgrade. If the "paidupgrade" key is flagged in the appcast, I want to give the user a chance to cancel before Sparkle downloads/installs an update that will cost money. And this requires aborting Sparkle's update progress.

  I guess I could modify Sparkle like this:

  1. If the update is a paid upgrade, temporarily disable the default to download updates silently.

  2. When the description appears, put up an additional warning (that I could return from a delegate method) to give the user a chance to cancel.

  I was just trying to do this without modifying the Sparkle source. I guess I'm a purist. :-)

  Is there a better way to handle a paid upgrade that I'm missing?

Thanks!

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

Oh, I see. Paid updates are really something we should handle better.

I think you should probably just modify Sparkle’s source. It’s supposed to be a little extensible, but I guess not this extensible. :/

I think that rather than having an extra dialog (distracting!), the update alert should have a big green band across the top of it denoting that this is a paid upgrade or something.

Revision history for this message
shs (sanford-sparkle) said : 		#4

Certainly. Or perhaps an "are you sure" sheet when the user OKs an update. I can easily add a bright red "PAID UPGRADE" to my localized appcast.

I've spoken with a few developers about this. It would be a very good direction for the next Sparkle. Allowing developers to specify the upgrade text would be even better. :-)

Thank you for the assistance and a wonderful framework!

PS - When is sparkle going to move beyond 1.5b6 anyway? :-)

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

Good question! My to-do list is a priority queue. Always at the top of the list is “that problem set that’s due tomorrow.” The next version of Sparkle is only a few items down on the list. However, Caltech is cleverly designed such that there’s ALWAYS a problem set due tomorrow, and it always takes all day to complete. Therefore, I never get past the first one or two items on my queue.

I guess what I’m trying to say is: when I can. :/

Can you help with this problem?

Provide an answer of your own, or ask shs for more information if necessary.

To post a message you must log in.