Here’s a quick fire list of 5 time-saving Objective-C tips that every developer should know. Perfect for making time for that extra coffee!
1. Enum shorthand
Enums at their simplest are labelled sets of integers. Where an inexperienced programmer might use a number to represent the download state of an image lets say, e.g. 0 = queued, 1 = downloading, 2 = downloaded, 3 = complete… When using these numbers in actual code a simple slip of the finger on the keyboard and they could easily type an extra digit in their if statement or assignment. These types of errors don’t usually show up when compiling. Even worse, these are usually obscure errors that only reveal themselves at run-time and only then when things don’t work as expected often requiring considerable debugging effort.
This is where enums step in. Enums are really handy and allow you to associate symbols or ‘labels’ with integers. If you type an enum value that doesn’t exist the compiler steps in and reports an error at compile-time instead and Xcode will probably suggest a fix for you if it was a typo! The other benefit of enums is that you can quickly add new values into them and assuming your code doesn’t save the integer to disk your code will automatically work with the new values.
There are a couple of different ways to define enums but the easiest way which will also provide Xcode with some extra compiling hints is as follows:
typedef NS_ENUM(NSInteger, VRDownloadState) {
VRDownloadStateQueued,
VRDownloadStateDownloading,
VRDownloadStateDownloaded,
VRDownloadStateError
};
2. NSNotification NSString constants
Similar to using enums to generate compile-time errors when you have typos, experienced developers use NSString constants for their NSNotification posts. The easiest way to use them is to define an extern in the header and then define the pointer constant in the implementation file. Now use VRPhotoUploaderStateChangeNotification in place of your string.
VRUploader.h
extern NSString * const VRStateChangeNotification;
VRUploader.m
#import "VRUploader.h"
NSString * const VRStateChangeNotification = @"VRStateChangeNotification";
3. Gitignore List for Xcode files
If you use Git as your version control system, paste the contents of this in your .gitignore file and the troublesome Xcode user files won’t be committed to Git which should save you some unnecessary conflict resolution. These are files that typically remember window positions or which files you have open and can safely be ignored.
# Mac OS X
*.DS_Store
# Xcode
*.pbxuser
*.mode1v3
*.mode2v3
*.perspectivev3
*.xcuserstate
project.xcworkspace/
xcuserdata/
# Generated files
*.o
# Backup files
*~.nib
4. Open Quickly and header scanning
A powerful technique used by experienced developers is to look directly at the header files instead of searching through the occasionally incomplete documentation. Often you can uncover undocumented comments in the header files and get directly to the methods you want to use, even in system frameworks such as UIKit and CoreBluetooth. To do this press Shift + Command + O or choose Open Quickly… in the file menu and then simply type in the name of the class header you want to look at such as ‘UIView’.
5. Define descriptions in your classes
NSLog is the staple of many developer debug workflows but surprisingly not many developers realise you can print out custom descriptions of your own objects instead of displaying the usual hex memory address. You could use this to display the contents of your objects similar to how arrays display their keys. To do this simply implement a – (NSString *)description method in your sub-class. If you need the class name and memory address you can use [super description] or use the %p format specifier and pass in self for the memory address. To specify the class name use %@ and pass in NSStringFromClass([self class]).
- (NSString *)description
{
NSString *className = NSStringFromClass([self class]);
return [NSString stringWithFormat:@"<%@: %p %@ - %d>", className, self, self.playerID, self.score];
}
These are just 5 of my most used tips and if you aren’t using them then you should be. Bookmark this page if you have trouble remembering the enum syntax or can’t quite remember the syntax for NSString* consts and share with other developers if you found this post useful. Also if there are any other tips you’d like to share, please post them in the comments.
This is a great post. Everyone should know these. However, using description rather than debugDescription will sometimes cause issues with AppStore reviews. debugDescription is the appropriate version to use today.