Fabián Cañas' Blog

Safe Casting in Objective-C

Fri, 14 Feb 2014 02:36:23 MST

I’m writing a small safe casting for Objective-C. I’ll be putting it on GitHub

The Story

Somewhere on the web, there was some test I took to determine how well I know Objective-C. I think it was elance. One question which infuriated me at the time was something like “if you have an array NSArray *a, how do you make it an NSMutableArray?” The reason I got angry was that the answer was supposedly

NSMutableArray *mutableArray = (NSMutableArray *)a;

Except that this is tremendously dangerous, wrong, stupid, crazy… well. You get the picture. The real answer of course is something like

NSMutableArray *mutableArray = [a mutableCopy];

Unless you want to actually modify the same instance that a is if it’s a mutable array, in which case you have to do the all-too-familiar dance

NSMutableArray *mutableArray;
if ([a isKindOfClass:[NSMutableArray class]]) {
    mutableArray = a;
}

At which point you proceed to mutate mutableArray, which is also a, possibly ignoring the fact that mutableArray may be nil. Or maybe you return early if it’s nil.

Casting is Dangerous

If you cast between object that are the same foundational type, no work is done. What I mean is that if you cast from an float to an int, since they’re represented differently in the machine, some work is done to represent that float as a int that changes the value you’re working with.

In Objective-C, when we’re dealing with objects, we’re dealing with pointers to objects. These are really just pointers. They represent a memory address, and not a real usable value. So if you cast an NSArray to an NSMutableArray, nothing happens. Same if you case an object to an int *. (Which is coincidentally prohibited by ARC for similar reasons that ARC prohibits putting objects in structs… It’s necessary to make certain restrictions in order to ensure the correctness of the program, which is what ARC concerns itself with. But anyway, casting an object to an int * used to be perfectly valid, if slightly insane.)

Almost every time I see a cast involving an Objective-C object, I get very worried. Objective-C has a lovely type system. We should use it. Our compiler helps us move finding bugs from run time to compile time. Casting is a way to tell the compiler “don’t worry, I know what I’m doing.” But I’ve seen too many cases of people not knowing what they’re doing. They forget that method signatures specify a more general type for a reason. If you are passed an object with type id<MyProtocol>, you shouldn’t even assume you’re working with an NSObject. And if you’re passing around raw ids all the time, you should strongly consider coming up with good protocols. Or maybe you’re taking a parameter that may be one of two very distinct types you say? Well that’s certainly odd, but I hope you’re at least doing the Objective-C casting dance.

Getting Rid of the Casting Dance

I wrote the casting dance out above. But here it is again with a little more detail.

NSMutableArray *ma;
if ([a isKindOfClass:[NSMutableArray class]]) {
    // You have a mutable array!
    ma = a;
} else {
    // You don't have a mutable array!
}
// `ma` is `nil` if `a` wasn't originally an `NSMutableArray`

I want to get rid of that, and many things like it. So this project aims to reduce the above down to this

NSMutableArray *ma = [NSMutableArray cast:a];
// `ma` is `nil` if `a` wasn't originally an `NSMutableArray`

Conditional Code

Often what we really want to do is run certain code if an object is of a specific type.

if ([a isKindOfClass:[NSMutableArray class]]) {
    NSMutableArray *ma = a;
    [ma addObject:x];
}

Technically, this could have the same effect

[[NSMutableArray cast:a] addObject:x];

Practically, this ends up getting more complex. Likely I will want to include ways of running a block with the passed object if the object is the kind that’s expected. Maybe something like

[NSMutableArray cast:a intoBlock:^(NSMutableArray *ma){
    [ma addObject:x];
    [ma addObject:y];
    [ma addObject:z];
}];

or even

BOOL success = [NSMutableArray cast:a intoBlock:^(NSMutableArray *ma){
                   [ma addObject:x];
                   [ma addObject:y];
                   [ma addObject:z];
}];
if (!success){
    // Do whatever it is you need to do if `a` is not mutable...
}

But what’s the point?

Conciseness

It is more concise, while also being idiomatic.

Education

Every Objective-C programmer knows how to cast. Sadly, many don’t understand that it doesn’t give you any guarantees. It just tells the compiler “shut up, I know what I’m doing”. Here’s at least one example more related to fast enumeration. But surely you’ve explained this sort of thing to somebody in the past? It’s an honest enough mistake to make.

It’s too easy to gloss over the casting dance, correct code that looks very familiar (and if and a cast), and not realize that there’s a very important technical decision being made there. I would rather somebody come across a weird cast: method in my code base and ask why it’s there. Then I can go on about the dangers of casting.

