7049 brauchte mehr als 1 Monat für die Einführung, selbst wenn die PR 7 Tage nach dem Fehlerbericht zusammengeführt wurde

Und das Öffnen eines Pull-Requests kann immer noch dazu führen, dass der Request in der Schwebe stecken bleibt, bis ein Beamter von Xamarin sich die Zeit nimmt, sich die geänderten Dateien anzusehen.

Hoffentlich hat das Team einen Plan, um einige der Engpässe rund um den PR + Veröffentlichungsprozess zu beseitigen.

Und das Öffnen eines Pull-Requests kann immer noch dazu führen, dass der Request in der Schwebe stecken bleibt, bis ein Beamter von Xamarin sich die Zeit nimmt, sich die geänderten Dateien anzusehen.

Und sehen Sie sich das an, nachdem jemand aus dem Xamarin.Forms-Team in einem Problem mit hoher Sichtbarkeit erwähnt wurde, antwortete schließlich auf https://github.com/xamarin/Xamarin.Forms/pull/7728.

Und das Öffnen eines Pull-Requests kann immer noch dazu führen, dass der Request in der Schwebe stecken bleibt, bis ein Beamter von Xamarin sich die Zeit nimmt, sich die geänderten Dateien anzusehen.

Und sehen Sie sich an, dass jemand aus dem Xamarin.Forms-Team nach einer Erwähnung in einem Problem mit hoher Sichtbarkeit endlich auf xamarin/Xamarin.Forms#7728 geantwortet hat.

Ich fühle mit dem Team. So viele Probleme sind nicht einfach zu sortieren/zu verwalten/zu beheben. Allerdings muss man sich definitiv darauf konzentrieren, Engpässe zu beseitigen und die offenen Fragen und PRs zu bereinigen.

Zugegeben, Qualität war schon immer ein Problem für jeden Aspekt der Xamarin-Entwicklung. Oft bin ich frustriert wegen Inkompatibilitäten zwischen den Komponenten, nicht funktionierendem Build in VS oder meiner App, die nach einem Update auf die neue Version von Forms abstürzt. Das Zeug sollte einfach funktionieren. Ich sollte nicht gezwungen sein, mein Layout zum dritten Mal neu zu erstellen, weil einige Steuerelemente oder Layouts einfach nicht gut zusammenarbeiten.

Ich sehe ein paar verwandte Punkte

1) Ich weiß nicht, wie viele Leute an Forms arbeiten, aber für mich sieht es so aus, als ob das Team zu klein ist, um mit dem schnell wachsenden Tempo neuer Bugs oder PRs Schritt zu halten. Dies wird nur noch schlimmer, da sie die Aufmerksamkeit zwischen Forms und Maui aufteilen müssen. Ich hoffe wirklich, dass das Team bald einen erheblichen Schub bekommt.

2) Es wäre wirklich hilfreich, wenn Microsoft damit beginnen würde, Forms tatsächlich in ihren eigenen Apps zu verwenden. Und damit meine ich nicht einfache Demo- oder Konferenz-Apps. Ich meine echte Apps wie Teams oder Outlook. Ich würde mich freuen, wenn ich mich hier irre, aber ich habe es nicht geschafft, eine MS Forms-App in den Stores zu finden und laut einer Quelle wie diesem Tweet https://twitter.com/safaiyeh/status/1219294459298344961 verwenden sie hauptsächlich reagieren einheimisch.

• das sendet wirklich kein gutes Signal, denn wenn MS nicht ihre eigene Technologie (XF) verwendet, warum sollten wir dann?

• Die interne Verwendung von Formularen in komplexen Apps könnte eine zusätzliche Testebene sein und die Anzahl der Probleme reduzieren, die in der öffentlichen Veröffentlichung auftreten. Außerdem konnten sie sehen, dass die Arbeit mit Formularen nicht so einfach ist, wie sie uns erzählen

3) Ein weiteres Problem sehe ich darin, dass MS ständig versucht, das Rad in Form von XF Xaml neu zu erfinden, anstatt bereits bewährte und bestehende Lösungen wie Win UI Xaml zu verwenden. Sie müssen Zeit in die Entwicklung bereits vorhandener Features und in die Behebung von dadurch eingeführten Fehlern investieren und dann bleibt weniger Zeit für andere Features und Bugfixes.

Ich stimme @Reveon zu 100% zu
Oh, und ich muss sagen, dass die Verwendung von VisualStudio für Windows mit Xamarin eine sehr frustrierende Erfahrung ist.

Sie fügen ständig herausragende, blockierende, Bugs hinzu ... ich weiß nicht einmal, wie das möglich ist (Dinge wie das Brechen ALLER iOS-Geräte-Builds, das Brechen von Provisioning-Profilen, das Brechen der Gestenerkennung ... wie können solche Bugs in die Produktion gehen und dann? dauert es Wochen oder Monate, um im Release-Build behoben zu werden? keine Ahnung ....)

Dafür bin ich auf Rider umgestiegen und verwende jetzt überall Jetbrains-Produkte :) Zumindest kann ich eine IDE verwenden, die in iOS & Windows genau gleich ist und weiterhin produktiv arbeiten.

Ich bin mir sicher, dass sich mit MAUI solche Dinge ändern werden, und früher oder später wird Microsoft anfangen, MAUI intern für ernsthafte Projekte zu verwenden

Ein weiteres Zeugnis:
https://github.com/xamarin/Xamarin.Forms/issues/10482#issuecomment -633730446
@EmilAlipiev :

Ich habe 1,5 Monate darauf gewartet, dass mein PR für diese Ausgabe zusammengeführt wird. Es gibt bereits ein bestehendes Problem für Ios und Android, das im Juli 2019 behoben wurde und niemand für uwp angerührt wurde. Ich habe im April behoben und mehrmals um Überprüfung und Zusammenführung gebeten. Es ist wirklich ärgerlich, wie xamarin-Teams arbeiten. Sie können sehen, dass sie nur 1-2 PRs pro Tag überprüfen.
#10316

Obwohl ich oft frustriert bin, ist "Xamarin ist fehlerhaft" eine harte Aussage. 2000+ offene Probleme heute, wenn Sie überprüfen, ob flatter mehr als 5000 offene Probleme hat. Zahlen sind nicht so wichtig. xamarin.forms bietet mehr als andere Cross-Plattformen wie uwp (einschließlich xbox), wpf, mac, gtk, tizen. So gibt es zum Beispiel bei Wpf viele offene Fragen, die für die meisten von uns weniger Priorität haben.
Kern von xamarin.forms sollten ios, android und uwp sein, obwohl das xamarin-Team uwp oft vernachlässigt.

