AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Firemonkey vs. Xamarin

Ein Thema von lowmax_5 · begonnen am 17. Feb 2014 · letzter Beitrag vom 28. Jun 2017
Antwort Antwort
Seite 1 von 3  1 23   
Benutzerbild von MEissing
MEissing

Registriert seit: 19. Jan 2005
Ort: Egelsbach
1.384 Beiträge
 
Delphi 12 Athens
 
#1

AW: Firemonkey vs. Xamarin

  Alt 24. Jun 2014, 10:50
Würde Embarcadero wieder mehr Fokus auf Produktivität beim Entwickeln legen (Sprachfeatures, IDE-Support), und einen vernünftigen Multi-Platform-Ansatz fahren (= mit der anderen Plattform sauber integrieren anstelle alles auf jeder Plattform wieder künstlich selber nachzuimplementieren, das Wettrennen kann man aufgrund der schnellen Entwicklung auf allen Plattformen grundsätzlich nämlich nicht gewinnen), gekoppelt mit einer vernünftigen Sales-Strategie (freie SKU's, die z.B. nur zum Entwickeln taugen aber nicht in die Stores deployen können), eine freie Desktop-SKU die ohne die (neuen, wirklich ihr Geld werten) Produktivity-Features daherkommt, aber nicht nur über DB-Zugriff einschränken, dann würde Delphi an sich auch wieder attraktiver werden.
Sprachfeatures: Klar fehlt da was.... aber verstecken muss sich Delphi da nicht. Wer mehr will, kann sich ja mal den C++Builder anschauen.

Multiplattform-Ansatz: Das ist ein Glaubenskrieg, wie man das macht. Die Kunden rennen uns die Bude ein, weil wir es so machen, wie wir es machen. Mich wundert, daß Du das Wort "Einheitsbrei" nicht verwendet hast

Freie SKU/Produkt: Gibt's doch.... Appmethod.
Matthias Eißing
cu://Matthias.Eißing.de [Embarcadero]
Kein Support per PN
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.880 Beiträge
 
Delphi 11 Alexandria
 
#2

AW: Firemonkey vs. Xamarin

  Alt 24. Jun 2014, 11:00
Zitat:
Sprachfeatures: Klar fehlt da was.... aber verstecken muss sich Delphi da nicht. Wer mehr will, kann sich ja mal den C++Builder anschauen.
Ist das nicht ein Widerspruch?
Zitat:
Freie SKU/Produkt: Gibt's doch.... Appmethod.
Aber nur für C++.

Ich habe so das Gefühl man will sich von Delphi oder OP, wie es nun genannt wird, verabschieden.
Markus Kinzler
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.645 Beiträge
 
#3

AW: Firemonkey vs. Xamarin

  Alt 24. Jun 2014, 11:04
Sprachfeatures: Klar fehlt da was.... aber verstecken muss sich Delphi da nicht. Wer mehr will, kann sich ja mal den C++Builder anschauen.

Freie SKU/Produkt: Gibt's doch.... Appmethod.
Wir reden hier aber von Delphi und nicht von C++. Ist ja schliesslich die Delphi-Praxis hier und nicht die C++ - Praxis

Und nochwas zur Attraktivität:
Das Pay-for-Bugfix-Konzept ist glaube ich der meistgenannte Stolperstein, den ihr Euch selber in den Weg legt. Für das Visual Studio 2010 (da gibts auch schon zwei Nachfolge-Versionen), gibt es noch bis Juli 2015 Mainstream-Support, extended sogar bis 2020. Ihr solltet wirklich überlegen, zumindest 2-3 Jahre noch Bugfixes nachzuliefern.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat
greenmile

Registriert seit: 17. Apr 2003
1.107 Beiträge
 
Delphi 10.3 Rio
 
#4

AW: Firemonkey vs. Xamarin

  Alt 24. Jun 2014, 11:07
Wir reden hier aber von Delphi und nicht von C++. Ist ja schliesslich die Delphi-Praxis hier und nicht die C++ - Praxis
  Mit Zitat antworten Zitat
lowmax_5

Registriert seit: 9. Mai 2003
Ort: Münster, NRW
258 Beiträge
 
Delphi 11 Alexandria
 
#5

AW: Firemonkey vs. Xamarin

  Alt 24. Jun 2014, 11:12
Ziel meines initialen Posts war es tatsächlich die unterschiede der beiden genannten Lösungen Firemonkey und Xamarin aufzuzeigen, um dann eine qualifizierte Entscheidung treffen zu können.

Ich habe z.B. nicht erwartet, das FMX hier eine fehlerfreie und überlegene Lösung zur Verfügung stellt. Jedes Produkt wird seine Vor-/und Nachteile sowie Schwächen haben. Zumal der Ansatz der Produkte jeweils an anderer ist. Daher ist es sehr hilfreich zu wissen, wo die individuellen Stärken&Schwächen liegen - und dafür Bedarf es nun mal einen Vergleich ohne dass ein Produkt dadurch gleich schlecht ist.

Auf Grund der Art der Anwendung und den speziellen Anforderungen, wird hier jeder eine andere Entscheidung treffen können. Fakt scheint aber so sein, dass sich beide Lösungen für die mobile Entwicklungen durchaus eignen.

Interessant wäre es noch zu wissen, ob es noch weitere Lösungen für die mobile Entwicklung gibt und dort schon entsprechende Erfahrungen gesammelt wurden.
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.880 Beiträge
 
Delphi 11 Alexandria
 
#6

AW: Firemonkey vs. Xamarin

  Alt 24. Jun 2014, 11:26
Zitat:
Interessant wäre es noch zu wissen, ob es noch weitere Lösungen für die mobile Entwicklung gibt und dort schon entsprechende Erfahrungen gesammelt wurden.
HTML/CSS/JS ( PhoneGAP, JQuery (mobile), Enyo, ...)
Markus Kinzler
  Mit Zitat antworten Zitat
jensw_2000
(Gast)

n/a Beiträge
 
#7

AW: Firemonkey vs. Xamarin

  Alt 24. Jun 2014, 11:58
Interessant wäre es noch zu wissen, ob es noch weitere Lösungen für die mobile Entwicklung gibt und dort schon entsprechende Erfahrungen gesammelt wurden.
Hier mal eine ganz kurze und hoffentlich wertungsfreie Zusammenfassung von mir:

FM:
- UI wird einmal entwicklelt und für alle unterstützten Plattformen ansatzweise passend gerendert
- durch das ständige rendern (OpenGL) hoher Akkuverbrauch und etwas zähere User Experience auf dem Device
- große Applikationsdateien, auch bei kleiner Funktionalität (Fokus: Ladezeit, Deployment)
- Plattform SDKs werden durch Wrapper gekapselt. Dadurch:
- kleine Lernkurve (aus Sicht des Delphi Entwicklers)
- Support und Beispiele "nur" aus Delphi Kreisen
- mühsames Herankommen an spezielle API Funktionen, u.U. viel Code Overhead durch "IfDefs"
- Businesslogic wird zentral für alle Plattformen entwickelt
- Sprachfeatures: wie "Delphi"
- IDE/Produktupdates: 1-2 mal pro Jahr
- unterstützt neben Windows: iOS, OSX, Android (ARM)

Oxygene / Remobjects C#:
- Arbeitet direkt mit den SDKs der Plattformen
- UI wird pro Plattform in einem separaten Projekt angelegt
- UI wird per Code oder über die UI Design Tools der entsprechenden Plattformen "gebaut"
- Businesslogic wird zentral für alle Plattformen entwickelt
- normaler Akkuverbrauch und normale User Experience auf dem Device (außer man programmiert Spiele )
- kleine Applikationsdateien, da direkt auf die "OnDevice" SDKs zugegriffen wird.

- Plattform SDKs werden direkt verwendet. Dadurch:
- sehr steile Lernkurve für jede Plattform, kaum Lernkurve in der Business Logic
- Support und Beispiele können aus jedem Kanal für jede Plattform gezogen werden (mit Ausnahme der reinen Sprachsyntax)
- direktes Herankommen an alle API Funktionen mit "plattformtypischen Methodensignaturen"

- Auf Wunsch können "Mapped Types" verwendet werden. Diese begradigen "intern" plattformspezifische Unterschiede zwischen den Basistypen. Zur Laufzeit werden dabei aber keine Wrapper verwendet, sondern direkt die Typen der jeweiligen Plattform.
- Sprachfeatures: großartig, mehr als jede hauseigene Plattformsprache "für sich" könnte
- IDE/Produktupdates: 4x mal pro Jahr oder wöchentlich per "Beta"
- unterstützt neben Windows: iOS, OSX, Java (allgemein überall), Android (Intel,ARM), Windows Phone und Windows Store Apps
- Cool: Remobjects C# Code kann mit Oxygene (Pascal) Code in einem Projekt gemischt werden (wenn man beide Lizenzen hat). Das erleichtert das schnelle Mitnehmen von altem Code und man kann die Stärken von Pascal und C# fallweise ausnutzen.

Xamarin (unvollständig, weil ich selbst damit nie gearbeitet habe):
- "MS" C# mit Wrappern zu den SDKs der Plattformen
- UI wird pro Plattform in einem separaten Projekt angelegt (?)
- Businesslogic wird zentral für alle Plattformen entwickelt
- normaler Akkuverbrauch und normale User Experience auf dem Device (außer man programmiert Spiele )
- größere Applikationsdateien, wegen der SDK Wrapper.
- steile Lernkurve für jede Plattform, kaum Lernkurve in der Business Logic
- Support und Beispiele können "fast" aus jedem Kanal für jede Plattform gezogen werden. Die C# Wrapper erfordern allerdings ein zusätzliches Umdenken bei der Syntax.


Vielleicht mögen die Xamariner, Lazarus User und FMXer hier bekannte Top/Flop Features ergänzen ...
  Mit Zitat antworten Zitat
Benutzerbild von cookie22
cookie22

Registriert seit: 28. Jun 2006
Ort: Düsseldorf
936 Beiträge
 
Delphi XE2 Professional
 
#8

AW: Firemonkey vs. Xamarin

  Alt 24. Jun 2014, 22:16
Wer mehr will, kann sich ja mal den C++Builder anschauen.
Verkauft sich der C++ Builder überhaupt noch? Ich frag das hier nicht um irgendwie zu flamen oder sonst etwas, aber nutzt nicht jeder der unter Windows mit C++ arbeitet VS + QT?


+1... Genauso sehe ich das auch...
Das völlig kritiklose Fanboi-Gelaber nervt mindestens genauso.
Gruß
Cookie
  Mit Zitat antworten Zitat
Benutzerbild von Phoenix
Phoenix
(Moderator)

Registriert seit: 25. Jun 2002
Ort: Hausach
7.645 Beiträge
 
#9

AW: Firemonkey vs. Xamarin

  Alt 25. Jun 2014, 06:12
Wer mehr will, kann sich ja mal den C++Builder anschauen.
Verkauft sich der C++ Builder überhaupt noch? Ich frag das hier nicht um irgendwie zu flamen oder sonst etwas, aber nutzt nicht jeder der unter Windows mit C++ arbeitet VS + QT?
Ich glaube, als DPler haben wir da einen gewissen vorbelasteten Standpunkt. Wenn ich das aber richtig verstanden habe ist die C++ Builder Gemeinde um einiges größer als die Delphi-Gemeinde, die Jungs sind nur nicht so Publikumswirksam in Foren etc. organisiert.
Sebastian Gingter
Phoenix - 不死鳥, Microsoft MVP, Rettungshundeführer
Über mich: Sebastian Gingter @ Thinktecture Mein Blog: https://gingter.org
  Mit Zitat antworten Zitat
Robotiker
(Gast)

n/a Beiträge
 
#10

AW: Firemonkey vs. Xamarin

  Alt 25. Jun 2014, 07:58
Verkauft sich der C++ Builder überhaupt noch? Ich frag das hier nicht um irgendwie zu flamen oder sonst etwas, aber nutzt nicht jeder der unter Windows mit C++ arbeitet VS + QT?
Ich glaube, als DPler haben wir da einen gewissen vorbelasteten Standpunkt. Wenn ich das aber richtig verstanden habe ist die C++ Builder Gemeinde um einiges größer als die Delphi-Gemeinde, die Jungs sind nur nicht so Publikumswirksam in Foren etc. organisiert.
Ich bin mir nicht sicher. Habe zu Schulzeiten mit Delphi und Borland C++ angefangen und bin beruflich im Embedded/Automotive/Automatisierungsbereich unterwegs. Traditionell arbeiten da viele PC-seitig mit dem C++ Builder, weil sich das von Borland C++ her kommend so ergeben hat. MS hatte zu frühen C++ Zeiten nicht den besten Ruf.

Heute sehe ich bei vielen Firmen doch eher VS oder Qt Creator, seltener Netbeans oder EclipseCDT. Wenn C++ Builder, dann meist 5 oder 6. Jemand der FireMonkey einsetzt, ist mir da noch nicht begegnet.

Wenn man in C++ Cross Plattform arbeitet, nervt die Rückständigkeit des 32 Bit Compilers von Emba dann doch sehr. Der 64-Bit Compiler basiert zwar auf Clang, aber da auch nicht auf der aktuellen Version. Außerdem, wenn man auf jedem Linux Clang umsonst hat und Google heftig an Clang für VS schraubt, warum soll man den dann noch zusätlich kaufen ?

Wenn Emba jede Menge neue C++ Entwickler die Türe einrennen, ist das schön für sie. Es hält das Produkt am Leben. Aber mir begegnen die nicht, offenbar ist das eine ganz andere Zielgruppe.

Geändert von Robotiker (25. Jun 2014 um 08:02 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 3  1 23   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:51 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz