• We are gonna store a variable in the user defaults to store the locked orientation, or the lack of lock.
• Check the lock when the view controller wants to rotate.

First, on first run, we need to store the variable on the defaults, so on the app delegate, we’ll do this:

We are storing -1 because that’s gonna mean “unlocked”

Now, to lock the orientation, when the view controller that’s gonna lock it is in the orientation we want to lock, we’ll do this:

Now, on the view controllers we want to lock, we’ll override this selector like this:

What that selector returns is ture for the supported orientations, so the first thing we’ll do is to check that interfaceOrientation is not upside down. Then, if orientation is -1, which means unlocked, return true, because we want it to rotate. And finally, if orientation is not -1, we’ll compare it to interfaceOrientation to allow it to be only in the locked orientation.

Aditionally, you can store orientation in an ivar, to avoid so many calls to the user defaults, but for the sake of it making sense, I didn’t do it here.

Here are some small but useful additions to the UIColor class in UIKit.

This is what it does:

• Adds a method to get a color from a Hex string (with either this #FFFFFF or this FFFFFF format).
• Adds a method to get a color from an Hex string with custom alpha value.
• Adds a method to get a color from a selector string.

Here’s the download:

File: UIColor Additions (1.95KB) added: 19/03/2010

nil is ObjC’s null, which means that the pointer to the object doesn’t really point to anything. This is usually when you haven’t created the object.

However, in ObjC, nil is much more useful than in other languages. In languages like Java, if an object is null and you try to do pretty much anything with it, it will fail at runtime. nil is a lot more flexible.

In ObjC, you can send nil as a parameter for a selector(that’s how methods are called on ObjC, will use that from now on), receive nil from one, and even call  a selector on nil.

Why is this useful?

This is useful mostly to avoid checking if the object you got is nil every time you get an object, or before you call a selector on an object you are not sure. If you have some complex code which doesn’t always initialize objects before sending messages to them, you don’t have to worry on checking if the object is nil or not.

(You can even call something directly on “nil”, like this [nil setText:aText];, though it will give you a warning, and it isn’t useful at all )

Sometimes you’ll receive nil, and you don’t have to check that object before sending it to another object. For example, if you want to get a song lyrics and then send it to an UILabel, you can just send it without checking it, and it won’t crash.

Another cool thing you can do with nil, and objects in general, is using them as BOOLs. If you need to know if an object is nil (for example, before initializing it (under some circumstances)), you can do if(anObject){}, and if anObject is different from nil, it will happen, if the object is nil, it won’t.

What do I get when the selector I call should return something, but I call it on a nil object?

When the selector you call is supposed to return something, and the object you call it on is nil, it will return some defaults:

• nil if the return type is an object.
• 0/0.0 if the return type is an integer/float/double.
• NO if the return type is BOOL.
• If the return type is a struct, it will fill it’s fields with the above rules.

Things you should look for

Releasing an object will not set it to nil. If you release an object that might get called in the future, and you are not gonna initialize it right away, you can do anObject = nil; to make sure that if you send a message to it, it doesn’t fail.

You shouldn’t take your nil habits to other languages, because chances are that the language won’t support it and it will fail .

Here are some PDFs that have been really helpful to me, I have not bought any books or anything. I did take a course on basic C, and I’m also being teached Java at school.

• ObjC
• iPhone101
  
• iPhone App Programming Guide

This is a template app that will make an empty app that does nothing but put your screen white. It’s made from a UIApplication subclass, a UIViewController subclass and a UIView subclass, so it’s pretty much ready for you to code your own view, add your own methods and turn it into something.

File: App Template (3.31KB) added: 06/06/2009

While ObjC uses C as a core, and accessing properties is quite similar as in other languages (object.property;), methods are a little bit different from other languages I’ve used.

Methods

This is the kind of stuff that confused me the most:

So yea, it’s kinda like WTF?

Basically, what we are doing here is sending a message called “somethingElse”, with parameters “anotherThing” and “Damn”, to an object called “something”.

So let’s take a look at some actual code, this is the way we call an UIAlertView:

Should be more understandable:

First, we are creating a new object called “alert”, of the type “UIAlertView”. Then we are initializing it, then showing it, and then tell it to be autoreleased. (Note, nil is ObjC’s null).

What [UIAlertView alloc] does is tell the OS to make some space in the RAM for a new object of the type UIAlertView.

Next, what initWithTitle:@”Hello”… does is initialize the alert with title “Hello”, message “Hello World”, etc. What [alert show] will do is to show the alert, and [alert autorelease] will autorelease when it’s not needed anymore.

If you go to the frameworks and find UIAlert.h, you’ll find that it has a method like this:

There you can see where everything came from. In C, it would look like:

That’s how methods are in ObjC, basically.

Headers

Now, usually, before using an object, you have to set it up for it to work/look as you want, then you use it, and then you release it, for example, we want to add a label that says Hello World in the middle of the screen:

Note that we are doing all the changes before adding it to as a subview, otherwise, the user could see as the properties are changing, and see the object being modified. We don’t want that.

Anyway, if you go to UILabel.h and look for “initWithFrame”, “setText”, “setTextColor”, etc., you won’t find those methods.

The first one is a method from UIView. If you don’t find it in the class you are using, it’s in one of it’s superclasses, when UILabel is declared, it’s declared like this: UILabel : UIView. That means it’s a subclass of UIView, and that it inherited some methods and properties of it (you probably knew this already if you had used OOP before).

The other methods are “setters”. If you go to UILabel.h, you’ll see something like: “@property(nonatomic, retain) NSString *text”. That means that ObjC will automatically create a getter method called “getText”, that will return the value of “text”, and a setter method called “setText”, which will take a NSSting as a parameter and will assign that string to “text”. There are other modifiers (besides nonatomic and retain), but I’ll come by them later.

So here it is, a very quick overview on Object Orientated Programming (OOP)

In OOP, you define classes, which are abstractions of things, for example, an animal class (the most used example in my experience). Classes have attributes and methods, in this case, attributes would be size, color, etc., while methods would be run, jump, eat, etc.

However, “animal” is too abstract, so we could create a dog class that is a subclass of the animal class. It inherits most of the attributes (there are different kind of attributes, private and protected *) and methods from the animal class, but it implements some new ones.

When at runtime, we create objects from those classes, say, an object called “Lassie” that is of the dog kind.

When we create them, we have to set up some of their attributes, for that we use initializers or constructors. In ObjC, they are methods which’s names usually start with “initWith…”. They are usually quite clear of what they require.

*Kinds of attributes :

In ObjC, attributes are, by default, private. If you don’t specify it, other objects can’t access them.

To make them accessible, we use @property and @synthesize/@dynamic on the interface declaration.

There you have a really quick overview on how OOP works.