1. Es sollten Kernelemente wie Layouts, Listenansichten, Karussell, Sammlungsansicht, Bilder, Karten, Label, Editor usw. vorhanden sein. Diese sollten fehlerfrei sein. Wenn Sie eine neue Version erstellen oder diese aktualisieren, müssen Sie sicherstellen, dass kein Showstopper-Bug vorliegt. Wenn es einen Fehler gibt, müssen Sie ihn innerhalb von maximal einer Woche beheben. Aber das Xamarin-Team veröffentlicht dieses coole "4.5-4.6" mit coolen Funktionen (wer braucht dieses schicke Tool 10% der Community?) und die Bildkontrolle ist kaputt. Problem wurde Anfang März gemeldet und bis heute nicht behoben. Dasselbe "In native Assemblys bündeln" ist defekt. Aus diesen entscheidenden Gründen kann ich nicht auf 4.5 und 4.6 upgraden. Sie entwickeln sich weiter und 4.7 fügt neue Funktionen hinzu. Ich und die meisten von uns behalten die Versionshinweise im Auge, ob unsere Fehler behoben sind, ich lese nicht einmal mehr, welche Funktion hinzugefügt wurde.
2. Das Xamarin-Team muss dies verstehen. Der wichtigste Grund, warum sich viele Leute für Xamarin entscheiden, ist "UWP". Ich bin Freiberufler. Ich frage meinen Kunden, warum nicht flattern oder nativ reagieren? Er sagt, weil Xamarin über UWP verfügt. Ich möchte auch UWP. Aber Uwp ist mit xamarin.forms meistens fehlerhaft. Sie haben CollectionView eingeführt, es ist wirklich großartig, aber seit einem Jahr ist dieser Fehler nicht behoben. Ich habe es behoben, niemand rezensiert. Ich war entmutigt, weitere Beiträge zu leisten.
3. Hotreload funktioniert überhaupt nicht. Ich habe auf Twitter alle "Kusskusse" gelesen, wie toll hotreaload ist. Ich denke, mit mir sollte etwas nicht stimmen oder sie verwenden ein anderes Tool. Denn oft aktualisiert Hotreload nicht. Ich verwende immer noch Tools von Drittanbietern wie Livexaml usw. Ich habe sogar eine einfache Konsolenanwendung erstellt, um meinen eigenen Hotreload durchzuführen. kostet mich 1 Tag. Funktioniert viel besser als die von Xamarin und funktioniert sogar für uwp. Wie können sie es nicht liefern? Sie hatten Leberlast arbeitete.

4. Wichtigster Punkt; was @Reveon erwähnt hat. Sie benötigen eine echte Unternehmensanwendung, die mit xamarin.forms funktioniert, und sie sollten sie mit neuen Versionen aktualisieren, um echte Probleme zu erkennen. Sie beschweren sich, dass "es nicht so schwer ist, Repro zu geben". Ja, es ist sehr schwierig, wenn dieses Problem nur bei Ihrer Unternehmensanwendung auftritt, nicht bei einer Todo-App. Sie müssen versuchen, dieselbe Benutzeroberfläche zu replizieren. Es kann Ihre Tage kosten, bis Sie es herausfinden. Deshalb ist es sehr wichtig, dass es jemanden gibt, der eine große Bewerbung hat. Ich frage mich wirklich, ob einer dieser Xamarin-Entwickler, die wir auf Twitch, YouTube, Twitter usw. sehen, jemals eine große Anwendung mit xamarin.forms entwickelt hat.

5. Ich muss etwas zugeben, obwohl ich nicht gerne Nicht-Open-Source-Tools verwende, sind mehr als 50% meiner Apps mit Syncfusion-Tools. Ohne Syncfusion denke ich, dass es so schwer ist, eine funktionierende Unternehmensanwendung zu bekommen. Sie haben alles, was Xamarin nicht hat oder was Xamarin-Buggy ist. Zum Beispiel suchte ich jahrelang nach einem Ersatz für sfListView mit Drag & Drop, Swipe-Ansicht, Linear- und Rasterlayout, besserer Virtualisierung usw. Schließlich kam xamarin mit CollectionView heraus und sie warfen es uns als "coole Version" von Listview ins Gesicht, aber dann ist es es buggy. Funktioniert nicht für Uwp. viele fehlende Funktionen. Suchen Sie einfach innerhalb der Ausgaben nach CollectionView, Sie werden Dutzende davon sehen.

Ich glaube immer noch daran, dass Xamarin das beste Tool für Cross-Plattform ist und ich hoffe, dass sie dieses Problem als konstruktives Feedback auffassen.

Bisher tolle und konstruktive Kommentare. Ich las die Liste und fühlte mich genauso wie die anderen Entwickler. Die Probleme treten bei denen von uns häufig auf, die Xamarin.Forms zum Entwickeln von Unternehmens-Apps verwenden. Die Fehlerverfolgung und -behebung erfordert mehr Aufmerksamkeit, aber insbesondere ein klarer Punkt, und ich habe mich oft gefragt, warum es keine MS-Unternehmensanwendung gibt, die mit Xamarin.Forms erstellt wurde. MS Teams oder andere. Wenn die Antwort lautet: mit Xamarin.Forms viel zu kompliziert oder unmöglich, gibt es einen großartigen internen Einblick, um die Plattform als Ganzes zu verbessern und zu versuchen, diese Probleme zu beheben. Xamarin/MAUI wird sicherlich gewinnen, wenn mehr Entwickler testen, beitragen und die Nachricht verbreiten, aber dies sollte eine Einbahnstraße sein. Auch hier beschwere ich mich nicht, aber es wäre großartig, dieses Jahr, nächstes Jahr, eine großartige MS-Version einer mobilen Anwendung zu sehen, die mit MAUI oder Xamarin erstellt wurde. Überprüfen Sie auch die Entwickler auf ihre Frustrationen oder mögliche Verbesserungen und bringen Sie die plattformübergreifende Entwicklung auf ein neues Niveau.

Denn ich wurde erwähnt...

Ich leite ein kleines Projekt für eine plattformübergreifende Anwendung zwischen Android und Windows Desktop (WPF).

Wir haben viele Bugs gefunden, an denen wir eine Runde arbeiten oder beheben mussten. Derzeit starte ich ein internes Projekt für die Fixes und Performance-Verbesserungen, da das Teilen unserer Lösungen mit diesem langsamen Fortschritt unmöglich ist. Wir haben auch Deadlines.

Bugs in die offizielle Pipeline zu bringen ist für unser kleines Team sehr teuer , daher wäre es schön , mehr Aufmerksamkeit zu bekommen, vielleicht bekommst du mehr von der Community.

Im wpf-Teil von xamarin ist viel zu tun. Die Leistung ist schlecht und es ist die Hölle von einfachen Fehlern. Aber die Idee dahinter und die Basis sind gesetzt. Es ist traurig, den aktuellen Zustand zu sehen, denn er könnte viel besser sein...

Zugegeben, Qualität war schon immer ein Problem für jeden Aspekt der Xamarin-Entwicklung. Oft bin ich frustriert wegen Inkompatibilitäten zwischen den Komponenten, nicht funktionierendem Build in VS oder meiner App, die nach einem Update auf die neue Version von Forms abstürzt. Das Zeug sollte einfach funktionieren. Ich sollte nicht gezwungen sein, mein Layout zum dritten Mal neu zu erstellen, weil einige Steuerelemente oder Layouts einfach nicht gut zusammenarbeiten.

Ich sehe ein paar verwandte Punkte

1. Ich weiß nicht, wie viele Leute an Forms arbeiten, aber für mich sieht es so aus, als ob das Team zu klein ist, um mit dem schnell wachsenden Tempo neuer Bugs oder PRs Schritt zu halten. Dies wird nur noch schlimmer, da sie die Aufmerksamkeit zwischen Forms und Maui aufteilen müssen. Ich hoffe wirklich, dass das Team bald einen erheblichen Schub bekommt.
2. Es würde wirklich helfen, wenn Microsoft anfangen würde, Forms tatsächlich in ihren eigenen Apps zu verwenden. Und damit meine ich nicht einfache Demo- oder Konferenz-Apps. Ich meine echte Apps wie Teams oder Outlook. Ich würde mich freuen, wenn ich mich hier irre, aber ich habe es nicht geschafft, eine MS Forms-App in den Stores zu finden und laut einer Quelle wie diesem Tweet https://twitter.com/safaiyeh/status/1219294459298344961 verwenden sie hauptsächlich reagieren einheimisch.

• das sendet wirklich kein gutes Signal, denn wenn MS nicht ihre eigene Technologie (XF) verwendet, warum sollten wir dann?
• Die interne Verwendung von Formularen in komplexen Apps könnte eine zusätzliche Testebene sein und die Anzahl der Probleme reduzieren, die in der öffentlichen Veröffentlichung auftreten. Außerdem konnten sie sehen, dass die Arbeit mit Formularen nicht so einfach ist, wie sie uns erzählen

