Firemonkey vs. Xamarin

[jensw_2000]

Zitat von Mavarik:

Welche der Kritiker an FMX hat mit der aktuellen Version (XE6.1) mal eine App für Android, iOS und Windows geschrieben?

Nö. Werde ich auch nicht.

Zitat von Mavarik:

Von der ersten Version bis heute, hat FMX einen gewaltigen Sprung gemacht. Einige Schachen funktionierten selbst mit XE5 noch nicht, die jetzt problemlos und sehr performat laufen.

Seit XE2 habe ich aber schon dafür gezahlt und FMX war nirgends besser oder gleichwertig mit anderen Lösungen.

Zitat von Mavarik:

FMX Programme sind zu groß? Ja, hier könnte der Linker noch besser optimieren.
FMX Programme brauchen zu viel Strom? Hab ich noch nicht testen können, aber Theoretisch müsste es eigentlich sein. (Egal?)
FMX Programme haben "nachgebildete" Controls! Na und? Also meine User merken das eh nicht und wenn ist es Ihnen egal...

Da kann man nichts gegen sagen. Jeder hat seine eigenen Maßstäbe für Qualität und Useability.


Dem gegenüber steht: "Visual Studio Pro mit RemObjects C# und Oxygene"
Da drin ist alles was ich brauche. Nativ für Windows,Java incl. Android, iOS, OSX, Windows Phone, Web.

Zitat von Mavarik:

- Ich brauche eine Routine? Dann lade ich eine Unit aus meinem reichen Fundus, der sich seit über 30 Jahren angesammelt hat. Zu 95% kann ich den Code so übernehmen.

Zu 95% will ich den alten Code garnicht mehr übernehmen. Das .Net Framework bietet für Windows alles, was man sich mit Delphi mühsam selbst bauen musste. Falls doch mal etwas fehlt: NuGet - Paket suchen - Lizenz anschauen - Paket installieren und fertig ist die Arbeit.
Die 3rd Party Komponenten wie DevExpress sind für .Net auch Jahrzehnte gegenüber Delphi Schwesterkomponenten voraus.
Auf anderen Plattformen (hier besonders iOS), gibt es so geniale SDKs und APIs, die keinen Wrapper brauchen. Mit den nativen SDKs gibt es kaum etwas, das man nicht mit ein paar wenigen Zeilen Code mit Bordmitteln lösen kann. Falls doch etwas fehlt haben es andere bereits gelöst und man findet seine fertige Arbeit in Stackoverflow & Co.
Die neuen iOS8 SDK benutze ich auch schon seit kurz nach der WWDC. Da muss ich jetzt nicht bis zum Herbst warten, bis EMBT wieder Geld braucht und XE7 mit iOS 8 Skin rausbringt

Zitat von Mavarik:

Gibt es eine bessere Empfehlung?[/B]

Zitat von Mavarik:

PS.: @alle "Nestbeschmutzer" die meinen XYZ wäre doch viel besser geeignet oder FMX wäre nicht professionell genug:
Was macht Ihr dann hier im Forum? Wenn das andere so toll ist schreib doch da im Forum.

Bin doch schon nur noch ganz selten hier... und verkneife mit alle Crossplattform Posts.
Hier musste ich kurz nochmal drauf antworten.

Zitat von Mavarik:

Hab Euch alle Lieb...

[/QUOTE]
Ich auch.

[D-User]

Zitat von jensw_2000:

Zitat von Mavarik:

Welche der Kritiker an FMX hat mit der aktuellen Version (XE6.1) mal eine App für Android, iOS und Windows geschrieben?

Nö. Werde ich auch nicht.

Zitat von Mavarik:

Von der ersten Version bis heute, hat FMX einen gewaltigen Sprung gemacht. Einige Schachen funktionierten selbst mit XE5 noch nicht, die jetzt problemlos und sehr performat laufen.

Seit XE2 habe ich aber schon dafür gezahlt und FMX war nirgends besser oder gleichwertig mit anderen Lösungen.

hm, du kannst also den aktuellen Zustand nicht beurteilen weil du XE6 gar nicht kennst?

Zitat von jensw_2000:

