For the most part iOS will let you code anything you want, however occasionally you will find the need to do something out of the ordinary, or reuse an existing class. Trying to do this with public APIs can be a headache, and often requires tons of code. You may heave heard of private APIs, and also may have heard about how apps get rejected from the AppStore for using them. This is often true, but if you know how to safely and properly use private APIs then you can harness their power.
If you’ve ever needed to have an object with multiple delegates you may have created an array and then added each of your delegates to it. This does work but there’s a simpler way which is much easier to implement. Using the NSNotificationCenter you can have objects subscribe to the events/messages they want to know about and get called whenever that ‘event’ takes place. The Cocoa framework uses this as well, and let’s you subscribe to things such as an app entering the background, changing orientations, when it’s running out of memory and when the keyboard is presented or dismissed.
When developing on the Mac and using custom frameworks in your application, when you compile the frameworks are copied into your applications bundle then linked at runtime. These frameworks will most likely be bundled up with their headers. Some of the frameworks you include may not be things you want to make public to the world, which you are essentially doing by including the headers with the framework.
Since Xcode 4.1 when your application throws an exception your console just prints a list of function pointers and you don’t get a proper stack trace. This isn’t helpful if you’re trying to find the exact line the error occurred on.
When using delegates in an object in Objective-C it is important that the delegate is only assigned within your object, and never retained. The reason for this is to prevent a retain loop, where two objects retain each other; they will never be released. The fix is simple, but can catch you off guard if you want to create an array or dictionary of delegates (using an NSDictionary or NSArray).
Many times during development I have needed to attach simple user info to objects in Objective-C, such as a table row, context info and other object pointers. Previously to achieve this I would subclass my target object’s class and add the variables needed to hold the extra information. This worked, but had a couple of problems.
If you code precompiled libraries for people to use (frameworks, static libraries etc) you may want to hide your variables from the headers so other coders know as little about how your classes work as possible. It works similar to categorising a class and adding new methods, except you can also use new variables that only the implementation file (.m) knows about.
Since the introduction of iOS4, blocks have become very prevalent in the Cocoa framework as a quick and non messy way of implementing a ‘callback’. Blocks can be passed around just like any other variable. They are most used in UIView animations.
Harnessing the power and simplicity of blocks is something that I have been doing a lot more since iOS4, turning old fashioned protocol delegates into blocks where it makes sense.
So you’re coding away, everything is coloured nicely so you can distinguish between reserved words, datatypes and variables, but then the unthinkable happens; all your code turns black. Not to worry, you can live without the colours, but when you see the “symbol not found” message and Xcode is no longer autocompleting variables and functions for you, you start the panic. Your development time rolls to a halt and you can no longer quickly jump around from method to method. You realise Xcode has broken it’s intellisense index.
If you have worked with some of the basic iOS controls previously you have probably pulled hair trying to figure out how to change the colours around. Most notably the UISwitch – currently developers only have access to the standard blue version, and it doesn’t help when the orange ‘Airplane Mode’ switch teases you in