Modelli e idiomi comuni in Xamarin.Mac

  • Articolo

In tutte le API Apple esposte tramite C#, alcuni idiomi e modelli arrivano più e più volte. Se si ha esperienza con la programmazione con Xamarin.iOS, questi potrebbero risultare familiari. La documentazione fa spesso riferimento a questi modelli e idiomi ripetutamente, quindi avere una conoscenza approfondita di questi modelli consentirà di avere un senso della documentazione che si trova.

MVC - Model View Controller

Model View Controller, o MVC per brevità, è un modello molto comune trovato in Cocoa. Una discussione dettagliata esula dall'ambito di questo documento, ma in breve è un modo per strutturare l'applicazione in componenti:

  • Gli oggetti modello rappresentano i dati sottostanti visualizzati e modificati (ad esempio indirizzi in una rubrica)
  • Gli oggetti Visualizza gestiscono il disegno di un determinato oggetto sullo schermo e gestiscono l'interazione dell'utente (campo di testo che mostra l'indirizzo sullo schermo)
  • Gli oggetti controller gestiscono l'interazione tra Model e View. Esegue il push delle modifiche del modello "su" per aggiornare la visualizzazione ed eseguire il push delle modifiche dalla visualizzazione quando gli utenti apportano modifiche nell'interfaccia utente.

Se si ha familiarità con MVVM (Model View ViewModel) da altre librerie, ad esempio WPF, il controller agisce in modo simile a ViewModel, ma è spesso più strettamente associato agli elementi specifici dell'interfaccia utente.

Altre informazioni dettagliate sono disponibili qui:

Origine dati/delegato/sottoclasse

Un altro modello molto comune in Cocoa riguarda la fornitura di dati agli elementi dell'interfaccia utente e la reazione alle interazioni dell'utente. Usando NSTableView come esempio, è necessario fornire in qualche modo i dati per ogni riga, alcuni set di elementi dell'interfaccia utente che rappresentano tale riga, alcuni set di comportamenti per reagire alle interazioni dell'utente e possibilmente una certa quantità di personalizzazione. I modelli di origine dati e delegato consentono di gestire la maggior parte dei casi senza dover ricorrere alla sottoclasse NSTableView .

  • Alla DataSource proprietà viene assegnata un'istanza di una sottoclasse personalizzata di NSTableViewDataSource cui viene chiamato per popolare la tabella con i dati (tramite GetRowCount e GetObjectValue).

  • Alla Delegate proprietà viene assegnata un'istanza di una sottoclasse personalizzata di NSTableViewDelegate che fornisce la visualizzazione per un determinato oggetto modello (tramite GetViewForItem) e gestisce le interazioni dell'interfaccia utente (tramite , MouseDownInHeaderOfTableColumne così viaDidClickTableColumn).

In alcuni casi, è possibile personalizzare un controllo in modo da evitare gli hook specificati nel delegato o nell'origine dati ed è possibile sottoclassare direttamente la vista. Prestare attenzione, tuttavia, in molti casi l'override del comportamento predefinito richiederà quindi di gestire tutto questo comportamento manualmente (la personalizzazione del comportamento di selezione potrebbe richiedere l'implementazione di tutti i comportamenti di selezione manualmente).

In Xamarin.iOS alcune API, ad esempio UITableView sono state estese con una proprietà che implementa sia il delegato che l'origine dati (UITableViewSource). In questo modo è possibile aggirare la limitazione comune che una singola classe C# può avere una sola classe di base e la visualizzazione dei protocolli viene eseguita tramite classi di base.

Per altre informazioni sull'uso delle tabelle VIews in un'applicazione Xamarin.Mac, vedere la documentazione di Visualizzazione tabelle.

Protocolli

I protocolli in Objective-C possono essere confrontati con le interfacce in C# e in molti casi vengono usati in situazioni simili. Ad esempio, l'esempio NSTableView precedente, sia il delegato che l'origine dati sono effettivamente protocolli. Xamarin.Mac espone queste classi come classi di base con metodi virtuali di cui è possibile eseguire l'override. La differenza principale tra interfacce e Objective-C protocolli C# consiste nel fatto che alcuni metodi in un protocollo possono essere facoltativi da implementare. È necessario esaminare la documentazione e/o la definizione di un'API per determinare cosa è facoltativo.

Per altre informazioni, vedere la documentazione relativa a delegati, protocolli ed eventi .