Dem gegenüber steht: "Visual Studio Pro mit RemObjects C# und Oxygene"
Da drin ist alles was ich brauche. Nativ für Windows,Java incl. Android, iOS, OSX, Windows Phone, Web.

wirklich nativ oder wieder nur .NET-unterlegt???
wohl also nicht wirklich nativ...

Zitat von jensw_2000:

Zitat von Mavarik:

- Ich brauche eine Routine? Dann lade ich eine Unit aus meinem reichen Fundus, der sich seit über 30 Jahren angesammelt hat. Zu 95% kann ich den Code so übernehmen.

Zu 95% will ich den alten Code garnicht mehr übernehmen.

sorry, aber da drängt sich mir beinahe so ein bisschen der Gedanke auf:
"nix Orgiginelles dabeigesewen?" (nicht zu ernst nehmen)

[jensw_2000]

Zitat von D-User:

Zitat von jensw_2000:

Zitat von Mavarik:

Welche der Kritiker an FMX hat mit der aktuellen Version (XE6.1) mal eine App für Android, iOS und Windows geschrieben?

Nö. Werde ich auch nicht.

Zitat von Mavarik:

Von der ersten Version bis heute, hat FMX einen gewaltigen Sprung gemacht. Einige Schachen funktionierten selbst mit XE5 noch nicht, die jetzt problemlos und sehr performat laufen.

Seit XE2 habe ich aber schon dafür gezahlt und FMX war nirgends besser oder gleichwertig mit anderen Lösungen.

hm, du kannst also den aktuellen Zustand nicht beurteilen weil du XE6 gar nicht kennst?

Ich habe noch eine aktive Maintenance und kenne XE6. Ich werde FMX XE6.1 einfach nicht testen, weil es noch immer nicht mit nativem Dalvik / UIKit / Android SDK / Cocoa Touch arbeitet.

Zitat von D-User:

Zitat von jensw_2000:

Dem gegenüber steht: "Visual Studio Pro mit RemObjects C# und Oxygene"
Da drin ist alles was ich brauche. Nativ für Windows,Java incl. Android, iOS, OSX, Windows Phone, Web.

wirklich nativ oder wieder nur .NET-unterlegt???
wohl also nicht wirklich nativ...

OK, .Net ist nicht -CPU nativ-. Java auch nicht. ObjC Kompilate schon. Aber hier reden wir wieder über das endlose Thema "Was heißt eigentlich nativ?".
Für mich bedeutet es, dass ich in meinen Apps die gleichen UI Komponenten verwende und gleiche UI Experience anbiete wie der "Plattformhersteller". Ich nutze die gleichen SDKs und Frameworks, damit am Ende alles so läuft, wie die Plattform es "vorsieht".

Oxygene und RemObjects C# arbeiten direkt auf den SDKs von iOS, OSX, Android und Windows Phone.
Dort werden keine extra Layer oder gar Wrapper genutzt. Alles echte Bordmittel ...
Bei Xamarin (das ich nicht nutze) liegen recht gute Wrapper dazwischen, die am Ende auf den nativen SDKs terminieren.

Zitat von D-User:

Zitat von jensw_2000:

Zitat von Mavarik:

- Ich brauche eine Routine? Dann lade ich eine Unit aus meinem reichen Fundus, der sich seit über 30 Jahren angesammelt hat. Zu 95% kann ich den Code so übernehmen.

Zu 95% will ich den alten Code garnicht mehr übernehmen.

sorry, aber da drängt sich mir beinahe so ein bisschen der Gedanke auf:
"nix Orgiginelles dabeigesewen?" (nicht zu ernst nehmen)

Ich bin seit Delphi 3 dabei und habe bis XE5 schon ein paar Sachen geschrieben die ich interessant fand. Meine Kunden auch...
Mit XE5 habe ich einen Strich drunter gezogen und bin zu VS2013 + RemObjects gewechselt.
Anfangs habe ich versucht meinen wertvollen Delphi Code krampfhaft zu migrieren.
Man lernt dabei aber recht schnell, dass .Net bzw. die iOS bzw. Android SDKs fast alles mitbringen, was man sich auf der dafür vorgesehen Plattform nur wünschen kann. Portiertes Delphi war eigentlich immer komplizierter oder schlechter als das, was die Plattformen ab Werk mitbringen.

