Empathy and Thoughtfulness

In spite of my skepticism, I gave Big Nerd Ranch a shot, and in one week over the holiday break, I worked through Big Nerd Ranch’s Objective-C Programming and iOS Programming guides. It was immediately obvious that the authors cared deeply for the reader’s understanding of the content. This sense of empathy and thoughtfulness aided the learning process, and allowed me to start my first iOS application immediately.

Focus on learning

And now, just half a year later, I am settling into a developer internship with Big Nerd Ranch. On our first day, each member of the intern team was given an office tour, a workstation, a mentor and a MacBook Pro. As a first assignment, I was asked to review an internal iOS application, and to introduce some additional features using Test-Driven Development (TDD), a concept that was new to me. My instructions were to borrow books from the Big Nerd Ranch library, try things, ask questions of anybody, make mistakes, and learn. There was no deadline, no threat of penalty if I didn’t perform—the utmost concern was that I learn.

And learn I have. My mentor and a few other experienced developers review my code and provide comments, questions and challenges. This simple process has been very powerful, exposing me to the tools and techniques of experienced iOS developers, and I receive feedback at the right place and time. I’m continuing to work on that application, and have been invited by another developer to research and implement automated testing on a major project.

Nerdvana

There are lots of nerdy perks at the Ranch: coffee, standing desks, breakfast, a ping-pong table, a massage therapist, Tech Talks—but what has been most meaningful to me is the same thing I felt while reading the Big Nerd Ranch guides: an overwhelming sense that learning is what matters.

In my opinion Big Nerd Ranch’s strength lies in this focus on learning. It is applied to their guides, classes, and app development process. This may be what they mean by Nerdvana, a sense that there should be few barriers between you and the knowledge you seek. Nerdvana, for me, is not knowing what Objective-C was six months ago, but now being able to read an expert’s code comments and understand them.

The post Empathy, thoughtfulness, and learning: Being an Intern at Big Nerd Ranch appeared first on Big Nerd Ranch Blog.

Nerd extraordinaire Steve Sparks wrote a new take on a classic that we know you’re going to love. Check it out on Vimeo or on YouTube.

Cocoa Got Blocks

The post Cocoa Got Blocks appeared first on Big Nerd Ranch Blog.

Be True to your Self

One of the simplest object interrogation methods is -self. You send it to an object, and you get that object back. I love weird little methods like this. Is there some kind of corner case that it addresses? Maybe there’s some cool technique I’m missing. Why would you have a call like this? Why go to the trouble of calling

thing2 = [thing1 self];

rather than just doing

thing2 = thing1;

One use of -self is throwing a monkey wrench into ARC. You’ve got a bug where ARC is thinking you’re done with an object, but you’re actually not, and it’s getting released from underneath you. After you file a Radar saying that ARC is mis-handling a corner case, add a call to [thing1 self] at the bottom of your method. The compiler will think you’re still using thing1 (because you now are), and the actual method is as close to a no-op as you can get.

Another use is in higher-order programming interfaces. -self is a method that takes no arguments and returns an object. A lot of other methods, like -uppercaseString, do the same thing. Say you had a function that applies a map operation to an array, where a “map operation” sends a message to every element of an array and then collects the results into another array and returns it. Here’s a cheesy implementation of a map:

NSArray *MapArrayWithSelector (NSArray *array, SEL selector) {
    NSMutableArray *map = [NSMutableArray array];

    for (id thing in array) {
        id result = [thing performSelector: selector];
        if (result) [map addObject: result];
    }

    return [map copy];  // Strip off mutability

} // MapArrayWithSelector

You can easily uppercase a set of names with it:

NSArray *names = @[ @"Emily", @"Step", @"Vikki" ];
NSArray *upperNames = MapArrayWithSelector (names, @selector(uppercaseString));

This returns an array populated with EMILY, STEP, and VIKKI. Say in your processing of data you decide that you want to pass an array through a pipeline of operations but you don’t want anything to change the data at some – just pass it on to the next stage. In that case, you can use -self as a no-op, a passthrough, without having to have any special casing:

NSArray *noOpNames = MapArrayWithSelector (names, @selector(self));

That’ll return the the list of names in their original mixed case.
Along those lines, you can use self in Key-Value Coding strings. This call is totally legal:

NSString *greeble = [@"Bork" valueForKey: @"self"]

Like with the map you can have a lot of functionality based on KVC and just use "self" when you don’t want the data to be transformed.

