This allows us to remove SPUUserDriverUIComponent and remove a bunch of logic in the user driver regarding termination. The user drivers generally don't need to know about the application bundle anymore, and strictly now only show UI events.
This has another advantage of the agent being able to quit multiple instances of an application even if the application to update is sandboxed.
We enforce the logic that an application can only be relaunched if it was running initially.
These changes are to make XPC environment more friendly. Every reply block must
get a response and is not optional to respond to. For example we can no longer have
a reply block that is just "cancelUpdate()"; it must now take an option whether
we are done now or if we want to cancel, and the receiver should now be aware
when canceling doesn't make sense (i.e, if update already aborted). Furthermore,
a reply block must get exactly *one* response.
non-void/synchronous calls over XPC don't work properly, and
these methods don't seem very proper architecture wise anyway.
A proper solution will be needed for notifying the delegate of modal alerts
If an automatic update needs to be applied at termination,
the app delegate will need to hold responsibility of delaying
termination until Sparkle is ready to relaunch
Note that the protocol API for the user updater driver can still be improved.
applicationWillTerminate: is done from the user driver because that's the only way that will
function across different processes.
We support NSSecureCoding for SUAppcastItem and SUHost
Callbacks from XPC <-> Host app now async to main GCD queue.
This is needed for everything to be thread safe.
Todo: NSDate parsing sucks and is temporarily disabled.
In particular, we're using deprecated methods to read the dates,
which don't support NSSecureCoding. The other problem is that the dates are
really useless technically and we shouldn't sort by them.
Everything related to the protocol is intended for showing & dismissing progress,
as well as making UI actions such as canceling, installing, confirming update permissions
This is still incomplete and not perfect yet.
In particular, these delegate methods ought to perhaps be grouped in a separate class.
The UI code that is currently done should be treated the same manner as a custom UI
Relaunching Sparkle should give customization over showing the UI of the autoupdater app
Zorg
Philippe Casgrain
Bryan Jones