Flutter hat eine ganze Seite gewidmet, um Leute von Xamarin.Forms zu gewinnen. Sie sagen, wir sollten den Wettbewerb ignorieren. Wirklich?

Blazor-Bindungen sind wunderschön! Ich fange gerade erst damit an und sie bieten die Einfachheit, die Flutter bietet.

@davidortinau wie ich im anderen Thread schon sagte. Der MAUI-Blog-Post sorgte für massive Verwirrung. Die Leute scheinen jetzt MVU = als Code/DSL betrachten zu denken.
Dies ist jedoch völlig unabhängig davon, was MVU ist. MVU ist mit XAML perfekt möglich. Es hat nichts damit zu tun, wie Sie die Ansicht schreiben.
Es geht nur darum, ein unveränderliches Modell + eine Update-Funktion zu erstellen, die ein Modell und eine Nachricht nimmt und ein neues Modell erstellt, sowie eine Ansichtsfunktion, die das Modell nicht direkt mutiert, sondern neue Befehle (Nachrichten) in die Update-Schleife sendet.

Ich denke, MAUI sollte sich nur an eine Art des UI-Designs halten, nämlich: XAML

Blazor Syntex ist in Ordnung, aber MVU erscheint mir völlig unnötig. Wenn es Flutter-Entwickler anlocken soll, lassen Sie sie bitte bei Flutter bleiben; Zerstören Sie NICHT die Schönheit von XAML;

Es ist für C#- und .NET-Entwickler gedacht.

@sim756

Ich denke, MAUI sollte sich nur an eine Art des UI-Designs halten, nämlich: XAML

Es war nie nur ein Weg. Codebasierte Benutzeroberflächen wurden von Anfang an durch Xamarin.Forms unterstützt. Es macht Sinn, das zugänglicher zu machen. Übrigens: MVU lässt sich problemlos mit XAML ( Xamarin.Forms , WPF ) nutzen.

@Happypig375

Flutter hat eine ganze Seite gewidmet, um Leute von Xamarin.Forms zu gewinnen. Sie sagen, wir sollten den Wettbewerb ignorieren. Wirklich?

Nun, wir haben besser die Seite " Xamarin für Flutter-Entwickler "!

@rohanbojja

Blazor-Bindungen sind wunderschön! Ich fange gerade erst damit an und sie bieten die Einfachheit, die Flutter bietet.

Alles ist in Ordnung, außer diesem, und deshalb mag ich Flutter nicht :

Bild 0

@forki

@davidortinau wie ich im anderen Thread schon sagte. Der MAUI-Blog-Post sorgte für massive Verwirrung. Die Leute scheinen jetzt MVU = als Code/DSL betrachten zu denken.
Dies ist jedoch völlig unabhängig davon, was MVU ist. MVU ist mit XAML perfekt möglich. Es hat nichts damit zu tun, wie Sie die Ansicht schreiben.
Es geht nur darum, ein unveränderliches Modell + eine Update-Funktion zu erstellen, die ein Modell und eine Nachricht nimmt und ein neues Modell erstellt, sowie eine Ansichtsfunktion, die das Modell nicht direkt mutiert, sondern neue Befehle (Nachrichten) in die Update-Schleife sendet.

Ich bin ziemlich verwirrt!! Danke, du hast es gerade klargestellt, der Beitrag ist katastrophal verwirrend:

Bild 1

@saint4eva

Ich denke, MAUI sollte sich nur an eine Art des UI-Designs halten, nämlich: XAML
Blazor Syntex ist in Ordnung, aber MVU erscheint mir völlig unnötig. Wenn es Flutter-Entwickler anlocken soll, lassen Sie sie bitte bei Flutter bleiben; Zerstören Sie NICHT die Schönheit von XAML;

Es ist für C#- und .NET-Entwickler gedacht.

" Es ist für C#- und .NET-Entwickler gedacht ", genau genommen sollte es nicht von Flutter beeinflusst werden (ich fürchte, es ist...).

@aspnetde

@sim756

Ich denke, MAUI sollte sich nur an eine Art des UI-Designs halten, nämlich: XAML

Es war nie nur ein Weg. Codebasierte Benutzeroberflächen wurden von Anfang an durch Xamarin.Forms unterstützt. Es macht Sinn, das zugänglicher zu machen. Übrigens: MVU lässt sich problemlos mit XAML ( Xamarin.Forms , WPF ) nutzen.

Ich kenne. Manchmal schreiben wir new Button() { .... } , aber dieser Beitrag ( Bild 1 ) hat mich und viele andere, glaube ich, verwirrt.

@Happypig375

Flutter hat eine ganze Seite gewidmet, um Leute von Xamarin.Forms zu gewinnen. Sie sagen, wir sollten den Wettbewerb ignorieren. Wirklich?

Nun, wir haben besser die Seite " Xamarin für Flutter-Entwickler "!

