Another method we examine for the iPhone OS is event response. Events can appear on the iPhone or iPad in three main ways: through bare events, through delegated events, and through notification. Whereas the methods of our earlier topics all derived from NSObject, event response instead comes from the UIResponder object, whereas notification comes from the NSNotificationCenter. You won't have to worry about accessing responder methods and properties because UIResponder is the parent of most UIKit objects, but the NSNotificationCenter requires special access.
Most user input results in an event being placed into a responder chain. This is a linked set of objects that, for the most part, goes backward up through the view hierarchy. Any input is captured by the first responder, which tends to be the object the user is directly interacting with. If that object can't resolve the input, it sends it up to its superview, then to its superview, all the way up the chain. If input gets all the way up the view hierarchy to the window object, it's next sent to the application itself, which tends to pass it off to an application delegate as a last resort.
Any of these objects can choose to handle an event, which stops its movement up the responder chain. Following the standard MVC model, you'll often build event response into UIViewController objects, which are pretty far up the responder chain. For any UIControl objects, such as buttons, sliders, and toggles, events are often turned into actions. Whereas events report touches to the screen, actions instead report manipulations of the controls and are thus easier to read. Actions follow a slightly different hierarchy of response.
Events can be sent to an object in a way other than via a first responder: through a delegate. This is an object (usually a view controller) that says it will take care of events for another object (usually a view). It's close kin to a data source, which is an object (again, usually a view controller) that promises to do the data setup and control for another object (again, usually a view). Delegation and data sourcing are each controlled by a protocol, which is a set of methods the delegate or data source agrees to respond to. For example, a table's delegate might have to respond to a method that alerts it when a row in the table has been selected. Similarly, a table's data source might describe what all the rows of the table look like. Delegates and data sources fit cleanly into the MVC model used by Objective-C, because they allow a view to hand off its work to its controller without having to worry about where each of those objects is in the responder chain.
Standard event response and delegation represent two ways that objects can be alerted to standard events, such as fingers touching the screen. A third method can also be used to program many different sorts of activities, such as the device's orientation changing or a network connection closing: the notification. Objects register to receive a certain type of notification with the NSNotification-Center and afterward may process those notifications accordingly.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Marvin V. Hayels at 09232010
1. Basics to understanding the structure of an embedded Linux system
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.
Partners: Damenmode