What are best practices that you use when writing Objective-C and Cocoa

Question

I know about the HIG  which is quite handy    but what programming practices do you use when writing Objective-C  and more specifically when using Cocoa  or CocoaTouch

User · Answer

Sort strings as the user wants

When you sort strings to present to the user, you should not use the simple compare: method. Instead, you should always use localized comparison methods such as localizedCompare: or localizedCaseInsensitiveCompare:.

For more details, see Searching, Comparing, and Sorting Strings.

User · Answer

Use standard Cocoa naming and formatting conventions and terminology rather than whatever you re used to from another environment   There are lots of Cocoa developers out there  and when another one of them starts working with your code  it ll be much more approachable if it looks and feels similar to other Cocoa code   Examples of what to do and what not to do    Don t declare id m something  in an object s interface and call it a member variable or field  use something or  something for its name and call it an instance variable  Don t name a getter -getSomething  the proper Cocoa name is just -something  Don t name a setter -something   it should be -setSomething  The method name is interspersed with the arguments and includes colons  it s - NSObject performSelector withObject    not NSObject  performSelector  Use inter-caps  CamelCase  in method names  parameters  variables  class names  etc  rather than underbars  underscores   Class names start with an upper-case letter  variable and method names with lower-case    Whatever else you do  don t use Win16 Win32-style Hungarian notation   Even Microsoft gave up on that with the move to the  NET platform

User · Answer

Resist subclassing the world   In Cocoa a lot is done through delegation and use of the underlying runtime that in other frameworks is done through subclassing   For example  in Java you use instances of anonymous  Listener subclasses a lot and in  NET you use your EventArgs subclasses a lot   In Cocoa  you don t do either     the target-action is used instead

User · Answer

I know I overlooked this when first getting into Cocoa programming   Make sure you understand memory management responsibilities regarding NIB files   You are responsible for releasing the top-level objects in any NIB file you load   Read Apple s Documentation on the subject

User · Answer

IBOutlets  Historically  memory management of outlets has been poor  Current best practice is to declare outlets as properties    interface MyClass  NSObject       NSTextField  textField     property  nonatomic  retain  IBOutlet NSTextField  textField   end   Using properties makes the memory management semantics clear  it also provides a consistent pattern if you use instance variable synthesis

User · Answer

Also  semi-related topic  with room for more responses     What are those little Xcode tips  amp  tricks you wish you knew about 2 years ago

User · Answer

import  MyClass h    interface MyClass    -  void  someMethod  -  void  someOtherMethod   end   implementation MyClass

User · Answer

Only release a property in dealloc method  If you want to release memory that the property is holding  just set it as nil   self  lt property gt    nil

User · Answer

The Apple-provided samples I saw treated the App delegate as a global data store  a data manager of sorts  That s wrongheaded  Create a singleton and maybe instantiate it in the App delegate  but stay away from using the App delegate as anything more than application-level event handling  I heartily second the recommendations in this blog entry  This thread tipped me off

User · Answer

Clean up in dealloc   This is one of the easiest things to forget - esp  when coding at 150mph  Always  always  always clean up your attributes member variables in dealloc   I like to use Objc 2 attributes - with the new dot notation - so this makes the cleanup painless  Often as simple as   -  void dealloc       self someAttribute   NULL       super dealloc       This will take care of the release for you and set the attribute to NULL  which I consider defensive programming - in case another method further down in dealloc accesses the member variable again - rare but could happen    With GC turned on in 10 5  this isn t needed so much any more - but you might still need to clean up others resources you create  you can do that in the finalize method instead

User · Answer

Golden Rule  If you alloc then you release   UPDATE  Unless you are using ARC

User · Answer

