Category Archives: Objective-C

GSoC 2013: Red rectangle!

It turns out I’m slower with GSoC progress than anticipated. GNUstep meeting in Cambridge, which I’ll discuss in upcoming posts (and do so as soon possible, so I don’t forget all the wonderful sights and experiences, and all the wonderful people I met), was informative, but it turns out not quite supportive of my GSoC productivity. I spent a week being nervous before my first international trip, and I spent the last week (after returning) being impressed with how wonderful Germany and England are.

So, what progress did I make?

Preparations

First, before the trip, I prepared the backend. I figured out the simple things, such as where do I have to modify configure scripts in order to add support for the new backend, as well as which classes are expected by gnustep-gui. I identified the minimum set of methods that need to exist in the relevant classes (mostly OpalGState) and I added stubs.

Opal exposing X11 drawables as contexts

In Cambridge, thanks to help from Opal’s author Eric Wasylishen, we started exposing the creation of CGContext specific to X11 drawables. The function already existed in Opal; we just refactored the code a bit. (Rest of the hacking time in Cambridge was spent on other tasks.)

Drawing onscreen

Now that I finally cleared my head of amazement at how beautiful Cambridge is and how great hosts we had, I decided that it’s really long overdue that we get some content drawn on-screen. It took me a while to figure out where to draw in order to actually get the content drawn on-screen. It turns out the safest place to insert my dummy draw method is -[OpalGState DPSfill] — probably because it’s intended as the place to draw stuff, as opposed to various initialization methods such as -[OpalGState DPSinitgraphics].

The dummy draw method draws a red rectangle 1024×768, so I’m very happy to report that the test application’s NSWindow is, as of today, fully red.

Thoughts on next steps

Overall, I hope that things will roll much, much faster from here onward. There are bound to be many bugs along the way — and many assumptions by existing apps and themes. It’ll slow implementation down, but I hope that along the way I’ll figure out a way to clean up the current messy situation with gnustep-back‘s numerous classes such as GState, Context, et al.

The scariest part is that the Cairo backend looks like it handles many complex behaviors and different use situations. Let’s see how many bugs the Opal backend will have in the end and how much of Cairo backend’s behavior I’ll have to replicate to fix them. 🙂

Core Data: Migrating ignores manual mapping model (or fails migration) despite mapping model's existence

Let’s say you created a somewhat complex migration model. Among other things, let’s say it includes entity migration policies (you know — subclasses of NSEntityMigrationPolicy).

However, Core Data ignores your manual migration model. Why, oh why?

You can try looking into this by clicking on schema name in Xcode 4, picking the “Run” sidebar ‘tab’, picking the “Arguments” tab, and adding -com.apple.CoreData.MigrationDebug 1. (See tech note TN2124.)

Alright, so now you see what the source persistent store’s version hashes are, and what the expected destination store’s version hashes should be. Then you see how Core Data starts migration by telling you its conclusion about what the hashes are (for the second time). Finally, it starts iterating over your manual mapping models (the .xcmappingmodel bundles).

And then you see that it finds your mapping model, picks up on it, then decides the hashes are wrong and ignores it!

“What the…?” you wonder. You compare hashes, and they are listed in different order, but essentially the same.

I can only conclude this is a bug in Core Data (or in the entity editor in Xcode4).

Luckily it’s easy to remedy! Go to the mapping model, pick another source and destination model version, then restore to the correct source and destination model versions. Definitely do make a git commit prior to making this change so you can compare what happened.

Alternatively, an answer on StackOverflow has a different solution which can be applied in case you know what is the version of the original persistent store. It involves manually setting version hashes on the NSEntityMappings inside the NSMappingModel.

Patching an unrecognized selector into a misbehaving OS X app

Let’s say you have an app that misbehaves. As in, it raises an exception mentioning an unrecognized selector.

Of course, it’s third party and closed-source.

But you are an enterprising young developer and you really want to patch this app.

