Auto-release Pools and Background Threads

Regarding Objective-C programming for MAC OS X and IOS:

(from https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmAutoreleasePools.html )

Cocoa always expects there to be an autorelease pool available. If a pool is not available, autoreleased objects do not get released and your application leaks memory. If you send an autorelease message when a pool is not available, Cocoa logs a suitable error message. The AppKit and UIKit frameworks automatically create a pool at the beginning of each event-loop iteration, such as a mouse down event or a tap, and drain it at the end. Therefore you typically do not have to create a pool, or even see the code that is used to create one. There are, however, three occasions when you might use your own autorelease pools:

If you are writing a program that is not based on a UI framework, such as a command-line tool.

If you write a loop that creates many temporary objects.

You may create an autorelease pool inside the loop to dispose of those objects before the next iteration. Using an autorelease pool in the loop helps to reduce the maximum memory footprint of the application.

If you spawn a secondary thread.

You must create your own autorelease pool as soon as the thread begins executing; otherwise, your application will leak objects. (See “Autorelease Pools and Threads” for details.)

Cocoa Asynchronous Methods and Event Callbacks

Chilkat v9.3.0 for Cocoa now includes the asynchronous functionality and event callback functionality that has been available in the C++ libs.

Asynchronous methods run in a background thread such that the call immediately returns to the application.  Events are not fired w/ asynchronous method calls — your app would periodically check to see if the background task is finished.

To implement an event callback, your app would define/implement a class that inherits from one of the Cko*Progress base classes.  You provide method implementations to override the methods specified in the Cko*Progress classes (see the header files).  The callback object is specified via the EventCallbackObject property.  For example:

// property setter: EventCallbackObject
– (void)setEventCallbackObject: (CkoFtp2Progress *)eventObj;