There are a few things I have started to do that I do not think are standard   1  With the advent of properties  I no longer use     to prefix  private  class variables   After all  if a variable can be accessed by other classes shouldn t there be a property for it   I always disliked the     prefix for making code uglier  and now I can leave it out   2  Speaking of private things  I prefer to place private method definitions within the  m file in a class extension like so    import  MyClass h    interface MyClass    -  void  someMethod  -  void  someOtherMethod   end   implementation MyClass   Why clutter up the  h file with things outsiders should not care about  The empty    works for private categories in the  m file  and issues compile warnings if you do not implement the methods declared   3  I have taken to putting dealloc at the top of the  m file  just below the  synthesize directives   Shouldn t what you dealloc be at the top of the list of things you want to think about in a class   That is especially true in an environment like the iPhone   3 5  In table cells  make every element  including the cell itself  opaque for performance  That means setting the appropriate background color in everything   3 6  When using an NSURLConnection  as a rule you may well want to implement the delegate method   -  NSCachedURLResponse   connection  NSURLConnection   connection                   willCacheResponse  NSCachedURLResponse   cachedResponse         return nil      I find most web calls are very singular and it s more the exception than the rule you ll be wanting responses cached  especially for web service calls   Implementing the method as shown disables caching of responses   Also of interest  are some good iPhone specific tips from Joseph Mattiello  received in an iPhone mailing list    There are more  but these were the most generally useful I thought  note that a few bits have now been slightly edited from the original to include details offered in responses    4  Only use double precision if you have to  such as when working with CoreLocation  Make sure you end your constants in  f  to make gcc store them as floats   float val   someFloat   2 2f    This is mostly important when someFloat may actually be a double  you don t need the mixed-mode math  since you re losing precision in  val  on storage   While floating-point numbers are supported in hardware on iPhones  it may still take more time to do double-precision arithmetic as opposed to single precision   References    Double vs float on the iPhone iPhone iPad double precision math   On the older phones supposedly calculations operate at the same speed but you can have more single precision components in registers than doubles  so for many calculations single precision will end up being faster   5  Set your properties as nonatomic  They re atomic by default and upon synthesis  semaphore code will be created to prevent multi-threading problems  99  of you probably don t need to worry about this and the code is much less bloated and more memory-efficient when set to nonatomic   6  SQLite can be a very  very fast way to cache large data sets  A map application for instance can cache its tiles into SQLite files  The most expensive part is disk I O   Avoid many small writes by sending BEGIN  and COMMIT  between large blocks  We use a 2 second timer for instance that resets on each new submit  When it expires  we send COMMIT    which causes all your writes to go in one large chunk  SQLite stores transaction data to disk and doing this Begin End wrapping avoids creation of many transaction files  grouping all of the transactions into one file   Also  SQL will block your GUI if it s on your main thread  If you have a very long query  It s a good idea to store your queries as static objects  and run your SQL on a separate thread  Make sure to wrap anything that modifies the database for query strings in  synchronize      blocks   For short queries just leave things on the main thread for easier convenience   More SQLite optimization tips are here  though the document appears out of date many of the points are probably still good   http   web utk edu  jplyon sqlite SQLite optimization FAQ html

User · Answer

Think about nil values  As this question notes  messages to nil are valid in Objective-C   Whilst this is frequently an advantage -- leading to cleaner and more natural code -- the feature can occasionally lead to peculiar and difficult-to-track-down bugs if you get a nil value when you weren t expecting it

User · Answer

One rather obvious one for a beginner to use   utilize Xcode s auto-indentation feature for your code   Even if you are copy pasting from another source  once you have pasted the code  you can select the entire block of code  right click on it  and then choose the option to re-indent everything within that block     Xcode will actually parse through that section and indent it based on brackets  loops  etc   It s a lot more efficient than hitting the space bar or tab key for each and every line

User · Answer

Don t write Objective-C as if it were Java C  C   etc   I once saw a team used to writing Java EE web applications try to write a Cocoa desktop application   As if it was a Java EE web application   There was a lot of AbstractFooFactory and FooFactory and IFoo and Foo flying around when all they really needed was a Foo class and possibly a Fooable protocol   Part of ensuring you don t do this is truly understanding the differences in the language   For example  you don t need the abstract factory and factory classes above because Objective-C class methods are dispatched just as dynamically as instance methods  and can be overridden in subclasses

