Percorso
percorso proposto
Delegation and controllers
A delegate is a protocol (interface) that defines methods that an object implements in order to receive specific messages from other objects. Delegates objects are most often used to receive asynchronous callbacks such as user input, I/O. It is a means of implementing a delegation based design pattern wherein the responsibility for performing an action is transferred from some root source to an interested third party. For instance, UIApplication has delegate methods that provide a third party with the ability to perform operations at certain times during the applications lifetime.
A controller is an object that usually contains UI elements (views, controls, etc.) and data, In many cases, a controller is a delegate and can implement several delegate protocols to receive events from multiple objects. Keep in mind that many UI elements and controls let you pass events back to the controller by linking them to an IBAction method in Interface Builder. This is very handy as it doesn't require extra code to implement delegates. However, some other APIs such as the ABPeoplePickerNavigationController or NSURLConnection have no visualization in Interface Builder and so must use delegates to handle their events
-managing views - for loading them into memory from disk when they are needed and unloading them when they are not. -They transform content from some underlying model object into a form that is usable by your view objects, -load content into your in-memory model from the disk or from the internet, and dump the contents back to disk when you save and/or quit.
Delegation
The delegating object keeps a reference to the other object—the delegate—and at the appropriate time sends a message to it. The message informs the delegate of an event that the delegating object is about to handle or has just handled. The delegate may respond to the message by updating the appearance or state of itself or other objects in the application, and in some cases it can return a value that affects how an event is handled. The main value of delegation is that it allows you to easily customize the behavior of several objects in one central object. The delegating object is typically a framework object, and the delegate is typically a custom controller object. The delegating object holds a weak reference to its delegate.
+------------+ +-------------+ | | --- windowShouldClose ---> | | | window | | delegate | | | <--- NO ----------------- | | +------------+ +-------------+
An example of a delegating object is an instance of the NSWindow class of the AppKit framework. NSWindow declares a protocol, among whose methods is windowShouldClose:. When a user clicks the close box in a window, the window object sends windowShouldClose: to its delegate to ask it to confirm the closure of the window. The delegate returns a Boolean value, thereby controlling the behavior of the window object.
Delegation and Notifications
The delegate of most Cocoa framework classes is automatically registered as an observer of notifications posted by the delegating object. The delegate need only implement a notification method declared by the framework class to receive a particular notification message. Following the example above, a window object posts an NSWindowWillCloseNotification to observers but sends a windowShouldClose: message to its delegate.
Data Source
A data source is almost identical to a delegate. The difference is in the relationship with the delegating object. Instead of being delegated control of the user interface, a data source is delegated control of data. The delegating object, typically a view object such as a table view, holds a reference to its data source and occasionally asks it for the data it should display. A data source, like a delegate, must adopt a protocol and implement at minimum the required methods of that protocol. Data sources are responsible for managing the memory of the model objects they give to the delegating view.
Interface builder
collegare un widget da interface builder al codice nel controller consiste di:
.h
@interface project_Controller : UIViewController { IBOutlet UILabel *statusText; // oggetti da esportare nella view } // oggetto da creare nel controller @property (retain, nonatomic) UILabel *statusText; // action -(IBAction)buttonPressed:(id)sender;
.m
-(IBAction)buttonPressed:(id)sender { NSString *newText = [[NSString alloc] initWithFormat: @" Hello World!!!"]; statusText.text = newText; //se il widget è pubblicato è possbile controllarlo dal metodo [newText release]; }
Serie di chiamate di una applicazione When the process is started, it runs the NSApplicationMain function, which creates an instance of NSApplication. The application object reads the main nib file and unarchives the objects inside. The objects are all sent the message awakeFromNib. Then the application object checks for events.
The timeline for these events appears in When it receives an event from the keyboard and mouse, the window server puts the event data into the event queue for the appropriate application. The application object reads the event data from its queue and forwards it to a user interface object (like a button), and your code gets triggered. If your code changes the data in a view, the view is redisplayed.
Then the application object checks its event queue for another event. This process of checking for events and reacting to them constitutes the main event loop.
Partita Iva: 02360450205
Content of this site is licensed under Creative Commons Attribution-Share Alike License.
