heise.de: Microsoft Build 2016: Xamarin wird Teil von Visual Studio und Open Source

[Sir Rufo]

Die Styles findet man auch bei WPF - also kein Alleinstellungsmerkmal von FMX

Wenn man sich angeschaut hat was da bei WPF geht, dann weiß man, dass bei FMX noch reichlich Luft nach oben ist

[himitsu]

Wobei die unnativen JavaApps mir auch freude bereiten, da ich kaum was erkennen kann, weil sich bei mir fast Alle viel zu klein darstellen.

[Phoenix]

Zitat von jaenicke:

Ein paar Beispiele für sehr weit verbreitete Programme und Apps habe ich ja genannt.
Natürlich kann niemand sagen, ob sie nicht noch weiter verbreitet wären, wenn sie native Oberflächen nutzen würden...

Lieber Herr Namensvetter, so geht das nicht.
Du forderst Belege, ich liefere ein paar konkrete Fälle, aber Du selber lieferst für Deine Behauptungen keinerlei Belege.

Also müssen wir, bis auch Du Belege liefern kannst, erstmal davon ausgehen, dass Deine Behauptung meine belegte Aussage würde nicht stimmen, erstmal nicht stimmt.

[jaenicke]

Es mag ja sein, dass zumindest einige native Apps dann mehr User hatten. Ich behaupte auch nicht, dass das nicht generell so sein mag (auch wenn ich es bezweifle).

Zudem wird in den Artikeln zumindest teilweise auch geschrieben, dass auch Bugs behoben und neue Features eingeführt wurden. Dass die Apps dann beliebter sind, ist auch klar.
// Edit:
Und Belege für die Behauptungen finde ich auch nicht. Nur gut argumentierte Behauptungen.

Deine Aussage, auf die ich geantwortet habe, war aber, dass der "Einheitsbrei" niemanden im Consumerbereich anspricht. Angesichts der vielen Millionen Nutzer der genannten (und noch vieler anderen) Anwendungen und Apps bezweifle ich das aber ganz entschieden...

[Sir Rufo]

Man kann doch ganz allgemein sogar sagen, dass ein speziell für den Einsatzzweck und -ort angepasstes Produkt besser ist als ein generelles.

Ein Produkt ist gut, wenn es die Erwartungen (Geschwindigkeit, Bedienung, Workflow, Design, ...) erfüllt. Wie man das schafft - also welches Framework man einsetzt - ist vom Prinzip völlig egal.

Wenn man aber diesen Erwartungen auf drei Gerätekategorien (Desktop, Tablet, Phone, Watch) und unterschiedlichen Plattformen (Windows 7-10, OSX, iOS, Android) zu 100% gerecht werden möchte (keine Kompromisse), dann habe ich für das UI ein Projekt pro Kategorie/Plattform Kombination.

Zwingt einem das Framework Kompromisse auf, die man nicht haben will, dann führt der Weg zum angestrebten Ziel nur noch über die native Entwicklung.

[Sir Rufo]

Bei Interesse schaut man sich z.B. einmal das Xamarin Beispiel-Projekt

https://github.com/xamarinhq/app-acquaint/tree/master

an. Eine Anwendung die jeweils nativ und mit XForms erstellt wurde. Dort kann man sich das gesamte Look & Feel anschauen und vergleichen. Die Unterschiede liegen hier in den Feinheiten aber genau da hat der Frosch meistens die Locken

[Darlo]

Zitat von Phoenix:

Okay, dann mal bitte Butter bei die Fische.
[...]
Wenn dem nicht so wäre, würde ich im Gegenzug gerne mal ein paar konkrete Beispiele dafür sehen, wo Firemonkey-Apps konsistent ein 5-Sterne Rating im AppStore halten.
Oder einen einzigen Beleg, wo ein Rewrite einer nativen App durch Firemonkey hinterher ein besseres Rating erhalten hat als vorher.

Gerne:

[Bambini]

Zitat von MEissing:

...was vermisst du bei den FMX Controls?

Es fühlt sich leider nicht wie die original Controls an oder es gib sie nicht. HTML, RTF, MacOS Toolbar u.v.m.
Das Mischen von FMX mit den native Plattform Controls gelingt nur sehr eingeschränkt oder gar nicht.

[Bambini]

Noch einen kleinen Nachtrag dazu: Ich weiß das es bereits HTML und einen RTF Editor für FMX gibt und will keineswegs die Leistung und den tollen Support der Entwickler schmälern,
aber die Komponenten können leider nicht mit den native mithalten.

[Darlo]

Mit FMX kann man aber ebenso native Komponenten nutzen. Ich nutze iCL von TMS. Je nach Anforderung ist man doch super flexibel mit Firemonkey. iOS-GUI native, Windows, OS X und Android mit Firemonkey.