Delphi und die VCL waren unter Windows immer Klasse, aber leider zunehmend vernachlässigt.
FMX ... hat mich jahrelang dazu bewegt zu zahlen und zu hoffen.
Seit ich meinem Absprung zu .Net, Oxygene und RemObjects C# kann ich nur Marc Hoffman's "Welcome to the 21st Century" zitieren ..

[Wunni]

Jeder sollte die Entwicklungsumgebung einsetzen, mit der er die Aufgabenstellung am besten lösen kann.
Ich habe mich für XCode+Objective-C entschieden, wenn ich etwas für den Mac oder iOS baue. Ich bekomme die Tools von Apple kostenlos und mit Xcode habe ich jede Menge Spaß und viele Dinge, die ich in Delphi immer vermisst habe. Das wichtigste: Qualität, Stabilität und aktuelle SDK und API. Der Umstieg hat nicht wirklich lange gedauert. Mit Visual Studio 2013 habe ich nach meiner Meinung die beste IDE für die heutigen Anforderungen, kann mit Xamarin auch alle Plattformen bedienen. Wenn es unbedingt Pascal sein muss, dann ist Lazarus eine sehr gute Wahl und für viele Aufgaben völlig ausreichend.
Wenn ich unbedingt "regelmäßig" viel Geld ausgeben möchte, dann kann ich auch Delphi nehmen. Ich muss mir dann nur darüber im klaren sein, dass ich jedes Jahr eine neue Version kaufen MUSS, weil mit Erscheinen einer neuen Delphi Version die Fehler der vorherige Version vom Hersteller nicht mehr behoben werden und einige unzureichend implementierte Features nicht mehr fertig entwickelt werden ("bitte kaufen sie das Update"). Ausserdem muss man bedenken, wie schnell ein Jahr herum ist und dass man innerhalb dieses Jahres auch noch lange warten muss, bis alle Komponentenhersteller mit den Anpassungen fertig werden. Ich persönlich lasse mich ungern auf diese Weise an einen Lieferanten ketten und daher habe ich mich nach fast 20 Jahren entschieden, Delphi nicht mehr für neue Projekte einzusetzen. Über eine strubbelige komplette Neuinstallation nur wegen eines Updates müssen wir ja heutzutage nicht mehr reden (Kopfschütteln). Wem das alles nichts ausmacht, der sollte mit Delphi weiter machen...

[Dejan Vu]

Endlich mal eine objektivere Sicht auf die Dinge.

[Wunni]

zur Diskussion um "NATIVE" noch folgendes:

C# erzeugt jetzt auch nativen Code

Microsoft hat mit ".NET Native" einen Compiler für C# vorgestellt, der keine Intermediate Language, sondern direkt Maschinencode erzeugt. Das Unternehmen rückt damit einen Schritt weiter von seiner Zwischensprache und der Just-in-Time-Kompilierung ab. Der im Rahmen der BUILD-Konferenz in San Francisco vorgestellte .NET Native liegt erst mal als Vorabversion vor, die als Add-on zu Visual Studio 2013 Update 2 installierbar ist. Zunächst gilt der C#-Compiler nur für Windows Apps, die auf Basis der Windows Runtime (WinRT) in Windows 8.x laufen, nicht aber für klassische Windows-Desktop- und Windows-Server-Anwendungen.
Noch nicht konkret angekündigt, aber durchaus naheliegend ist, dass .NET Native in nicht allzu ferner Zukunft auch für klassische Windows-Anwendungen mit vollständigem .NET Framework verfügbar sein wird. Dann gäbe es für alle .NET-Anwendungen eine durchgehende Native-Code-Strategie zum eigenen Programmcode, über das .NET Framework bis hin zur Betriebssystem-API WinRT. (von Holger Schwichtenberg)

Quelle: http://www.heise.de/developer/meldun...e-2161015.html

[MrSpock]

Danke für die Verlinkung des interessanten Artikels. Aufgefallen ist mir in dem Artikel auch, dass als Grund für .NET Native die Performance (Startzeit und Speicherverbrauch) der bisherigen .NET Anwendungen genannt wird. Eine Tatsache, auf die einige hier schon lange hinweisen, die aber von den .NET Überzeugten gerne wegdiskutiert werden.