User · Answer

Don t use unknown strings as format strings  When methods or functions take a format string argument  you should make sure that you have control over the content of the format string   For example  when logging strings  it is tempting to pass the string variable as the sole argument to NSLog       NSString  aString      get a string from somewhere      NSLog aString     The problem with this is that the string may contain characters that are interpreted as format strings  This can lead to erroneous output  crashes  and security problems   Instead  you should substitute the string variable into a format string       NSLog        aString

User · Answer

Some of these have already been mentioned  but here s what I can think of off the top of my head    Follow KVO naming rules  Even if you don t use KVO now  in my experience often times it s still beneficial in the future  And if you are using KVO or bindings  you need to know things are going work the way they are supposed to  This covers not just accessor methods and instance variables  but to-many relationships  validation  auto-notifying dependent keys  and so on  Put private methods in a category  Not just the interface  but the implementation as well  It s good to have some distance conceptually between private and non-private methods  I include everything in my  m file  Put background thread methods in a category  Same as above  I ve found it s good to keep a clear conceptual barrier when you re thinking about what s on the main thread and what s not  Use  pragma mark  section   Usually I group by my own methods  each subclass s overrides  and any information or formal protocols  This makes it a lot easier to jump to exactly what I m looking for  On the same topic  group similar methods  like a table view s delegate methods  together  don t just stick them anywhere  Prefix private methods  amp  ivars with    I like the way it looks  and I m less likely to use an ivar when I mean a property by accident  Don t use mutator methods   properties in init  amp  dealloc  I ve never had anything bad happen because of it  but I can see the logic if you change the method to do something that depends on the state of your object  Put IBOutlets in properties  I actually just read this one here  but I m going to start doing it  Regardless of any memory benefits  it seems better stylistically  at least to me   Avoid writing code you don t absolutely need  This really covers a lot of things  like making ivars when a  define will do  or caching an array instead of sorting it each time the data is needed  There s a lot I could say about this  but the bottom line is don t write code until you need it  or the profiler tells you to  It makes things a lot easier to maintain in the long run  Finish what you start  Having a lot of half-finished  buggy code is the fastest way to kill a project dead  If you need a stub method that s fine  just indicate it by putting NSLog    stub    inside  or however you want to keep track of things

User · Answer

Sort strings as the user wants

When you sort strings to present to the user, you should not use the simple compare: method. Instead, you should always use localized comparison methods such as localizedCompare: or localizedCaseInsensitiveCompare:.

For more details, see Searching, Comparing, and Sorting Strings.

User · Answer