Clarity

The closer that code can read to prose the better the intent of the programmer can be understood. It also means that there’s fewer places for bugs to creep in. Consider doing something with items in an array.

We used to do things this way. Novices a day into a “learn to code” camp can read that. Loops are boring (and error prone).

NSArray *a;
for (int i = 0; i &lt; a.count; i++) {
  NSLog(@"%@", a[i]);
}

Then fast enumeration came along, and off-by-one and out-of-bounds errors became rarer.

NSArray *a;
for (id object in a) {
  NSLog(@"%@", object);
}

And I even prefer block enumeration sometimes because it puts the semantics of what we’re doing in the message we’re sending instead of in understanding the syntactic sugar of fast enumeration.


NSArray *a;
[a enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
    NSLog(@"%@", a);
}];

This is especially helpful when dealing with other collection types. Some people don’t know off the top of their heads whether fast enumeration of a dictionary iterates over objects or keys.

Digress and Reflect

With all the recent chatter about Apple needing to replace Objective-C, one common call is to move away from C. That “we’re one NULL pointer dereference away from a crash”. I don’t remember the last time code I’ve worked closely with crashed from a NULL pointer dereference. It happens when you’re using C language features, and most code where you can’t avoid C is code that belongs in C (image manipulation, DSP). I think it’s clear that the very best Objective-C developers need to know and love C inside and out. But you can make a lot of pretty solid apps without knowing much about C.

I think it’s much more common for an app to crash with unrecognized selector sent to instance. And here’s why I brought up the “Apple needs to drop Objective-C” thing. Objective-C is remarkable for its powers of introspection and runtime manipulation. What I’ve described above is possible. I think it will be easy. So I’m making a project on GitHub, and starting work on it tonight.

OHMKit

Sat, 27 Jul 2013 02:14:29 MST

I’ve written Objective-C code to turn a service response into a fully hydrated model object too many times. It also seems I’m not the only one. Just a couple of weeks ago, I decided to put together OHMKit so I’d never have to write boilerplate code for object mapping again.

Check out the source on GitHub!

OHMKit is a mixin to make any Objective-C class easier to hydrate from a dictionary representation, such as you might get from a web service. It makes it easy to keep any direct knowledge of the idiosyncrasies of the service you’re consuming tucked away in a single place.

It exists because RestKit (which is awesome by the way), is sometimes too big, heavy, and indirect.

This project doesn’t know about networks. Use AFNetworking.

This project doesn’t know about routes. Use SOCKit.

This project doesn’t know about CoreData. It will not manage graphs of entities for you quite like RestKit does. But it is built on KVO, and does not care about your model objects’ super class. So you can safely make subclasses of NSManagedObject mappable.

Usage

Basic Mapping

Given a model

@interface MYModel : NSObject
@property (nonatomic, strong) NSString *name;
@property (nonatomic, strong) NSString *favoriteWord;
@property (nonatomic, assign) NSInteger favoriteNumber;
@end

Anywhere in you application, make the model mappable, and assign it a dictionary of mappings from the keys a service will provide to the keys your actual model object uses.