LOL. Stellen Sie sich eine Seite vor, die "Windows Forms für WPF-Entwickler" gewidmet ist.

XAML ist nur ein "Tool" auf dem Objektmodell... Sie können xaml, c# verwenden. Sie können Ihre App mit MVVM (mit oder ohne XAML) oder mit MVU entwerfen (um fair zu sein, waren die bereitgestellten Beispiele keine "echte" MVU, aber dies ist ein anderes Thema).

Wenn Sie codierte Benutzeroberfläche oder den MVU-Ansatz nicht mögen, ignorieren Sie es einfach :) Es besteht keine Notwendigkeit, es zurückzuschieben.

Ich glaube nicht, dass dies nur dazu dient, Flatterentwickler anzuziehen. Das MVU-Muster ist auf dem Vormarsch und eignet sich sehr gut für die mobile Entwicklung.

Auch codierte UI ist auf dem Vormarsch... Reagieren, Flattern, SwiftUI, etc... Sie gewinnen viel an Popularität und sind nicht nur ein Hype...

@GiampaoloGabba
Ich denke, ich sollte klarstellen, dass ich weniger gegen MVU als gegen Coded-UI bin. Ich bin durch diesen Beitrag verwirrt, dass ich befürchte, dass Coded-UI die Standardmethode für die Entwicklung von UIs sein wird (....ich habe Angst, XAML zu verlieren).

Nun, wir haben .designer.cs , aber wir mussten dort keinen Code bearbeiten, selbst ich denke, viele der Windows Forms-Entwickler haben den Inhalt der .designer.cs- Dateien nie gesehen. Aber hier haben wir den _fähigen_ GUI-Editor , mit dem wir uns nicht um den Coded-UI-Code in der Datei _.designer.cs_ kümmern mussten.

Ich bearbeite besser den Titel dieser Ausgabe.

Was ich sagen wollte:

Was werden wir zwischen Flutter/Swift/Coded-UI- Ding und WPF/XAML mit einem GUI-Editor wie Blend für Visual Studio wählen?

@sim756

Ich kenne. Manchmal schreiben wir new Button() { .... }

Manchmal schreiben Leute ganze XF-Apps, ohne XAML anzufassen – und sie freuen sich darüber ;-).

@sim756

Ich kenne. Manchmal schreiben wir new Button() { .... }

Manchmal schreiben Leute ganze XF-Apps, ohne XAML anzufassen – und sie freuen sich darüber ;-).

@aspnetde

Ich bin überrascht..!! 😢

Allerdings nicht für sie, sondern für Leute wie mich, die Blend für Xamarin/MAUI wollen, ist unglücklich:

Android Studio- Bewegungseditor

https://developer.android.com/studio/write/motion-editor

@ sim756 Ich frage mich, ob Sie immer noch Blend-Unterstützung haben möchten, nachdem Sie in einem System mit ordnungsgemäß funktionierendem Hot-Reload gearbeitet haben. Normalerweise bevorzugen die Leute das sehr

Ausgehend von einem XAML / Blend-Hintergrund war mein erster Gedanke bezüglich der Benutzeroberfläche im Code, zurückzutreten, aber nachdem ich es ausprobiert hatte, gab es viele Vorteile, die ich einfach nicht in Betracht gezogen hatte. Die Beseitigung der Notwendigkeit von - was jetzt massiv überkomplex erscheint, sich aber zu der Zeit völlig vernünftig anfühlte - Funktionen wie Konverter, Ressourcen und ähnliches hat mich zu einem echten Glauben an Code-First-UIs gemacht.

Nun, wir haben .designer.cs, aber wir mussten dort keinen Code bearbeiten, selbst ich denke, viele der Windows Forms-Entwickler haben den Inhalt der .designer.cs-Dateien nie gesehen.

@ sim756 - Während ein fähiger Designer nach einem großartigen Produktivitätstool klingt, haben Sie, wenn Sie schon eine Weile dabei sind, möglicherweise an "alten" Codebasen gearbeitet, bei denen der Designer kaputt war und vor einigen Visual Studio-Versionen nicht mehr funktionierte. und Sie müssten Tausende von Zeilen in .designer.cs von Hand verstehen und bearbeiten. Da selbst kleinste Änderungen (wie das Ausrichten einer Schaltfläche) in solchen Codebasen ein oder zwei Tage dauern können, werden all diese Produktivitätsvorteile überdacht. (Hatte diese Erfahrungen mit WinForms und WebForms zuvor).

Wenn es um XAML geht, spricht @dsyme in diesem Vortrag über Fabulous über die Abhängigkeit von schweren Werkzeugen mit einem Abschnitt, der dem "Problem mit XAML" gewidmet ist. Obwohl Fabulous viele eigene Probleme hat, ist es immer noch schwer, vielen der angesprochenen Punkte zu widersprechen.