Recently I wanted to write a layer that had its content animate, but as far as I could determine CALayer doesn’t support this out of the box, though it is really pretty close. If you add an @dynamic property to a CALayer subclass and set it, your layer will be sent -actionForKey: and the returned animation will be passed to your -addAnimation:forKey:.

The problem is that CALayer doesn’t know that this change means it needs to update your contents property too, so the animation will happen but no display change will happen.

The API on CALayer really isn’t sufficient for this task, so it isn’t too surprising it isn’t supported. Since CALayer is a generic KVC container you can squirrel away random keys/value pairs in it and use them for whatever purposes you want. But it has no way of knowing that a particular property change should provoke an update to the content, and updating the content unnecessarily would seriously hurt performance.

I’ve whipped up some sample code with a superclass that shows one approach to handling this.

The sample subclass looks like:

@interface WaveLayer : ContentAnimatingLayer
@property CGFloat phase, frequency, amplitude;
@end

@implementation WaveLayer
@dynamic phase, frequency, amplitude;

+ (NSSet *)keyPathsForValuesAffectingContent;
{
    static NSSet *keys = nil;
    if (!keys)
        keys = [[NSSet alloc] initWithObjects:@"phase",
                   @"frequency", @"amplitude", nil];
    return keys;
}

- (void)drawInContext:(CGContextRef)ctx;
{
    … draw a sine wave …
}
@end