OHMMappable([MYModel class]);
OHMSetMapping([MYModel class], @{@"favorite_word"  : @"favoriteWord",
                                 @"favorite_number": @"favoriteNumber");

And now anywhere in your application, objects of the class MYModel can be hydrated with a dictionary from a service whose keys will be translated by the mapping dictionary you provided.

MYModel *testModel = [[MYModel alloc] init];

	[testModel setValuesForKeysWithDictionary:@{"name"           : “Fabian”,
                                            "favorite_word"  : “absurd”,
                                            "favorite_number": 47];

Recursive Mapping

You don’t have to do anything special to get recursive mapping of mappable objects. If an object conforming to <OMMappable> has a property whose type also conforms to <OMMappable>, and the value for that key in the hydration dictionary is itself a dictionary, we’ll instantiate a new model object and hydrate it. (If that didn’t make sense, just read the next code snippet)

interface MYClass : NSObject
property (nonatomic, strong) NSString *name;
@end

	interface MYClass2 : NSObject
property (nonatomic, strong) NSString *name;
property (nonatomic, strong) NSString *favoriteWord;
property (nonatomic, assign) NSInteger favoriteNumber;
property (nonatomic, assign) MYClass *favoriteObject;
end

	OHMMappable([MYClass class]);

	OHMMappable([MYClass2 class])
OHMSetMapping([MYClass2 class], {“favorite_word”  : "favoriteWord", 
                               “favorite_number”: "favoriteNumber", 
                               “favorite_object” : @“favoriteObject”});

	MYModel *testModel = [[MYClass2 alloc] init];

	NSDictionary *class2Response = {“name”           : "Fabian", 
                                 “favorite_word”  : "absurd", 
                                 “favorite_number”: 2, 
                                 “favorite_object”: {“name” : @“Rock”}};

	[testModel setValuesForKeysWithDictionary:class2Response];

Now, testModel.favoriteObject is an instance of MYClass hydrated with “Rock” as its name.

Internally, the new model object is initialized with [[ alloc] init], and then hydrated with [ setValuesForKeysWithDictionary:dictionary]. If you have a model that needs special consideration for initialization, use an adapter block.

Adapter Blocks to handle special properties

Users can pass a dictionary of blocks for field requiring special handling. Say a service sends back a dictionary that looks something like this:

{
    “favorite_color”: [
        122,
        50,
        80
    ],
    “least_favorite_color”: [
        121,
        51,
        81
    ]

	}

and we expect to map it to a model like this

@interface MYModel : NSObject
@property (nonatomic, strong) UIColor *favoriteColor;
@property (nonatomic, strong) UIColor *leastFavoriteColor;
@end

You can adapt the response with an adapter block:

OHMMappable([MYModel class]);
OHMSetMapping([MYModel class], @"least_favorite_color" : @"leastFavoriteColor", @"favorite_color" : @"favoriteColor")
OHMValueAdapterBlock colorFromNumberArray = ^(NSArray *numberArray) {
    return 
                           green:[numberArray[1] integerValue]/255.0
                            blue:[numberArray[2] integerValue]/255.0
                           alpha:1];
};
OHMSetAdapter([MYModel class], @{@"favoriteColor": colorFromNumberArray, @"leastFavoriteColor": colorFromNumberArray});

Note that the key for the adapter is the key on the model object, not on the response. And adapters are added for a property, not a type. If the above example had multiple properties that were colors, you would have to set an adapter block for each property. It would be smart to reuse adapter blocks in your code.

The OHMValueAdapterBlock type is a block that takes an id and returns an id. i.e typedef id(^OHMValueAdapterBlock)(id);

TODO

Undefined Keys

The behavior of undefined keys should be configurable at 3 levels:

Raise, because I should know about everything.
Drop unrecognized keys. We don’t need them, but we shouldn’t crash.
Add keys to a dictionary so that serialization/deserialization can be symmetric

Option 2 is currently the only behavior, and I’m inclined to leave is as the default behavior.

NSCoding

It might be nice if we built a way to make a class NSCoding compatible if it’s not already. I like Mantle, but I don’t want to be told what my super class should be (had you noticed?).

Per File ARC in CocoaPods

Sat, 04 May 2013 03:11:04 MST

tl;dr

Pod::Spec.new do |s|
  s.name = 'MyPod'
  ...
  non_arc_files = 'Classes/FirstNonARCClass.m',
    'Classes/SecondNonARCClass.m',
    'Classes/ThirdNonARCClass.m'
  s.requires_arc = true
  s.source_files = 'Classes/*.{h,m}'
  s.exclude_files = non_arc_files
  s.subspec 'no-arc' do |sna|
    sna.requires_arc = false
    sna.source_files = non_arc_files
  end
end

ARC

Automatic reference counting (ARC) is a good thing. It's a great compile-time technology that makes it easier, in most cases, to not accidentally introduce trivial memory leaks in modern Objective-C apps.

But sometimes, you have older code with traditional memory management; it's not really worth converting to ARC if it's correct, and possibly finely tuned. And sometimes ARC introduces a little unnecessary overhead that can balloon out of control when handling large numbers of objects. There are also good reasons to put Objective-C objects into structs or other odd places that ARC prohibits or makes difficult (Objective-C++ anyone?).

That said, ARC is almost always a good idea. And so disabling ARC should be the exception, not the rule.

CocoaPods

CocoaPods is an excellent dependency management system for Objective-C projects. Dependencies are distributed as 'Pods' which are described in podpecs. A podspec is a kind of build description, that specifies where the source is to be found, dependencies it has, and how it should be configured and compiled.

CocoaPods lets you specify ARC on a spec or subspec basis, but doing so on a per-file basis is not planned for the spec DSL. The suggested way of doing this is a little unsatisfactory because it has you listing each file to exclude twice. Luckily we're working with ruby and we can just exctract the list of files to exclude into a list we can use to exclude from the sources and include in a non-ARC subspec.