Since we bind the disabled state of the “Check Now” button (in preferences) to this property, we cannot update the property in a background thread, as the UI can only be updated from the main thread.
Use int64_t instead of NSUInteger, check against NSURLSessionTransferSizeUnknown, and ensure that completedUnitCount is the last thing we set on the NSProgress object, so that there is no potential race condition with a progress object being completed, but still having a non-zero estimated time remaining value.
We either set it explicitly or rely on automatic key view loop calculations.
As for the latter: When auto-layout was initially introduced, the automatic key view loop calculation broke, as it used the view frames before layout. It should have been fixed several OS versions ago though, so we can use it again, as long as we are not working with view-based table views.
Changes:
- Use NSURLSession and OakDownloadManager to download updates (instead of libcurl).
- Use NSFileManager’s replaceItemAtURL:… to update the application bundle (instead of custom code).
- Use NSTask to relaunch the application (instead of fork/exec).
- Use the same window for the initial prompt, and for showing download progress.
- Show estimated time remaining in download window (via NSProgress).
- Allow retrying downloads on various forms of failures.
- Don’t require xib file for download window.
Regressions:
- We no longer support updating the application as root: I tried using an authorized NSFileManager instance, but it did not work for me, and the previous code we used for this was using legacy APIs.
This was done using search and replace. Presumably it should be done in Xcode so that it can adjust the xib for the new deployment target, otherwise what is the point of storing deployment version in the xib and provide it as a command line argument to the xib compiler as well (only to get a warning if the versions do not match)?
Since we have multiple application targets, it doesn’t make sense with a global APP_NAME variable.
Though if building the frameworks as standalone bundles and embedding them in different applications, we may need some sort of unique component in the bundle identifier, but we currently do not do this (they are all statically linked, so the Info.plist is currently unused).
Although this is actually deprecated in 10.10, new APIs are available in 10.9 and it will make addressing deprecation warnings when upgrading to 10.10 easier.