No, Really. Who Are You?

You can ask an arbitrary object a lot about its parentage. You can ask “are you a member of this class” with -isMemberOfClass:. You can also ask an object if it is a member of a class or a subclass of a particular class with -isKindOfClass:.

-isMemberOfClass: does an identity comparison between the receiver’s class and the class passed as an argument:

id null = [NSNull null];
if ([null isMemberOfClass: [NSNull class]]) NSLog (@"YEP!");

This prints out “YEP!”

Why am I using NSNull here, rather than a more common class like NSString? It turns out -isMemberOfClass: isn’t all that useful. Using it defeats the use of polymorphism. -isMemberOfClass: says that you don’t care about what an object can do, but that it is an instance of precisely one class.

With modern Cocoa, many of the objects you deal with on a regular basis are not actually the class you think they are, but are of a specialized subclass. Consider NSString. You’d think / hope that this would work:

if ([@"Howdy" isMemberOfClass: [NSString class]]) NSLog (@"YEP!");

But it actually doesn’t. Thanks to class clusters, the actual class of the literal string is an __NSCFConstantString. -isMemberOfClass: is asking “hey constant string, are you nothing but an NSString?” and the answer is, of course, “no”.

Instead you’d use -isKindOfClass:. This asks “Are you a member of the given class, or one of its subclasses.”. Another way of looking it is asking “Do you have this class somewhere in your inheritance chain?” Mutating the test by using -isKindOfClass: gives you good results:

if ([@"Howdy" isKindOfClass: [NSString class]]) NSLog (@"YEP!");

This will print out YEP. You’re just interested in that this thing is a string, not what particular flavor of string it is.

Checking Applications

There can be some practical applications of these kinds of check. One use of -isMemberOfClass: is in implementations of -isEqual, and you consider objects of two different classes to be unequal, even if their contents are the same:

- (BOOL) isEqual: (id) otherDude {
    BOOL equal = [self isMemberOfClass: [otherDude class]]
        && [[self name] isEqualToString: [otherDude name]]
        && [self shoeSize] == [otherDude shoeSize];

    return equal;
} // isEqual

(Just a quick style note – I like to split up the calculation and the return into two statements. It’s now very easy to put a breakpoint on the return statement and inspect what it’ll be returning.)

One use of -isKindOfClass: is querying an object you get back from a possibly insecure store. Users can muck with NSUserDefaults on the desktop, so you might get an object back that causes your program heartburn.

NSUserDefaults *defs = [NSUserDefaults standardUserDefaults];

NSDictionary *defaultDefaults = @{
   @"spoon" : @"waffle"
};

[defs registerDefaults: defaultDefaults];

It registers some defaults with NSUserDefaults. You can then later on get the value out and use it:

NSString *thing = [defs objectForKey: @"spoon"];
NSLog (@"thing is %@", [thing uppercaseString]);

You can find the complete program at this gist. What can go wrong? I put in a string, and I get out a string. On iOS it’s not that much of a problem (outside of program bugs), but on the Mac you can do all sorts of fun stuff. Here’s a run with the default value, a run after changing the default, and a final run after setting it a really bad value:

% ./defaults-death
2013-06-11 15:50:13.811 defaults-death[48089:303] thing is WAFFLE

% defaults write defaults-death spoon -string badger
% ./defaults-death
2013-06-11 15:51:01.548 defaults-death[48121:303] thing is BADGER

% defaults write defaults-death spoon -integer 23
% ./defaults-death
2013-06-11 15:51:12.319 defaults-death[48128:303] -[__NSCFNumber uppercaseString]: unrecognized selector sent to instance 0x17c3

(and you all know what a backtrace looks like)

What happened? The “spoon” user default now has an NSNumber in it, not an NSString. You try to do stringy-things with it and things blow up in your face. You can sanity check values you get back from NSUserDefaults like this:

NSString *thing = [defs objectForKey: @"spoon"];
if ([thing isKindOfClass: [NSString class]]) {
    NSLog (@"thing is %@", [thing uppercaseString]);
} else {
    NSLog (@"bad defaults, man!");
}

Anatidae Keyboarding

