Run loop management is not entirely automatic. You must still design your thread’s code to start the run loop at appropriate times and respond to incoming events. Both Cocoa and Core Foundation provide run loop objects to help you configure and manage your thread’s run loop. Your application does not need to create these objects explicitly; each thread, including the application’s main thread, has an associated run loop object. Only secondary threads need to run their run loop explicitly, however. In both Carbon and Cocoa applications, the main thread automatically sets up and runs its run loop as part of the general application startup process.
iddata type to represent a variable that is an object without specifying what sort of object it is. This is referred to as dynamic typing.
Dynamic typing contrasts with static typing, in which the system explicitly identifies the class to which an object belongs at compile time. Static type checking at compile time may ensure stricter data integrity, but in exchange for that integrity, dynamic typing gives your program much greater flexibility. And through object introspection (for example, asking a dynamically typed, anonymous object what its class is), you can still verify the type of an object at runtime and thus validate its suitability for a particular operation.
Property List Types and Objects
Property lists consist only of certain types of data: dictionaries, arrays, strings, numbers (integer and float), dates, binary data, and Boolean values. Dictionaries and arrays are special types because they are collections; they can contain one or multiple data types, including other dictionaries and arrays. This hierarchical nesting of objects creates a graph of objects. The abstract data types have corresponding Foundation classes, Core Foundation types, and XML elements for collection objects and value objects.
- When we create an object, it has a retain count of 1.
- When we send an object a retain message, its retain count is incremented by 1.
- When we send an object a release message, its retain count is decremented by 1.
- When you send an object a autorelease message, its retain count is decremented by 1 at some stage in the future. This way the instance is cleared when pool is drained. But there is high chance of object not cleared when multiple retains are done so we must enclose every retain with a release
- If an objectʼs retain count is reduced to 0, it is deallocated. No further release or autorelease calls are allowed
nonatomic specifies that accessors are nonatomic. By default, accessors are atomic.
Properties are atomic by default so that synthesized accessors provide robust access to properties in a multithreaded environment. That is, the value returned from the getter or set via the setter is always fully retrieved or set regardless of what other threads are executing concurrently.
If you specify strong, copy, or retain and do not specify nontoxic, then in a reference-counted environment, a synthesized get accessor for an object property uses a lock and retains and auto-release the returned value. the implementation will be similar to the following:
[_internal lock]; // lock using an object-level lock id result = [[value retain] autorelease]; [_internal unlock]; return result;
If you specify
nonatomic, a synthesized accessor for an object property simply returns the value directly.
Markup and Deprecation
Properties support the full range of C-style decorators. Properties can be deprecated and support
__attribute__ style markup:
@property CGFloat x AVAILABLE_MAC_OS_X_VERSION_10_1_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X_VERSION_10_4; @property CGFloat y __attribute__((…));