Shouldn't handling taps be done by a view controller?
No. Il controllo del rating è pensato per essere un'unità autonoma. Pensa a un pulsante o a un dispositivo di scorrimento: un pulsante si occupa di evidenziare e ignorare se stesso in risposta ai tocchi e invia messaggi di azione al suo target quando il pulsante cambia stato; un cursore sposta il pollice mentre il tocco si sposta e invia messaggi di azione quando il suo valore cambia. Il controllo del rating è lo stesso.
Se inserisci il codice per gestire l'interazione dell'utente di base nel controller di visualizzazione, dovrai inserire lo stesso codice in ogni controller di visualizzazione che utilizza il controllo delle classificazioni. Ciò non promuove l'affidabilità, la manutenibilità o la facilità d'uso. Poiché il controllo delle classificazioni dovrebbe sempre comportarsi allo stesso modo in risposta agli stessi tocchi, indipendentemente da dove è utilizzato in un'applicazione, ha senso scrivere quel codice una volta nel controllo.
Similarly, the "rating"...for this control is also stored with the view code. Shouldn't the rating be in a Model for this custom control?
Ancora, no. Il controllo deve ricordare la valutazione in modo che sappia quante stelle visualizzare ogni volta che deve ridisegnarsi. Se la vista doveva recuperare la valutazione da una classe del modello per ogni ridisegno, si tratta di molte comunicazioni inutili e, peggio ancora, crea una dipendenza tra la vista e il modello.
Nell'implementazione di MVC da parte di Apple, la vista non conosce nulla sulle classi di modelli, il modello non sa nulla sulle classi di visualizzazione e i controller mediano tra i due. Quando un'app presenta una "scena" o una collezione di viste, il controller della vista otterrà tutte le informazioni che dovrebbero essere visualizzate e configurerà le visualizzazioni che gestisce. Pertanto, il controller di visualizzazione nell'app di esempio potrebbe trovare il valore di valutazione nel modello e passare tale valutazione al controllo di valutazione. Non c'è nulla di male nel controllo del rating ricordando il valore. Se l'utente modifica la valutazione, il controllo invierà un messaggio alla sua destinazione, che normalmente sarà il controller della vista, e il controller della vista può aggiornare il modello. Se qualche altra interazione (come un tocco sul pulsante "record successivo" o qualsiasi altra cosa) fa sì che il controller di visualizzazione mostri altre informazioni, aggiornerà le sue visualizzazioni secondo necessità con i dati del modello appropriati.
Hai ragione che il modello è il luogo in cui deve essere memorizzata la valutazione per un dato record (o qualsiasi cosa venga visualizzata), e il modello è da dove viene il valore, ma è bene che il controllo ne ricordi la sua valore proprio come un cursore memorizza il suo valore o una vista testuale ricorda il suo testo.
Am I misunderstanding how this is all supposed to work?
Penso che tu stia solo cercando di capirlo in termini di altre implementazioni MVC, come quelle che si trovano spesso nei framework web. È difficile mettere da parte i propri preconcetti e osservare come funzionano il modello, la vista e le classi di controller nei framework Apple, ma posso vedere che ci stai provando.
Or is it ok to have model, view, and controller in the same class together?
No, l'intero punto del paradigma MVC è di aiutarti a capire come separare le cose in ruoli distinti. MVC (la versione di Apple, comunque) promuove flessibilità e riusabilità eliminando le dipendenze tra classi di modelli e di visualizzazione. Le classi del modello non dovrebbero preoccuparsi di come i dati che contiene saranno presentati all'utente: l'interfaccia potrebbe essere Cocoa o Cocoa Touch, o un'interfaccia solo testo, o un'interfaccia web, e il modello non dovrebbe cambiare a tutti. Viceversa, i tuoi punti di vista dovrebbero sapere come presentare le informazioni che ti vengono fornite, ma non dovrebbero sapere o preoccuparsi da dove provengono le informazioni o anche ciò che realmente rappresenta. Ad esempio, la proprietà "rating" nel nuovo controllo è in realtà solo un numero che l'utente può impostare con un tocco e nulla nel controllo deve dipendere dal fatto che il numero rappresenti effettivamente una valutazione di qualcosa o di un'altra quantità.
Aggiornamento: ho esaminato il tutorial pochi minuti fa e hai ragione che RatingControl agisce come una vista e un controller, ma lo fa in diversi contesti. Per il controller della vista, RatingControl è solo una vista come qualsiasi altra. Dal punto di vista dei pulsanti all'interno del controllo, però, RatingControl è un po 'come un controller in quanto crea e li gestisce, ed è anche il bersaglio delle azioni dei pulsanti.