In Objective-C, an object’s life cycle and its ownership qualification are not the same thing. The former is about how long the object itself lives in memory. The latter is about the different behaviors of ownerships towards what the object refers to in the different stage of the objects’s life cycle.
If an object is declared with retainable object owner type, but without an explicit ownership qualifier, its type is implicitly adjusted to have __strong qualification.
As a special case, if the object’s base type is Class (possibly protocol-qualified), the type is adjusted to have __unsafe_unretained qualification instead.
A clean, abstracted way to expose state values of an object.
Properties are one of two metaphors exposed by an object, the other being Methods (which are “a clean, abstracted way to perform an action”).
Useful tools for making gif for tutorials.
@implementation NSDictionary (Helpers)
+ (NSDictionary *)dictionaryWithContentsOfData:(NSData *)data
// uses toll-free bridging for data into CFDataRef and CFPropertyList into NSDictionary
CFPropertyListRef plist = CFPropertyListCreateFromXMLData(kCFAllocatorDefault, (CFDataRef)data,
// we check if it is the correct type and only return it if it is
if ([(id)plist isKindOfClass:[NSDictionary class]])
return [(NSDictionary *)plist autorelease];
// clean up ref
Here is a template originally written by Tim Pope at tpope.net and mentioned in the Pro Git book
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here
From Documentation/SubmittingPatches in the Git repo:
Describe your changes in imperative mood, e.g. “make xyzzy do frotz” instead of “[This patch] makes xyzzy do frotz” or “[I] changed xyzzy to do frotz”, as if you are giving orders to the codebase to change its behavior. Try to make sure your explanation can be understood without external resources. Instead of giving a URL to a mailing list archive, summarize the relevant points of the discussion.