SlideShare une entreprise Scribd logo
1  sur  62
Just do it
Apriamo Xcode e compiliamo...




    Stefano Zanetti § The Alchemist
Stefano Zanetti
   Apple iOS Developer
    Superpartes Innovation Campus & H-Farm

   Co-founder di
    # Pragma Mark ― www.pragmamark.org

   [tt] @stefanozanetti_
    [in] Stefano Zanetti
    [fb] stefano.znt
    [email] zanetti.stefano@gmail.com



                                             iOS Bootcamp
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
MVC




Il design pattern MVC assegna ad ogni oggetto un ruolo
            preciso: Model,View o Controller

                                               iOS Bootcamp
MVC



       Model

        Data

Il design pattern MVC assegna ad ogni oggetto un ruolo
            preciso: Model,View o Controller

                                               iOS Bootcamp
MVC



       Model                             View

        Data                           Display

Il design pattern MVC assegna ad ogni oggetto un ruolo
            preciso: Model,View o Controller

                                                 iOS Bootcamp
MVC
                    Coordinator

                      Controller



       Model                             View

        Data                           Display

Il design pattern MVC assegna ad ogni oggetto un ruolo
            preciso: Model,View o Controller

                                                 iOS Bootcamp
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
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
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
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
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
View

E’ ciò che l’utente vede


• Sa come disegnarsi
• Risponde alle azioni dell’utente



                                     iOS Bootcamp
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
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
Xcode




        iOS Bootcamp
Xcode



Editor/Builder




                 iOS Bootcamp
Xcode



            Editor/Builder


Navigator



                             iOS Bootcamp
Xcode

                             Inspector



            Editor/Builder


Navigator



                                iOS Bootcamp
Xcode

                             Inspector



            Editor/Builder


Navigator
                              Library


                                iOS Bootcamp
Xcode

                             Inspector



            Editor/Builder


Navigator
                              Library
                 Console
                                iOS Bootcamp
Xcode
                     Jump Bar
                                Inspector



            Editor/Builder


Navigator
                                 Library
                 Console
                                   iOS Bootcamp
Navigator
• Project Navigator (cmd + 1)
• Symbol Navigator (cmd + 2)
• Search Navigator (cmd + 3)
• Issue Navigator (cmd + 4)
• Debug Navigator (cmd + 5)
• Breakpoints Navigator (cmd + 6)
• Log Navigator (cmd + 7)
                                    iOS Bootcamp
Inspector

• File Inspector (alt + cmd + 1)
• Quick Help Inspector (alt + cmd + 2)
• Identity Inspector (alt + cmd + 3)
• Attributes Inspector (alt + cmd + 4)
• Size Inspector (alt + cmd + 5)
• Connections Inspector (alt + cmd + 6)
                                          iOS Bootcamp
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
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
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
Connettiamo




ctrl + click sul controllo + drag

                                    iOS Bootcamp
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
Connettiamo




ctrl + click sul controllo + drag

                                    iOS Bootcamp
La prima App...
   dalla teoria alla pratica




   Stefano Zanetti § The Alchemist
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
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
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
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
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
Di cosa abbiamo bisogno?


•   - (id)initWithNibName:(NSString *)nibNameOrNil bundle:
    (NSBundle *)nibBundleOrNil;

•   - (void)presentModalViewController:(UIViewController
    *)modalViewController animated:(BOOL)animated;

•   - (void)dismissModalViewControllerAnimated:(BOOL)animated;




                                                           iOS Bootcamp
Creare un ViewController



PMViewController *controller = [[[PMViewController alloc]
initWithNibName:@"PMViewController" bundle:nil] autorelease];




                                                        iOS Bootcamp
Creare un ViewController



PMViewController *controller = [[[PMViewController alloc]
initWithNibName:@"PMViewController" bundle:nil] autorelease];




     Nome del file xib


                                                        iOS Bootcamp
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
Quale transizione utilizzare?

//    UIModalTransitionStyle:
//
//    UIModalTransitionStyleCoverVertical,
//    UIModalTransitionStyleFlipHorizontal,
//    UIModalTransitionStyleCrossDissolve,
//    UIModalTransitionStylePartialCurl,