1. Ein weiteres Problem sehe ich darin, dass MS ständig versucht, das Rad in Form von XF Xaml neu zu erfinden, anstatt bereits bewährte und bestehende Lösungen wie Win UI Xaml zu verwenden. Sie müssen Zeit in die Entwicklung bereits vorhandener Features und in die Behebung von dadurch eingeführten Fehlern investieren und dann bleibt weniger Zeit für andere Features und Bugfixes.

Ich stimme vielen der von Ihnen genannten Probleme zu. Microsoft muss auf jeden Fall eine Unternehmens-App mit Xamarin Forms oder iOS oder Android erstellen. Sobald sie ein funktionierendes Beispiel für eine Unternehmens-App haben, können wir uns nicht darüber beschweren, dass die Erstellung professioneller Apps frustrierend ist.

Xamarin Forms ist ein großartiges plattformübergreifendes Framework für diejenigen, die eine App einmal erstellen und überall arbeiten möchten. Es funktioniert hervorragend, wenn Sie einfache Apps erstellen. Aber sobald Sie anfangen, eine professionellere App mit mehr Funktionen wie Animationen, segmentierten Registerkarten, Datenvirtualisierung, komplexen Layouts usw. zu erstellen, kämpfen Sie immer mehr gegen das Framework, um eine Funktion zum Laufen zu bringen. Ich finde, dass einfache Dinge, die funktionieren sollten, entweder nicht offensichtlich sind oder Hacks erfordern, damit es funktioniert.

Features wie Xamarin Hot Reload befinden sich noch in der Entwicklungsphase. Wenn ich beispielsweise eine Stiländerung in der App.xaml oder einem Ressourcenwörterbuch vornehme, auf das von App.xaml verwiesen wird, wo ich meine Stile und Ressourcen speichere, wird Hot Reload das Layout der App im Simulator durcheinander bringen oder das App zum Absturz.

Ich finde, dass Visual Studio beim Entwickeln von Xamarin-Apps unglaublich fehlerhaft ist. Wenn Sie beispielsweise mein Android-Projekt als Startprojekt ausgewählt haben, damit testen und dann zu meinem iOS-Projekt als Startprojekt wechseln, werden alle Arten von falschen Fehlern angezeigt. Das Zerstören der bin- oder obj-Ordner hilft nicht. Ich muss VS neu starten. In einem anderen Beispiel verliert VS zufällig die Verbindung zu meinem Mac, während ich meine App debugge. Es wird dazu führen, dass mein VS einfriert. Ich werde einen Wutanfall bekommen, mein Hobby und mein Leben als mobiler Entwickler in Frage stellen und VS mit dem Task-Manager töten. Außerdem stelle ich fest, dass zukünftige Versionen von Visual Studio Fehler wieder einführen, die in früheren Versionen behoben wurden. Ich weiß nicht, wie man eine frühere Version von VS installiert, nachdem die neueste Version veröffentlicht wurde und ich sie installiere. Ich kann es deinstallieren und versuchen, es mit dem Installationsprogramm neu zu installieren, aber es wird immer die neueste Version installiert. Es ist nicht wie ein NuGet-Paket, bei dem Sie eine beliebige Version installieren können.

Warum ist ein segmentiertes Registerkartensteuerelement nicht bereits Teil des Xamarin-Toolkits? Segmentierte Registerkarten werden fast überall verwendet. Ich sollte nicht das Syncfusion-Toolkit oder ein anderes Toolkit verwenden müssen, um ein so häufiges Steuerelement zu verwenden.

Ich bin nervös, MAUI zu verwenden, wenn es in einer professionellen App herauskommt, die ich entwickle, bis viele dieser Entwicklerfrustrationen mit Xamarin und Visual Studio behoben sind. Ich werde damit spielen und experimentieren, wenn es herauskommt. Aber ich werde selbstbewusster, wenn Microsoft herauskommt und eine Unternehmens-App mit MAUI entwickelt, anstatt einfache Demo-Apps zu erstellen.

Kann uns jemand über die Roadmaps von Xamarin Forms und MAUI aufklären? Werden sie parallel gepflegt? Gibt es einen harten Stopp für die Unterstützung von Xamarin Forms und wird Microsoft MAUI in einem zukünftigen Visual Studio-Update in den Rachen stecken?

Dankeschön

@SunnyMukherjee Aus den FAQ,

Wie sieht die Zukunft von Xamarin.Forms aus?

Die nächste Hauptversion von Xamarin.Forms wird etwa im September 2020 erscheinen und durch die Veröffentlichung von .NET MAUI mit .NET 6 weiter aktualisiert werden. Danach wird Xamarin.Forms für 12 Monate weiterhin vorrangig gewartet.

Grundsätzlich wird Xamarin.Forms nach Version 5 beendet.

@SunnyMukherjee Aus den FAQ,

Wie sieht die Zukunft von Xamarin.Forms aus?

Die nächste Hauptversion von Xamarin.Forms wird etwa im September 2020 erscheinen und durch die Veröffentlichung von .NET MAUI mit .NET 6 weiter aktualisiert werden. Danach wird Xamarin.Forms für 12 Monate weiterhin vorrangig gewartet.

Grundsätzlich wird Xamarin.Forms nach Version 5 beendet.

Bis Mitte 2021. . . Wenn Covid mich nicht vorher umbringt, werden entweder Maui oder Xamarin Forms die Arbeit erledigen.

@SunnyMukherjee Ich höre deinen Schmerz. Ich verwende Xamarin.Forms seit seiner ersten Veröffentlichung, und es hat sich seitdem entwickelt. Denken Sie daran, dass Microsoft Xamarin.Forms nicht erstellt hat, sondern erst 2018 gekauft hat. MAUI ist also das Projekt von Microsoft, um es besser umzuschreiben und nahtlos mit dem gesamten .net zusammenzuarbeiten. Das Arbeiten mit Xamarin.Forms ist nicht trivial, da es nicht trivial ist. Viele Leute sagen, sie sollten einfach das tun, was Uno oder Flutter getan haben, und die Steuerelemente vollständig selbst erstellen - aber das ist gegen das, was Xamarin.Forms ist. Es handelt sich um ein natives Entwicklungs-Framework, bei dem die nativen Steuerelemente auf eine gemeinsame Weise verfügbar gemacht werden. Das ist keine kleine Aufgabe. Ich hatte auch viele Probleme mit Xamarin.Forms, aber insgesamt überwiegt die Zeitersparnis durch die Verwendung, anstatt dieselbe App in mehreren Sprachen zu schreiben, die Probleme bei weitem. Darüber hinaus lohnt es sich noch mehr, 90% des Codes mit den Backend-ASP.Net-Kernprojekten teilen zu können.
Es ist zwar wichtig, Microsoft mitzuteilen, was wir von MAUI wollen – aber wir müssen verstehen, dass es keine leichte Aufgabe für sie ist, und ich hoffe, dass MAUI ein großer Schritt in die richtige Richtung sein wird.
Sehen Sie sich dieses Video aus dem kürzlich erstellten MAUI der Demo an und erklärt, wie es in die Roadmaps passt und was sie in der Zwischenzeit auf Xamarin.Forms tun und unterstützen werden:
https://channel9.msdn.com/Events/Build/2020/BOD106?ocid=AID3012654&WT.mc_id=Build2020_pmmsocialblog

Beim Lesen hier frage ich mich, was ich hier lernen kann, um die Qualität von Xamarin.Forms zu verbessern. Ich würde gerne auf die ursprüngliche Frage von @Happypig375 zurückkommen :

Irgendwelche Gedanken zur Verbesserung?