In general, though, querying an object for its class is a code smell. If you’re doing object-oriented design, you should be relying on polymorphism to obviate the need to know exactly what kind of object you’re dealing with. If you have tests all over your code like “is this a fish? Do this thing. Is this a battery? Do this other thing.” then you should re-think your design. There are valid times when you might ask an object in an arbitrary collection “are you an array? Ok, I’ll process you differently than if you were just a view.”, but it’s easy to fall back on -isKindOfClass: as a crutch.

Instead of asking “are you a fish?” or “are you a battery?”, you can instead ask very specific questions like “Do you support uppercaseString?” or “Do you respond to numberOfSectionsInCollectionView:?” by using the method -respondsToSelector:.

-respondsToSelector: takes your selector, grabs the class from the object (via the isa pointer), and roots around inside the pile of methods to see if your selector is in there. If it finds the selector in there, or finds it in the set of methods that the superclasses implement, it reports success. Otherwise, not.

Objective-C doesn’t really care about the flavor of the receiver when sending a message. It just cares that it can handle a particular message by running some code. The compiler might add some type checking to catch common errors as a convenience to us, but fundamentally it’s not necessary to the operation of the language. This message agnosticism is a very powerful behavior. It enables Duck Typing.

The term duck typing comes from the phrase “if this thing walks like a duck, talks like a duck, and plays poker as badly as a duck, then I can treat it as if it were a duck.” If an object responds to a particular set of messages, you can treat it as a particular kind of object. It doesn’t really matter what the actual class (or type) the object is.

Cocoa data sources and delegates take advantage of duck typing. Any object that can handle -tableView:numberOfRowsInSection: and -tableView:cellForRowAtIndexPath: can participate as a UITableView data source. This could be one of your navigation controllers. This could be a collection of media items. You could even put a category on NSArray to make any array a possible tableview data source.

You can adopt protocols in your @interfaces and class extensions to declare to the world “Hey, I implement the required methods of this protocol. And perhaps more!”. If you’re interested in protocols, you can get more info.

What about those optional methods? If you’re implementing code that calls optional delegate or data source methods, you would use -respondsToSelector: to see if a particular object responds to that method. If it responds, groovy! Go ahead and make the call. Otherwise, don’t even bother. Checking is easy:

if ([self.delegate
         respondsToSelector: @selector(worldMap:selectedCountryCode:)]) {
    [self.delegate worldMap: self  selectedCountryCode: countryCode];
}

An aside about -conformsToProtocol:. this is a call similar to -respondsToSelector: that tells you if a class conforms to a particular protocol. You can use this to pre-flight operations. You could load a plugin and check to make sure it conforms to your application’s interface to plugins. There’s one slight gotcha – -conformsToProtocol: doesn’t actually check to make sure that the methods are implemented. All it does is see if the creator of the class explicitly adopted the protocol, not that it actually implemented everything. Is this ever a problem? Rarely. But sometimes you might be in a situation where some other programmer’s delegate object is dying when you send it messages. They might have adopted the protocol, but not actually satisfied the contract.

How is that possible? Here are two classes. Goofus says he adopts UITableViewDataSource, but doesn’t actually implement anything. Gallant, being the shy retiring type, implements the required portions of the data source, but doesn’t tell anyone:

@interface Goofus : NSObject <UITableViewDataSource>
@end

@implementation Goofus
@end


@interface Gallant : NSObject
@end

@implementation Gallant
- (NSInteger)tableView:(UITableView *)tableView
    numberOfRowsInSection:(NSInteger)section {
    return 23;
}

- (UITableViewCell *)tableView:(UITableView *)tableView
         cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    return nil;
}
@end

The compiler might warn you about Goofus not implementing the required methods. And if you aren’t Fixing Your Warnings it can slip through. When you actually go to interact with one of these gents, the compiler will warn you that Gallant has bad mojo, but Goofus is OK:

Then, at run time, messages to Goofus will explode in your face. HA HA.

All that being said, I believe it’s perfectly fine to use -conformsToProtocol: as a quick check to see if this object might implement all of the required methods, just don’t expect it to do a deep introspection for you. If you’re having unrecognized selector issues with @required methods, double-check to make sure the class adopting the protocol is behaving.

Up next

Remember that complaint from earlier?

-[__NSCFNumber uppercaseString]: unrecognized selector sent to instance 0x17c3

Next time we’ll take a look at what causes that, and how you can leverage unrecognized selectors to your own advantage.

The post Inside the Bracket, part 3 – Who Are you? appeared first on Big Nerd Ranch Blog.

The small details