I will not identify the app that I patched, to avoid any impression that I’m cracking the app. (It’s a popular app and I’ve run into pretty nice anti piracy protection blocking gdb on multiple layers. Since I’m not familiar with cracking and was not even attempting that, I’ve decided that it’s best to simply avoid mentioning the app name.)

Makefile

all: misbehavingappfixer.dylib

misbehavingappfixer.dylib: misbehavingappfixer.o
        gcc \
                -dynamiclib \
                -undefined suppress -flat_namespace \
                misbehavingappfixer.o \
                -framework Cocoa -o misbehavingappfixer.dylib
run:
        DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=`pwd`/misbehavingappfixer.dylib /Applications/Misbehaving\ App.app/Contents/MacOS/Misbehaving\ App

misbehavingappfixer.c

#include 
#include 
static CFStringRef nameImp(id self, SEL _cmd)
{
        return CFSTR("IVFlawedClass");
}

void inject_init(void) __attribute__((constructor));
void inject_init(void)
{
        Class _IVFlawedClass = objc_getClass("IVFlawedClass");
        if(!_IVFlawedClass)
        {
                printf("Could not find IVFlawedClass");
                return;
        }

        SEL nameSel = sel_registerName("name");
        class_addMethod(_IVFlawedClass, nameSel, (IMP)nameImp, "@@:");
}

I avoided using Objective-C because I had some issues when I tried going that route. It should work, but I didn’t want to spend any more time on this than I already have.

Now, to use this:

make
make run

This will compile the fix dylib, and then launch the Misbehaving App while first preloading our fix dylib.

For more information, see these:

Note: from comments on Mike Ash’s post, it seems that since I’m not overwriting symbols, I don’t need to (and, more importantly, *should* not) be using flat namespace. That means, I should not be using DYLD_FORCE_FLAT_NAMESPACE and -flat_namespace.

But, it works for me, so what the hell. 🙂

Exploring Apple's customization of titlebar in Xcode 4

As you may have noticed, Xcode’s NSWindow does not actually have a single representedURL; it has two, the project and the current in-project file.

So how did Apple achieve that?

First things first, you can start figuring that out by yourself by asking your window’s contentView for its superview. Although undocumented, enough apps seem to be playing around with this (including Xcode) that I presume Apple would be reluctant to change something important here.

Second, I’m not going to actually show you any code just yet. Perhaps in a future blog post; I did start writing something, but it’s unfinished.

Third, there is no third: let’s get to it.

Hacking tools

Playing with contentView‘s superviews can only get you so far (although, you may be able to hack something anyway). Injecting code in form of plugins into Xcode is possible, as proven by JugglerShu’s XVim.

But there’s a nicer way.

Say hello to F-Script. It’s a nice scripting language and let’s-call-it mini-IDE in itself, but there’s something far more powerful it can do.

On F-Script

It has a full fledged object browser that uses introspection to figure out what the hell exists in the view hierarchy. It also has a nice view picker so you can easily access the exact view that you’re playing with. Python may be neat for programming, but this one is just smashing for debugging GUI apps.

F-Script is not intended to be used as a standalone dev environment however; you’re supposed to put it into your app and use it at runtime. Kind of like what you can do with Python already… except this one comes with a runtime debugging GUI out of the box (and the aforementioned view picker!), and is pretty dedicated to playing with Cocoa and Objective-C (while Python can play with it through its PyObjC bridge – powerful, but not the best way to do it; also, method names become lengthy and weird when written in Python).

Note that I, for now, have absolutely no experience with F-Script as a programming language, and I don’t intend to learn it too much for now, just as I don’t intend to learn all nuts and bolts of GDB. It may be nice, but for now, it’s far, far, far more amazing as a debugging tool.

Okay, so where does playing with Xcode come in?

Unfortunately, not in the form of injecting the debugging code into Xcode and playing with it. This is the loveliest part of F-Script, however; you can inject it into any app and inspect how it works, see runtime class definitions, send messages to existing objects, etc. But not with Xcode, because of some magic that Xcode is doing causing F-Script to crash Xcode.

