3. Di cosa parliamo oggi?
• MVC - Design Pattern Modal View Controller
• Xcode: introduzione alle funzioni base
• Sviluppiamo la nostra prima App:
• main.m
• AppDelegate
• UIViewController
• UINavigationController
• UITableViewController
iOS Bootcamp
4. MVC
Il design pattern MVC assegna ad ogni oggetto un ruolo
preciso: Model,View o Controller
iOS Bootcamp
5. MVC
Model
Data
Il design pattern MVC assegna ad ogni oggetto un ruolo
preciso: Model,View o Controller
iOS Bootcamp
6. MVC
Model View
Data Display
Il design pattern MVC assegna ad ogni oggetto un ruolo
preciso: Model,View o Controller
iOS Bootcamp
7. MVC
Coordinator
Controller
Model View
Data Display
Il design pattern MVC assegna ad ogni oggetto un ruolo
preciso: Model,View o Controller
iOS Bootcamp
8. MVC
Coordinator
Input utente
Controller
Model View
Data Display
Il design pattern MVC assegna ad ogni oggetto un ruolo
preciso: Model,View o Controller
iOS Bootcamp
9. MVC
Coordinator
Aggiorna Input utente
Controller
Model View
Data Display
Il design pattern MVC assegna ad ogni oggetto un ruolo
preciso: Model,View o Controller
iOS Bootcamp
10. MVC
Coordinator
Aggiorna Input utente
Controller
Model View
Notifica
Data Display
Il design pattern MVC assegna ad ogni oggetto un ruolo
preciso: Model,View o Controller
iOS Bootcamp
11. MVC
Coordinator
Aggiorna Input utente
Controller
Model View
Notifica Aggiorna
Data Display
Il design pattern MVC assegna ad ogni oggetto un ruolo
preciso: Model,View o Controller
iOS Bootcamp
12. Model
Descrive il/i modello/i dei dati utilizzato/i dalla nostra
applicazione
Definisce la logica con cui vengono manipolati questi
dati. es: salvataggio, modifica, eliminazione...
iOS Bootcamp
13. View
E’ ciò che l’utente vede
• Sa come disegnarsi
• Risponde alle azioni dell’utente
iOS Bootcamp
14. Controller
E’ l’intermediario tra una o più View e uno o più Model
• Interpreta le azioni dell’utente eseguite nella View
e comunica al Model eventuali cambiamenti da
apportare
• Segnala alla View le variazioni ai dati compiute dal
Model
• Gestisce il ciclo di vita degli altri oggetti
iOS Bootcamp
15. Best practice
1. Utilizziamo l’MVC per dividere il lavoro
2. Impariamo a conoscere il Framework, non
reinventiamolo.
3. Non abusiamo delle View
4. Minimiziamo le dipendenze mutuali
5. Dividiamo il codice in moduli
iOS Bootcamp
25. Library
• File Template Library (ctrl + alt + cmd + 1)
• Code Snipped Library (ctrl + alt + cmd + 2)
• Object Library (ctrl + alt + cmd + 3)
• Media Library (ctrl + alt + cmd + 4)
iOS Bootcamp
26. Jump Bar
• Mostra il percorso relativo del file corrente
• Ci permette di navigare velocemente tra i file che
si trovano allo stesso livello
iOS Bootcamp
27. IBOutlet
@property (nonatomic, retain) IBOutlet UILabel *label;
• Rappresenta una variabile d’istanza che referenzia
un altro oggetto
• Questa referenza è configurata ed archiviata
attraverso l’Interface Builder
• Ogni volta che accediamo ad uno xib viene
ristabilita la connessione tra l’oggetto utilizzato
nello xib e la variabile d’istanza ad esso collegata
iOS Bootcamp
29. IBActions
- (IBAction)doSomething:(id)sender;
• Utilizzato al posto di void
• Dichiara che il metodo è una “Action”. In questo
modo IB, come per gli IBOutlet, è consapevole
della sua presenza e può collegarlo ad un evento
• Il parametro sender è controllo che manda il
messaggio
iOS Bootcamp
31. La prima App...
dalla teoria alla pratica
Stefano Zanetti § The Alchemist
32. Il punto di ingresso: main.m
#import <UIKit/UIKit.h>
#import "AppDelegate.h"
int main(int argc, char *argv[])
{
@autoreleasepool {
return UIApplicationMain(argc, argv, nil,
NSStringFromClass([AppDelegate class]));
}
}
iOS Bootcamp
33. AppDelegate Start & End
- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
// Il sistema notifica alla nostra applicazione che la fase di
caricamento è terminata
}
- (void)applicationWillTerminate:(UIApplication *)application
{
! Il sistema notifica alla nostra applicazione che l'utente o
//
il sistema stesso ha richiesto la chiusura della nostra
applicazione. Possiamo usare questo metodo per salvare lo
status della nostra applicazione.
}
iOS Bootcamp
34. Enter in Background
- (void)applicationWillResignActive:(UIApplication
*)application
{
// Il sistema notifica alla nostra applicazione che sta per
diventare inattiva. Disabilitare Timer, mettere in pausa i
Task, ...
}
- (void)applicationDidEnterBackground:(UIApplication
*)application
{
// Se la nostra applicazione supporta il background, questo
metodo viene chiamato al posto del applicationWillTerminate.
Utilizzate questo metodo per rilasciare le risorse, salvare i
dati, invalidare i timers...
}
iOS Bootcamp
35. Enter in Foreground
- (void)applicationWillEnterForeground:(UIApplication
*)application
{
! Il sistema notifica che l’applicazione sta passando dallo
//
stato di background a quello di inattiva. In questo metodo è
possibile ripristinare la maggior parte delle cambiamenti
effettuati prima di entrare in background.
}
- (void)applicationDidBecomeActive:(UIApplication *)application
{
! Il sistema notifica che l’applicazione è tornata attiva.
//
Utilizzare questo metodo per far ripartire i vari task attivi,
timers, eventualmente per effettuare un refresh
dell’interfaccia utente...
}
iOS Bootcamp
36. UIViewController
• Un UIViewController è controller generico utile
per manipolare le UIView.
• Mette a disposizione diversi metodi che sono
chiamati quando una vista appare o scompare.
iOS Bootcamp
39. Creare un ViewController
PMViewController *controller = [[[PMViewController alloc]
initWithNibName:@"PMViewController" bundle:nil] autorelease];
Nome del file xib
iOS Bootcamp
40. Creare un ViewController
PMViewController *controller = [[[PMViewController alloc]
initWithNibName:@"PMViewController" bundle:nil] autorelease];
Bundle in cui
Nome del file xib
cercare il file xib
iOS Bootcamp
42. Utilizziamo il ViewController
Presentiamo in modale il ViewController
[self presentModalViewController:controller animated:YES];
Rimuoviamo il ViewController
[self dismissModalViewControllerAnimated:YES];
iOS Bootcamp
48. Push
Creiamo e aggiungiamo un nuovo contenuto allo stack
dei ViewControllers
UIViewController *detailViewController = [[UIViewController
alloc] initWithNibName:@"detailViewController" bundle:nil];
[self.navigationController
pushViewController:detailViewController animated:YES];
[detailViewController release];
iOS Bootcamp
49. Pop
Rimuoviamo il ViewController corrente dallo stack e
torniamo a quello precedente
[self.navigationController popViewControllerAnimated:YES];
Rimuoviamo tutti i ViewControllers dallo stack e
torniamo al rootViewController
[self.navigationController popToRootViewControllerAnimated:YES];
iOS Bootcamp
51. UITableView
Cosa ci serve?
• un UITableViewController
Oppure:
• un UIViewController
• una UITableView
• implementare correttamente
UITableViewDataSource (rappresentazione dei
dati) e il UITableViewDelegate (visualizzazione
contenuto celle)
iOS Bootcamp
57. Cell Identifier
Descriviamo le singole righe della slide precedente:
CellIdentifier viene definito statico perchè questo metodo viene
richiamato moltissime volte. La parola chiave “static” permette
di non ricreare un oggetto se ne esiste già uno di quel tipo.
static NSString *cellIdentifier = @"Cell";
iOS Bootcamp
58. Riutilizzare le celle
Il DataSource riutilizza gli oggetti UITableViewCell. Tramite
questo metodo chiediamo alla UITableView se esiste una cella
con quel particolare identifier che possiamo riutilizzare
UITableViewCell *cell = [tableView
dequeueReusableCellWithIdentifier:cellIdentifier];
iOS Bootcamp
59. UITableView
Nel caso non esista nessuna cella riutilizzabile ne creiamo una
nuova
if (cell == nil)
{
cell = [[[UITableViewCell alloc]
initWithStyle:UITableViewCellStyleDefault
reuseIdentifier:cellIdentifier] autorelease];
}
Aggiorniamo il testo della cella con la riga del nostro array
corrispondente alla riga dell’NSIndexPath interessato
cell.textLabel.text = [_elements objectAtIndex:indexPath.row];
iOS Bootcamp
61. What’s NeXT !?
Using Storyboard iCl
cat Push
ou
d
ion
int
egr
No and
atio
n
tifi
cal
Lo
e
has
Ma Dat
urc
nag a
pP
Co em
red ent
Ap
ata : Advanced UITableView
In-
and custom
UITableViewCell
iOS Bootcamp
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n
The Model-View-Controller (MVC) design pattern assigns objects in an application one of three roles: model, view, or controller. The pattern defines not only the roles objects play in the application, it defines the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries and communicates with objects of the other types across those boundaries.\nModel Objects\nModel objects encapsulate the data specific to an application and define the logic and computation that manipulate and process that data. For example, a model object might represent a character in a game or a contact in an address book. A model object can have to-one and to-many relationships with other model objects, and so sometimes the model layer of an application effectively is one or more object graphs. Much of the data that is part of the persistent state of the application (whether that persistent state is stored in files or databases) should reside in the model objects after the data is loaded into the application. Because model objects represent knowledge and expertise related to a specific problem domain, they can be reused in similar problem domains. Ideally, a model object should have no explicit connection to the view objects that present its data and allow users to edit that data&#x2014;it should not be concerned with user-interface and presentation issues.\nCommunication: User actions in the view layer that create or modify data are communicated through a controller object and result in the creation or updating of a model object. When a model object changes (for example, new data is received over a network connection), it notifies a controller object, which updates the appropriate view objects.\nView Objects\nA view object is an object in an application that users can see. A view object knows how to draw itself and can respond to user actions. A major purpose of view objects is to display data from the application&#x2019;s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.\nBecause you typically reuse and reconfigure them, view objects provide consistency between applications. Both the UIKit and AppKit frameworks provide collections of view classes, and Interface Builder offers dozens of view objects in its Library.\nCommunication: View objects learn about changes in model data through the application&#x2019;s controller objects and communicate user-initiated changes&#x2014;for example, text entered in a text field&#x2014;through controller objects to an application&#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&#x2019;s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.\nCommunication: A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.\n\n