Tom Harrington:
There’s still no full IPC mechanism on iOS. NSDistributedNotification hasn’t made the jump from OS X to iOS and probably never will. But file coordination and presentation can serve the same purpose, as long as the apps use the same app group.
When I was adding file coordination and presentation to my demo app, I realized that they could also be used for notifications between an app and its extensions. If one of them does a coordinated write while the other is using a file presenter for the file, the call to presentedItemDidChange happens almost instantly. Notification is the whole purpose of that method, so it makes sense it would work this way. I want to be notified if a specific file changes, and that’s how I get the notification.
But you don’t need to care about the file contents to be interested in notifications. If you just want a notification, choose a file name and use it as the notification mechanism. Any time one process needs to notify the other, make a change to the file. The other will get a file presenter call, and the notification is complete. It feels sort of like a hack but really this is exactly how the API is designed to work.
Update (2014-11-22): Apple TN2408 (via JanApotheker):
Using file coordination in an app extension to access a container shared with its containing app may result in a deadlock. This is usually the case if a process is suspended mid coordinated I/O. This can be more prevalent on iOS where most apps will be suspended after a short period of time after being moved to the background. Extensions should use alternatives to file coordination.
[…]
Regardless of this issue, the containing app (and all applications) should properly use background task assertions around file operations they require completed in a shared container (with or without extensions). This includes all writes or deletions. Such a process might still be killed by jetsam but at a much lower frequency.
Update (2014-11-29): Wade Spires recommends CFNotificationCenterGetDarwinNotifyCenter for iOS IPC.
Update (2014-12-01): Harrington has filed a bug on NSFileCoordinator:
This would seem to be a textbook example of a situation where NSFileCoordinator and NSFilePresenter would be ideal. Nay, it would seem to be the primary purpose for those classes to exist. The documentation for NSFileCoordinator even goes so far as to say that “…NSFileCoordinator class coordinates the reading and writing of files and directories among multiple processes.” But actually using it between different processes turns out to not be safe.
The tech note explains that “…you are obliged to write to that container in a coordinated manner to avoid data corruption. However, you must not use file coordination APIs directly for this.” This kind of documentation makes me sad.
Cocoa Extensions Interprocess Communication (IPC) iOS iOS 8 Objective-C Programming
Adam C. Engst:
We’re like you — we turn to the Web for answers first. But a lot of what’s on the Web is incomplete, unrelated, out of date, or flat-out wrong, whereas we work hard on accuracy and relevance in our books. We have to compete with all the content that’s already out there, but that’s hard if we’re not on the same playing field. So we’ve put the full text of each Crash Course on our Web site for search engines to index and for people to read […]
This may seem nuts, but people in the publishing industry also thought we were crazy back in 2003 when we refused to apply DRM to our books. What little copying there is hasn’t harmed our sales over the last 11 years, so with the Crash Courses, we’re going further and making them freely available on the Web. But, why would anyone buy such a book? Two reasons: first, we believe those who want offline access, better formatting, or more help than one chapter can provide will do the right thing and support our efforts, and those who needed only a quick answer wouldn’t have purchased anyway. Second, although the first chapter is easily read, we’ve slowed down navigating within the Web versions of books other than “Read Me First: A Take Control Crash Course,” so trying to read the entire book online would be unsatisfying.
E-books iOS Mac
Ash Furrow:
We discovered, as I mentioned earlier, that Swift just isn’t ready for primetime yet. I want it to be, but it was probably a mistake to write the app in Swift. By our projections, it took us about four times longer than we had anticipated to complete the project (in terms of person-hours worked). A lot of that is admittedly due to our own faulty estimates, but a lot more of it is attributable to Swift’s immaturity. In future projects, we’re going to be more mindful about estimation.
[…]
So we’re pretty much stuck with Swift, as much as you can be “stuck” with a totally awesome language that just needs some more time to have a mature ecosystem of tools. Swift does, after all, address most of my concerns with Objective-C. It has a lot of features that made developing Eidolon a joy. I’m impressed with what Apple’s made so far, but I’m eagerly waiting for Xcode 6.2 and beyond.
Language Design Programming ReactiveCocoa Swift Programming Language
Gareth Wilson:
We think that for each customer issue, we have to do two things:
- Solve the customer’s problem right away
- Find a way to stop that problem from happening again
How we solve the first depends on the specific problem at hand, but to resolve the second we use the 5 Whys method.
[…]
If you stick to Fixing Things Twice then over time all the common problems get resolved. This frees up your Customer Service team to look in to the unique issues that need more time.
I think this is the right way to do things and leads to a higher quality product. It’s incredibly satisfying to track down root causes. But you have to exercise some discretion because this is a hole with no bottom. At a certain point, you can do more good for more customers by not trying to second-fix issues of diminishing severity and popularity.
Business FogBugz Programming
Lukas Mathis:
In Time Machine, the selector for picking how far to get back is finicky, and hard to use. As far as I can tell, it’s impossible to know when specific files actually changed, unless you manually step through the history and check the file’s modification date. The UI doesn’t properly support what is probably the most common use case: getting back the most recent good version of a single file.
[…]
All I needed was for Time Machine to show me what versions of a specific file it had backed up, so that I could pick the one with the most recent modification date. Not any old version — the most recent version. But I can’t tell Time Machine to just show me what versions of a file it has. Instead, I’m (sluggishly, because Time Machine’s UI apparently requires more power than the most recent Tomb Raider) stepping back through Time Machine’s version history, painfully trying to figure out which specific instance of the files it shows me is the one that I need to recover.
tmutil looks very useful and can remove the Time Machine metadata that would ordinarily be messed up if you tried to manually restore from a snapshot. But it doesn’t seem to solve this particular problem. The easiest way I’ve seen is BackupLoupe, however even that will show you an entry for each snapshot containing the file, rather than each distinct version of the file.
Backup BackupLoupe Mac Mac App Time Machine
