PHP to Objective C, where the f**k are parameters?

Posted: January 16th, 2012 | Author: | Filed under: iOS | 22 Comments »
This entry is part 2 of 4 in the series iOS Beginner blog series

Javascript, PHP, Ruby functions

I assume you are very familiar with declaring functions in any of the languages above, if not, you should not be reading this. Let’s begin with a simple function to send email in these languages:

// PHP or Javascript
do_send_email (recipient, cc, subject, body);
// Ruby
do_send_email (recipient, cc, subject, body)

So it’s clear by looking at the function’s signature that it takes 4 parameters and they could be optional, depends on your implementation. Even if you missed one parameter, in most cases it is fine, no complain, no fatal error.

First encounter with Objective-C

Below is one example of Objective-C function calls

[[UILabel alloc] initWithFrame:CGRectMake(0,0,120,35)];

This is the kind of code I see the most when I first opening up a source file and try to read Objective-C syntax. And I’m sure this is the case for many of you right now.
Now, the biggest problem is that you cannot even tell what it is, left alone guessing what it does. Obviously, I couldn’t tell and that was why I had to ask myself “where the f**k are parameters?”. Because then I can somewhat guess what function it calls.

Unfortunately for me, no one told me that I’m way ahead of myself. So I’m tell you now: Stop guessing! Go back to the basics before continue reading this.

As mentioned in the beginning of the series, I’m not writing a tutorial series, I’m writing about the WHYs of the language, in a way more fundamental than even knowing the syntax itself.

The function’s full name

This is where it gets interesting. For an email sending function call similar to that of PHP:

[emailSender doSendEmailToRecipient:(NSString*)email cc:(NSString*)cced_email subject:(NSString*)subject_to_send body:(NSString*)body_to_send];

The function’s entire name is doSendEmailToRecipient:cc:subject:body: and *not* just doSendEmailToRecipient

Strict and brilliant by design

The Objective-C function’s name is designed to include the parameters’ names. This is not the case with most web programming languages.
Why does it have to be this way? The obvious reason is Objective-C is a compiled language, once you get it wrong, it cannot even be compiled.

However, the more important reason, the motivation of this post, and one of my most important ‘enlightment’ moments is that the function call tell you exactly what to expect without looking back at how it was declared. It is strict by design so that you cannot screw it up.

Imagine, you are writing a black-box email sending class and you need to tell other programmers how to use it by telling them the name of the functions, the parameters they accept. Ask yourself, how did you do it in PHP/Javascript/Ruby? For me, it would be via the source code or the documentation.

In Objective-C this mechanism is built right into the function name itself. Even if you don’t have the source code or the documentation, you still can pretty much understand how to use it correctly. The parameter names are always self-descriptive and the type is strict. Again, you cannot use the wrong syntax, the compiler will simply cough out tons of red lines and refuse to let you do any more stupid things.

So in my opinion, this is actually brilliant design. No doubt it requires more typing, but it potentially saves a lot of (human) communication errors when sharing codes and working in a team. When I was still coding in PHP, I found myself constantly having another file open just see the declaration of a function I wrote before that. (Extra typing time * 100000) < Total time save ==> happy coder.

If you are not convinced

do_send_email("[email protected]", "[email protected]", "Hello!", "hi!");

Now, which one is the recipient? What is the subject?