The ContentAnimatingLayer superclass provides some bookkeeping and basic support for updating the content when the content-affecting properties are changed. First, it adds support for -actionFor<Key>; like many other key-based Cocoa protocols (Radar #6372335). On top of this, it adds support for determining which properties are content-affecting with +keyPathsForValuesAffectingContent and -isContentAnimation:. Active content-affecting animations are then tracked and an update timer is fired when there is at least one such animation.

This makes it as easy as I’d hoped it would be to write content animating layers; hopefully you’ll find this useful too! I’ve asked Apple to add this to CALayer in the future. If you’d like it too, you can reference my Radar #6372372.

The sample code is just that, my first cut at a sample. Some possible issues/improvements:

• The -actionFor<Key> support may or may not be fast enough (or really not even necessary).
• Instead of following the class-based KVO customization pattern, CALayers are often customized by the delegate. So, the NSSet-returning method should maybe be an instance method or maybe the -isContentAnimation: should be split up and call a new -layer:isContentAnimatingKey: delegate method.
• It would be nicer to tie into the normal CoreAnimation timing mechanism instead of creating a per-instance NSTimer. Even without that, it might be a bit more efficient to have a single animation timer for all instances of ContentAnimatingLayer. Also, right now the timer doesn’t get registered for the event tracking runloop mode, though it maybe should.
• This approach assumes that a change to a content-affecting key requires the entire content be redrawn. This may or may not be the case for any particular layer. A change to a content-animating property might want to specify an NSRect-based animation that describes the dirty area.

Since OmniFocus makes extensive use of the Omni Frameworks, one of the very first challenges we hit when starting with the SDK was how to structure our source and Xcode projects so that we could re-use some of our battle-tested common code between OmniFocus on the Mac and on the iPhone. Some people like splitting up their source into frameworks and some don’t. That’s all good, but on the iPhone 3rd party developers have no supported way to build their own frameworks.

Many limitations also come with a benefit, and in this case it is smaller application packages. A framework may include classes or categories that are used in several clients, but not all of them. On the iPhone, we want fast downloads from the App Store (possibly over the cell network) and we want fast startup times. Both of these require us to not bloat our executable with code not specifically used by our app.

Given that we can’t use real frameworks bundles, we need to directly include our framework source in our iPhone project. I’ll describe an approach that’s worked well for us and might suit you too.

First, we want to be sure that we don’t pick up any extra headers that we didn’t intend to use. For example, if our OmniFoundation NSSet category imports another extension header, we want to be sure that we consider that change rather than just letting the dependency creep in (if nothing else, we need to build the corresponding .m file). One approach that helps with this is to use <…> instead of “…” imports, so we have:

#import <OmniFoundation/NSSet-OFExtensions.h>

This ensures that Xcode finds our header from a “public” location rather than finding it relative to the file being compiled. Now, if we do have an internal header that shouldn’t be published, we can leave it in an “…” import, but we have to take care to add those .m files to the target.

Second, we want to “publish” the headers for the public headers necessary to build the subset of the framework we’ll be using. We accomplish this with a sequence of Build Phases in our OmniFocus target in Xcode:

The first interesting phase, Create Header Directories, gives us a place in our build area for the headers:

FRAMEWORK_HEADER_BASE="$DERIVED_SOURCES_DIR/FrameworkHeaders"
mkdir -p "$FRAMEWORK_HEADER_BASE"
mkdir -p "$FRAMEWORK_HEADER_BASE"/OmniBase
mkdir -p "$FRAMEWORK_HEADER_BASE"/OmniFoundation
mkdir -p "$FRAMEWORK_HEADER_BASE"/XMLData
mkdir -p "$FRAMEWORK_HEADER_BASE"/OmniFocusModel
mkdir -p "$FRAMEWORK_HEADER_BASE"/OODataTypes
mkdir -p "$FRAMEWORK_HEADER_BASE"/OmniDataObjects

Then, for each “framework” we have a Copy Files build phase that is set to copy to the header directory in question. For example, Copy OmniBase Headers looks like:

Finally, we need to let Xcode find the headers when it builds our target. Opening the Target Info editor for our iPhone app, we can double-click the Header Search Path entry and add the top level FrameworkHeaders directory:

Now we can add just the framework headers and source files we need to our iPhone project. Each “public” header can then be dragged into the appropriate Copy Files build phase for installation during builds.

This isn’t the end of the road, but it is a good start. Other issues involve making sure that your NSError domain strings aren’t dependent on your bundle identifier (since on the Mac they’ll be in different bundles and on the iPhone not), resource location (again, due to the one bundle vs. many difference on the platforms), and generating strings files when your sources are spread around (there are a couple scripts floating around for doing this; once we clean ours up we’ll hopefully publish it).

You could check the object that’s passed in as well. Unfortunately, this doesn’t help the case where a subclass or superclass has registered a notification on the same key path of the same object.

If, however, you specify something unique for the context, you can use that to correctly identify your notifications.

Proper use of the KVO context will allow a single object to subscribe to a key across a parent and child class in some common cases, but there is a hidden danger. If your two classes both follow the basic pattern of adding an observation when your object is created and removing it when your object is dying, all will be well. But if you have a class that may toggle its observation on and off based on some varying criteria, you can get in trouble.

The core of the problem is an API flaw in KVO; -removeObserver:forKeyPath: doesn’t include a context argument. So, if you have an object that is subscribed to a key twice, with two different context pointers, there is no way to specify which one is to be removed. If your object is dying and cleaning up all observations, this isn’t a big deal. But if your subclass logic wants to temporarily turn off its observation, it has no way to make sure that’s what happens — it might instead end up removing the superclass observation.

Now, granted this is a relatively rare case that can be accounted for in your design. But, this takes an otherwise general and extremely useful API and adds a bit of worry to it every time you use it. You can’t use it locally in a class without worrying about what your super- and subclasses are doing.

I’ve written up Radar 6244260 on this, including a test case. Hopefully they’ll add a proper -removeObserver:forKeyPath:context: and deprecate the current method for some future release.

• Objective-C: Printing Class Name from Dtrace
• Objective-C: Using Instruments to trace messages-to-nil

I have a internal tool at Omni that traces message sends by creating new method IMPs to wrap the existing ones in a trampoline, but it requires some nasty assembly stubs and has only ever worked on Sparc, ppc and x86. It is very fast, but hard to maintain and a little fragile (and doesn’t handle the nil case). A 90% solution can be obtained by extending Bill and other’s work.

Ken sent out a partial tracing solution this morning and finally got me off my keister. Here is a D script that catches ObjC message sends and dumps a OPML fragment (which can then be wrapped in the XML goo via an external shell script or whatever) and then viewed in OmniOutliner.

Download: objc-trace-opml.d.gz

This isn’t a perfect solution by any means. Some of the issues:

• This has to be run in an essentially single-threaded program; any background threads must be totally quiescent or you’ll get a mixture of output from multiple threads. It wouldn’t be too hard to modify this script to include a thread identifier or maybe just filter out anything from background threads.
• This won’t handle exceptions correctly; they’ll break the OPML nesting. Our internal tool handles this, but since NSError arrived on the scene, this is less of an issue. Just avoid tracing code with exceptions.
• dtrace is slow when matching all entries in the objc provider. The startup time on this script is something like 40 seconds on my machine. Annoying, but not the worst thing ever, since you are likely to trace once and then spend a fair bit of time examining the results.
• This particular variant of the script will only work on x86 due to the hacky way I check for objc_msgSend_stret.
• dtrace can overflow its buffer and drop events when there are massive numbers of probe hits. Run with a big buffer and trace only the exact set of methods you need. Ideally you’ll be running in the debugger, stop right before where you need to trace turn on tracing and then ‘next’ over one or two lines of code. The ‘-b’ flag to dtrace can also be used to increase the buffer size.

Some of the nice bits:

• No assembly-fu required.
• Call hierarchy is preserved and can be expanded/hoisted and such in OmniOutliner.
• Both the class of the receiver and the class of the method implementation are included. So, you can see that +[MySuperclass initialize] is getting called on MySubcass, for example.
• All method invocations are shown, so you can see nested calls to super instead of just the initial call to objc_msgSend. I’ve not tested whether cached method IMPs get traced too; normal code should get traced as expected. Swizzling, IMP caching or dynamically registering methods will possibly not work as well.
• The pointer value of the receiver is emitted. By the time you examine the output, it might be dead and gone, but a surprising amount of the time it isn’t. For example, things like static NSStrings, NSScriptClassDescriptions, interface widgets and other cache-once data may still be around for submitting to ‘po’ in the debugger.

(gdb) b -[NSUserDefaults objectForKey:]
Breakpoint 17 at 0x94172fa4
(gdb) c
Continuing.
... invoke service, hit breakpoint ...
(gdb) po *(id *)($fp + 16)
NSShouldActivateForServiceRequest
(gdb)

Is there a better way to do this? Google and mdls don’t seem to know about NSShouldActivateForServiceRequest at all, so I’m guessing not.

Here is a simple little command-line AppleScript that will let you set an individual Terminal’s style from the command line;
(2009-09-01: updated for Snow Leopard)setterminalstyle-v2

Put the script in your PATH somewhere and then add a ssh function in your .zshrc, or equivalent:

# Show remote Terminal sessions with a different style.
# TERM_PROGRAM doesn't get set if we are logged in remotely,
# but then the originating Terminal could have done this (hopefully).
if [ "$TERM_PROGRAM" = "Apple_Terminal" ]; then
  function ssh {
    SetTerminalStyle ssh
    /usr/bin/ssh "$@"
    SetTerminalStyle default
  }
fi

Finally, create a ssh Settings entry in Terminal’s preferences:

Other obvious commands for this include sudo and su.Using RPROMPT and Terminal’s processes scripting property on tab it might be possible to get this to work without the function wrappers, but executing the AppleScript on every command was a little too slow for my taste.

Near the beginning of June, I added some support to our software update and crash logging frameworks to keep track of things like:

• total times the application has been launched
• total number of crashes
• total amount of time the application has been running

(As always, our software update system reports its information without including any personal details, and can be disabled entirely if so desired.)

Using this, we can now chart the total number of hours OmniFocus has been running vs. the total number of crashes (reported or not!). As the pool of people testing OmniFocus goes up, or some testers go idle, or some user with large number of crashes isn’t reporting them, we don’t have to wonder as much how that affects our average crash rate.

After my latest crash fix, our rate has improved to about 8000 hours per crash. We aren’t sure yet what constitutes a reasonable lower limit for hours/crash, but this does let us notice when a fix we’ve made actually is addressing the issue. We aren’t yet tracking the number of hours that the application is active (an hour spent hidden counts the same as an hour spent in full use). Whether this matters, when averaged across a large number of users, is open to question.

Still, there are only 8760 hours in a year, so if we can get above that, we’ll be feeling pretty good.

• Please report every single crash you hit, even if you don’t know how to reproduce it yet. Include any details of what you were doing leading up to the crash. We can then correlate reports from different users to narrow down the cause, even if no one person can reliably reproduce the problem.
• If you are comfortable doing so, include your document as a starting point (for OmniFocus, this is in ~/Library/Application Support/OmniFocus). If you have qualms about sending your data, skipping this is OK. Another option is to export your file to a backup and then trim down that copy to include only the portions necessary to reproduce the problem.
• List the exact steps to reproduce the problem, starting from the file you included or from an empty document. It is hard to be too specific: for example, you might be tempted to say “I deleted the second task of the project ‘Foo’”, but this doesn’t make it clear whether you used the delete key, a main menu item, a context menu, invoked an AppleScript, or picked up the task and dragged it to the trash. In some cases, the distinction matters. When in doubt, describe the physical actions you used (”press key X”, “clicked button Y”).
• If the proper behavior isn’t obvious (”don’t crash”), tell us what you expected to happen. Maybe you have a perspective on a design question we haven’t considered or that we should reconsider.

With crash reports in particular, it is important to include reproducible steps. Sometimes this isn’t possible, and that’s fine — please report the crash anyway with whatever details you have. With a large enough pool of people, someone will be able to figure out how to reproduce it.

Crash reports are CC’d directly to the entire OmniFocus engineering team. If you include reproducible steps, we’ll typically stop whatever else we’re working to fix it immediately.