The actual hack is mostly based on this blog post about intercepting the keyboard on iOS, and it’s not pretty. I had to modify some constants to make it work on iOS5/6.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

#define GSEVENT_TYPE 2
#define GSEVENT_FLAGS 12
#define GSEVENTKEY_KEYCODE 15
#define GSEVENT_TYPE_KEYUP 10
// http://nacho4d-nacho4d.blogspot.co.uk/2012/01/catching-keyboard-events-in-ios.html
__attribute__((constructor)) static void PSPDFKitAddKeyboardSupportForUIAlertView(void) {
    @autoreleasepool {
        // Hook into sendEvent: to get keyboard events.
        SEL sendEventSEL = NSSelectorFromString(@"pspdf_sendEvent:");
        IMP sendEventIMP = imp_implementationWithBlock(^(id _self, UIEvent *event) {
            objc_msgSend(_self, sendEventSEL, event); // call original implementation.

            SEL gsEventSEL = NSSelectorFromString([NSString stringWithFormat:@"%@%@Event", @"_", @"gs"]);
            if ([event respondsToSelector:gsEventSEL]) {
                // Key events come in form of UIInternalEvents.
                // They contain a GSEvent object which contains a GSEventRecord among other things.
                int *eventMem = (int *)[event performSelector:gsEventSEL];
                if (eventMem) {
                    if (eventMem[GSEVENT_TYPE] == GSEVENT_TYPE_KEYUP) {
                        UniChar *keycode = (UniChar *)&(eventMem[GSEVENTKEY_KEYCODE]);
                        int eventFlags = eventMem[GSEVENT_FLAGS];
                        //NSLog(@"Pressed %d", *keycode);
                        [[NSNotificationCenter defaultCenter] postNotificationName:@"PSPDFKeyboardEventNotification" object:nil userInfo: @{@"keycode" : @(*keycode), @"eventFlags" : @(eventFlags)}];
                    }
                }
            }
        });
        PSPDFReplaceMethod(UIApplication.class, @selector(sendEvent:), sendEventSEL, sendEventIMP);

        // Add keyboard handler for UIAlertView.
        SEL didMoveToWindowSEL = NSSelectorFromString(@"pspdf_didMoveToWindow");
        IMP didMoveToWindowIMP = imp_implementationWithBlock(^(UIAlertView *_self, UIEvent *event) {
            objc_msgSend(_self, didMoveToWindowSEL, event); // call original implementation.

            static char kPSPDFKeyboardEventToken;
            if (_self.window) {
                id observerToken = [[NSNotificationCenter defaultCenter] addObserverForName:@"PSPDFKeyboardEventNotification" object:nil queue:nil usingBlock:^(NSNotification *notification) {
                    NSUInteger keyCode = [notification.userInfo[@"keycode"] integerValue];
                    if (keyCode == 41) /* ESC */ {
                        [_self dismissWithClickedButtonIndex:_self.cancelButtonIndex animated:YES];
                    }else if (keyCode == 40) /* ENTER */ {
                        [_self dismissWithClickedButtonIndex:_self.numberOfButtons-1 animated:YES];
                    }
                }];
                objc_setAssociatedObject(_self, &kPSPDFKeyboardEventToken, observerToken, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
            }else {
                id observerToken = objc_getAssociatedObject(_self, &kPSPDFKeyboardEventToken);
                if (observerToken) [[NSNotificationCenter defaultCenter] removeObserver:observerToken];
            }
        });
        PSPDFReplaceMethod(UIAlertView.class, @selector(didMoveToWindow), didMoveToWindowSEL, didMoveToWindowIMP);
    }
}

You also need some swizzling helpers, here’s what I use:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// http://www.mikeash.com/pyblog/friday-qa-2010-01-29-method-replacement-for-fun-and-profit.html
static void PSPDFSwizzleMethod(Class c, SEL orig, SEL new) {
    Method origMethod = class_getInstanceMethod(c, orig);
    Method newMethod = class_getInstanceMethod(c, new);
    if (class_addMethod(c, orig, method_getImplementation(newMethod), method_getTypeEncoding(newMethod))) {
        class_replaceMethod(c, new, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
    }else {
        method_exchangeImplementations(origMethod, newMethod);
    }
}

void PSPDFReplaceMethod(Class c, SEL orig, SEL newSel, IMP impl) {
    Method method = class_getInstanceMethod(c, orig);
    if (!class_addMethod(c, newSel, impl, method_getTypeEncoding(method))) {
        PSPDFLogError(@"Failed to add method: %@ on %@", NSStringFromSelector(newSel), c);
    }else PSPDFSwizzleMethod(c, orig, newSel);
}

And it’s actually not that easy to get right. In PSPDFKit v1 I used the Apple recommended way (see their Photo example) of subclassing layoutSubviews. This was “good enough” until I added smart zoom in version 2 of my PDF framework. (That is, text block are detected and zoomed onto with a double tap, just like you’re used to in Mobile Safari). I noticed that the zoomToRect method did not work properly, the final rect was offset - and it was quite obvious why, since the layoutSubview-method moved around the frame of the view that was zoomed on. And don’t try to compensate this moving - it seems quite impossible to get right.

The next generation (PSPDFKit 2.2 and upwards) used override setContentOffset: to always center the content. This works, but has the drawback that you can’t pan the view around when you’re zooming out more - it’s always fixed centered. This solution also has a very nasty hidden bug where the UIScrollView can be “locked up” and don’t accept any touches anymore until you perform a pinch in/out. I’ve had an Apple DTS against this and even they only came up with useless workarounds. (like not using gesture recognizers… right.) It’s hard to reproduce this bug here without open sourcing half of my framework, so please just trust me on that one.

I’ve asked around on Twitter (thanks, everyone!) and most recommendations were about overriding layoutSubviews. Some suggested stuffing the view into another view and doing the centering manually (which I tried) but this has the drawback that you can scroll into the empty space when zoomed in (or you adapt the view and get the same problem as you had in layoutSubviews).

The solution that works by far best is by setting contentInset. It allows to pan around the view when zoomed out and doesn’t expose the “lock” bug that overriding setContentOffset: had. It also works fine with using zoomToRect. There are a few gotchas when using edgeInsets as well - for example I have a mechanism that preserves the current view state (page, zoom, contentOffset) and restores that later on. If you set contentOffset to 0,0 this will un-center your image (in contrast to method 1 and 2). But you can trigger re-centering with following trick:

1
2
3

        // Trigger a new centering (center will change the content offset)
        scrollView.contentInset = UIEdgeInsetsZero;
        [scrollView ensureContentIsCentered];

I’ve made a small GitHub project that shows off all three centering techniques and zooms to a small rect on double tap (to show off the zoomToRect problem). Hopefully this helps someone save a few hours!

#define UI_APPEARANCE_SELECTOR

In the simplest case, add UI_APPEARANCE_SELECTOR to your properties to inform others that this property can be set via an UIAppearance proxy. There are however some gotchas that are not clearly mentioned in the documentation, and it’s always interesting how something like this works behind the scenes. (This is not a tutorial - go ahead and read Apple’s documentation on UIAppearance if you’ve never used it before)

From looking at the debugger, UIAppearance is quite smart and only applies properties before the view is added to a window.

UIAppearance mostly is for UIView subclasses, with some exceptions like UIBarItem (and UIBarButtonItem) who internally handle their respecive view. For those classes Apple implemented a custom apperance proxy (_UIBarItemAppearance).

When a custom apperance is set, _UIAppearanceRecorder will track the customizations. There are also certain optimized apperance storage classes like (_UISegmentedControlAppearanceStorage) for UISegmentedControl or _UINavigationBarAppearanceStorage for UINavigationBar.

Let’s start with a simple example, converting this class (taken from my iOS PDF SDK) to work with UIAppearance:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

/// Simple rounded label.
@interface PSPDFRoundedLabel : UILabel
/// Corner radius. Defaults to 10.
@property (nonatomic, assign) CGFloat cornerRadius;
/// Label background. Defaults to [UIColor colorWithWhite:0.f alpha:0.6f]
@property (nonatomic, strong) UIColor *rectColor;
@end

@implementation PSPDFRoundedLabel
- (id)initWithFrame:(CGRect)frame {
    if (self = [super initWithFrame:frame]) {
        self.rectColor = [UIColor colorWithWhite:0.f alpha:0.6f];
        self.cornerRadius = 10.f;
    }
    return self;
}
- (void)setBackgroundColor:(UIColor *)color {
    [super setBackgroundColor:[UIColor clearColor]];
    self.rectColor = color;
}
// drawRect is trivial
@end

Simply adding UI_APPEARANCE_SELECTOR will not work here. One gotcha is that UIAppearance swizzles all setters that have a default apperance, and tracks when they get changed - so that UIAppearance doesn’t override your customizations. This is a problem here, since we use setters in the initializer, and for UIAppearance it now looks as we already customized the class ourselves. Lesson: Only use direct ivar access in the initializer for properties that comply to UI_APPEARANCE_SELECTOR.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

/// Simple rounded label.
@interface PSPDFRoundedLabel : UILabel
/// Corner radius. Defaults to 10.
@property (nonatomic, assign) CGFloat cornerRadius UI_APPEARANCE_SELECTOR;
/// Label background. Defaults to [UIColor colorWithWhite:0.f alpha:0.6f]
@property (nonatomic, strong) UIColor *rectColor UI_APPEARANCE_SELECTOR;
@end

@implementation PSPDFRoundedLabel {
    BOOL _isInitializing;
}
- (id)initWithFrame:(CGRect)frame {
    _isInitializing = YES;
    if (self = [super initWithFrame:frame]) {
        _rectColor = [UIColor colorWithWhite:0.f alpha:0.6f];
        _cornerRadius = 10.f;
    }
    _isInitializing = NO;
    return self;
}
- (void)setBackgroundColor:(UIColor *)color {
    [super setBackgroundColor:[UIColor clearColor]];
    // Check needed for UIAppearance to work (since UILabel uses setters in init)
    if (!_isInitializing) self.rectColor = color;
}
// drawRect is trivial
@end

This class now fully works with UIAppearance. Notice that we had to do some ugly state checking (_isInitializing), because UILabel internally calls self.backgroundColor = [UIColor whiteColor] in the init, which then calls the setRectColor, which would already could as “changed” for UIAppearance. Notice the TaggingApperanceGeneralSetterIMP that Apple uses to track any change to the setter:

I’m using following code to test the customizations:

[[PSPDFRoundedLabel appearanceWhenContainedIn:[PSCThumbnailGridViewCell class], nil] setRectColor:[UIColor colorWithRed:0.165 green:0.226 blue:0.650 alpha:0.800]];
[[PSPDFRoundedLabel appearanceWhenContainedIn:[PSCThumbnailGridViewCell class], nil] setCornerRadius:2];

We can also use the runtime to query at any point what apperance settings there are for any given class. This is only meant to be used within the debugger, since it uses private API to query _UIAppearance.

po [[NSClassFromString(@”_UIAppearance”) _appearanceForClass:[PSPDFRoundedLabel class] withContainerList:@[[PSCThumbnailGridViewCell class]]] valueForKey:@”_appearanceInvocations”]
$0 = 0x0bd08cc0 <__NSArrayM 0xbd08cc0>(
<NSInvocation: 0xbd08a60>
return value: {v} void
target: {@} 0x0
selector: {:} _UIAppearance_setRectColor:
argument 2: {@} 0xbd08210
,
<NSInvocation: 0xbd09100>
return value: {v} void
target: {@} 0x0
selector: {:} _UIAppearance_setCornerRadius:
argument 2: {f} 0.000000
)

That’s it, the class is fully compatible with UIAppearance. When using this inside a framework, you should write custom UIAppearance rules instead of manually setting the property, to allow to override those rules from the outside (remember, manually setting a property will disable it for apperance usage). +load is a good time for that. There are some more gotchas on UIAppearance like BOOL not being supported (use NSInteger instead), and some honorable exceptions that do support apperance selectors, like DACircularProgress.

While developing a new version of PSPDFKit, I started using UIMenuController more and more. The first thing you’ll notice is that it’s different from your typical target/action pattern: the target is missing.

1

[UIMenuItem alloc] initWithTitle:@"Title" action:@selector(menuItemAction:)];

This is partly actually pretty genius. iOS checks if the @selector can be invoked calling canPerformAction:withSender: which is part of UIResponder. If the object returns NO, the system walks up the UIResponder chain until it finds an object that returns YES or nextResponder returns nil.

A typical resonder chain looks like this: UIView -> UIViewController -> UINavigationController -> UIApplication -> AppDelegate.

Now this is great in theory, if you implement e.g. copy: on your viewController, the firstResponder can be any subview and it still works. In practice however I found this more limitating and annoying. And I’m not the only one.

Especially if your menus get more complex, your code is littered with selectors. So let’s write a block-based subclass. Enter PSMenuItem.

1
2
3

PSMenuItem *actionItem = [[PSMenuItem alloc] initWithTitle:@"Action 1" block:^{
    NSLog(@"Hello, from a block!");
}];

My naive approach was to just use one common selector internally and execute the block that is saved in the PSMenuItem subclass. The only problem: (id)sender of the action gets called with the UIMenuController. This is wrong on so many levels, especially since UIMenuController is a singleton anyway. There’s no easy way to know what UIMenuItem has been pressed. But since I already was committed in writing the subclass, that couldn’t stop me. We just create a unique selector for each UIMenuItem, and catch execution at a lower level.

Enter Cocoa’s Message Forwarding

If the runtime can’t find a selector on the current class, message forwarding is started. (That’s the tech that allows classes like NSUndoManager or NSProxy.)

1. Lazy method resolution: resolveInstanceMethod: is called. If this returns YES, message sending is restarted as the systme assumes that the method has been added at runtime. We could theoretically use this and add a method that calls the block at runtime. But this would pollute the object with many new methods - not what we want.

2. Fast forwarding path: -(id)forwardingTargetForSelector:(SEL)sel has been added in Leopard as a faster approach to the NSInvocation-based message forwarding. We could use this to react to our custom selector, but we would have to return an object that implements our selector (or does not throw an exception with undefined methods.) Possible candidate, but there’s something better.

3. Normal forwarding path: This is the “classic” message forwarding that exists since the old days. Here actually two methods are called. methodSignatureForSelector:, followed by forwardInvocation:. (The method signature is needed to build the NSInvocation). PSMenuItem hooks into both of those methods. But let’s go step by step through PSMenuItem’s + (void)installMenuHandlerForObject:(id)object

1
2
3
4
5

+ (void)installMenuHandlerForObject:(id)object {
    @autoreleasepool {
        @synchronized(self) {
            // object can be both a class or an instance of a class.
            Class objectClass = class_isMetaClass(object_getClass(object)) ? object : [object class];

Note the @synchronized, swizzling is not thread save. Also we add an @autoreleasepool here, as this could be executed from +load or +initialize; at a very early time where’s no default NSAutoreleasePool in place yet.

class_isMetaClass checks if object_getClass returns a class or a meta-class. This is needed because object can both be a instance of a class or a class object itself, and you can’t just invoke a isKindOfClass on a Class object. If you’re wondering what a meta-class is; it’s basically a class that defines methods available on the class. CocoaWithLove has a great article on that.

1
2
3
4
5
6
7
8
9
10
11
12

        // check if menu handler has been already installed.
        SEL canPerformActionSEL = NSSelectorFromString(@"pspdf_canPerformAction:withSender:");
        if (!class_getInstanceMethod(objectClass, canPerformActionSEL)) {

            // add canBecomeFirstResponder if it is not returning YES. (or if we don't know)
            if (object == objectClass || ![object canBecomeFirstResponder]) {
                SEL canBecomeFRSEL = NSSelectorFromString(@"pspdf_canBecomeFirstResponder");
                IMP canBecomeFRIMP = imp_implementationWithBlock(PSPDFBlockImplCast(^(id _self) {
                    return YES;
                }));
                PSPDFReplaceMethod(objectClass, @selector(canBecomeFirstResponder), canBecomeFRSEL, canBecomeFRIMP);
            }

Here we test if the class has already been swizzled by us with using class_getInstanceMethod. Again, because object might be a Class already, we can’t just use respondsToSelector:. Next, we test if we should add a handler to canBecomeFirstResponder. This is needed to make the UIMenuController display in the first place.

Note the imp_implementationWithBlock. This is a new method in iOS4.3 upwards, but has just a much nicer syntax and is more compact than classic C functions. There’s another small annoyance, PSPDFBlockImplCast. The syntax of imp_implementationWithBlock was slightly changed in yet to be released versions of Xcode, older versions still need the (__bridge void *) cast, newer versions will complain and only work without.

PSPDFReplaceMethod is a helper that first adds the new method via our pspdf_ selector name, then swizzles the original implementation with our custom implementation.

1
2
3
4
5
6

            // swizzle canPerformAction:withSender: for our custom selectors.
            // Queried before the UIMenuController is shown.
            IMP canPerformActionIMP = imp_implementationWithBlock(PSPDFBlockImplCast(^(id _self, SEL action, id sender) {
                return PSIsMenuItemSelector(action) ? YES : ((BOOL (*)(id, SEL, SEL, id))objc_msgSend)(_self, canPerformActionSEL, action, sender);
            }));
            PSPDFReplaceMethod(objectClass, @selector(canPerformAction:withSender:), canPerformActionSEL, canPerformActionIMP);

Next up, we swizzle canPerformAction:withSender:. This is called before the UIMenuController is displayed. If we detect our custom selector (PSIsMenuItemSelector), we return YES, else we call the original implementation. Note the tricky casting on objc_msgSend. (We could also build a NSInvocation, but that would be much slower and needs much more code).

PSIsMenuItemSelector is just a shorthand for return [NSStringFromSelector(selector) hasPrefix:kMenuItemTrailer];

1
2
3
4
5
6
7
8
9
10

            // swizzle methodSignatureForSelector:.
            SEL methodSignatureSEL = NSSelectorFromString(@"pspdf_methodSignatureForSelector:");
            IMP methodSignatureIMP = imp_implementationWithBlock(PSPDFBlockImplCast(^(id _self, SEL selector) {
                if (PSIsMenuItemSelector(selector)) {
                    return [NSMethodSignature signatureWithObjCTypes:"v@:@"]; // fake it.
                }else {
                    return (NSMethodSignature *)objc_msgSend(_self, methodSignatureSEL, selector);
                }
            }));
            PSPDFReplaceMethod(objectClass, @selector(methodSignatureForSelector:), methodSignatureSEL, methodSignatureIMP);

Finally we arrive at the method that’s called during message forwarding, when the user selects a UIMenuItem. We again check for the selector and return a faked NSMethodSignature. If we wouldn’t return a signature here, we’d get a selector not implemented exception. "v@:@" is the selector encoding for -(void)action:(id)sender. v is the return type (void), the first @ is self, the : is the selector (_cmd), the @ finally is id sender. You can learn more on Apple Developer about objc type encodings.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

            // swizzle forwardInvocation:
            SEL forwardInvocationSEL = NSSelectorFromString(@"pspdf_forwardInvocation:");
            IMP forwardInvocationIMP = imp_implementationWithBlock(PSPDFBlockImplCast(^(id _self, NSInvocation *invocation) {
                if (PSIsMenuItemSelector([invocation selector])) {
                    for (PSMenuItem *menuItem in [UIMenuController sharedMenuController].menuItems) {
                        if ([menuItem isKindOfClass:[PSMenuItem class]] && sel_isEqual([invocation selector], menuItem.customSelector)) {
                            [menuItem performBlock]; break; // find corresponding MenuItem and forward
                        }
                    }
                }else {
                    objc_msgSend(_self, forwardInvocationSEL, invocation);
                }
            }));
            PSPDFReplaceMethod(objectClass, @selector(forwardInvocation:), forwardInvocationSEL, forwardInvocationIMP);
        }
    }
}
}

Finally, the last piece. After methodSignatureForSelector returned a valid NSMethodSignature, the system builds a NSInvocation object that we can handle (or not). Here we load the selector, loop through all menuItems in the UIMenuController and finally call the block on the PSMenuItem, if found. Note that we could also extract UIMenuController from the NSInviation itself, but since it’s a singleton, there’s no need for that.

One, simple piece remains. We build up the custom selector in our initWithTitle:block:

1
2
3
4
5
6

// Create a unique, still debuggable selector unique per PSMenuItem.
NSString *strippedTitle = [[[title componentsSeparatedByCharactersInSet:[[NSCharacterSet letterCharacterSet] invertedSet]] componentsJoinedByString:@""] lowercaseString];
CFUUIDRef uuid = CFUUIDCreate(kCFAllocatorDefault);
NSString *uuidString = CFBridgingRelease(CFUUIDCreateString(kCFAllocatorDefault, uuid));
CFRelease(uuid);
SEL customSelector = NSSelectorFromString([NSString stringWithFormat:@"%@_%@_%@:", kMenuItemTrailer, strippedTitle, uuidString]);

I’ve used a UUID to even allow menu items with the same title, they else would generate the same selector and would potentially call the wrong block.

Also, thanks to Mike Ash for his great Friday Q&A about Objective-C Message Forwarding.

It’s a bit crude, and Xcode won’t show any warnings if you’re doing subscripting on any object now, but you know what you’re doing, right? Furthermore this is only temporary, to make it compile with Xcode 4.4. In Xcode 4.5, this snippet won’t do anything and isn’t needed anymore, since the new SDK already has those methods defined on the classes you care about. Just make sure this is in your global header file. (e.g. precompiled headers)

Note that unlike literals, who are really just syntactical sugar and already work great in Xcode 4.4+ (LLVM 4.0+), subscripting actually calls into new methods. So how does this “magically defining headers” actually work?

Thanks to Mike Ash and Cédric Luthi, here’s the answer:

The subscripting compatibility shim is actually part of ARCLite. The ARCLiteload function takes care of dynamically adding the four subscript methods with class_addMethod. The implementations of these methods simply call the equivalent non-subscript methods.

If you, for any reason, are not on ARC yet, you really want to force the compiler to link with libarclite using the -fobjc-arc linker flag. This works all the way back to iOS 4.3.

Also check out the new Xcode Refactoring Assistant to convert your codebase to Modern Objective-C. It’s awesome.

Wanna know more tips and tricks about iOS? Follow @steipete on Twitter.

Regular output of po [[UIWindow keyWindow] recursiveDescription]

Pimped output:

The solution is surprisingly simple. Add the following code somewhere to your project and you’re done. As a bonus, this also lists attached childViewControllers if you run iOS5 or above, and it will show you if a childViewController has a greater frame than it’s parentViewController (this is usually a easy to miss bug).

Note the usage of __attribute__((constructor)), this will call the method at a very early stage on app loading. (thus we need an explicit @autorelease pool).

Works with or without ARC, iOS 4.3 and above. (imp_implementationWithBlock requires iOS 4.3, unless you want to perform some dark magic.)

For those if you that are curious, I use a private API call (_viewDelegate), but that’s obfuscated (it would pass a AppStore review) and you really only should compile that function in DEBUG mode anyway.

Before iOS5, NSURLCache just saved requests to memory, even if the documentation said otherwise - the diskCapacity property was silently ignored. This led to some open source subclasses of NSURLCache, that retrofit disc caching. Most popular is SDURLCache and my enhanced, faster fork of it. Even Apple has an example online that shows how to create a simple URLCache.

As of iOS5, NSURLCache automatically saves responses to disk. I haven’t found anything the release notes that confirms the change, but I tried it both with iOS 4.3/5.0/5.1 on the simulator and the device, and with every 5.x version a disk cache file is created and populated. This is great, as many developers probably aren’t aware of this and the system just does the right thing - and it’s fast.

If the Cache-Control headers indicate that this request can be cached, iOS automatically saves it to a local sqlite cache file in AppDirectory/Caches/(bundleid)/Cache.db. E.g. public, max-age=31536000 marks that the request cache will be valid for a year, as max-age is listed in seconds.

The sqlite scheme for the cache looks identical with the one used in OS X:

So, why should you care? Well, the Cache.db caches any file that has a correct Cache-Control header set. Thus, if you download a pdf document, it might end up in your disk cache as well, taking up twice the memory.

The default NSURLCache will be used, with a disk limit of 20MB. You can easily test this with gdb/lldb:

1

p (int)[[NSURLCache sharedURLCache] diskCapacity]

The memoryCapacity defaults to 40MB, although the cache will clear itself in low memory situations.

So for downloads that you manually save to disk, you might want to override the NSURLConnection delegate connection:willCacheResponse: and return nil.

With creating NSURLRequest using requestWithURL:cachePolicy:timeoutInterval:, you can define the cachePolicy, but this only allows you to choose how if and how the cache will be read.

Available options are: only use the cache value (NSURLRequestReturnCacheDataDontLoad), try the cache and load if different (NSURLRequestReturnCacheDataElseLoad) or ignore cache entirely (NSURLRequestReloadIgnoringLocalCacheData).

The default option, if not set explicitly, is NSURLRequestUseProtocolCachePolicy, which most of the time is equivalent to NSURLRequestReturnCacheDataElseLoad, thus uses the cache if the object hasn’t changed. There are a few other options in the enum, but those are unimplemented.

Note: There doesn’t seem a way to force caching of certain requests, connection:willCacheResponse: is only called if the response contains a Cache-Control header, according to Apple’s documentation:

The delegate receives connection:willCacheResponse: messages only for protocols that support caching.

Lastly, Apple suggests that caching can also be fine-tuned with subclassing NSURLProtocol, which indeed allows some interesting use-cases like providing a cache for UIWebView or decrypting files on the fly.

If you’re not yet using AFNetworking, you really should. It’s a big step forward compared to classical NSURLConnection handling, even if Apple recently added a few new fancy shorthands in iOS5. In AFNetworking, your network operations are indeed subclasses of NSOperation, which allows a much better control what’s currently running, and AFHTTPClient is the perfect base class to implement any API.

I’m in a better situation than ever. I finally figured out what I wanna do with my life. I’m no longer enviously looking at other places. I learned what’s really important. And that you can’t just replace life-long friends.

Don’t get me wrong. I’m gonna miss San Francisco. Really. Such a great city. Such an awesome spirit; unlike any other city I’ve ever been to. And heck, half of my Twitter followers are here, so super-nice to finally meet up with you guys!

So why leave at all? Well, it just didn’t work out. I’m full of ideas and really, really wanna work on my own stuff.

Back when I got my job offer at a WWDC party in 2011, I was in a whole different position, worked. as. a. freelancer. for some nice companies, but wanted a change. So the prospect of living in San Francisco, being part of the startup culture, working together on something great, was very, very appealing. (damn you, Hacker News!)

So, I accepted the offer and waited for my visa. Waited, and waited. I stopped doing freelance work because initially we thought it’d all be done in a month. Ha, how wrong we were. In the end it took more than 6 month! I even finished my bachelors degree during that time.

Not only that. Suddenly my mind was free from all the freelance work (and the feeling of guilt when I didn’t work on them). Naturally, I filled that space up with other. projects. And, partly inspired by some friends, I wanted to try the paid component business. So this happened. In the end, while waiting for my visa, I’ve created a viable business that’s now making more money than my full-time job possibly ever could.

All gears where set for SF, so I took the gig, it was all about the experience now. I really believed I could do this. But then, managing a 40h+ job with basically another full-time job on the side is nearly impossible, and after killing myself for a while, I finally had to choose which is more fun. Well, let’s say it wasn’t a hard decision. (To be correct, it was very hard. I hate letting people down, and of course while they’re a business, I also respected them, and had a hard time to disappoint their high expectations they had in me.)

This all sounds so simple and logical now, but I really jumped into the whole business and landed on my feet. Support requests and ideas are exploding, and as revenue goes up, so does the amount of time to care about my product. Also, I was really looking forward to work wit some well-respected people in the iOS scene, only to find out that they had already left the company before I came here.

Lastly, NSConference gave me the final kick. Such an amazingly great amount of inspiring people that genuinely love what they do - you can’t just go back to your 11-7 job after experiencing that. Also, meeting customers that use your product and really love it is the sweetest thing ever.

I have no regrets on trying it, and I’m very thankful for the opportunity they’ve given me - in fact it’s one of the best things ever happened to me! It gave me the guts to go full-indie, without even thinking about it. It helped me to figure out what I really wanna do with my life.

So, what’s next? Well, I’ve big plans with making PSPDFKit even better… and then there’s this other app idea, that’s crossing my mind way too often. I’m building this for myself, because I really, really want it. And every time I did that, it turned out to be a great success. If you wanna hear more about it, you should follow me on Twitter.

And about San Francisco, I’ll probably be back pretty soon ;)

