Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL

Chapter 32. Bindings and Controllers > Bindings and Controllers Limitations and... - Pg. 325

Bindings and Controllers context:context]; } If you use the approach of converting Key Value Observation notifications into NSNotifications , you can have any number of observers that each register a different selector for the same key path. Unfortunately, the NSNotification approach has problems of its own. Using key path strings as notification names is not ideal because key paths are specified in Interface Builder and must be duplicated exactly in your code that registers for notifications. A simple change in Interface Builder could necessitate changes to notification code in multiple disparate places within your application. The compiler can't detect errors in the key path strings, so you must test at runtime to detect key path errors. Nevertheless, NSNotificationCenter provides at least one way to circumvent the use of explicit string comparisons in your own code. Bindings and Controllers Limitations and Ben- efits A common criticism of bindings is that there is too much magic happening that the programmer can't see. This chapter dispels some of the magic. Bindings are hard to document because they typically aren't visible in code. The same criticism can be made for Targets, Actions, and Outlets that are configured in Interface Builder. However, due in part to the flexibility and potential complexity of bindings, the need to document bindings is even greater than the need to document Targets, Actions, and Outlets. The use of string keys avoids coupling between objects. Any two properties of any two objects can bind together as long as properties corresponding to the string keys can be found at runtime. Of course, the corresponding down side is that the compiler can't determine correctness of bindings. You have to wait until runtime to test