Adding additional details in NSCopying / NSCopying documentation about stream properties

This commit is contained in:
Mattt Thompson 2012-08-15 10:03:46 -07:00
parent 7132b96124
commit 19a491b45b

View file

@ -79,13 +79,14 @@ extern NSString * const AFNetworkingOperationDidFinishNotification;
### NSCoding Caveats
- Encoded operations do not include any block properties. Be sure to set `completionBlock` and any other callback blocks as necessary when using `-initWithCoder:` or `NSKeyedUnarchiver`, for example.
- Encoded operations do not include any block or stream properties. Be sure to set `completionBlock`, `outputStream`, and any callback blocks as necessary when using `-initWithCoder:` or `NSKeyedUnarchiver`.
- Operations are paused on `encodeWithCoder:`. If the operation was encoded while paused or still executing, its archived state will return `YES` for `isReady`. Otherwise, the state of an operation when encoding will remain unchanged.
### NSCopying Caveats
- `-copy` and `-copyWithZone:` return a new operation with the `NSURLRequest` of the original. So rather than an exact copy of the operation at that particular instant, the copying mechanism returns a completely new instance, which can be useful for retrying operations.
- Operation copies do not include `completionBlock`, but do include any other callback blocks of the original. `completionBlock` often strongly captures a reference to `self`, which, perhaps surprisingly, would otherwise point to the _original_ operation when copied.
- A copy of an operation will not include the `outputStream` of the original.
- Operation copies do not include `completionBlock`. `completionBlock` often strongly captures a reference to `self`, which, perhaps surprisingly, would otherwise point to the _original_ operation when copied.
@warning Attempting to load a `file://` URL in iOS 4 may result in an `NSInvalidArgumentException`, caused by the connection returning `NSURLResponse` rather than `NSHTTPURLResponse`, which is the behavior as of iOS 5.
*/