121- Formal vs informal protocol.
In addition to formal protocols, you can also define an informal protocol by grouping the methods in a category declaration:
@interface NSObject (MyProtocol)
//someMethod();
@end
Informal protocols are typically declared as categories of the NSObject class, because that broadly associates the method names with any class that inherits from NSObject. Because all classes inherit from the root class, the methods aren’t restricted to any part of the inheritance hierarchy. (It is also possible to declare an informal protocol as a category of another class to limit it to a certain branch of the inheritance hierarchy, but there is little reason to do so.)
When used to declare a protocol, a category interface doesn’t have a corresponding implementation. Instead, classes that implement the protocol declare the methods again in their own interface files and define them along with other methods in their implementation files.
An informal protocol bends the rules of category declarations to list a group of methods but not associate them with any particular class or implementation.
Being informal, protocols declared in categories don’t receive much language support. There’s no type checking at compile time nor a check at runtime to see whether an object conforms to the protocol. To get these benefits, you must use a formal protocol. An informal protocol may be useful when all the methods are optional, such as for a delegate, but (in Mac OS X v10.5 and later) it is typically better to use a formal protocol with optional methods.
122- Optional vs required
Protocol methods can be marked as optional using the @optional keyword. Corresponding to the @optional modal keyword, there is a @required keyword to formally denote the semantics of the default behavior. You can use @optional and @required to partition your protocol into sections as you see fit. If you do not specify any keyword, the default is @required.
@protocol MyProtocol
@optional
-(void) optionalMethod;
@required
-(void) requiredMethod;
@end
123- Memory Management
If you alloc, retain, or copy/mutablecopy it, it’s your job to release it. Otherwise it isn’t.
124-Copy vs assign vs retain
· Assign is for primitive values like BOOL, NSInteger or double. For objects use retain or copy, depending on if you want to keep a reference to the original object or make a copy of it.
· assign: In your setter method for the property, there is a simple assignment of your instance variable to the new value, eg:
(void)setString:(NSString*)newString{
string = newString;
}
This can cause problems since Objective-C objects use reference counting, and therefore by not retaining the object, there is a chance that the string could be deallocated whilst you are still using it.
· retain: this retains the new value in your setter method. For example:
This is safer, since you explicitly state that you want to maintain a reference of the object, and you must release it before it will be deallocated.
(void)setString:(NSString*)newString{
[newString retain];
[string release];
string = newString;
}
· copy: this makes a copy of the string in your setter method:
This is often used with strings, since making a copy of the original object ensures that it is not changed whilst you are using it.
(void)setString:(NSString*)newString{
if(string!=newString){
[string release];
string = [newString copy];
}
}
125- alloc vs new
“alloc” creates a new memory location but doesn’t initializes it as compared to “new”.
126- release vs pool drain
“release” frees a memory. “drain” releases the NSAutoreleasePool itself.
127- NSAutoReleasePool : release vs drain
Strictly speaking, from the big picture perspective drain is not equivalent to release:
In a reference-counted environment, drain does perform the same operations as release, so the two are in that sense equivalent. To emphasise, this means you do not leak a pool if you use drain rather than release.
In a garbage-collected environment, release is a no-op. Thus it has no effect. drain, on the other hand, contains a hint to the collector that it should “collect if needed”. Thus in a garbage-collected environment, using drain helps the system balance collection sweeps.
128-autorelease vs release
Autorelase: By sending an object an autorelease message, it is added to the local AutoReleasePool, and you no longer have to worry about it, because when the AutoReleasePool is destroyed (as happens in the course of event processing by the system) the object will receive a release message, its RetainCount will be decremented, and the GarbageCollection system will destroy the object if the RetainCount is zero.
Release: retain count is decremented at this point.
129- Autorelease Pool
Autorelease pools provide a mechanism whereby you can send an object a “deferred” release message. This is useful in situations where you want to relinquish ownership of an object, but want to avoid the possibility of it being deallocated immediately (such as when you return an object from a method). Typically, you don’t need to create your own autorelease pools, but there are some situations in which either you must or it is beneficial to do so.
130- How autorelease pool is managed.
Every time -autorelease is sent to an object, it is added to the inner-most autorelease pool. When the pool is drained, it simply sends -release to all the objects in the pool.
Autorelease pools are simply a convenience that allows you to defer sending -release until “later”. That “later” can happen in several places, but the most common in Cocoa GUI apps is at the end of the current run loop cycle.
Discover more from mycodetips
Subscribe to get the latest posts sent to your email.
