Inherits from NSObject
Declared in PXObjectPool.h
PXObjectPool.m

Overview

An abstract object pool, capable of pooling multiple types of objects. You should use an object pool in situations where the same type of class must be allocated and deallocated many times over a period of time. The object pool holds on to unused objects instead of deallocating them, to avoid the overhead involved in allocating and releasing memory

You may create and keep track of your own instance of PXObjectPool, but you can also use the global shared object pool to quickly access pooled object across the entire application.

Tasks

  •   delegate

    An optional delegate of type PXObjectPoolDelegate. Can be used to customize what objects will be returned to the user for any given class type.

         property
  • – newObjectUsingClass:

    Returns a pooled object of the given type. The returned object will have a retainCount of 1, and must be released by the user at a later time. When the returned object is no longer needed it should be returned to the pool. To return an object to the pool, pass it to the releaseObject: method instead of calling [NSObject release] on it directly.
  • – releaseObject:

    Returns an object to the pool and takes control of its ownership. Passing an object to this method is equivalent to calling release on it, and so you must follow the usual rules of object ownership. You should never return an object to a pool if you don’t have ownership of it (a retain on it) for the same reason you shouldn’t release it if you don’t have a retain on it.
  • – purgeCachedData

    Clears all cached data in the pool from memory. As a pool is used it can potentially collect many unused objects. Call this method to get rid of all objects currently sitting in the pool without being used. Useful in low system memory situations.
  • + sharedObjectPool

    A global object pool which can be shared accross the entire application. You’re welcome!

Properties

delegate

An optional delegate of type PXObjectPoolDelegate. Can be used to customize what objects will be returned to the user for any given class type.

@property (nonatomic, retain) id<PXObjectPoolDelegate> delegate

Declared In

PXObjectPool.h

Class Methods

sharedObjectPool

A global object pool which can be shared accross the entire application. You’re welcome!

+ (PXObjectPool *)sharedObjectPool

Declared In

PXObjectPool.m

Instance Methods

newObjectUsingClass:

Returns a pooled object of the given type. The returned object will have a retainCount of 1, and must be released by the user at a later time. When the returned object is no longer needed it should be returned to the pool. To return an object to the pool, pass it to the releaseObject: method instead of calling [NSObject release] on it directly.

- (id)newObjectUsingClass:(Class)typeClass

Parameters

typeClass

The class from which an instance should be created

Return Value

A pooled instantiated object of the given class.

See Also

Declared In

PXObjectPool.m

purgeCachedData

Clears all cached data in the pool from memory. As a pool is used it can potentially collect many unused objects. Call this method to get rid of all objects currently sitting in the pool without being used. Useful in low system memory situations.

- (void)purgeCachedData

Declared In

PXObjectPool.m

releaseObject:

Returns an object to the pool and takes control of its ownership. Passing an object to this method is equivalent to calling release on it, and so you must follow the usual rules of object ownership. You should never return an object to a pool if you don’t have ownership of it (a retain on it) for the same reason you shouldn’t release it if you don’t have a retain on it.

- (void)releaseObject:(id)object

Discussion

Another important part of returning an object to a pool is resetting its state. An object that is returned to the pool with a state that hasn’t been reset may be given to the user at a different time, causing confusion as the user expects an object with a fresh state. This can lead to memory leaks and crashes which can be difficult to debug.

To avoid this confusion, have your pooled objects implement the PXPooledObject protocol, which requires a reset method to be implemented. This reset method is autuamatically invoked when the object is returned to a PXObjectPool, and should take care of resetting its internal state.

If you need to pool objects which you didn’t design (and hence can’t conform to the PXPooledObject protocol) you must reset their states manually before returning them to the pool.

Declared In

PXObjectPool.m