[controller
setModalTransitionStyle:UIModalTransitionStyleCoverVertical];




                                                        iOS Bootcamp
Utilizziamo il ViewController

Presentiamo in modale il ViewController

[self presentModalViewController:controller animated:YES];




Rimuoviamo il ViewController

[self dismissModalViewControllerAnimated:YES];




                                                        iOS Bootcamp
Appear/Disappear

              Gestione visualizzazione view

•   - (void)viewWillAppear:(BOOL)animated

•   - (void)viewDidAppear:(BOOL)animated

•   - (void)viewWillDisappear:(BOOL)animated

•   - (void)viewDidDisappear:(BOOL)animated

•   - (void)viewDidLoad

•   - (BOOL)shouldAutorotateToInterfaceOrientation:
    (UIInterfaceOrientation)interfaceOrientation




                                                      iOS Bootcamp
Memory Warning!


- (void)viewDidLoad                    - (void)viewWillUnload




               - (void)didReceiveMemoryWarning




                                                       iOS Bootcamp
UINavigationController

Estende la classe UIViewController implementando
la navigazione, semplice e veloce, tra ViewControllers




                                               iOS Bootcamp
Push & Pop

            Navigazione tra ViewControllers:

•   - (id)initWithRootViewController:(UIViewController
    *)rootViewController;

•   - (void)pushViewController:(UIViewController
    *)viewController animated:(BOOL)animated;

•   - (NSArray *)popToViewController:(UIViewController
    *)viewController animated:(BOOL)animated;

•   - (NSArray *)popToRootViewControllerAnimated:
    (BOOL)animated;




                                                         iOS Bootcamp
RootViewController

        Inizializzazione UINavigationController


UIViewController *viewController = [[UIViewController alloc]
initWithNibName:@"ViewController" bundle:nil];


UINavigationController *navigationController =
[[UINavigationController alloc]
initWithRootViewController:viewController];


[viewController release];




                                                        iOS Bootcamp
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
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
UITableView

Ecco qualche esempio di TableView:




                                     iOS Bootcamp
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
UITableViewDataSource
• Obbligatori
 •   - (NSInteger)tableView:(UITableView *) UITableView
     numberOfRowsInSection:(NSInteger)section;

 •   - (UITableViewCell *)tableView:(UITableView *)
     UITableView cellForRowAtIndexPath:(NSIndexPath
     *)indexPath;


• Opzionali
 •   - (NSInteger)numberOfSectionsInTableView:(UITableView
     *)tableView;

 •   - (NSString *)tableView:(UITableView *)tableView
     titleForHeaderInSection:(NSInteger)section;

 •   ...


                                                          iOS Bootcamp
Data Model
                 Definiamo il modello dati

#import <UIKit/UIKit.h>

@interface PMFATableViewController :
UIViewController<UITableViewDataSource, UITableViewDelegate>
{
    UITableView *_tableView;
    NSArray *_elements;
}
@property (nonatomic, retain) IBOutlet UITableView *tableView;
@property (nonatomic, retain) NSArray *elements;

@end


                                                        iOS Bootcamp
Popoliamo l’array di oggetti

 - (void)viewDidLoad
 {
! [super viewDidLoad];

! NSArray *elements = [NSArray arrayWithObjects:@"Objective-C",
                         @"UIViewController",
                         @"UITabBarController",
                         @"UINavigationController",
                         @"UITableView",
                         nil];

! self.elements = elements;
 }




                                                         iOS Bootcamp
Configuriamo il DataSource


- (NSInteger)tableView:(UITableView *)tableView
numberOfRowsInSection:(NSInteger)section
{
    ! return [_elements count];
}




                                                  iOS Bootcamp
Configuriamo il DataSource

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:
(NSIndexPath *)indexPath
{
  static NSString *cellIdentifier = @"Cell";

    UITableViewCell *cell = [tableView
    dequeueReusableCellWithIdentifier:cellIdentifier];

    if (cell == nil)
    {
      cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault
      reuseIdentifier:cellIdentifier] autorelease];
    }

    cell.textLabel.text = [_elements objectAtIndex:indexPath.row];

    return cell;
}




                                                                             iOS Bootcamp
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
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
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
UITableViewDelegate
•   - (void)tableView:(UITableView *)tableView willDisplayCell:
    (UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath
    *)indexPath;