Side note: injection of F-Script is done via gdb. The F-Script Anywhere automator workflow intended to be put into ~/Library/Services actually consists of figuring out frontmost app’s process ID, constructing some gdb commands and running gdb. gdb commands used involve attach to existing process, then calling Objective-C method -[NSBundle load] on /Library/Frameworks/FScript.framework, and finally calling +[FScriptMenuItem insertInMainMenu] and detaching. Quite ingenious!

Finding the beast

Let’s get back to business. Although Xcode crashes, view inspector of F-Script works long enough to let us know the name of the class implementing the custom view Apple uses in the titlebar for displaying two “represented URLs”. A-ha! DVTDualProxyWindowTitleView, we’ve found you!

Now, where could this be defined? Let’s explore various private frameworks found in Xcode using class-dump (install it from MacPorts). And voila! Xcode.app/Contents/SharedFrameworks/DVTKit.framework. Using class-dump we can also see that it’s used in… DVTDualProxyWindow, a subclass of NSWindow. Wonderful!

Now, just trying to load this framework into standalone F-Script.app fails miserably and returns NO. At least for me. otool -L told me which frameworks this one depends on… so I loaded them first.

About the beast

Finally, DVTDualProxyWindow is a subclass of NSWindow which apparently overrides -setTitle: to do nothing, overrides -setRepresentedURL: to be used for the ‘project’ URL, and defines new method -setSecondaryRepresentedURL: to add the ‘document’ URL. Both of these methods are just talking to DVTDualProxyWindowTitleView. We don’t really care what happens behind the scenes; it’s just a regular view. But let’s see if it works.

Open F-Script app. Right click on the toolbar and choose ‘Customize’. Aside from customization sheet, a new window appears titled ‘Custom Buttons’. Pick one of ‘CustomX’ buttons, and select ‘Block…’. (Of course, prior to that, in the toolbar customization sheet, drag the picked button to the toolbar… you know, so you can click it.)

Now, paste in the following code.

Testing the beast

[:selectedObject | 



(NSBundle bundleWithPath:'/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework') load.

(NSBundle bundleWithPath:'/System/Library/PrivateFrameworks/DataDetectorsCore.framework') load.

(NSBundle bundleWithPath:'/System/Library/PrivateFrameworks/DataDetectors.framework') load.
(NSBundle bundleWithPath:'/System/Library/Frameworks/SecurityInterface.framework') load.
(NSBundle bundleWithPath:'/System/Library/Frameworks/Carbon.framework') load.
(NSBundle bundleWithPath:'/System/Library/Frameworks/CoreServices.framework') load.

errorPointer := FSObjectPointer objectPointer.
(NSBundle bundleWithPath:'/Applications/Xcode.app/Contents/SharedFrameworks/DVTKit.framework') loadAndReturnError:errorPointer.


" printing out an error: 
   errorPointer at:0.
"

"win := ((DVTDualProxyWindow alloc) init)."

win := DVTDualProxyWindow alloc initWithContentRect:(125<>513 extent:383<>175)
                                   styleMask:NSTitledWindowMask + NSClosableWindowMask + NSMiniaturizableWindowMask + NSResizableWindowMask
                                     backing:NSBackingStoreBuffered
                                       defer:NO.

(win setRepresentedURL:(NSURL fileURLWithPath:'/Applications/Xcode.app')).
(win setSecondaryRepresentedURL:(NSURL fileURLWithPath:'/Applications/Xcode.app')).



"Instantiate a button, put it in the window and configure it"
button := NSButton alloc initWithFrame:(247<>15 extent:90<>30).
win contentView addSubview:button.
button setBezelStyle:NSRoundedBezelStyle.
button setTitle:'Boo'.
button setKeyEquivalent:'\r'.

"An example of using F-Script blocks to handle click on button. Ignore it."
conversionScript := [(form cellAtIndex:2) setStringValue:(form cellAtIndex:0) floatValue * (form cellAtIndex:1) floatValue].

" From docs: "
"The [...] notation creates an object of class Block which represents a block of code that can be executed later (Block is an Objective-C class provided by the F-Script framework). In our block, we simply get the values of the fields in the user interface objects, perform the computation (simply involves multiplication) and put the result in a UI element.
"

"An example on how to add handling for button click. Ignore it."
"Make the script the target of the button.
The script will be evaluated when the user presses the button"
button setTarget:conversionScript.
button setAction:#value.


"Show window"
(win orderFront:nil).



]