Eines unserer Hauptziele bis zur Auslieferung von .NET MAUI ist die Verbesserung der Grundlage und des Ausgangspunkts. Aus diesem Grund verbringen wir einen Großteil unserer aktuellen Sprints mit CollectionView-Problemen und schlagen vor, die Feature-Entwickler in Xamarin.Forms 5 zu pausieren, damit wir von September 2020 bis November 2021 mehr Zeit auf die Problemlösung konzentrieren können.

Dies alles ist auf unseren Sprint- Projektboards sichtbar.

Zusamenfassend:

• Seien Sie bei Community-Pull-Requests schneller.

Ich habe den Pull-Request-Baum vor Tagen neu erstellt. Warum dauert die Überprüfung so lange?

WPF-Renderer, potenzielle Fehlerpunkte:

• Messen/Anordnen der Kontrollen
• Logical/Visual-Childtree ist kaputt
• Leistung

Hallo @davidortinau , ich denke, eine gute Möglichkeit, dies

• Fehler-Problem-Triage
• Verwalten, Versenden und Pushen für PR-Überprüfung und Zusammenführung.

Er/sie ist unser Ansprechpartner, wenn etwas zu langsam geht und er/sie erklären kann, was los ist.
Darüber hinaus wäre es fantastisch, wenn es nicht rechtliche Hindernisse gibt, wenn wir einen Twitch-Kanal haben könnten, auf dem wiederum jemand einen Fehler behebt oder eine PR online überprüft. IHMO könnte dies einen enormen Einfluss auf das Interesse und die Zusammenarbeit externer Entwickler haben.
Dies gilt sowohl für .NET MAUI als auch für Xamarin Forms. Aber vielleicht bin ich nur ein Träumer 😄

Ich bin nicht wirklich überrascht, dass Xamarin.Forms viele Fehler aufweist, wenn man die Anzahl der Plattformen bedenkt, auf denen es ausgeführt wird, und die Änderungen von den Plattformen oder durch die eigene Entwicklung.

Was mich jedoch überrascht, ist die Anzahl der Regressionsfehler, Dinge, die zuvor funktioniert haben oder zuvor behoben wurden und die dann mit der nächsten Version nicht mehr funktionieren.
Für mich ist das ein klares Zeichen dafür, dass ich nicht genug getestet habe. Ein strengeres Testregime kann dazu führen, dass einige Änderungen nicht in der nächsten Version enthalten sind, aber es ist wirklich notwendig, sie frühzeitig zu erkennen, um das Stigma eines unzuverlässigen Produkts zu vermeiden, um es ganz offen zu sagen.

Weitere Tests sind etwas, das ich als Lektion aus Xamarin.Forms für MAUI sehen möchte. Es konnte viele gemeldete Probleme und Ressourcenverschwendung vermeiden, da der fehlerhafte Code den Umweg nahm, anstatt sofort mit der erstellten PR behoben zu werden.

Als ich sagte "Kernfunktionen" und "kritische Fehler". Das ist, was ich meine, Problem wie dieses . Das ist jetzt super nervig. Ich habe eine Woche lang eine Veröffentlichung durchgeführt, ohne dieses Problem wirklich zu kennen. Ich habe mich gefragt, warum die Aufbewahrung von Apps dramatisch gesunken ist. Stellen Sie sich vor, ich spreche hauptsächlich nicht Englisch und ein spanischer oder deutscher Benutzer öffnet die App und sie ist aufgrund dieses Fehlers Englisch. Er wird es sofort deinstallieren, obwohl meine App in diese Sprache übersetzt ist. Dieser Fehler kann vorkommen, wurde aber vor einem Mount gemeldet? warum wurde nicht behoben. Sogar Appcenter und Azure Pipelines haben diesen Fehler.

Um den Rahmen zu verbessern. Ich würde gerne hinzufügen:

Verbessern Sie die Möglichkeit, Ihren eigenen Renderer zu schreiben. Vermeiden Sie das Schlüsselwort internal .

Anstatt nur Beispielprojekte auf GitHub zu veröffentlichen, kann Microsoft eine professionelle Unternehmens-App wie OneDrive oder die Xbox-App mit Xamarin Forms, iOS oder Android erstellen und im App Store veröffentlichen, damit andere Personen als Entwickler sie verwenden können. Microsoft hat dies bereits getan, indem es Visual Studio von C++ zu C# und WPF migriert hat (wobei der Kunde in diesem Fall der Entwickler ist). Das wird Microsoft über unsere Schwachstellen informieren und wenn sie erfolgreich sind, wird es der Entwickler-Community enormes Vertrauen geben, dass mit Xamarin alles möglich ist.

Ich bin froh, dass es dazu ein Posting gibt und ich möchte meine Frustration abwägen. Ich bin oft passiv beim Posten von Antworten auf bestehende Probleme , aber was mich auslöst, ist dieses Problem in Bezug auf die BundleAssemblies ; Nach mehr als 2 Monaten dieses schwerwiegenden Problems habe ich immer noch keinen klaren Hinweis auf die Lösung, den Status oder den Weg der Xamarin-Mitglieder.

Ich leite ein Agile-Scrum-Team und sehr oft ist der KPI die Geschwindigkeit (die Menge der geleisteten Arbeit). Manchmal, wenn ein Problem auf ein bestimmtes hitziges Niveau eskaliert ist, wird mein Schlusssatz immer sein: "... Ich frage mich, was ich hier lernen kann, um die Qualität von " [unseres Produkts] zu verbessern. Nichts für ungut (wirklich), aber das ist nur, um meinen Chef oder unseren Kunden zu bevormunden. Wenn ich das in einem solchen Diskussionskontext sage, bedeutet dies nur, dass ich oder mein Product Owner dem Job nicht gewachsen sind oder wir uns im Zustand der Ablehnung oder im schlimmsten Fall befinden, wir wissen wirklich nicht, was los ist. (Ein großes Lob an einen unserer Stakeholder, der mir den Verstand ausschlägt)

Was mich wirklich stört, sind die Regressionsfehler und das Fehlen einer präzisen Antwort/Erklärung des Problems. Jede einzelne XF-Version neigt dazu, etwas kaputt zu machen; und es bricht etwas, das offensichtlich ist - Ausrichtung falsch, Bild wird nicht angezeigt, Textkürzung funktioniert nicht usw. Die Hälfte unserer Testfälle dient nur dazu, diese XF-Regressionen zu überprüfen; es ist lächerlich. Offensichtlich stimmt etwas mit den internen Tests von XF nicht. Selbst wenn ein Show-Stopper- Bug bestätigt wird, kann es immer noch mehrere nachfolgende Neuveröffentlichungen geben; Was ist der Sinn dieser neuen Versionen, wenn wir sie nicht verwenden können? Sollten diese Neuerscheinungen nicht in Ihre Beta aufgenommen werden?

Nach alledem sind ich und unsere Stakeholder der "toxischen Kultur" bei XF sehr müde. Es ist so, als ob Windows 10 ein Update veröffentlichen kann, das die Dateien des Benutzers oder das System des Benutzers löscht (aber zumindest sind ihre Reaktion und ihr Hotfix schnell). Ich glaube, unsere Frustration liegt hier nicht an den fehlenden Funktionen in XF, sondern an der Qualität der Veröffentlichung. Wie kann XF die Qualität verbessern? Sie können online suchen und Millionen von Ergebnissen erhalten; und ich bin mir nicht einmal sicher, wo ich hier anfangen soll, ohne arrogant zu sein, Microsofts Verständnis von "Qualitätssicherung" zu untergraben. Ich bin sicher, Microsoft weiß, wie man Qualitätssicherung durchführt (hey, ich habe die Whitepaper von Microsoft dazu gelesen). Es kommt auf die verantwortliche Person an; er/sie braucht die Verantwortung, Rechenschaftspflicht und das Engagement, um die Qualitätsprüfung zu verbessern (oder durchzuführen).