iOS7 brings a whole new interface, one that pays attention to the small details that define the total experience. The new look is centered on the idea of simplicity and efficiency, bringing order to complexity, as Jony Ive said. What this has served to remind me of is the complexity involved in making an app feel and look easy to use.

By now you’ve probably seen images of Apple’s re-design of several of the apps. Gone are the days of faux leather; instead we now have a systemwide flatter, more minimalistic look. As with any change, opinions on this shift will range from extremely negative to very positive, but one thing is for certain: it’s here to stay.

Changes for developers

Apple has gone all in with these changes and in a way forced the hand of developers from here on out. Consistency is one of the pillars of the iPhone/iPad ecosystem, and users enjoy having a common look, feel and experience across all of their apps. With Apple updating all of the stock apps, users will become accustomed to the new way of interacting with apps. Going back with the edge of the screen, fluid transitions between screens, and translucent views will all become second nature to the user. This means that users will begin to expect the same from third-party apps.

This doesn’t mean developers should immediately freak out and start working weekends to revamp their apps to match the new look. On the other hand, if your app has a custom UI that you’ve worked on over the years, you may be telling yourself, “I don’t need to make any changes. My app already looks great.”

I feel that these are both the wrong approach.

A deeper look

Instead, iOS7 warrants a deeper look at the app and its functionality. One of the things that Apple made clear was that they did not simply go about changing how things look. Instead, they focused on the experience and how things feel for the user. The word game Letterpress was given a 2013 Apple Design award because it “stands out for its beautifully understated game interface, simple gestures, subtle animations and restrained sound design.” So you can see that it’s not just changes in appearance that are important.

In all, I love Apple’s new change in design, and not entirely based on they way it looks. More importantly, I like the fact that the platform is evolving and changing, instead of clinging to what has worked in the past. Apple is forcing developers to look at their apps once again, and to think about how they can improve their experience. Developers will look at what Apple has done and “steal” certain features, but also will improve upon others, helping sustain the rich environment of apps that the iOS platform is known for.

The post WWDC 2013: Focusing on the little things appeared first on Big Nerd Ranch Blog.

As a developer, I’m working toward the same goal that Apple is: to delight people and improve their lives. So seeing Apple serve our shared audience so well means good things for the near-term future of iOS development. Yesterday’s keynote was a love letter to those users.

Apple made it clear that the Mac platform is alive and well. If you wondered what the next step was in the iOS-ification of OS X, Apple gave the same answer as always: Mac stands on its own merits. Apple has continued to improve the integration between their platforms, but not by pursuing some generic, hand-wavy goal of making them more similar. Each OS will continue to be fully tailored for the devices it is on, each detail intentional to that context. Apple has added even more shared APIs, as well as implemented pieces across lots of shared concepts (notifications, Messages, Maps, AirDrop, etc.). But they’re not sharing the UI or UX wholesale. Each detail of integration is hand-crafted for the platform it lives on.

Improved experiences

Let’s look at just one example. Users can now choose to get their iOS app’s push notifications on their Mac too. Not only can users have an improved experience, but Apple has just extended developers’ reach to customers. This can change how we think about push notifications, when and what to send.

You should start thinking about how you can use this to improve your user’s experience with your app. I don’t know if we have access to also allow custom responses/interaction right within the notifications, but I hope so. Certainly this makes it more compelling to use push notifications where they make sense, and also to consider a companion Mac app.

The moral of the story

The biggest takeaway I got from the WWDC keynote is that you should understand your users’ problem. Not their proposed solution, but the underlying problem. Then you should solve that problem, paying close attention to context and to the details. Don’t be distracted by any other solution you’ve seen before.

Instead, you should strive to design the perfectly fit solution, custom-tailored to the problem. Clear away everything else, and you’ll have something beautiful and powerful. All those things you cleared away? They can come back after you get the first, focused release out there. Iterate. Release. Listen to your customers. And repeat.

The post WWDC 2013 keynote: a love letter to users appeared first on Big Nerd Ranch Blog.

for (NSView *view in visibleviews) {
    [view drawRect: view.bounds];
}

Objective-C performs this magic by having a collection associated with each object. This collection has a mapping of names (like drawRect:) to chunks of code. The mapping of names to code happens at runtime, rather than compile or link time. This deferral comes at a slight performance penalty, but gives us access to interesting under-the-hood data at runtime, and also gives us a lot of flexibility.

What is this extra data? What is this flexibility? Glad you asked.

