iOS / asi-http-request

Added a test for client certificates (iOS only)
Attempt to fix, YET AGAIN, building for 10.6 and that stupid NSXMLParserDelegate

Conflicts:
	.gitignore

Based on an idea from Jesse Rusak -> http://github.com/MindSea/asi-http-request/commit/f346f7f9de333501f732404323e8f73e911fbeea

…at it gets the name of the correct bundle, such as in the case of a Preference Pane.

… has been downloaded.

Tweak tests

Without this code, I found that adding assert(self.isCancelled) after [super cancel] resulting in the assert failing - ie. isCancelled was not returning true - when tested on an ipad running iOS 3.2.1 (not tested elsewhere).

…d are only sent at the point when finished is actually changed.

Also only send notifications for isExecuting if it has changed state. (markAsFinished can be called more than once for cancelled requests)

Cancellation ends up addressing runloop objects and CF objects (and also accesses the runloop for the current thread), at least some of which will only work on the thread the request is running on.

For example, cancel calls cancelLoad which calls destroyReadStream which needs to access the runloop for the request for this:

[[self readStream] removeFromRunLoop:[NSRunLoop currentRunLoop] forMode:[self runLoopMode]];

It seems that notifying the NSOperationQueue we're complete before we start running causes a problem resulting in a crash.

Hence, we avoid calling markAsFinished unless we're inprogress - main() will call it when we do start.

This can be used by clients to alter or inspect the queue.

The most obvious use for this is calling setMaxConcurrentOperations: on the queue to alter the number of simultaneous requests that will be made over the network.

Tweaks to fix more LLVM warnings

…f the delegate was removed before we called it.

(The cache only stores 200 response codes.)

The client can still check if the cache was used or not by checking 'didUseCachedResponse'.

It is not safe to call retain on these objects unless we're on the main thread, as the main thread could have already started a dealloc() (but not reached the setDelegete:nil call) on the object when retain is called, potentially resulting in an object that is both retained and dealloced.

The previous mechanism can end up calling a delegate that has been removed by a setDelegate:nil, and hence may already be deallocated.

Now we run a callback on the mainthread, which only dereferences the delegate/queue and selectors to be called when it runs on the main thread.

The authenticationdelegate code is still using the old method. This should be looked at separately; it is slightly more complex as it needs to know if a delegate exists to be called.

Conflicts:
	Classes/ASIHTTPRequest.m

Closes gh-66

Add tests for same

…, and seems to be more reliable on iOS3 device
Fix deprecated warning in ASIDownloadCache
Tweaks to sample iphone app - rotation fixes, remove bandwidth use bar for now