Ich denke, es ist für Community-Mitarbeiter hilfreich, wenn das Xamarin.Forms-Team weitere Dokumente über die Xamarin.Forms-Architektur, das Designprinzip und den Workflow in Github oder MS-Dokumenten aufschreibt.
Aus meiner Sicht verwende ich Xamarin.Forms, um meine Produkte zu erstellen. Ich habe 2 Möglichkeiten, wenn ich die Fehler treffe, eines ist das Senden des Problems an Github und das Warten darauf, dass es eines Tages behoben wird, und das andere ist das Senden des Problems an Github und habe es selbst behoben.
Nach dem Klonen des Quellcodes und dem Debuggen ist es schwer zu verstehen, wie die Funktionen funktionieren. Zum Beispiel https://github.com/xamarin/Xamarin.Forms/issues/8521
Ein weiteres Beispiel ist das Seitennavigationsfeature von Xamarin.Forms auf Android-Seite. Die Navigationsfunktion zwischen den Aktivitäten auf Native Android ist leicht zu verstehen. Aber auf Xamarin.Forms scheint es eine Hauptaktivität zu verwenden, um (vielleicht) alle Seiten zu verarbeiten (außer den nativen Formularen und der nativen Ansicht).

Ich denke, das ist großartig.

Die Aufteilung der Galerie und der Vitrinen für Spezifikationen/Probleme usw. in kleinere Projekte, die leichter bearbeitet und präsentiert werden können, ist ein großer Vorteil im Entwicklungszyklus.

Eines der problematischsten Dinge ist es, mehrere verschiedene Versionen zu haben, in denen Fehler behoben oder Funktionen eingeführt und dann, wenn sie weitergehen, verbessert werden.
Mehrere kleinere Instanzen zu haben, hilft dabei sehr.

Eine andere Sache, an die ich denke, ist die Verwendung von Codespaces und in Zukunft Github-Codespaces, bei denen man Punktdateien für ein Problem anhängen kann (einschließlich der richtigen xamarin-Version usw.) und dann könnten wir einfach Codespaces verwenden oder diese Version auschecken.

Am besten wäre es, wenn die kleineren Control-Galerie-Teile dann als separat erhältliche Projekte vorliegen und einfach in Codespaces geöffnet werden können. Ich sehe viele Vorteile in der Kombination kleinerer Control-Apps und Codespaces.

Ich denke, was ich damit sagen will ist:

• Mehrteilige Kontrollgalerie
• Codespace-Unterstützung
• Punktdateien im Problem

Edit: dritten Punkt hinzugefügt.

Ich stimme zu, dass ich seit Monaten einige Probleme am Stück offen habe. Ich habe XF geklont, aber ich verliere mich einfach darin.
Ein Dokument für ein Video, das nur zeigt, wie die Lösung funktioniert, wäre also großartig.

Je mehr .Netty dies sein kann, desto besser.

1. Entfernen Sie magische Zeichenfolgen und untypisierte Bindungen aus dem Kern. Verlangen Sie nicht, dass jemand, der zum Repository beiträgt, eine nicht typisierte Bindung oder eine nicht typgeprüfte Zeichenfolge schreibt. Dadurch werden Fehler drastisch reduziert, das Beheben von Fehlern erheblich erleichtert und das Refactoring erleichtert, sodass keine neuen Fehler auftauchen.
2. Erfordern Sie nicht, dass Mitwirkende sich mit Markup-Layern befassen. Einige Entwickler möchten XAML oder CSS verwenden, aber Mitwirkende, die Fehler beheben, sollten sich nicht um diese Dinge kümmern. Nur Leute, die an Markup-Sprachen arbeiten, die eine Schicht über den echten .Net-Klassen sein sollten, sollten sich um diese Schicht kümmern.
3. Der Renderer-Ansatz sollte so strukturiert sein, dass das Versäumnis, eine Eigenschaftsänderung (oder ein Typfehler dabei wie oben) zu implementieren, ein Typfehler ist.
4. Gegebenenfalls sollte es eine Toleranz für die Implementierung einiger Features ohne plattformspezifische Bindungen geben, z. B. die Verwendung von SkiaSharp oder Shapes oder zusammengesetzten MAUI-Objekten, für zuverlässige plattformübergreifende Implementierungen, die dasselbe anzeigen und keine neuen Fehler einführen.

An einem Punkt haben wir eine Richtung getestet, in der Benutzer mit einem vereinfachten SLN dazu beitragen können

https://github.com/PureWeen/Xamarin.Forms.Sandbox

Geben Sie einfach eine sehr gezielte "Contributor.sln" an, in der Mitwirkende einen Fix oder eine API demonstrieren können

Entferne alle aktuellen Galerien und konzentriere sie einfach auf die Plattformen und eine MainPage

Wäre ein Lösungsfilter besser? Sie müssen nicht zwei Lösungen pflegen.

Wir werden sehen, was alles mit Solution Filters entwickelt wird

AFAIK funktioniert derzeit nicht auf vsmac und sie sind ein bisschen seltsam, wenn Sie Projekte mit mehreren Zielen haben. Sobald wir eine erstklassige Unterstützung für Multi-Targeting haben und die Hauptprojekte nur im SDK-Stil sein können, denke ich, dass der Bedarf an Lösungsfiltern nicht mehr so ​​hoch ist.

Die andere nervige Sache ist, dass VS für Windows derzeit alle Ziele erstellt, wenn Sie Multi-Targeting haben, während vsmac nur das für den Plattformkopf erstellt, den Sie ausführen.

Die andere nervige Sache ist, dass VS für Windows derzeit alle Ziele erstellt, wenn Sie Multi-Targeting haben, während vsmac nur das für den Plattformkopf erstellt, den Sie ausführen.

Unterstützung dafür in VS für Windows zu bekommen wäre großartig! Ich könnte all diese zusätzlichen Konfigurationen loswerden, die ich gemacht habe, um nur die Plattform zu erstellen, mit der ich gerade arbeite.

Stimmen Sie zu, dass die aktuelle Multi-Targeting-Story zu VS für Mac unglaublich frustrierend ist. Leider ist Multi-Targeting eine so großartige Option, dass ich es immer noch als meinen Ansatz wähle und nur als technischer Support für andere im Team fungiere, die auf Probleme stoßen. Es ist ein nie endender Strom der Frustration.