[emailSender doSendEmailToRecipient:@"[email protected]"
                                 cc:"[email protected]"

Crystal clear!

I hope you understood the very fundamental reason why Objective-C syntax has to be the way it is. Accept the ‘weird’ syntax that you have never seen before, and appreciate the thoughts Apple has put into improving the language (Apple does not design it) and be at peace with yourself.

Updated: as pointed out by one commenter below. The language was designed by Brad Cox, not Apple. Apple inherited it with OpenStep/Rhapsody/MacOSX.

Let me know what you think about this post and give me some feedback on what should I write next for the series in the comment form below.

The iOS Beginner blog series

Posted: January 14th, 2012 | Author: | Filed under: iOS | Tags: , , , , | 17 Comments »
This entry is part 1 of 4 in the series iOS Beginner blog series

A dedication to the high-level programmers

After almost a year learning Objective C and iOS programming, now I can say that I understand most of the materials available in StackOverflow and there is rarely any question that I don’t know *how* to look for the answer. I can certainly tell the differences between a .h file and .m file and I also know how to load up cool stuffs from and see if I can use them for my needs.

However, looking back at the early days, none of the above made any sense to me at all. I blamed myself mostly for having absolutely no background in any low level language. No C, C++, Pascal, etc. Like many developers out there, I started since very young with self-taught front-end web programming skills (HTML, CSS, JS) then moved on to back-end languages like PHP. (I started Rails at the same time as Objective C too).


The problem with having such a long history with web programming languages is that all languages fundamentally are the same: no compilation, no machine code, real time changes, nothing to do with memory management. For me coding = write code, refresh, see, change, refresh

And so, I threw myself into iOS with a very open mind, expect the unexpected, just like any other time I prepared to dive into new platforms. But this time, it’s not like any other. For the first month I really struggled, trying to convince myself to learn, trying not to give up and pull out. App crashed almost every time I tried to run, or worse, it didn’t even compile and I have no clue where or what to fix. I just couldn’t accept the fact that I have to write so much code just to achieve so little.

It took me a really long time to put a single HelloWorld on the screen because trying to find the answer for one question only lead to many others:

Begin: How do I write a Hello World on the screen?
=> What type of project should I start Tabbed Application or Single View Application or Utility Application (XCode template)?
=> What’s a window? What’s a controller? Why is it called a view-controller, not view *and* controller?
=> What’s the function to create a label?
=> Where the f**k are the function’s parameters?
=> How to put a label in the correct position?

And then there’s all the nasty provisioning before I can gulp in the delicious HelloWorld word on my iPhone. Don’t even start asking.


I kept bitching and complaining how much more work it was compare to Rails for several months (most of the time to my colleagues @ajhit406, @arun). Only when I started to accept the fact that Objective-C is a compiled, low-level language, in which my experience was clearly absent, I began to appreciate the language and the way the whole eco-system works. I no longer view [[alloc] init] as chores, instead, I remember every one of them and consider how much memory it might take everytime I wrote it.

Not only I learnt how to write Objective-C codes, the process of creating apps taught me so much more about designing for small screens. And that is why whenever I got a chance, I wouldn’t stop cursing and swearing about how bad Android design is and how fundamentally broken it is.

So I hope you got the point clear, if not : Objective-C is an awesome language. Period.

iOS Beginner blog series

With that, I wanted to help out those who began to learn iOS development, especially programmers who are coming from no programming background or web development background, to quickly adapt to Objective C and understand the broader picture.

The iOS Beginner blog series, including this one will attempt to do that.
The series will not to teach you how to achieve specific implementations, however, my approach will be to explain the fundamental concepts, the “why” of why you have to do certain things.

It took me only a month from a total noob to be doing advanced Rails stuff. But it took me almost a year to be confident in making good quality iOS apps, for example this one. So I hope by sharing my experience, you won’t take as long.

The very first concept will be from one of the questions above, which I found most difficult to understand at first: Where the f**k are parameters?

A replica of Path’s table view

Posted: January 13th, 2012 | Author: | Filed under: Custom UI, iOS | 5 Comments »

If you have used Path recently, then the screenshots above should be very familiar. I am always very keen on learning about new ways of providing better user experience through interface design so Path 2.0 impressed me a lot in that area. There are several innovative UI controls in just one single app. The most noticable one was the fly-out menu. It has been replicated in Objective-C, CSS3 and even Adobe Edge.

So for the hackathon night at Anideo, I decided to replica and create a flexible foundation for another not less impressive control found in Path App : the overlay info panel that shows time when you scroll.

The screenshots above shows my progress so far after a few hours into it. It works pretty well with relatively little code. Download demo video of it in action here (1.1MB)

The implementation I wanted has to be simple and flexible. Built with just a simple UIView for the overlay and a UIImage stretched to fill the background. It is highly customizable with 6 callback events that you can override to provide any functionality that you need.

I have push the code to my public git repo at
You can get the code and run the Demo project to get an idea what you can do with it or follow my code below.

How to use and extend KNPathTableViewController

First, the library consists of two source files and two graphic files for the background. Add these files to your XCode project as usual. Everything you need to know about this class can be found in .h file.

Create your own class based on KNPathTableViewController and use it like a normal UITableViewController out of the box. At this moment, only two init methods are supported, but you can submit a pull request to my repo and add more if you need to.

-(id)initWithStyle:(UITableViewStyle)style infoPanelSize:(CGSize)size;

The infoPanelSize is the width and height of your overlay control. The background is created using UIImageView with a stretchable image based on the midpoints of the two images. Default size and other settings can be changed in .h as well.

After you have declared your custom class, override these methods in your implementations

-(void)infoPanelDidScroll:(UIScrollView*)scrollView atPoint:(CGPoint)point;

All of these are optional but the most important one you should override is the infoPanelDidScroll:atPoint: call.

The overlay info panel UIView can be access using read-only property self.infoPanel and you can use this to add your custom elements.

In my Basic Demo, I added a single UILabel to the overlay and update it with the information about the current row it is at. The current row index can be calculated with the (CGPoint)point parameter.

In Path App, there is a lot more than just a simple UILabel: a round background clock, two moving clock hands, two dynamically sized labels that show date and time. Essentially they are additional information about the current postion it is at. And it is not limited to that single row as you can see in my Section Demo. The overlay label shows the current section it is at.


So from here, the possibilities are quite unlimited. You can use this control as another space-saving tool for the important-but-tiny tableview. You can potentially do away with the section headers and display it in the overlay instead. Alternatively, you can just use it as a fancy touch to your app. Up to you.

I do not have any future plan for the library but you could suggest more using the form below.
Also, let me know if you use it in any of your cool project.

Oh and checkout my other app too.