39th Day As An iOS Developer With No Experience

photo from: imgfave

October 27, 2015 - TUESDAY - First of all, one of the stuffs I learned today is the 'PerformSelector' in iOS. I will discuss it later. I just want to say that I ate McDonalds today. I feel so fat. But did you know that I lift weights? Oh yeah.

Going back to that PerformSelector, I find it powerful than calling your own void method. Let me explain this more. Look at the codes below, I have here a method called printHello.

- (void)printHello
{
   NSLog(@"Hello PrettyITGirl!");
}

and then, think about a way to call that method. The first thing that comes to our mind is of course calling it using the usual way:

[self printHello];

Well, there's nothing wrong with that. But the PerformSelector has the advantage that you can dynamically determine which selector to call at runtime. You can call your method with delay if you want.

SEL selector = [self gimmeASelectorToCall];
[self performSelector: selector];

With Delay:

[self performSelector:@selector(changeText:) withObject:text afterDelay:2.0];

Furthermore: Take a look at the answer of the user dasblinkenlight:

A selector object lets you call a method that you do not know at compile time. You need to know only the name of a method as a string in order to call it. When the name of the method that you are calling is known at compile time, using selectors is counterproductive: the code becomes less readable for no apparent advantage. When you are writing a library that needs to call methods in other code that is compiled separately from the library, selectors provide a way to decouple the two pieces of code.

Okay, honestly, I can't still understand what they're all saying about the known method stuffs, but I will ask my CTO about this next time. If you are very familiar with selector, please let me know.