Click on the ‘Run’ button, and type in ‘nil‘. (You don’t really care about the selectedObject, but I did not study F-Script long enough to avoid it.)

Hopefully this gives you enough idea to debug with, explore with, as well as an idea on how to implement dual-representedURL windows. Good luck and have fun! 🙂

NSMutableDictionary without automatic retaining of contained objects

There may arise a situation where you absolutely can’t do something without either doing ugly hacks with overriding -release (which you should never, ever do), or using non-Objective-C constructs such as C++’s std::map (shudder), or rolling out your own key-value storage data structure (evil NIH syndrome strikes again).

The Reason

The only valid reason I can think of for doing this is to avoid a cyclic reference. For example, an object must be stored in a dictionary, but should be automatically removed from it upon being -dealloc‘ed. This is exactly what I’m doing in a game I’m slowly working on in order to cache OpenGL textures. I tried hacking this by overriding -release and monitoring -retainCount. Any Objective-C developer worth the name will know that’s a pretty dumb thing to do: -retainCount is a pretty shaky thing to depend on, due to various compiler optimizations, and overriding -release can only cause issues. (Yes, that includes overriding -release to force yourself and your teammates never to destroy a singleton. I actually saw that being done in production code. Pretty nasty stuff.)

Pretty much invalid reasons are:

  • storing non-Objective-C pointers or data types. If you’re making use of NSMutableDictionary, you’re probably making use of Objective-C and Foundation. So make use of the reference counting mechanism built into the framework by wrapping the non-Objective-C data type into something that can be swallowed by the framework nice and easy. Create a thin wrapper around this data by subclassing NSObject
  • not wanting to deal with the reference counting system. Oh, so you’re one of those people who don’t like to use -retain/-release/-autorelease? You find them abhorrent? Go and cry to your mommy; the reference counting system is one of the most powerful mechanisms enabled by Objective-C and provided by Foundation. Shunning it is no good.

Oh, and if you’re one of the ARC-loving pansies developers, sorry; I have no idea what effect this’ll have on your funny-colored little world. Because we’re about to dive into the mean world of Core Foundation.

This also, sadly, means I have no idea how this’ll work with GNUstep.

The Explanation

So you may have heard that Core Foundation equivalents of Foundation classes are “toll-free bridged”. What does this mean?

This means that if you create a CFArray, you can use the resulting pointer as an NSArray, and vice versa. This is pretty handy if you’re writing code that interacts with Mac OS X’s kernel. When writing something that talks to Bluetooth subsystem (say, a new Bluetooth service), you will use C functions that accept and return CFDictionary instances. Oh, sir, yes they do.

So to clean up your code of all those nasty CFDictionary*() function calls, and make it look all nice and Objective-C-ish, what can you do? You just pass the resulting CFDictionary pointer as the first thing in the brackets (you know, where you usually put an Objective-C message target?) and you use plain old Foundation message sends to do operations with the dictionary. To get rid of the warning, you can cast it either prior to the message send or in-line when performing the send.

  CFDictionaryRef dict; // same as CFDictionary *
  
  // . . . initialize it here . . .

  [((NSDictionary*)dict) valueForKey:@"someKey"];
  // ...or alternatively:
  NSDictionary * theDict = (NSDictionary*)dict;
  [dict valueForKey:@"someKey"];