•   - (CGFloat)tableView:(UITableView *)tableView
    heightForRowAtIndexPath:(NSIndexPath *)indexPath;

•   - (UIView *)tableView:(UITableView *)tableView
    viewForHeaderInSection:(NSInteger)section;

•   - (UIView *)tableView:(UITableView *)tableView
    viewForFooterInSection:(NSInteger)section;

•   - (void)tableView:(UITableView *)tableView
    didSelectRowAtIndexPath:(NSIndexPath *)indexPath;

•   ...



                                                        iOS Bootcamp
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
Thanks ☺




pragmamark.org

                 iOS Bootcamp

Contenu connexe

En vedette

Mobile Apps Per iOS , visione d'insieme
Mobile Apps Per iOS , visione d'insiemeMobile Apps Per iOS , visione d'insieme
Mobile Apps Per iOS , visione d'insiemeFrancesco De Simone
 
Xcode 6の新機能
Xcode 6の新機能Xcode 6の新機能
Xcode 6の新機能Shingo Sato
 
Session 1 - Introduction to iOS 7 and SDK
Session 1 -  Introduction to iOS 7 and SDKSession 1 -  Introduction to iOS 7 and SDK
Session 1 - Introduction to iOS 7 and SDKVu Tran Lam
 
History of iOS
History of iOSHistory of iOS
History of iOSpyro2927
 

En vedette (6)

Android vs iOS
Android vs iOSAndroid vs iOS
Android vs iOS
 
Mobile Apps Per iOS , visione d'insieme
Mobile Apps Per iOS , visione d'insiemeMobile Apps Per iOS , visione d'insieme
Mobile Apps Per iOS , visione d'insieme
 
Xcode 6の新機能
Xcode 6の新機能Xcode 6の新機能
Xcode 6の新機能
 
Session 1 - Introduction to iOS 7 and SDK
Session 1 -  Introduction to iOS 7 and SDKSession 1 -  Introduction to iOS 7 and SDK
Session 1 - Introduction to iOS 7 and SDK
 
History of iOS
History of iOSHistory of iOS
History of iOS
 
Presentation on iOS
Presentation on iOSPresentation on iOS
Presentation on iOS
 

Similaire à Xcode - Just do it

Sviluppo Di Applicazioni Su I Os
Sviluppo Di Applicazioni Su I OsSviluppo Di Applicazioni Su I Os
Sviluppo Di Applicazioni Su I OsNoDelay Software
 
Alessandro Forte - MVP vs MVC
Alessandro Forte - MVP vs MVCAlessandro Forte - MVP vs MVC
Alessandro Forte - MVP vs MVCAlessandro Forte
 
Migliora il tuo codice con knockout.js
Migliora il tuo codice con knockout.jsMigliora il tuo codice con knockout.js
Migliora il tuo codice con knockout.jsAndrea Dottor
 
Tech Webinar: Test e2e per AngularJS e non solo
Tech Webinar: Test e2e per AngularJS e non soloTech Webinar: Test e2e per AngularJS e non solo
Tech Webinar: Test e2e per AngularJS e non soloCodemotion
 
Sviluppare app native per iOS
Sviluppare app native per iOSSviluppare app native per iOS
Sviluppare app native per iOSGaspare Novara
 
Sviluppare apps native per iOS - Lo Stretto Digitale
Sviluppare apps native per iOS - Lo Stretto DigitaleSviluppare apps native per iOS - Lo Stretto Digitale
Sviluppare apps native per iOS - Lo Stretto Digitalelostrettodigitale
 
Making iOS UIKit Simulator for MacOS X
Making iOS UIKit Simulator for MacOS XMaking iOS UIKit Simulator for MacOS X
Making iOS UIKit Simulator for MacOS XDaniele Margutti
 