Variables and properties  1  Keeping your headers clean  hiding implementation Don t include instance variables in your header  Private variables put into class continuation as properties  Public variables declare as public properties in your header  If it should be only read  declare it as readonly and overwrite it as readwrite in class continutation  Basically I am not using variables at all  only properties   2  Give your properties a non-default variable name  example     synthesize property   property     Reason 1  You will catch errors caused by forgetting  self   when assigning the property  Reason 2  From my experiments  Leak Analyzer in Instruments has problems to detect leaking property with default name   3  Never use retain or release directly on properties  or only in very exceptional situations   In your dealloc just assign them a nil  Retain properties are meant to handle retain release by themselves  You never know if a setter is not  for example  adding or removing observers  You should use the variable directly only inside its setter and getter   Views  1  Put every view definition into a xib  if you can  the exception is usually dynamic content and layer settings   It saves time  it s easier than writing code   it s easy to change and it keeps your code clean   2  Don t try to optimize views by decreasing the number of views  Don t create UIImageView in your code instead of xib just because you want to add subviews into it  Use UIImageView as background instead  The view framework can handle hundreds of views without problems   3  IBOutlets don t have to be always retained  or strong   Note that most of your IBOutlets are part of your view hierarchy and thus implicitly retained   4  Release all IBOutlets in viewDidUnload  5  Call viewDidUnload from your dealloc method  It is not implicitly called   Memory  1  Autorelease objects when you create them  Many bugs are caused by moving your release call into one if-else branch or after a return statement  Release instead of autorelease should be used only in exceptional situations - e g  when you are waiting for a runloop and you don t want your object to be autoreleased too early   2  Even if you are using Authomatic Reference Counting  you have to understand perfectly how retain-release methods work  Using retain-release manually is not more complicated than ARC  in both cases you have to thing about leaks and retain-cycles  Consider using retain-release manually on big projects or complicated object hierarchies   Comments  1  Make your code autodocumented  Every variable name and method name should tell what it is doing  If code is written correctly  you need a lot of practice in this   you won t need any code comments  not the same as documentation comments   Algorithms can be complicated but the code should be always simple   2  Sometimes  you ll need a comment  Usually to describe a non apparent code behavior or hack  If you feel you have to write a comment  first try to rewrite the code to be simpler and without the need of comments    Indentation  1  Don t increase indentation too much  Most of your method code should be indented on the method level  Nested blocks  if  for etc   decrease readability  If you have three nested blocks  you should try to put the inner blocks into a separate method  Four or more nested blocks should be never used  If most of your method code is inside of an if  negate the if condition  example    if  self             long initialization code        return self      if   self       return nil           long initialization code      return self     Understand C code  mainly C structs  Note that Obj-C is only a light OOP layer over C language  You should understand how basic code structures in C work  enums  structs  arrays  pointers etc   Example    view frame   CGRectMake view frame origin x  view frame origin y  view frame size width  view frame size height   20     is the same as    CGRect frame   view frame  frame size height    20  view frame   frame    And many more  Mantain your own coding standards document and update it often  Try to learn from your bugs  Understand why a bug was created and try to avoid it using coding standards   Our coding standards have currently about 20 pages  a mix of Java Coding Standards  Google Obj-C C   Standards and our own addings  Document your code  use standard standard indentation  white spaces and blank lines on the right places etc

User · Answer

Use NSAssert and friends  I use nil as valid object all the time     especially sending messages to nil is perfectly valid in Obj-C   However if I really want to make sure about the state of a variable  I use NSAssert and NSParameterAssert  which helps to track down problems easily

User · Answer

Avoid autorelease  Since you typically 1  don t have direct control over their lifetime  autoreleased objects can persist for a comparatively long time and unnecessarily increase the memory footprint of your application  Whilst on the desktop this may be of little consequence  on more constrained platforms this can be a significant issue  On all platforms  therefore  and especially on more constrained platforms  it is considered best practice to avoid using methods that would lead to autoreleased objects and instead you are encouraged to use the alloc init pattern   Thus  rather than   aVariable    AClass convenienceMethod     where able  you should instead use   aVariable     AClass alloc  init      do things with aVariable  aVariable release     When you re writing your own methods that return a newly-created object  you can take advantage of Cocoa s naming convention to flag to the receiver that it must be released by prepending the method name with  new    Thus  instead of   -  MyClass   convenienceMethod       MyClass  instance      self alloc  init  autorelease          configure instance     return instance      you could write   -  MyClass   newInstance       MyClass  instance     self alloc  init          configure instance     return instance      Since the method name begins with  new   consumers of your API know that they re responsible for releasing the received object  see  for example  NSObjectController s newObject method     1  You can take control by using your own local autorelease pools  For more on this  see Autorelease Pools

User · Answer