And you can also do the opposite thing! You can create an NSDictionary and pass it off as a CFDictionary.

  NSDictionary * dict = [[NSDictionary alloc] initWithObjectsAndKeys:@"value", @"key", nil];

  // . . . use it here . . .

  // now we'd have to do [dict release].
  // or, we could have autoreleased the object right after
  // initializing it.
  // but let's be fancy.
  CFDictionaryRef cfDict = (CFDictionaryRef)dict;
  CFRelease(cfDict);

The Solution

So how do we actually create a NSMutableDictionary whose objects won’t be retained nor released?

It turns out to be wonderfully simple. You see, CFDictionaryCreateMutable() is a C function. And C doesn’t have a concept of reference counting built deep down into its core. So when you create a dictionary for use with C code, in a C-only program, you probably don’t want the dictionary to try to send messages to pointers which are not really Objective-C objects.

And as we have demonstrated each CFDictionary is actually an NSDictionary.

If you are using a C function, it’s a good idea to actually default to C behavior: no retaining and no releasing. It might also be a good idea to allow one to use a third-party reference counting mechanism?

That’s exactly what was done here. When calling CFDictionaryCreateMutable(), you feed it an allocator which can be used to allocate memory instead of the default one, the default capacity (just like -initWithCapacity:), and two pointers which describe just how the dictionary should behave when retaining, releasing, describing, copying, hashing and comparing values and keys.

First thing I did, and that seems to work quite well, is just pass NULL for the last two pointers. That is, it works quite well when your keys are constant strings which won’t be released that easily. I haven’t experienced a crash even when they aren’t, but let’s not risk it.

So let’s see.

NSMutableDictionary * ourDictionary = (NSMutableDictionary*)CFDictionaryCreateMutable(nil, 0, NULL, NULL);

Good, but let’s improve it by passing a pointer to a default structure for copying and releasing keys. Note that NSMutableDictionary also copies its keys. Exploring why it does so should be an exercise for the reader.

NSMutableDictionary * ourDictionary = (NSMutableDictionary*)CFDictionaryCreateMutable(nil, 0, &kCFCopyStringDictionaryKeyCallBacks, NULL);

Now our keys are copied and released where appropriate, while the values are left untouched.

Optionally, explore using kCFTypeDictionaryKeyCallBacks in situations where your keys may be other CFType-derived objects. (That is, not just CFStrings/NSStrings.) Don’t use this if there is even a remote chance of your key being a mutable object.

Overriding HTTP user agent for calls to -initWithContentsOfURL:

Perhaps you need to override the HTTP user agent whenever you call -initWithContentsOfURL: from classes such as NSString, NSDictionary or NSArray, or one of this method’s convenience wrappers such as +stringWithContentsOfURL:, +dictionaryWithContentsOfURL: or +arrayWithContentsOfURL:. So let’s consider how this can be accomplished under iOS.

From what I can see, there is no easy and “clean” way apart from adding a category on the classes where you need to support this and writing your own implementation of -initWithContentsOfURL: and convenience functions (with a slightly different name, of course). These implementations would use NSURLConnection‘s +sendSynchronousRequest:returningResponse:error:. Of course, as with -initWithContentsOfURL: you’d use this replacement method in a background thread to maintain UI responsiveness.

You’d have to write a reimplementation of -initWithContentsOfURL: because the first place you can change this is NSURLRequest, or more specifically, its mutable variant NSMutableURLRequest, using the -setValue:forHTTPHeaderField:. But, if you have tons of code, you probably can’t easily change it to use the new method.

So I dug in and, with a few smart tricks (such as feeding a broken non-NSURL as a NSURL to figure out which methods get called, then implementing them as necessary), I figured out which of several ways for fetching web content is actually used in NSString‘s implementation of -initWithContentsOfURL:. These could have been NSURLConnection or some low level messing with CFNetwork.