Ich denke, das Frustrierendste an XF ist, wenn unser Beitrag (sei es eine neue PR, eine neue Ausgabe oder sogar eine einfache Frage oder Feedback) vom Team einfach ignoriert wird.
Das Team ist wahrscheinlich zu klein. Aber es würde definitiv helfen, eine Person zu haben, die sich dafür engagiert, innerhalb einer angemessenen Zeit Antworten zu geben.

Ein gutes Beispiel ist diese Regression zu BundleAssemblies (sie wurde bereits mehrfach erwähnt).
Ein weiteres gutes Beispiel ist dieses Problem bezüglich CollectionView.

Ein weiteres Problem für mich ist, dass eine XF-App natürlich von Änderungen in XF betroffen ist, aber auch Mono, Visual Studio, Xamarin Framework, DotNet und sogar einige Microsoft-Bibliotheken.
Ich habe das Gefühl, dass diese Teams intern nicht gut kommunizieren.
Meiner Meinung nach würde es definitiv helfen, wenn Microsoft XF intern für seine Apps verwendet.

Auch hier ist ein gutes Beispiel diese Regression , für die die eigentliche Ursache in Mono und AndroidX liegt.
Aber ich kann dieses Problem auch in Dotnet-Erweiterungen erwähnen, die sich auf iOS-Apps auswirken, oder sogar dieses Problem in msal.
Und natürlich dieses Problem in Visual Studio , was den Quelllink betrifft.

Die Leute hier haben großartige Arbeit geleistet und das meiste, was ich sagen wollte, im Detail gesagt, also mache ich es schnell

Technische Probleme

• Visual Studio stürzt beim Arbeiten mit XF mehr als 3 Mal pro Minute ab.
• Viele grundlegende Steuerelemente fehlen oder erfordern einen Mist, um sie so zu gestalten, wie sie sein sollen.
• Wenn Sie XF sagen, sagen Sie nur das plattformübergreifende Framework mit der schlechtesten Leistung, und lassen Sie mich für die Leute klarstellen, dass XF native Android / iOS anpackt ... und so schwer. Schau einfach! schauen Sie bitte! für die Liebe Gottes! bei flatter, RN, NativeScript... Sie alle haben das gleiche Ziel, aber XF liegt weit zurück
• Das Hot Reload funktioniert nur gut, wenn Sie ein neues Projekt erstellen und den Standardtext auf der linken Seite erstellen und das wars. Dann allein!
• Jeder in der Flatter-Community zum Beispiel in jeder Veröffentlichung so: Oh OMG, es ist so cool, was sie getan haben. Auf der anderen Seite ist die XF-Com so: Mal sehen, was sie kaputt gemacht oder was sie hinzugefügt haben, das nur 10% der Com brauchen!
• Eine Startreise mit XF ist eine Reihe von Hecken, ein Beispiel wäre: Vor kurzem musste ich eines der gemeinsamen Steuerelemente in allen Apps im Playstore erstellen, das nur ein einfaches unteres Tab-Symbol ist. Die Verwendung von Shell mit Symbol hat nur einen großen Rand unten, die hässlich aussehen und wie alle anderen habe ich ein Problem erstellt, nur um zu bemerken, dass ein ähnliches Problem vor mehr als 6 Monaten behoben wurde ... Und keine Lösung im Weg
• Denken Sie an eine App ok? Irgendeine App? Gibt es einen In-App-Kauf oder eine Art Premium-Service? Natürlich tut es das. Sie suchen also nach einem Plugin für Google Pay und Apple Pay, oder? Oder sogar paypale oder? Lassen Sie mich Ihnen etwas sagen, es gibt nicht !!! Wenn Sie das offizielle Team von XF fragen, wissen Sie, was es antworten wird? Sie senden Ihnen einen Link zu einem veralteten, nicht offiziellen Plugin, das von einem Mann (das respektiere ich) vor 2 Jahren ohne Update erstellt wurde, WTF (sorry) !!

Nicht technisch

• Ach komm ooon, selbst die offizielle Dokumentation ist sehr schlecht, sie behandeln Funktionen auf To-Do-App-Ebene und Anleitungen
• Ich hasste XF schon bevor ich es benutzte, weißt du warum? Jeder sagt, dass selbst MS es nicht verwendet, warum also würden Sie es verwenden?
• Eine sehr langsame Reaktion auf Probleme und PRs, die die Community aus eigener Zeit und auf eigene Kosten erstellt, um dem XF-Team zu helfen !!!

Lösungen

• Das XF-Team ist sehr, sehr klein. Wie kann ein so großes Unternehmen wie Microsoft nicht genug Leute einstellen, um sein eigenes Produkt zu verbessern? Überall auf der Welt gibt es Talente, die Microsoft genauso lieben wie ich!
• Der XF sollte vor der Veröffentlichung hochrangige Probleme angehen, es zeigt nur, wie unreif das Team ist, wie nur Schiff, wen es interessiert ...
• Microsoft am meisten und ist verpflichtet, XF für ihre Produkte zu verwenden! Wenn nicht, ist es nur eine Art zu sagen, dass XF gut ist, aber nein, ich mag es nicht yukh
• Machen Sie eine sehr reichhaltige Dokumentation! Ein Dokument, das in den meisten Situationen die erste Anlaufstelle ist, stellen Sie mehr Leute ein! So einfach ist das. Es gibt viele erfahrene Entwickler, die bloggen, mit denen du arbeiten kannst
• XF ist nicht so bekannt wie Flutter. Machen Sie Partnerschaften mit den großen Coding-Influencern auf YouTube, selbst eine einfache Erwähnung hilft XF
• Es ist auch in Ordnung, sich andere Produkte anzusehen und zu sehen, was die Entwickler an ihnen mögen, und erstellen Sie Ihre eigene Version. Flattern zum Beispiel.
• Haben Sie keine Angst, die Community zu fragen, was sie wollen, leben Sie nicht unter einem Felsen und machen Sie, was niemand braucht!

Es tut mir sehr leid für mein aggressives Verhalten und mein schlechtes Englisch, ich mag XF wirklich sehr!
Maui ist ein neuer Ausgangspunkt, bitte machen Sie es zur neuen Revolution, jeder erwartet etwas Großartiges, also bitte enttäuschen Sie uns nicht, wir haben große Hoffnungen.

@Amine-Smahi Bitte kontaktieren Sie uns per E-Mail mit weiteren Informationen zu dem Verhalten, das zu Abstürzen führt ([email protected]).

Ich stimme voll und ganz zu, dass der Prozess zur Fehlerbehebung und zum Testen neuer Funktionen schrecklich ist.

Zum Beispiel:
https://github.com/xamarin/Xamarin.Forms/issues/3335 – beendet die Verwendung von ListView.RecycleElement
https://github.com/xamarin/Xamarin.Forms/issues/4168 - beendet die Verwendung von CompressedLayout

Wenn Sie neue Funktionen hinzufügen, die die Leistung verbessern - das ist großartig! Aber wenn diese Funktionen unbrauchbar sind, ist das sehr enttäuschend.

Und einige der Probleme, die meine Apps betreffen und seit langem nicht behoben wurden:
https://github.com/xamarin/AndroidX/issues/64
https://github.com/xamarin/Xamarin.Forms/issues/5087
https://github.com/xamarin/Xamarin.Forms/issues/5127
https://github.com/xamarin/Xamarin.Forms/issues/3168
https://github.com/xamarin/Xamarin.Forms/issues/8058 https://github.com/xamarin/Xamarin.Forms/issues/10055
https://github.com/xamarin/xamarin-android/issues/3341
https://github.com/xamarin/xamarin-android/issues/3480