Declared Properties  You should typically use the Objective-C 2 0 Declared Properties feature for all your properties   If they are not public  add them in a class extension   Using declared properties makes the memory management semantics immediately clear  and makes it easier for you to check your dealloc method -- if you group your property declarations together you can quickly scan them and compare with the implementation of your dealloc method   You should think hard before not marking properties as  nonatomic   As The Objective C Programming Language Guide notes  properties are atomic by default  and incur considerable overhead   Moreover  simply making all your properties atomic does not make your application thread-safe  Also note  of course  that if you don t specify  nonatomic  and implement your own accessor methods  rather than synthesising them   you must implement them in an atomic fashion

User · Answer

Think about nil values  As this question notes  messages to nil are valid in Objective-C   Whilst this is frequently an advantage -- leading to cleaner and more natural code -- the feature can occasionally lead to peculiar and difficult-to-track-down bugs if you get a nil value when you weren t expecting it

User · Answer

Some of these have already been mentioned  but here s what I can think of off the top of my head    Follow KVO naming rules  Even if you don t use KVO now  in my experience often times it s still beneficial in the future  And if you are using KVO or bindings  you need to know things are going work the way they are supposed to  This covers not just accessor methods and instance variables  but to-many relationships  validation  auto-notifying dependent keys  and so on  Put private methods in a category  Not just the interface  but the implementation as well  It s good to have some distance conceptually between private and non-private methods  I include everything in my  m file  Put background thread methods in a category  Same as above  I ve found it s good to keep a clear conceptual barrier when you re thinking about what s on the main thread and what s not  Use  pragma mark  section   Usually I group by my own methods  each subclass s overrides  and any information or formal protocols  This makes it a lot easier to jump to exactly what I m looking for  On the same topic  group similar methods  like a table view s delegate methods  together  don t just stick them anywhere  Prefix private methods  amp  ivars with    I like the way it looks  and I m less likely to use an ivar when I mean a property by accident  Don t use mutator methods   properties in init  amp  dealloc  I ve never had anything bad happen because of it  but I can see the logic if you change the method to do something that depends on the state of your object  Put IBOutlets in properties  I actually just read this one here  but I m going to start doing it  Regardless of any memory benefits  it seems better stylistically  at least to me   Avoid writing code you don t absolutely need  This really covers a lot of things  like making ivars when a  define will do  or caching an array instead of sorting it each time the data is needed  There s a lot I could say about this  but the bottom line is don t write code until you need it  or the profiler tells you to  It makes things a lot easier to maintain in the long run  Finish what you start  Having a lot of half-finished  buggy code is the fastest way to kill a project dead  If you need a stub method that s fine  just indicate it by putting NSLog    stub    inside  or however you want to keep track of things

User · Answer

Don t use unknown strings as format strings  When methods or functions take a format string argument  you should make sure that you have control over the content of the format string   For example  when logging strings  it is tempting to pass the string variable as the sole argument to NSLog       NSString  aString      get a string from somewhere      NSLog aString     The problem with this is that the string may contain characters that are interpreted as format strings  This can lead to erroneous output  crashes  and security problems   Instead  you should substitute the string variable into a format string       NSLog        aString

User · Answer

Use the LLVM Clang Static Analyzer  NOTE  Under Xcode 4 this is now built into the IDE   You use the Clang Static Analyzer to -- unsurprisingly -- analyse your C and Objective-C code  no C   yet  on Mac OS X 10 5  It s trivial to install and use    Download the latest version from this page  From the command-line  cd to your project directory  Execute scan-build -k -V xcodebuild     There are some additional constraints etc   in particular you should analyze a project in its  Debug  configuration -- see http   clang llvm org StaticAnalysisUsage html for details -- the but that s more-or-less what it boils down to    The analyser then produces a set of web pages for you that shows likely memory management and other basic problems that the compiler is unable to detect

User · Answer

Don t forget that NSWindowController and NSViewController will release the top-level objects of the NIB files they govern   If you manually load a NIB file  you are responsible for releasing that NIB s top-level objects when you are done with them

User · Answer

