I’ll do my best to Enumerate (ha!) the dynamic similarities between the languages. If I’ve missed something, let me know!

• Sending messages
• respond_to?
• Dynamic messages
• Defining methods
• Extending classes

Why yes you can. Simply call performSelector with up to two extra parameters:

You can also get a little funky and mess around with threads and delays. These are especially useful if you want to keep your UI updating (such as updating a progress bar while searching for data). Simply use the following:

Wouldn’t you know it, Objective-C has nearly the same method:

Don’t worry – Cocoa provides many convenience functions, including NSSelectorFromString, which will allow you to create messages willy-nilly:

Thanks to Ruby and Objective-C’s shared ancestry of the much-lamented SmallTalk language, you can accomplish dynamic message processing in either. It’s a bit trickier in Objective-C (specifically Cocoa), but it can be done by defining forwardInvocation.

And wouldn’t you like to know how it works? I would too! But I need to read a little more about it! So stay tuned, ‘cuz just like the subject matter, this blog is Dynamic! Ha! Get it!

No problem – the Objective-C runtime has all kinds of fanciness for messing with class and object innards. Although you can’t yet create closures at a whim, you can still switch around implementations.

Note: you should always import the following header when utilizing runtime functions:

Some functions you might be interested in for messing around with methods are:

They each require some or all following information:

• The class being modified. To modify instances of the class, you’d pass
  [MyClass class]
  in; to modify the class itself, you’d pass
  [MyClass class]->isa
• The selector (method name) being updated
• A Method Implementation (type ‘IMP’), which is just the compiled code that underlies a given method
• A string (technically a C character array, so don’t prepend an @ symbol to it) containing the types of the method signature. The first character represents the return type (”v” for void, “@” for object references, etc.; those are the most common you’d use, but there’s a list of type encodings you can refer to for more). The second and third should always be “@:”, representing an internal necessity. Any other characters are used to represent the actual argument types.

You probably figured out that the easiest way to define a method implementation (IMP) is to use class_getMethodImplementation. That way, you can do something like the following:

If that seems a little complex, don’t worry – it’s easy enough to boil it down into a convenience method:

You can put the SwizzleMethod function into a file and include it globally in your prefix header (usually named something like MyProject_Prefix.pch).

First of all, be sure to check out the Objective Support project, which accomplishes a lot of the goodness you’re used to from ActiveSupport.

Objective Support does its magic largely through the use of categories, which are a nice mixin-style feature of Objective-C. Essentially, categories allow you to “re-open” classes just like Ruby; you can create multiple categories for any given class and insert methods as you see fit. You can’t add instance variables, but you can override existing methods.

Thankfully, the implementation of categories is fairly simple:

Note: you may want to include your category header in your prefix header (or at least the classes in which its methods get called), as otherwise you’ll see a bunch of “object may not respond to xxxx” warnings.

This is by no means an exhaustive list of Objective-C’s dynamism, but it covers a lot of the goodies. If there’s something I left off that you earnestly believe should be here, or you see a (gasp!) code error, let me know!

Or if you want to get really freaky, you can define radii individually for each corner (unfortunately this syntax varies by rendering engine):

Now, if there’s anything I’ve learned about developing for the iPhone, it’s that it takes 10 times as much work as web development. Rounded corners were no exception, until iPhone OS 3.0 released this little gem:

Suddenly rounding corners on the iPhone was as easy as slicing bread. Yet there is no way to round individual corners like in a web browser, and much more importantly, using cornerRadius will kill your performance – especially on older devices. Sure, you can get by if you just have one or two rounded views and no scrolling, but we should haven’t to limit the glory of our rounded revolution, now should we?

Because I needed excellent performance with many simultaneous views as well as individually rounded corners, I opted to see what else I could come up with. Luckily, there were several examples on the interwebs with good techniques, though none gave me a simple way to round corners individually. So, after a little sweat, I came up with the following code for you, my dear readers, to use and nuture and love:

(Full sample project)

This draws a path on your graphics context, which can then be used to draw outlines or fill with colors/patterns/etc.

Notes:

• Because CGContextAddRoundedRect is defined as a function and not a method of some class, you’ll need to do a little configuration to get your compiler to accept it. Mainly, find your project’s precompiled header file (it should be called something like ProjectName_Prefix.pch) and insert the following line:

  #import "CGFunctions.h"

  That will allow you to use the function anywhere in your code.

• Watch out for the stroke going outside the view rectangle – you may get weird, uneven-looking drawing. I’ve provided an “inset” parameter in the CGContextAddRoundedRect function so that you can avoid just that. A good rule of thumb is to provide the same value to the inset as you do to your stroke width (you may know it as line width, set via the CGContextSetLineWidth function).

Here’s a simple example of using CGContextAddRoundedRect in practice:

In addition to painting, you can also use paths to mask images and do all kinds of other fun stuff with Quartz (check out this article for some sample image masking code).

That ought to get you started. Now, go forth and spread the rounded corner love!

The idea of required artistic responsibility (otherwise known as “The Deadline”) is new to no one, and yet we often forget how potent it can be. There’s a reason we all wrote so many papers in college – we had to. (Or, in some cases, bought them from shady websites… I speak of other people, of course. I was nowhere near shady. More on the sunny side.) In fact, I recently had an eye-opening experience with deadlines while developing shortcts.in with three friends at an overnight hackathon. The goal was to develop a web application in approximately 24 hours, and in doing so, I had perhaps the best team development experience of my life. “Agile” took on new meaning as we reached maximum velocity and cast aside the time-wasting “planning” phase in favor of pure, delicious implementation. As my team member Dave said at the time, “Why discuss when you can just do?” Well, I may be paraphrasing/alliterating that for the sake of epic impact, but the idea was clear. We would have missed out on that sublime clear-mindedness had we not had a ridiculous deadline looming over our head.

Let’s just say that that having time is inversely related to productivity. Really, We should all be doing Project365. Then again, sometimes you just have to stop working and play Dragon Age until 5am… not that I’ve ever done that, of course.