The Moving Pieces

Each object that’s floating around in memory is described by a class. In Objective-C, a class is an object too – it can receive messages. The class holds all the metadata that describes the instances of that class – things like the set of methods it implements, what protocols it adopts, any @properties, its instance variables, and so on. The class also has a reference to the one-and-only superclass of the class. Say UIButton inherits from UIView. This means that UIButton‘s superclass is UIView.

An individual object is a dynamically allocated chunk of memory that contains the instance variables of the object, such as the view’s bounds or the background fill color for a layer. The object also has a pointer, called isa, at a predictable location (the first 4 or 8 bytes of the object) . This points to the class. “isa” comes from “is-a”. This object in the memory is-a button because its isa pointer points to the UIButton class. It’s now very easy for you, when given any random Objective-C object, to find out where its class lives. Just look at the first pointer.

Here’s how all the chunks of data relate:

What’s going on in this diagram? A button’s isa pointer points to the UIButton class. The class has (amongst other stuff) a reference to its map of methods. It has a reference to its superclass (UIView) as well. UIButton implements some button-specific methods like drawRect and style, as well as the mysterious “blah” method. You can see that UIView implements some generic housekeeping methods, like the frame handling, background color storage, and it has its own version of blah.

So, that method map. It’s a dictionary of names and methods.

The name is called the selector. What’s a selector then? It’s the key into that dictionary. A selector is actually a char *, so you can print one out in gdb or lldb. This is an implementation detail, but makes for a nice debugging feature. The current selector is passed in a hidden argument called _sel, so you can “print _sel” inside of your debugger. If you’re going to and from string representation of selectors for actual work (say to some selector names in a Cocoa collection), use the NSStringFromSelector an NSSelectorFromString functions.

The selector is one side of the method map. The method implementation is on the other side. It’s the address of a function to call. It’s an IMP, short (and shouty) type that stands for “implementation”. An IMP is a function pointer which points to a function that takes an id and a selector:

typedef id (*IMP)(id, SEL, ...);

Look familiar? That’s the same as the arguments to objc_msgSend. It’s also the same two hidden parameters to methods: self and _sel.

You can ask an object for that function pointer that’s behind a particular message. It’s a function pointer, so you can jump through it like any other function pointer. Here’s some code that takes a string, gets the function pointer behind -uppercaseString, and then jumps through it directly. (Some code at this gist)

NSString *string = @"Bork";
IMP uppercase = [string methodForSelector: @selector(uppercaseString)];

NSString *upcase = uppercase (string, @selector(flonknozzle));
NSLog (@"%@ -> %@", string, upcase);

And a sample run:

Bork -> BORK

Notice that I passed a nonsense selector as the second argument (_sel). That shows that uppercase is just a function pointer and not actually vectoring through objc_msgSend.

Ordinarily you won’t be grabbing the IMP and jumping through it because it defeats the whole idea of polymorphism – you’re short-circuiting the method look up process. But if you know that all the objects in a collection are the same, you can get the IMP and jump directly to the method implementation. Be sure you’ve profiled your app before doing this kind of micro-optimization. It could become the source of bugs if your heterogenous collection starts having different kinds of objects in it. “Why is UIButton's -drawRect suddenly trying to draw sliders?”

Signature Move

A “signature” is the term for the types that a method or function takes as parameters and what its return value is. The signature of NSData‘s dataWithContentsOfFile: is “Takes a string (path) and returns an object (an NSData of the contents of the file at the path)”.

Method signatures are part of a class’s metadata. You can ask a class for the signature of a method using methodSignatureForSelector. The signature is encapsulated in a NSMethodSignature object that you can then poke around. Here’s an NSString method with some parameters:

- (NSRange) rangeOfCharacterFromSet: (NSCharacterSet *) aSet
                            options: (NSStringCompareOptions) mask
                              range: (NSRange) searchRange;

This method takes an object, a bit mask, and an NSRange struct. It returns an NSRange. You get the signature by asking the class:

NSMethodSignature *signature =
    [NSString instanceMethodSignatureForSelector: @selector(rangeOfCharacterFromSet:options:range:)];

Now poke around the signature:

NSLog (@"%ld arguments", [signature numberOfArguments]);

for (NSUInteger i = 0; i < [signature numberOfArguments]; i++) {
    NSLog (@"%ld -> %s", i, [signature getArgumentTypeAtIndex: i]);
}
NSLog (@"returning %s", [signature methodReturnType]);

