Application wide Fonts

So you get your nice shiny PSD's from the designer and your ready to tear though the new UI for your fantastic Application. However their is one problem. While the designs look great, the designer has chosen to use non default fonts. 

AFAIK there is no way to change the global default font for your app. So this means that have UILabel, and UITextField, and UITextView instance that you create needs to have it's font configured.

Configure each might take a while but what will take longer is if they decide to change their mind! While i'm relatively young, i've had this happened enough times that i know you should always plan for it.

so ....

This category provides you with some simply methods modelled on the existing UIFont class methods. Now if you couple this category with categories on the other text rendering classes, you have a nice short hand way to quickly render text in the font you want.



So as an example you could create a category on UILabel, and create a class method called labelWithAppSettings. This method would do the following

1. Allocate and instantiate a UILabel
2. Set it's font using one of the methods from UIFont+Additions
3. Return a Autoreleased object

This would allow us to create (Outside of IB) UILabel's across our application with the default settings by calling [UILabel labelWithAppSettings].

Now if you want to use IB (and you should, cause it's awesome, seriously), you either swizzle or use a category to override the awakeFromNib  on the text rendering classes and set font there.

While the above is very cool, i generally dislike using swizzling, or overriding methods via categories in production code. This generally causes your fellow programmers to swear at you while your not there.

Happy Coding

Non Global Singletons in Obj-C

Everyone seems to hate singletons. Personally i find them really convenient, but then i'm a lazy programmer. On my latest client app i decided to take a swing at making a hybrid singleton.

Generally speaking, Cocoa coventions (at least in all the documentation i've read), recommendation for sharing object instances across multiple controllers is to make it part of the application delegate. Personally i hate this, as it leads to a congested app delegate full of random iVars. Now it could be argued that if you find yourself in this place your doing it wrong, and in all truth you probably are. But considering that apple themselves suggest placing the CoreData ObjectContext in the app delegate, i think we're in good company.

My solution takes advantage of one of objective-c's many unique features, categories. Categories allow you to add methods to a class without modifing or subclassing. To most non cocoa programmers i just blew your mind, just wait to you find out about Swizzling!

Essentially i define a category on the class that i want to use as a singleton. In my scenario i wanted to have a single CLLocationManager In my entire app. This is because i need to access the devices location on a regular basis, and i want a global accuracy configuration ... and i just wanna try out some stuff :).

Code time


What i have done is simulated the typical method that you would expect to see for a singleton instance, but behind the scenes this method calls a property on the app delegate to get the shared instance variable.

In my eyes the positives to this approach are:
No global variable for the instance.
The Share instance is where you would expect it to me, and if required can be serialized on app exit.
Accessing the instance is as easy as [CLLocationManager sharedInstance] vs [[[[UIApplication sharedApplication] delegate] locationManager]


Lastly, if the internets tell me that this is a wacky idea i can refractor this to classic singleton, without making mass changes to my app. Thoughts and opinions.