All these comments are great  but I m really surprised nobody mentioned Google s Objective-C Style Guide that was published a while back   I think they have done a very thorough job

User · Answer

All these comments are great  but I m really surprised nobody mentioned Google s Objective-C Style Guide that was published a while back   I think they have done a very thorough job

User · Answer

If you re using Leopard  Mac OS X 10 5  or later  you can use the Instruments application to find and track memory leaks   After building your program in Xcode  select Run   Start with Performance Tool   Leaks   Even if your app doesn t show any leaks  you may be keeping objects around too long   In Instruments  you can use the ObjectAlloc instrument for this   Select the ObjectAlloc instrument in your Instruments document  and bring up the instrument s detail  if it isn t already showing  by choosing View   Detail  it should have a check mark next to it    Under  Allocation Lifespan  in the ObjectAlloc detail  make sure you choose the radio button next to  Created  amp  Still Living    Now whenever you stop recording your application  selecting the ObjectAlloc tool will show you how many references there are to each still-living object in your application in the    Net  column   Make sure you not only look at your own classes  but also the classes of your NIB files  top-level objects   For example  if you have no windows on the screen  and you see references to a still-living NSWindow  you may have not released it in your code

User · Answer

Avoid autorelease  Since you typically 1  don t have direct control over their lifetime  autoreleased objects can persist for a comparatively long time and unnecessarily increase the memory footprint of your application  Whilst on the desktop this may be of little consequence  on more constrained platforms this can be a significant issue  On all platforms  therefore  and especially on more constrained platforms  it is considered best practice to avoid using methods that would lead to autoreleased objects and instead you are encouraged to use the alloc init pattern   Thus  rather than   aVariable    AClass convenienceMethod     where able  you should instead use   aVariable     AClass alloc  init      do things with aVariable  aVariable release     When you re writing your own methods that return a newly-created object  you can take advantage of Cocoa s naming convention to flag to the receiver that it must be released by prepending the method name with  new    Thus  instead of   -  MyClass   convenienceMethod       MyClass  instance      self alloc  init  autorelease          configure instance     return instance      you could write   -  MyClass   newInstance       MyClass  instance     self alloc  init          configure instance     return instance      Since the method name begins with  new   consumers of your API know that they re responsible for releasing the received object  see  for example  NSObjectController s newObject method     1  You can take control by using your own local autorelease pools  For more on this  see Autorelease Pools

User · Answer

Write unit tests   You can test a lot of things in Cocoa that might be harder in other frameworks   For example  with UI code  you can generally verify that things are connected as they should be and trust that they ll work when used   And you can set up state  amp  invoke delegate methods easily to test them   You also don t have public vs  protected vs  private method visibility getting in the way of writing tests for your internals

User · Answer

kendell  Instead of    interface MyClass  private  -  void  someMethod -  void  someOtherMethod  end   Use    interface MyClass    -  void  someMethod -  void  someOtherMethod  end   New in Objective-C 2 0   Class extensions are described in Apple s Objective-C 2 0 Reference    Class extensions allow you to declare additional required API for a class in locations other than within the primary class  interface block   So they re part of the actual class - and NOT a  private  category in addition to the class  Subtle but important difference

User · Answer

Be more functional   Objective-C is object-oriented language  but Cocoa framework functional-style aware  and is designed functional style in many cases    There is separation of mutability  Use immutable classes as primary  and mutable object as secondary  For instance  use NSArray primarily  and use NSMutableArray only when you need   There is pure functions  Not so many  buy many of framework APIs are designed like pure function  Look at functions such as CGRectMake   or CGAffineTransformMake    Obviously pointer form looks more efficient  However indirect argument with pointers can t offer side-effect-free  Design structures purely as much as possible   Separate even state objects  Use -copy instead of -retain when passing a value to other object  Because shared state can influence mutation to value in other object silently  So can t be side-effect-free  If you have a value from external from object  copy it  So it s also important designing shared state as minimal as possible     However don t be afraid of using impure functions too     There is lazy evaluation  See something like - UIViewController view  property  The view won t be created when the object is created  It ll be created when caller reading view property at first time  UIImage will not be loaded until it actually being drawn  There are many implementation like this design  This kind of designs are very helpful for resource management  but if you don t know the concept of lazy evaluation  it s not easy to understand behavior of them   There is closure  Use C-blocks as much as possible  This will simplify your life greatly  But read once more about block-memory-management before using it  There is semi-auto GC  NSAutoreleasePool  Use -autorelease primary  Use manual -retain -release secondary when you really need   ex  memory optimization  explicit resource deletion