Carefully encapsulating your calls within a willChangeValueForKey/didChangeValueForKey call to “enable” KVO. Well, turns out, you just did shit work. There’s no reason to do the will/did dance, as long as you are using a setter method to change the ivar. It doesn’t need to be backed by an ivar or declared as a property. KVO was written long before there was anything like @property in Objective-C.

In fact, I am now writing iOS apps for about 4 years and didn’t know this. A lot. of. open. source. code. also gets this wrong. Apple has some good KVO documentation, where they explain the concept of Automatic Change Notifications.

There is a reason why you want to manually add willChangeValueForKey, most likely changing a variable also affects another variables. The most popular example is NSOperation:

Sometimes you also might wanna optimize how often you’re sending KVO notifications with overriding automaticallyNotifiesObserversForKey: to disable automatic change notifications for certain properties.

In this example, there might be expensive KVO observations when the image changes, so we wanna make damn sure that KVO is only fired if the image actually is a different one to the already set image:

If you currently have such obsolete calls, they’re not doing any harm. Incrementally called willChangeValueForKey doesn’t emit more notifications. Still, time to delete some code!

Update: Don’t forget that there are more ways that’ll save you manual calls to will/did, like using the little known addition keyPathsForValuesAffecting(PropertyName), which uses some runtime magic to make KVO smarter. Here’s a real-life example how I used that on AFNetworking, so people can register a KVO notification on “isNetworkActivityIndicatorVisible” and it’ll get sent every time activityCount is changed. (You’ll also see that I do some atomic updating that requires manual KVO.)

The old content has been moved into limbo. Most of it would have needed some update to be valid again, so you’re not missing a lot. So if you’re coming from Google and miss a particular thing, hit me up on Twitter and I might dig it up for you.