Das Team sollte die Verantwortung für die Funktionen übernehmen, die es implementiert. @StephaneDelcroix hat beispielsweise https://github.com/xamarin/Xamarin.Forms/pull/1136 implementiert https://github.com/xamarin/Xamarin.Forms/issues/4168 zugewiesen werden und CompressedLayout-bezogene Fehler beheben sollte.

Zur Dokumentation: Ich persönlich finde es meistens ok, bis auf die Release Notes, die total f * d up sind ;) (immer zu spät oder unvollständig)
Auch hier spreche ich nicht speziell von XF, sondern allgemeiner vom gesamten xamarin-Framework (xamarin.android, xamarin.ios, Visual Studio, Mono, Komponenten ...).

Hier ist ein Beispiel: xamarin ios Versionshinweise

@melimion

Wenn Sie neue Funktionen hinzufügen, die die Leistung verbessern - das ist großartig! Aber wenn diese Funktionen unbrauchbar sind, ist das sehr enttäuschend.

Dies ist absolut wahr.
Sie haben eine CollectionView hinzugefügt. Das Ergebnis sind eine Reihe von Fehlern auf Android, auf iOS ist es im Allgemeinen unbrauchbar (Disposed-Ausnahme, NSinconsistency-Ausnahme usw. Und dies, wenn Sie alles gemäß den offiziellen Anleitungen (!) tun.
Sie haben CarouselView hinzugefügt - die Fehler sind dieselben.
Wir müssen eine veraltete, aber stabilere Listview verwenden.

Wenn ich jetzt den Titel "wir haben hinzugefügt" sehe, scrolle ich sofort weiter.
Und Sie haben zum Beispiel auch andere Elemente
Swipeview,Expander, die auch viele Fehler enthalten.
Und dann gibt es, wie die Person oben schrieb, Mono, Visual Studio mit seinen eigenen Fehlern.

Brechen Sie die neuen Funktionen in 4.7-4.8 ab, achten Sie auf Fehlerbehebungen.
Die Entwicklung auf Xamarin ist wie das Finden von Problemumgehungen und temporären Lösungen.
Ich entschuldige mich für mein schlechtes Englisch

Gestern habe ich nachgeschaut. Es gibt mehr als 200 Themen mit großer Wirkung. Es macht keinen Sinn, neue Funktionen zu veröffentlichen, wenn kritische Fehler noch behoben werden müssen. Ich stimme dem vorherigen Vorschlag zu. Stoppen Sie neue Funktionen. Nehmen Sie sich Zeit, um die Anzahl der Probleme zu beheben und zu verringern. Ich bleibe zum Beispiel wegen eines Problems bei 4.4 hängen. Stellen Sie sich so viel mehr Menschen in dieser Situation vor. Stabilität und Leistung stehen an erster Stelle, wenn es IMHO keine Manpower für Innovation und Wartung gibt.

Ich frage mich, ob es eine Umfrage unter den XF-Entwicklern geben könnte, um zu sehen, ob wir lieber technische Bemühungen sehen würden, um die vorhandenen Fehler zu beseitigen oder die für 4.7 und darüber hinaus geplanten Funktionen hinzuzufügen. Ich meine, die neuen Features werden selbst weitere neue Bugs hinzufügen, was mehr Nacharbeit und mehr Verzögerungen verursachen wird... manchmal ist ein guter, altmodischer Feature-Freeze erforderlich.

Für mich persönlich würde ich mir wünschen, dass der größte Aufwand in MAUI gesteckt wird, was nach einem vernünftigen Zurücksetzen der XF-Architektur klingt, wobei der zweitgrößte Aufwand in die Beseitigung von Fehlern mit hoher Auswirkung gesteckt wird. Das Hinzufügen neuer Funktionen würde nicht einmal auf meine Liste kommen - ich würde sie lieber hinzufügen, wenn wir eine bessere Plattform haben, um sie hinzuzufügen.

@freever Ich stimme
Dies wird nicht nur die aktuellen Xamarin-Entwickler glücklicher machen, sondern auch diese Fehler für MAUI beheben!

Ich weiß nicht, ob diese Fehler hier in MAUI behoben werden oder in Xamarin.Forms behoben werden.

Ich habe das Gefühl, dass @davidortinau den Geist dieser Ausgabe hier behandelt hat

https://github.com/dotnet/maui/issues/109#issuecomment -635078640

Ich habe die Beschreibung mit seinem Kommentar aktualisiert

Ich möchte diesen Teil von dem, was er gesagt hat, wirklich noch einmal für alle hervorheben

Wir verbringen einen Großteil unserer aktuellen Sprints mit CollectionView-Problemen und schlagen vor, die Feature-Entwickler in Xamarin.Forms 5 zu pausieren, damit wir von September 2020 bis November 2021 mehr Zeit auf die Problemlösung konzentrieren können.

PureWeen hat das vor 10 Stunden geschlossen

Dutzende von xamarin-Entwicklern haben in diesem Ticket ihre Meinung geäußert, und ich habe nicht das Gefühl, dass sie gehört wurden.
Leider hast du gerade meinen Standpunkt bewiesen

@PureWeen Dieses Problem behandelt viel mehr als nur eine Reihe von Fehlern. Sie sind sogar in Punktform aufgeführt.

@tranb3r

Ich denke, das Frustrierendste an XF ist, wenn unser Beitrag (sei es eine neue PR, eine neue Ausgabe oder sogar eine einfache Frage oder Feedback) vom Team einfach ignoriert wird.

Inwiefern ist der Kommentar von @davidortinau für Sie zu kurz? Der Hauptpunkt, den ich anspreche, ist, dass wir die Entwicklung neuer Funktionen verlangsamen, damit wir uns mehr auf offene PRs und Fehler konzentrieren können und dann schließlich zu .net maui gelangen, das unser neueres .net 6-basiertes Produkt sein wird

@Happypig375

@pauldipietro hat sich an die Person

Der Geist dieser Ausgabe ist, dass XF zu viele Fehler hat und die Community ignoriert. Daher verlangsamen wir die Neuentwicklung, um uns mehr auf bestehende Fehler und offene PRs zu konzentrieren

Wenn es andere Probleme außerhalb der offenen Fehler gibt, lassen Sie uns Probleme für diese öffnen. Aber in diesem Problem geht es darum, dass es zu viele offene Fehler gibt, und wir haben einen Plan, um das zu beheben.

Mit MAUI sollten wir einen möglichst schnellen Bugfixing-Prozess haben. Irgendwelche Gedanken zur Verbesserung?

Wir entfernen eine Reihe von Legacy-Aspekten aus Form mit .NET Maui und verbringen dieses Jahr davor, uns stark auf Fehler und offene PRs zu konzentrieren, damit wir mit .NET Maui produktiver sein können

Das ist unser Projektboard

https://github.com/xamarin/Xamarin.Forms/projects

Sie können sehen, was wir zu jedem Sprint hinzufügen
https://github.com/xamarin/Xamarin.Forms/projects/70

Hier ist unsere Roadmap
https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
Wir versuchen, so transparent wie möglich zu sein, woran wir arbeiten

Wenn Probleme in diesen Repos gepingt werden oder einen hohen Fokus haben, versuchen wir, diese nach oben zu blasen, aber manchmal sind diese Algorithmen nicht perfekt.

@Amine-Smahi hier ist das Projektboard für Shell und was wir als Blocker sehen
https://github.com/xamarin/Xamarin.Forms/projects/54

Können Sie mich auf das Problem hinweisen, auf das Sie sich beziehen, damit ich es mir ansehen kann?

@PureWeen

Inwiefern ist der Kommentar von @davidortinau für Sie zu kurz? Der Hauptpunkt, den ich anspreche, ist, dass wir die Entwicklung neuer Funktionen verlangsamen, damit wir uns mehr auf offene PRs und Fehler konzentrieren können und dann schließlich zu .net maui gelangen, das unser neueres .net 6-basiertes Produkt sein wird

Wie bereits erwähnt, behandelt dieses Problem viel mehr als nur die Anzahl der Fehler in XF.

Wenn es andere Probleme außerhalb der offenen Fehler gibt, lassen Sie uns Probleme für diese öffnen. Aber in diesem Problem geht es darum, dass es zu viele offene Fehler gibt, und wir haben einen Plan, um das zu beheben.

Es gibt schon zu viele offene Fragen !!! Was bringt es, neue zu eröffnen, wenn man sie einfach ignoriert...

Einer der zuvor erwähnten wichtigen Punkte ist beispielsweise, dass Microsoft-Teams bei der Entwicklung von Apps xamarin verwenden sollten.
Hören Sie diese Rückmeldung? Was sollten wir tun, um Sie davon zu überzeugen, dass dies eine gute Idee ist? Sollen wir dafür ein Thema eröffnen???

Wie bereits erwähnt, behandelt dieses Problem viel mehr als nur die Anzahl der Fehler in XF.

Lassen Sie uns für diese verschiedene Themen erstellen. Mehrere Dinge in einem Problem zu behandeln, wird nicht produktiv sein.

Bei welchen anderen Kommentaren hier, die nichts mit offenen Bugs/PRS/Zerbrechlichkeitsproblemen in Bezug auf XF zu tun haben, möchten Sie Klarheit?

Einer der zuvor erwähnten wichtigen Punkte ist beispielsweise, dass Microsoft-Teams bei der Entwicklung von Apps xamarin verwenden sollten.
Hören Sie diese Rückmeldung? Was sollten wir tun, um Sie davon zu überzeugen, dass dies eine gute Idee ist? Sollen wir dafür ein Thema eröffnen???

Ja, wir versuchen buchstäblich jeden davon zu überzeugen, Xamarin zu verwenden

Wir sprechen viel mit internen Teams über App-Auswahl und es ist eine fortlaufende Diskussion. Viele dieser internen Diskussionen werden auch die Richtung von .NET Maui bestimmen.

Ich bin mir nicht sicher, was ich noch dazu sagen kann. Es gibt hier nicht viel umsetzbares, was ich tun kann, um Ihnen als Benutzer speziell zu helfen.

@PureWeen Der Geist dieses Problems ist, dass XF zu viele Fehler hat und die Community ignoriert. Daher verlangsamen wir die Neuentwicklung, um uns mehr auf bestehende Fehler und offene PRs zu konzentrieren

Daher erwarten wir für eine Weile eine etwas schnellere Rate an Fehlerbehebungen. Das ist gut, löst dieses Problem aber nicht vollständig. XF von Beta-Qualität zu stabil zu bringen ist eine sehr große Aufgabe und keine schnelle Lösung oder einzelne Strategie wird dies erreichen. Es wird große organisatorische, philosophische und architektonische Veränderungen erfordern. Ich würde vorschlagen:

1. Vereinfachen Sie das Repository , um Beiträge zu leisten und Beiträge zu überprüfen. Die neue Renderer-Architektur kann hilfreich sein, wenn sie XAML aus dem Kern verdrängt und Renderern einen typsichereren Ansatz bietet.
2. Priorisieren Sie Fehlerkorrekturen und saubere Codes gegenüber Funktionen. Da die Kultur von Xamarin darin besteht, neue Features hinzuzufügen, während Fehler ignoriert werden, besteht der beste Weg darin, neue Features vollständig zu verbieten, bis eine Qualitätsschwelle für vorhandene Features erreicht ist.
3. Erlauben Sie Breaking Changes, die Fehler beheben und Code bereinigen.
4. Nutzen Sie .Net voll aus , um Fehler zu reduzieren. Halten Sie die Dinge nach Möglichkeit innerhalb des Typsystems und übernehmen Sie C# 8-NRTs.
5. Reparieren Sie zuerst die grundlegendsten Steuerelemente , dann die restlichen Steuerelemente.
6. Überlassen Sie alte Zielbetriebssysteme und alte Editoren , um das Repository zu bereinigen, das Testen zu rationalisieren und Ressourcen für Fehlerbehebungen freizugeben.
7. Melden Sie öffentlich eine Metrik von Fehlern. Dies wird dazu beitragen, die Organisation auf Fehler zu konzentrieren. Setzen Sie den Fortschritt bei Fehlern als ersten Abschnitt in jedem Blog über ein Update.
8. Entfernen Sie Funktionen , um die Größe des Repositorys zu reduzieren und es wartungsfreundlicher zu machen.

Unsere Erfahrung: Wir verwenden nur grundlegende XF-Ansichten, weil wir nichts anderem als brauchbar vertrauen. Label, Eintrag, Schaltfläche, Auswahl, Schalter, DatePicker, Schieberegler, StackLayout, ScrollView, ContentView, Grid, ContentPage. Aber selbst dann tauchen Fehler auf und bleiben monatelang. Es ist so schwer, Korrekturen in XF zu bekommen, dass wir stattdessen einfach Renderer kopieren und in unseren Code einfügen.

Vereinfachen Sie das Repository, um Beiträge zu leisten und Beiträge zu überprüfen. Die neue Renderer-Architektur kann hilfreich sein, wenn sie XAML aus dem Kern verdrängt und Renderern einen typsichereren Ansatz bietet.

Das ist unser Plan. Ich habe hier ein Platzhalterproblem erstellt, dem Sie folgen oder Ihre Vorschläge machen können https://github.com/dotnet/maui/issues/147

Priorisieren Sie Fehlerkorrekturen und saubere Codes gegenüber Funktionen. Da die Kultur von Xamarin darin besteht, neue Features hinzuzufügen, während Fehler ignoriert werden, besteht der beste Weg darin, neue Features vollständig zu verbieten, bis eine Qualitätsschwelle für vorhandene Features erreicht ist.

Das ist meistens unser Plan.

Erlauben Sie Breaking Changes, die Fehler beheben und Code bereinigen.
Nutzen Sie .Net voll aus, um Fehler zu reduzieren. Halten Sie die Dinge nach Möglichkeit innerhalb des Typsystems und übernehmen Sie C# 8-NRTs.

Das ist langsam unser Plan. Es ist jedoch wichtig, den vollen Umfang der Benutzer zu verstehen, die unsere Produkte verwenden. Als wir zum Beispiel die vs2017-Unterstützung brachen, tauchte dieses Problem hier auf, das eine Menge Kommentare von Benutzern erhielt
https://github.com/xamarin/Xamarin.Forms/issues/7602

Wir können also nicht einfach den Sprung wagen. Ich würde diesen Sprung zu 100 Prozent gerne machen, aber wir können die Leute nicht einfach brechen.

Aber wir unternehmen konsequent Schritte, um auf diesen Sprung vorbereitet zu sein. Zum Beispiel die PR hier
https://github.com/xamarin/Xamarin.Forms/pull/10937

Erlaubt mir, einen internen CI-Prozess auszuführen, um C# 8 und andere Beta-Features zu testen.

Reparieren Sie zuerst die grundlegendsten Steuerelemente, dann die restlichen Steuerelemente.
Überlassen Sie alte Zielbetriebssysteme und alte Editoren, um das Repository zu bereinigen, das Testen zu rationalisieren und Ressourcen für Fehlerbehebungen freizugeben.

Das ist unser Plan, wie ich oben erwähnt habe

Melden Sie öffentlich eine Metrik von Fehlern. Dies wird dazu beitragen, die Organisation auf Fehler zu konzentrieren. Setzen Sie den Fortschritt bei Fehlern als ersten Abschnitt in jedem Blog über ein Update.

Untersuche dies. @samhouts erstellt bei jedem Sprint viele dieser Berichte für uns, sodass wir eine Perspektive auf alles haben, aber wir werden uns damit

Entfernen Sie Funktionen, um die Größe des Repositorys zu reduzieren und es wartungsfreundlicher zu machen.

Dies ist unser Plan mit .net MAUI. Bevor wir unseren .NET MAUI-Plan eingeführt haben, haben wir Listen mit Bereichen erstellt, die wir reduzieren können, um effektiver zu sein. Ein großer Teil davon wird die Renderer-Arbeit sein.

Hallo, zusätzlich zu den genannten Problemen gibt es viele Bugs im Zusammenhang mit Rechts-nach-links-Sprachen Rechte Sprachen), aber das Fehlen einer vollständigen Unterstützung für Rechts-Links-Kulturen, ist entmutigend und enttäuschend und hindert Entwickler tatsächlich daran, XF in internationalen / mehrsprachigen / Rechts-nach-Links-Apps zu verwenden.
Vielen Dank.

