Gängige Muster und Redewendungen in Xamarin.Mac
In den Apple-APIs, die über C# verfügbar gemacht werden, treten bestimmte Redewendungen und Muster immer wieder auf. Wenn Sie Erfahrung mit der Programmierung mit Xamarin.iOS haben, können diese vertraut sein. In der Dokumentation werden diese Muster und Redewendungen häufig wiederholt behandelt, sodass Ein fundiertes Verständnis dieser Muster Ihnen hilft, die von Ihnen gefundene Dokumentation zu verstehen.
MVC – Modellansichtscontroller
Der Modellansichtscontroller, kurz MVC, ist ein sehr gängiges Muster in Cocoa. Eine ausführliche Diskussion überschreitet den Rahmen dieses Dokuments, ist aber kurz gesagt eine Möglichkeit, Ihre Anwendung in Komponenten zu strukturieren:
- Modellobjekte stellen die zugrunde liegenden Daten dar, die angezeigt und bearbeitet werden (Ähnliche Adressen in einem Adressbuch)
- Ansichtsobjekte behandeln die Zeichnung eines bestimmten Objekts auf dem Bildschirm und die Behandlung von Benutzerinteraktionen (Ein Textfeld, das die Adresse auf dem Bildschirm anzeigt)
- Controllerobjekte behandeln die Interaktion zwischen dem Modell und der Ansicht. Sie pushen Modelländerungen "nach oben", um die Ansicht zu aktualisieren, und pushen "nach unten", wenn Benutzer Änderungen auf der Benutzeroberfläche vornehmen.
Wenn Sie mit MVVM (Model ViewModel) aus anderen Bibliotheken wie WPF vertraut sind, verhält sich der Controller ähnlich wie das ViewModel, ist aber häufig enger an die spezifischen Ui-Elemente gebunden.
Weitere Details finden Sie hier:
Datenquelle/Delegat/Unterklassen
Ein weiteres sehr häufiges Muster in Cocoa betrifft die Bereitstellung von Daten für Benutzeroberflächenelemente und das Reagieren auf Benutzerinteraktionen. Als NSTableView
Beispiel müssen Sie die Daten für jede Zeile, einen Satz von UI-Elementen, die diese Zeile darstellen, einige Verhaltensweisen für die Reaktion auf Benutzerinteraktionen und möglicherweise eine gewisse Anpassung bereitstellen. Mit den Datenquellen- und Delegatmustern können Sie die meisten Fälle verarbeiten, ohne sich selbst unterklassig NSTableView
machen zu müssen.
Der
DataSource
-Eigenschaft wird eine instance einer benutzerdefinierten Unterklasse zugewiesen, von derNSTableViewDataSource
aufgerufen wird, um die Tabelle mit Daten aufzufüllen (überGetRowCount
undGetObjectValue
).Der
Delegate
-Eigenschaft wird eine instance einer benutzerdefinierten Unterklasse zugewiesen, dieNSTableViewDelegate
die Ansicht für ein bestimmtes Modellobjekt (überGetViewForItem
) bereitstellt und Benutzeroberflächeninteraktionen (überDidClickTableColumn
,MouseDownInHeaderOfTableColumn
usw.) verarbeitet.
In einigen Fällen möchten Sie ein Steuerelement über die im Delegaten oder der Datenquelle angegebenen Hooks hinaus anpassen, und Sie können die Ansicht direkt unterklassieren. Seien Sie jedoch vorsichtig, in vielen Fällen erfordert das Außerkraftsetzen des Standardverhaltens, dass Sie das gesamte Verhalten selbst behandeln müssen (das Anpassen des Auswahlverhaltens erfordert möglicherweise, dass Sie alle Auswahlverhalten selbst implementieren müssen).
In Xamarin.iOS wurden einige APIs, z UITableView
. B. um eine Eigenschaft erweitert, die sowohl den Delegaten als auch die Datenquelle implementiert (UITableViewSource
). Damit wird die allgemeine Einschränkung umgegangen, dass eine einzelne C#-Klasse nur eine Basisklasse haben kann und die Darstellung von Protokollen über Basisklassen erfolgt.
Weitere Informationen zum Arbeiten mit Tabellen-VIews in einer Xamarin.Mac-Anwendung finden Sie in der Dokumentation zur Tabellenansicht .
Protokolle
Protokolle in Objective-C können mit Schnittstellen in in C# verglichen werden und werden in vielen Fällen in ähnlichen Situationen verwendet. Im obigen NSTableView
Beispiel sind sowohl der Delegat als auch die Datenquelle tatsächlich Protokolle. Xamarin.Mac macht diese als Basisklassen mit virtuellen Methoden verfügbar, die Sie überschreiben können. Der Hauptunterschied zwischen C#-Schnittstellen und Objective-C -Protokollen besteht darin, dass einige Methoden in einem Protokoll optional implementiert werden können. Sie müssen sich die Dokumentation und/oder Definition einer API ansehen, um zu ermitteln, was optional ist.
Weitere Informationen finden Sie in unserer Dokumentation zu Delegaten, Protokollen und Ereignissen .