Running this yields this extremely illuminating output:

5 arguments
0 -> @
1 -> :
2 -> @
3 -> Q
4 -> {_NSRange=QQ}
returning {_NSRange=QQ}

Ummm… Yeah. Moving on then!

Type Encodings

These character strings are “type encodings”. They’re character sequences that describe individual types. You can ask the compiler for a type’s encoding string by using the @encode directive: (this stuff is at this gist)

NSLog (@"int:        %s", @encode(int));
NSLog (@"CGRect:     %s", @encode(CGRect));
NSLog (@"NSString *: %s", @encode(NSString *));

This prints out:

int:        i
CGRect:     {CGRect={CGPoint=dd}{CGSize=dd}}
NSString *: @

Lower-case i for an int. CGRect is a {struct} with two structs, each of which has a double. @is an object pointer. You can see the list of encodings, or you can also ask Uncle Google for “objective-C runtime programming guide type encodings” for when Apple breaks this documentation link. The particular characters and what they correspond to are an implementation detail, so don’t go hardcoding “{_NSRange=QQ}“. You can use @encode to get the proper encoding string in a robust manner.

Here, again, is the signature for rangeOfCharacterFromSet…, annotated

5 arguments
0 -> @                       object pointer
1 -> :                       selector
2 -> @                       object pointer
3 -> Q                       unsigned long long
4 -> {_NSRange=QQ}       NSRange struct, with two unsigned long longs
returning {_NSRange=QQ       NSRange struct with two unsigned long longs

And now things should make more sense. The first two arguments are, you guessed it, self and _sel. Then follow the three arguments to the method – an object pointer (to an NSCharacterSet), a big int used for a bit mask, and an NSRange. It returns an NSRange.

There’s one caveat: the type encodings don’t handle variable argument lists. You can’t tell with NSMethodSignature if something is a varargs method or not.

Armed with this, you can figure out at run time what the calling convention is for an arbitrary method so long as you know its selector. Sure, that’s interesting trivia, but can it be useful information?

Equivoinvocations

If you know the signature for a method, and savvy with the platform ABI , you can package up message-sends into an object. In essence, creating the potential for a message send. Then, in the future, you can take this package and cause it to actually send a message. You’re freeze-drying a method invocation for later thawing. Apple gives us a class to do this, hiding the grody details : NSInvocation.

Be warned, NSInvocation is kind of a pain to deal with. And its performance is terrible. Mike Ash has a test program (that you can run for yourself) which times various common operations. Here’s a subset, with the time for each operation in nanoseconds.

IMP-cached message send     0.7
C++ virtual method call     1.1
Objective-C message send    4.9
NSInvocation message send  77.3

The timing of the first three are unsurprising – an IMP-cached message send is just a function pointer call, so it’s very fast. A C++ virtual method call is a pointer+offset (find the vtable) followed by a pointer + offset (find the function pointer in the vtable) and then a function pointer call. It’s a little more work so takes a bat more time. An Objective-C message send does a fair amount of work as you’ve seen already.

NSInvocation takes 15 times longer to use an already-existing NSInvocation object and invoke it than to call a method directly. 77 nanoseconds is actually not a long time, so don’t avoid invocations it if it can lead to elegant designs.

Making an NSInvocation is a multi-step process. Before showing the invocation, here’s some code that uses rangeOfCharacterInSet:… that we’ll invocationize.

//  (character indexes             11111111112222
//   in the string)      012345678901234567890123
NSString *baseString = @"Why hello there, Hoover.";
//  (randomRange)             |-------------|
NSRange randomRange = (NSRange){5, 15};

NSCharacterSet *set = [NSCharacterSet whitespaceCharacterSet];
NSStringCompareOptions options = NSBackwardsSearch;

NSRange lastSpace =
    [baseString rangeOfCharacterFromSet: set
                options: options
                range: randomRange];

This is saying “given this string, look in the range of [5,20) for the first whitespace character, but start searching from the end". In other words, what is the last whitespace character in that range? This call returns {16, 1}, which is the space right before Hoover.

First you need a method signature, otherwise how do you know what arguments to send to the IMP that backs rangeOfCharacterInSet:... ?

NSMethodSignature *rangeSignature =
    [NSString instanceMethodSignatureForSelector:
                  @selector(rangeOfCharacterFromSet:options:range:)];

Then make an invocation:

NSInvocation *spaceFinder =
    [NSInvocation invocationWithMethodSignature: rangeSignature];

Next, tell the invocation to retain any object arguments. Before ARC you would retain any objects that you put into invocations (and remembered to release them when done). We can't do that with ARC. So tell the invocation to retain its arguments so they don't disappear:

[spaceFinder retainArguments];

Set the target (self) and selector (_sel):

[spaceFinder setTarget: baseString];
[spaceFinder setSelector: @selector(rangeOfCharacterFromSet:options:range:)];

Then set the three arguments for the method. Start with argument index 2.

[spaceFinder setArgument: &set  atIndex: 2];  // target=0, selector=1
[spaceFinder setArgument: &options  atIndex: 3];
[spaceFinder setArgument: &randomRange  atIndex: 4];

And you're done! Invoke it to cause the message send to happen.

[spaceFinder invoke];

And then print the return value.

Uh... Where did the return value go? It gets stuffed into the invocation:

NSRange anotherLastSpace;
[spaceFinder getReturnValue: &anotherLastSpace];

This also returns {16,1], so life is good. You can re-use the invocation and point it at different strings by using setTarget:

//                                   1111111111
//                         01234567890123456789
NSString *secondString = @"I seem to be a verb!"; 
//                              |-------------|
[spaceFinder setTarget: secondString];
[spaceFinder invoke];
NSRange yetAnotherLastSpace;
[spaceFinder getReturnValue: &yetAnotherLastSpace];

This returns a range of {14, 1}, which is the space right before "verb".

You can reuse an invocation any number of times.

What's neat about NSInvocation is it takes message-sends, which are fundamentally verb-like in nature, and converts them into objects, which are fundamentally noun-like in nature. You can put these invocations into collections, where they sit, lurking, until called into action.

NSUndoManager is fundamentally a couple of NSArrays filled with NSInvocations. You can use invocations to make C callback handling easier. Rather than writing a thunk method that casts a context pointer to an object, and then calling a hard-coded method, you could instead use an NSInvocation as the context pointer, and have a single generic callback. They're also used under some circumstances when messages are sent to objects, as you'll see in the next installment. You can also use an invocation as an operation by putting an NSInvocationOperation onto a NSOperationQueue.

The second is just an observation. Notice that the setArgument: methods take addresses of stuff, like the address of the search options mask, or the address of the range to limit the character search in. There's no sizeof's anywhere to let NSInvocation know how many bytes to grab from memory. There's no need to - all that information is in the NSMethodSignature!

Data Today, Methods Tomorrow

Here ends the tour of some of the bits of information you can get at run-time given Objective-C's rich metadata. Next time, a tour of some of the methods you can use to put this metadata to good use.

The post Inside the Bracket, part 2 – data invocation appeared first on Big Nerd Ranch Blog.

Editor’s note: Brian Harper, Jeff Heaton and Brandy Porter are hitting the road to teach our mobile design courses in Ukraine, the Netherlands, India and Japan. At each destination, they’ll be sending blog “postcards” with updates.

Today I’m writing to you from a plane somewhere over Romania. Brian and I are headed to India for our next Microsoft design bootcamps. We just spent a week in Amsterdam, where we were able to work with the Big Nerd Ranch Europe team and deliver a three-day class covering iOS, Android and Windows 8 design principles.

The attendees ranged from local designers to government officials, all looking to better understand mobile design platforms. It was a great opportunity to teach to a smaller group, making the workshops a truly valuable and personal experience. The Amsterdam community is generally focused on iOS, but they understand the rising global importance of Android apps, and are intrigued and excited about Windows 8.

While we had to work during the day, we found a lot to do at night. Sundown didn’t occur until around 22:00, so late nights tended to sneak up on us (It’s worth mentioning that sunup was around 4:30, so early mornings also snuck up on us). We got to stay in the Big Nerd Ranch apartment while Bolot was teaching in Sweden, so we had easy access to restaurants, pubs, coffee shops and the Artis Royal Zoo. By borrowing Bolot’s bike and renting another, we had the entire city at our wheels. Some of the adventures we got into included world cuisine, the Rijks Museum of Dutch history and art, the Van Gogh Museum, harrowing bike rides, a canal tour by boat, more coffee than any reasonable person should drink, and time spent with new and fast friends.

Meeting genuine friends has to be the most valuable memory for me. Our European Nerds—Marcel, Bolot, Siemen and Rajiv—exemplify the kind of Nerd we like at the Ranch: intelligent, hardworking and kind. Siemen let me ride on the back of his bike across town on the first day we met, going out of his way to make sure we didn’t get lost. Rajiv is getting married in Mauritius this month! Marcel and his wife, Jeanette, ran the workshops without a hitch. We all met several times at various “eten and drinken” spots, simply tweeting our latest location to the group. It’s that kinda town.

We got to hang with the Appsterdam crowd during their Wednesday night meetup at Bax, where we met expats from around the world, all with a love for building brilliant apps. One Dutch guy is living and working in Brazil now, another in San Francisco; still another, Magnus Dahl, is from Sweden originally. He is actually the technical editor of our brand new Android Programming guide! We met Marcel’s son, Klaas, co-creator of Appsterdam and New Lemurs; and Olga, who is researching how to bring the Appsterdam community aspect to Greece, a country that is a bit segregated from the dev world right now. How exciting!

We saw these wonderful people a few more times over the rest of the week, and had riveting conversations in rockabilly bars, museums and even on bike rides. It really drove home this point for me: the most amazing part of Amsterdam is her people.

The post On the Road: Mobile Design in Amsterdam appeared first on Big Nerd Ranch Blog.

Alumni: If you’d like to share your success stories with us, please leave a note in the comments.

In my last post, I wrote about the process that lead me to create my first game, Kondrian. During that process, I learned a lot about creating iOS games. In fact, I’d almost call it a recipe. Here are the key steps:

• Create a story. You don’t have to share it with the player, but it helps you mold the game.

• Make five simple 2D prototype games. This will help you develop your process and thinking.

• Reduce your ambition for your first shipping game. Keep it small and focused.

• Choose an engine. Your main choices are:

  a.) rolling your own for full control and to reuse your UIKit skills,
  b.) Unity if you want to release on other platforms, or
  c.) Cocos2D, which abstracts OpenGL but in 2D only.