Nächste zwei Monate alte Ausgabe: https://github.com/xamarin/Xamarin.Forms/issues/11166
Fehler Erstellt am 22. Juni
PR eröffnet am 25. Juni.
Fehlerstatus 17. August: Immer noch nicht zusammengeführt. Wieso den? ;(

@PawKanarek willkommen bei Xamarin. normalerweise fügen sie nur Fixes oder Prs zusammen, die vom Team erstellt wurden. Aus diesem Grund ist es entmutigend, zu Xamarin beizutragen. Ich denke, dass sie die Teamkapazität reduziert haben. nur 2-3 Personen arbeiten aktiv an dem Projekt. Wenn Sie eine schnelle Lösung benötigen, erstellen Sie Ihre eigenen xamarin-Nuget-Pakete.

@EmilAlipiev Aber dieses Mal wurde der PR (für #11166) von einem Mitglied des Xamarin-Teams geöffnet und wurde immer noch nicht zusammengeführt xD

Wenn Sie sich unsere Release Notes und GitHub Insights ansehen, führen wir jede Menge PRs aus der Community zusammen. Tatsächlich sehe ich deinen Namen auf der neuesten Liste , @EmilAlipiev :)

Sie können sehen, dass im letzten Monat 40 neue Pull-Requests von 18 verschiedenen Personen geöffnet wurden . Pull Requests müssen vollständig getestet und überprüft werden, und mit der Menge, die wir erhalten, müssen wir Blockierungsprobleme und größere Regressionen ohne Workarounds priorisieren.

Ich weiß, dass wir nicht immer perfekt sind, aber wir arbeiten jeden Tag daran, uns zu verbessern. Vielen Dank für Ihre Geduld und dass Sie bei uns bleiben. Wir schaffen das zusammen!

@hamiddd1980 Es wird dich freuen zu hören, dass wir in den letzten Monaten einiges an RTL gearbeitet haben. Ich hoffe, es verbessert Ihre Erfahrung!

@samhouts Denken Sie daran, dass Sie kein Endprodukt von Xamarin sind. Wir brauchen nicht nur Geduld, sondern auch viel Personal und Geld. Jeder offene und verifizierte Fehler in github sollte so schnell wie möglich behoben werden, da er einen Schneeballeffekt in Form von technischen Schulden, Ärger und unnötigen Spannungen mit unseren Kunden erzeugt.

Bitte beheben Sie weitere Fehler, fügen Sie keine weiteren Funktionen hinzu. Stabilität vor Funktionalität. Sie haben noch 1.590 verifizierte Fehler https://github.com/xamarin/Xamarin.Forms/issues?q=is%3Aopen+is%3Aissue+-label%3As%2Funverified+label%3A%22t%2Fbug+%3Abug%3A% 22

@samhouts danke für deine Antwort. 1-2 Merge pro Tag ist extrem weniger. Ich arbeite an anderen plattformübergreifenden Tools und sie haben 15 Zusammenführungen pro Tag 455 Zusammenführungen im letzten Monat. Ich liebe Xamarin als Tool immer noch mehr und bin bereit, immer einen Beitrag zu leisten, aber meine Zusammenführung hat mehr als 2 Monate gedauert und ich musste diese Zusammenführung dreimal mit Rebased aus einem anderen Zweig erstellen.
Darüber hinaus gibt es auf Ihrer Seite die Priorisierung von Problemen. Die Leute suchen verzweifelt nach Fixes für Kerntools wie Fehler wie Device.Idiom.. oder CollectionView-Bugs usw.
Heute gab es einen großen Fortschritt, in der Tat 8 Zusammenführungen insgesamt. Aber um ehrlich zu sein, interessieren sich weniger Leute für die Swipe-Ansicht, Farbverlaufsbürsten oder Themen usw., wenn so kritische PRs monatelang in der Warteschlange stehen. Das ist meiner Meinung nach die größte Frustration

Jeder offene und verifizierte Fehler in github sollte so schnell wie möglich behoben werden

Dies ist offensichtlich unrealistisch; selbst wenn Microsoft die Größe des Xamarin.Forms-Teams drastisch erhöht hat.
Arbeite klüger, nicht härter, sagen sie (in diesem Fall sollte dies bedeuten, dass PRs Regressionstests einschließen müssen, um sicherzustellen, dass die Fehler nicht wieder auftauchen PRs werden länger und härter).

Bitte beheben Sie weitere Fehler, fügen Sie keine weiteren Funktionen hinzu

Diese Meinung teile ich auch. Genau genommen deckt der MAUI<>Xamarin.Forms-Übergangsplan dies jedoch bereits ab: Xamarin.Forms wird nur in den Fehlerbehebungsmodus übergehen, während neue Funktionen nur auf Maui landen.

(in diesem Fall sollte dies bedeuten, dass PRs Regressionstests enthalten müssen, um sicherzustellen, dass die Fehler nicht erneut auftauchen; dies ist jedoch wie bei allem auch ein Kompromiss, da die Überprüfungen der beigetragenen PRs länger und schwieriger werden).

Absolut. Dies ist ein Kompromiss, mit dem wir auch zu kämpfen haben. Wir haben Tausende (!) automatisierte Tests und führen sie auf mehreren Geräten durch. Das Problem ist, dass es Stunden dauert (derzeit ca. 4 Stunden pro Durchlauf pro Gerät), bis sie abgeschlossen sind, und sie sind aus verschiedenen Gründen manchmal leider etwas flockig. Zum Beispiel habe ich gestern einen Mitwirkenden wegen eines Tests angepingt, von dem ich dachte, dass er zu Recht fehlgeschlagen ist, nur um festzustellen, dass er tatsächlich fehlgeschlagen ist, weil Chrome uns gebeten hat, die neuen Nutzungsbedingungen zu akzeptieren. 🤦

Dies führt zu vielen Verzögerungen und bedeutet, dass PRs manchmal Tage brauchen können, um die Tests zu bestehen. Das liegt an uns, und das ist ein Problem, das wir lösen müssen.

Glücklicherweise _arbeiten_ wir an diesem Problem. Wir entwickeln eine neue Methode zum Testen von Plattform-Renderern, die eher Komponententests als der tatsächlichen Automatisierung der Benutzeroberfläche ähnelt, die weitaus zuverlässiger und schneller ist.

Was das Hinzufügen neuer Funktionen oder das Beheben von Fehlern @knocte sagt, wurde der Übergangsplan unter diesem Aspekt entwickelt. Unser Ziel für .NET MAUI ist es, schlank, schnell und zuverlässig zu sein. Dabei evaluieren wir, welche Features eigentlich in das Kernprojekt gehören und welche Features besser für das neue Community Toolkit geeignet sind, das zwar weiterhin von Microsoft unterstützt wird, aber von der Community weitgehend unterstützt wird.

Bitte beachten Sie, dass wir Sie und Ihre Kunden immer im Blick haben, wenn wir Änderungen vornehmen, und wir hören auf Ihr Feedback.