User · Answer

Make sure you bookmark the Debugging Magic page   This should be your first stop when banging your head against a wall while trying to find the source of a Cocoa bug   For example  it will tell you how to find the method where you first allocated memory that later is causing crashes  like during app termination

User · Answer

Turn on all GCC warnings  then turn off those that are regularly caused by Apple s headers to reduce noise    Also run Clang static analysis frequently  you can enable it for all builds via the  Run Static Analyzer  build setting   Write unit tests and run them with each build

User · Answer

Simple but oft-forgotten one  According to spec      In general  methods in different   classes that have the same selector    the same name  must also share the   same return and argument types  This   constraint is imposed by the compiler   to allow dynamic binding    in which case all the same named selectors  even if in different classes  will be regarded as to have identical return argument types  Here is a simple example    interface FooInt NSObject   - int  print   end   implementation FooInt - int  print      return 5     end   interface FooFloat NSObject   - float  print   end   implementation FooFloat - float  print      return 3 3     end  int main  int argc  const char   argv           NSAutoreleasePool   pool     NSAutoreleasePool alloc  init           id f1   FooFloat alloc init         prints 0  runtime considers  f1 print  to return int  as f1 s type is  id  and FooInt precedes FooBar     NSLog    f   f1 print         FooFloat  f2   FooFloat alloc init         prints 3 3 expectedly as the static type is FooFloat     NSLog    f   f2 print          f1 release        f2 release       pool drain        return 0

User · Answer

Try to avoid what I  have now decided to call Newbiecategoryaholism  When newcomers to Objective-C discover categories they often go hog wild  adding useful little categories to every class in existence   What  i can add a method to convert a number to roman numerals to NSNumber rock on      Don t do this   Your code will be more portable and easier to understand with out dozens of little category methods sprinkled on top of two dozen foundation classes   Most of the time when you really think you need a category method to help streamline some code you ll find you never end up reusing the method   There are other dangers too  unless you re namespacing your category methods  and who besides the utterly insane ddribin is   there is a chance that Apple  or a plugin  or something else running in your address space will also define the same category method with the same name with a slightly different side effect      OK  Now that you ve been warned  ignore the  don t do this part   But exercise extreme restraint

User · Answer

This is subtle one but handy one  If you re passing yourself as a delegate to another object  reset that object s delegate before you dealloc   -  void dealloc   self someObject delegate   NULL  self someObject   NULL      super dealloc       By doing this you re ensuring that no more delegate methods will get sent  As you re about to dealloc and disappear into the ether you want to make sure that nothing can send you any more messages by accident  Remember self someObject could be retained by another object  it could be a singleton or on the autorelease pool or whatever  and until you tell it  stop sending me messages    it thinks your just-about-to-be-dealloced object is fair game   Getting into this habit will save you from lots of weird crashes that are a pain to debug   The same principal applies to Key Value Observation  and NSNotifications too   Edit   Even more defensive  change   self someObject delegate   NULL    into   if  self someObject delegate    self      self someObject delegate   NULL

[iphone] What are best practices that you use when writing Objective-C and Cocoa?

Sort strings as the user wants

Examples related to iphone

Examples related to objective-c

Examples related to cocoa

Examples related to cocoa-touch

Examples related to ios