Progettazione per Apple Watch - Todi Appy Days 2015
Progettazione per Apple Watch - Todi Appy Days 2015Progettazione per Apple Watch - Todi Appy Days 2015
Progettazione per Apple Watch - Todi Appy Days 2015Todi Appy Days
 
Wearable Lab: Progettazione per Apple Watch
Wearable Lab: Progettazione per Apple WatchWearable Lab: Progettazione per Apple Watch
Wearable Lab: Progettazione per Apple WatchPaolo Musolino
 
Applicazioni web con Asp.Net MVC 6
Applicazioni web con Asp.Net MVC 6Applicazioni web con Asp.Net MVC 6
Applicazioni web con Asp.Net MVC 6Michele Aponte
 
Webkit meets native development
Webkit meets native developmentWebkit meets native development
Webkit meets native developmentNicholas Valbusa
 
Spring Framework
Spring FrameworkSpring Framework
Spring FrameworkNaLUG
 
Modi innovativi per costruire App
Modi innovativi per costruire AppModi innovativi per costruire App
Modi innovativi per costruire AppCommit University
 
Idiomatic Domain Driven Design
Idiomatic Domain Driven DesignIdiomatic Domain Driven Design
Idiomatic Domain Driven DesignAndrea Saltarello
 
Niccolò Becchi: Introduzione a GWT
Niccolò Becchi: Introduzione a GWTNiccolò Becchi: Introduzione a GWT
Niccolò Becchi: Introduzione a GWTfirenze-gtug
 

Similaire à Xcode - Just do it (20)

Sviluppo Di Applicazioni Su I Os
Sviluppo Di Applicazioni Su I OsSviluppo Di Applicazioni Su I Os
Sviluppo Di Applicazioni Su I Os
 
Programming iOS lezione 1
Programming iOS lezione 1Programming iOS lezione 1
Programming iOS lezione 1
 
Alessandro Forte - MVP vs MVC
Alessandro Forte - MVP vs MVCAlessandro Forte - MVP vs MVC
Alessandro Forte - MVP vs MVC
 
Spring Intro
Spring IntroSpring Intro
Spring Intro
 
Migliora il tuo codice con knockout.js
Migliora il tuo codice con knockout.jsMigliora il tuo codice con knockout.js
Migliora il tuo codice con knockout.js
 
Tech Webinar: Test e2e per AngularJS e non solo
Tech Webinar: Test e2e per AngularJS e non soloTech Webinar: Test e2e per AngularJS e non solo
Tech Webinar: Test e2e per AngularJS e non solo
 
Sviluppare app native per iOS
Sviluppare app native per iOSSviluppare app native per iOS
Sviluppare app native per iOS
 
Sviluppare apps native per iOS - Lo Stretto Digitale
Sviluppare apps native per iOS - Lo Stretto DigitaleSviluppare apps native per iOS - Lo Stretto Digitale
Sviluppare apps native per iOS - Lo Stretto Digitale
 
iOS_Course_8
iOS_Course_8iOS_Course_8
iOS_Course_8
 
Spring 2.5
Spring 2.5Spring 2.5
Spring 2.5
 
Making iOS UIKit Simulator for MacOS X
Making iOS UIKit Simulator for MacOS XMaking iOS UIKit Simulator for MacOS X
Making iOS UIKit Simulator for MacOS X
 
Progettazione per Apple Watch - Todi Appy Days 2015
Progettazione per Apple Watch - Todi Appy Days 2015Progettazione per Apple Watch - Todi Appy Days 2015
Progettazione per Apple Watch - Todi Appy Days 2015
 
Wearable Lab: Progettazione per Apple Watch
Wearable Lab: Progettazione per Apple WatchWearable Lab: Progettazione per Apple Watch
Wearable Lab: Progettazione per Apple Watch
 
Applicazioni web con Asp.Net MVC 6
Applicazioni web con Asp.Net MVC 6Applicazioni web con Asp.Net MVC 6
Applicazioni web con Asp.Net MVC 6
 
Webkit meets native development
Webkit meets native developmentWebkit meets native development
Webkit meets native development
 
Spring Framework
Spring FrameworkSpring Framework
Spring Framework
 
Modi innovativi per costruire App
Modi innovativi per costruire AppModi innovativi per costruire App
Modi innovativi per costruire App
 
