Steve McCabe:
The developers of Perian, the free and extremely popular video format extender for QuickTime, have announced that they are ceasing work on the project. In a statement on the project’s Web site, the developers have said that it’s time to move on, their goal of making video content playback easier on the Mac having been met.
There are plenty of standalone Mac video players. Perian is interesting because it enables any application that supports QuickTime or Quick Look to play additional formats. QuickTime once had built-in support for playing Flash videos. These days, Apple would rather promote its preferred video formats than ensure that applications on its platform can play files that users encounter in the wild. (Imagine if there were popular image formats that Safari and Preview couldn’t display.) I haven’t been following the QuickTime API very closely, but my impression is that ever since QuickTime X in Snow Leopard, the entire plug-in system has been deprecated, with no replacement.
Drew McCormack:
I’ve spent the last 3-4 months integrating Core Data syncing over iCloud into Mental Case for Mac. It is not in the wild yet, but we have started beta testing with a limited audience.
To say it has been a challenge would be an understatement — it has probably been one of the hardest tasks I have ever undertaken for a Mac or iOS app.
Update (2012-05-17): Part 2:
In other words, where with MobileMe there was a single truth database in the cloud, there is now just a collection of transaction logs from different devices, and a number of clients doing their best to independently reconcile those logs. As long as the updates are reasonably distinct, it works well, but when changes overlap considerably, you can get quite tricky situations. A lot of the discussion in this series of posts revolves around working around the conflicts that can arise.
Update (2012-05-26): Part 3:
For a start, any objects inserted while iCloud is disabled, and other changes made to the data, will not appear on other devices, even after iCloud is re-engaged. That means the user will see two distinct sets of data. They will wonder why the objects they see on one device are not appearing on the other. But that will likely be the least of the problems…
Update (2012-05-29): Part 4:
Having covered Core Data syncing via iCloud from a high level, in this post I want to introduce a simple test app, which will be extended over the coming weeks. The app should eventually contain most of the code snippets you will need to get your own app up and running with iCloud.
Update (2012-06-08): Part 5:
One solution to these problems is to add a file or files to the iCloud container to track which devices have contributed to the transaction logs. When a device starts syncing, an entry is made in the container. When the device stops syncing, the device entry is left in place as a record that it contributed to the iCloud logs.
Update (2012-06-16): Part 6:
The import takes place in a private context using a private persistent store coordinator, but it still makes use of your managed object classes, and uses key-value coding (KVC) to access properties. That means that if you have any side effects in your custom accessor methods, you could end up undermining the import.
[…]
Your app’s source can influence the import process in another way too. The validation rules of your entity model are applied during the import, as are validation checks in your managed object classes. If any fail, the import fails, and will never recover, leaving the app’s data in an inconsistent state across devices.