It turned out not to matter since NSURLRequest is generated out of the NSURL passed to the method. Customizing the user agent turned out to be just a matter of taking all NSURLRequests, forcing them to become mutable copies in form of instances of NSMutableURLRequest during the initializer and setting the user agent at that time. Specific initializer appearing in iOS implementation used in iOS 5 Simulator that ships with Xcode 4.2.1 appears to be -initWithURL:cachePolicy:timeoutInterval:.

It’s an enormous hack, but I decided to simply swizzle this method out. Swizzling NSURLConnection‘s class method +sendSynchronousRequest:returningResponse:error: did not appear to work – the original method still got called despite my best efforts to figure out what went wrong with swizzling, so I gave up on it. If you can see a mistake in my class swizzling code, please tell me about it in the comments section below.

I definitely have no idea whether or not your app will be rejected for this, but from what I know, method swizzling is not illegal.

//  NSURLRequest+UserAgentFix.m

 YOUR_USER_AGENT @"Your User Agent"
 "NSURLRequest+UserAgentFix.h"
 "NSObject+ISSwizzling.h"
@implementation NSURLRequest (UserAgentFix)
+(void)load
{
    [self swizzleMethod:@selector(initWithURL:cachePolicy:timeoutInterval:)
             withMethod:@selector(initWithURL2:cachePolicy:timeoutInterval:)];
}
-(id)initWithURL2:(NSURL *)URL cachePolicy:(NSURLRequestCachePolicy)cachePolicy timeoutInterval:(NSTimeInterval)timeoutInterval
{
    self = [self initWithURL2:URL cachePolicy:cachePolicy timeoutInterval:timeoutInterval];
    
    if(!self)
        return nil;
    
    if([self class] == [NSURLRequest class])
        self = [self mutableCopy];
    
    if([self class] == [NSMutableURLRequest class])
    {
        NSMutableURLRequest * req = self;
        [req setValue:YOUR_USER_AGENT forHTTPHeaderField:@"User-Agent"];
    }
    
    return self;
}
@end

// NSURLRequest+UserAgentFix.h
 <Foundation/Foundation.h>

@interface NSURLRequest (UserAgentFix)

@end
// NSObject+ISSwizzling.h
 <Foundation/Foundation.h>

@interface NSObject (ISSwizzling)
+ (BOOL)swizzleMethod:(SEL)origSelector withMethod:(SEL)newSelector;
+ (BOOL)swizzleClassMethod:(SEL)origSelector withMethod:(SEL)newSelector;

@end
// NSObject+ISSwizzling.m
 <objc/runtime.h>
 "NSObject+ISSwizzling.h"

@implementation NSObject (ISSwizzling)
+ (BOOL)swizzleMethod:(SEL)origSelector withMethod:(SEL)newSelector
{
    Method origMethod = class_getInstanceMethod(self, origSelector);
    Method newMethod = class_getInstanceMethod(self, newSelector);
    
    if (origMethod && newMethod) {
        if (class_addMethod(self, origSelector, method_getImplementation(newMethod), method_getTypeEncoding(newMethod))) {
            class_replaceMethod(self, newSelector, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
        } else {
            method_exchangeImplementations(origMethod, newMethod);
        }
        return YES;
    }
    return NO;
}
+ (BOOL)swizzleClassMethod:(SEL)origSelector withMethod:(SEL)newSelector
{
    Method origMethod = class_getClassMethod(self, origSelector);
    Method newMethod = class_getClassMethod(self, newSelector);
    
    Class class = object_getClass((id)self);

    if (origMethod && newMethod) {
        if (class_addMethod(class, origSelector, method_getImplementation(newMethod), method_getTypeEncoding(newMethod))) {
            class_replaceMethod(class, newSelector, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
        } else {
            method_exchangeImplementations(origMethod, newMethod);
        }
        return YES;
    }
    return NO;
}

@end

Tested on iOS 5 Simulator with NSString‘s +stringWithContentsOfURL:.