• Integrating with UIKit can save you a lot of time. If it’s applicable, integrating can save you time, not only by allowing you to reuse your UIKit knowledge and your UIKit code, but also by letting you advantage of the growing number of iOS libraries out there. In my case, I used a lot of UIBezierPath tech from one of my previous apps and used MagicalRecord to help with Core Data.

• Be careful: developing a good particle engine can be a time sink. Unity and Cocos2D provide particle engines, which might save you a lot of time if your game has a lot of effects.

• Find a good artist. You can’t avoid this step; it’s essential. However, innovative sound for this first game is not as important.

• Iterate. Iterate everything, and experiment with everything, including controls and game play.

• Vectors are very important for AI. Use GLKVector2 from GLKit and get your head around them.

• Think of your game as a work of art. Think of it as a part of you, and have fun doing it, because most indie game developers don’t make any money!

Making a game is a huge investment in time, energy and resources, much like many other non-game development projects. The rewards are huge, though. You’ll add to your development skillset and create something new. And you never know—it might help you achieve Nerdvana!

The post A recipe for creating iOS games appeared first on Big Nerd Ranch Blog.

I’m excited to announce that we are teaming up with Mailchimp and Mandrill to hold a Coderetreat on June 29th at our Krog Street office in Atlanta.

A Coderetreat is a daylong event where a small group of developers meet up to focus on improving their software design and development skills. It is an intense day of coding where we get to pair program with others, learn new problem-solving techniques and focus 100% on doing it right.

The event is free and is open to all software developers who are interested improving their software design and development skills. Participants will pair with each other during six sessions that will each focus on different aspects of crafting outstanding code.

If you are interested in attending, you can register here. There is a $10 deposit required to reserve your spot, which will be refunded when you sign in at the event. The event starts at 9:30 a.m. and will finish up around 6 p.m. Lunch and other refreshments will be provided, thanks to our co-sponsors, Mailchimp and Mandrill.

The post June 29th Coderetreat open for registration appeared first on Big Nerd Ranch Blog.

In this Tech Talk, Daniel discusses how the Kickstarter-funded HYREL 3D printer overcomes the problems faced by other printers. He covers traditional manufacturing processes and how 3D printing is changing them. The best part? The HYREL 3D can even print with chocolate.

The post The Hyrel 3D Printer: A Big Nerd Ranch Tech Talk appeared first on Big Nerd Ranch Blog.