MVC and Struts 1
MVC and Struts 1MVC and Struts 1
MVC and Struts 1
 
Idiomatic Domain Driven Design
Idiomatic Domain Driven DesignIdiomatic Domain Driven Design
Idiomatic Domain Driven Design
 
Niccolò Becchi: Introduzione a GWT
Niccolò Becchi: Introduzione a GWTNiccolò Becchi: Introduzione a GWT
Niccolò Becchi: Introduzione a GWT
 

Xcode - Just do it

  • 1. Just do it Apriamo Xcode e compiliamo... Stefano Zanetti § The Alchemist
  • 2. Stefano Zanetti  Apple iOS Developer Superpartes Innovation Campus & H-Farm  Co-founder di # Pragma Mark ― www.pragmamark.org  [tt] @stefanozanetti_ [in] Stefano Zanetti [fb] stefano.znt [email] zanetti.stefano@gmail.com iOS Bootcamp
  • 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
  • 16. Xcode iOS Bootcamp
  • 17. Xcode Editor/Builder iOS Bootcamp
  • 18. Xcode Editor/Builder Navigator iOS Bootcamp
  • 19. Xcode Inspector Editor/Builder Navigator iOS Bootcamp
  • 20. Xcode Inspector Editor/Builder Navigator Library iOS Bootcamp
  • 21. Xcode Inspector Editor/Builder Navigator Library Console iOS Bootcamp
  • 22. Xcode Jump Bar Inspector Editor/Builder Navigator Library Console iOS Bootcamp
  • 23. Navigator • Project Navigator (cmd + 1) • Symbol Navigator (cmd + 2) • Search Navigator (cmd + 3) • Issue Navigator (cmd + 4) • Debug Navigator (cmd + 5) • Breakpoints Navigator (cmd + 6) • Log Navigator (cmd + 7) iOS Bootcamp
  • 24. Inspector • File Inspector (alt + cmd + 1) • Quick Help Inspector (alt + cmd + 2) • Identity Inspector (alt + cmd + 3) • Attributes Inspector (alt + cmd + 4) • Size Inspector (alt + cmd + 5) • Connections Inspector (alt + cmd + 6) 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
  • 28. Connettiamo ctrl + click sul controllo + drag 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
  • 30. Connettiamo ctrl + click sul controllo + drag 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
  • 37. Di cosa abbiamo bisogno? • - (id)initWithNibName:(NSString *)nibNameOrNil bundle: (NSBundle *)nibBundleOrNil; • - (void)presentModalViewController:(UIViewController *)modalViewController animated:(BOOL)animated; • - (void)dismissModalViewControllerAnimated:(BOOL)animated; iOS Bootcamp
  • 38. Creare un ViewController PMViewController *controller = [[[PMViewController alloc] initWithNibName:@"PMViewController" bundle:nil] autorelease]; 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
  • 41. Quale transizione utilizzare? // UIModalTransitionStyle: // // UIModalTransitionStyleCoverVertical, // UIModalTransitionStyleFlipHorizontal, // UIModalTransitionStyleCrossDissolve, // UIModalTransitionStylePartialCurl, [controller setModalTransitionStyle:UIModalTransitionStyleCoverVertical]; iOS Bootcamp
  • 42. Utilizziamo il ViewController Presentiamo in modale il ViewController [self presentModalViewController:controller animated:YES]; Rimuoviamo il ViewController [self dismissModalViewControllerAnimated:YES]; iOS Bootcamp
  • 43. Appear/Disappear Gestione visualizzazione view • - (void)viewWillAppear:(BOOL)animated • - (void)viewDidAppear:(BOOL)animated • - (void)viewWillDisappear:(BOOL)animated • - (void)viewDidDisappear:(BOOL)animated • - (void)viewDidLoad • - (BOOL)shouldAutorotateToInterfaceOrientation: (UIInterfaceOrientation)interfaceOrientation iOS Bootcamp
  • 44. Memory Warning! - (void)viewDidLoad - (void)viewWillUnload - (void)didReceiveMemoryWarning iOS Bootcamp
  • 45. UINavigationController Estende la classe UIViewController implementando la navigazione, semplice e veloce, tra ViewControllers iOS Bootcamp
  • 46. Push & Pop Navigazione tra ViewControllers: • - (id)initWithRootViewController:(UIViewController *)rootViewController; • - (void)pushViewController:(UIViewController *)viewController animated:(BOOL)animated; • - (NSArray *)popToViewController:(UIViewController *)viewController animated:(BOOL)animated; • - (NSArray *)popToRootViewControllerAnimated: (BOOL)animated; iOS Bootcamp
  • 47. RootViewController Inizializzazione UINavigationController UIViewController *viewController = [[UIViewController alloc] initWithNibName:@"ViewController" bundle:nil]; UINavigationController *navigationController = [[UINavigationController alloc] initWithRootViewController:viewController]; [viewController release]; 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
  • 50. UITableView Ecco qualche esempio di TableView: 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
  • 52. UITableViewDataSource • Obbligatori • - (NSInteger)tableView:(UITableView *) UITableView numberOfRowsInSection:(NSInteger)section; • - (UITableViewCell *)tableView:(UITableView *) UITableView cellForRowAtIndexPath:(NSIndexPath *)indexPath; • Opzionali • - (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView; • - (NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section; • ... iOS Bootcamp
  • 53. Data Model Definiamo il modello dati #import <UIKit/UIKit.h> @interface PMFATableViewController : UIViewController<UITableViewDataSource, UITableViewDelegate> { UITableView *_tableView; NSArray *_elements; } @property (nonatomic, retain) IBOutlet UITableView *tableView; @property (nonatomic, retain) NSArray *elements; @end iOS Bootcamp
  • 54. Popoliamo l’array di oggetti - (void)viewDidLoad { ! [super viewDidLoad]; ! NSArray *elements = [NSArray arrayWithObjects:@"Objective-C", @"UIViewController", @"UITabBarController", @"UINavigationController", @"UITableView", nil]; ! self.elements = elements; } iOS Bootcamp
  • 55. Configuriamo il DataSource - (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section { ! return [_elements count]; } iOS Bootcamp
  • 56. Configuriamo il DataSource - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath: (NSIndexPath *)indexPath { static NSString *cellIdentifier = @"Cell"; UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:cellIdentifier]; if (cell == nil) { cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:cellIdentifier] autorelease]; } cell.textLabel.text = [_elements objectAtIndex:indexPath.row]; return cell; } 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
  • 60. UITableViewDelegate • - (void)tableView:(UITableView *)tableView willDisplayCell: (UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath; • - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath; • - (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section; • - (UIView *)tableView:(UITableView *)tableView viewForFooterInSection:(NSInteger)section; • - (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath; • ... 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

Notes de l'éditeur

  1. \n
  2. \n
  3. \n
  4. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  5. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  6. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  7. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  8. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  9. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  10. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  11. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  12. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  13. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  14. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  15. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  16. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  17. 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&amp;#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&amp;#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&amp;#x2019;s controller objects and communicate user-initiated changes&amp;#x2014;for example, text entered in a text field&amp;#x2014;through controller objects to an application&amp;#x2019;s model objects.\nController Objects\nA controller object acts as an intermediary between one or more of an application&amp;#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
  18. \n
  19. \n
  20. \n
  21. \n
  22. \n
  23. \n
  24. \n
  25. \n
  26. \n
  27. \n
  28. \n
  29. \n
  30. \n
  31. \n
  32. \n
  33. \n
  34. \n
  35. \n
  36. \n
  37. \n
  38. \n
  39. \n
  40. \n
  41. \n
  42. \n
  43. \n
  44. \n
  45. \n
  46. \n
  47. \n
  48. \n
  49. \n
  50. \n
  51. \n
  52. \n
  53. \n
  54. \n
  55. \n
  56. \n
  57. \n
  58. \n
  59. \n
  60. \n
  61. \n
  62. \n
  63. \n
  64. \n
  65. \n
  66. \n
  67. \n
  68. \n
  69. \n
  70. \n
  71. \n
  72. Grazie mille a tutti.\n\nBuon proseguimento ;)\n