AW: Firemonkey vs. Xamarin
Ich kram mal den alten Thread raus, anstatt einen neuen aufzumachen, sorry.
Arbeitet jemand von Euch zufällig mit Xamarin (evtl. sogar Xamarin.Forms). Gerade was ich so über die Probleme mit den Apps unter Delphi Tokyo lese, bin ich wenig begeistert, mit Delphi das ganze anzufangen. Zumal ich gerade da von der Preispolitik gerade extrem angenervt bin. Ich werde ständig mit megagünstigen Rabatten von Embarcadero gelockt - 49% Rabatt beim Upgrade von Starter auf Prof INKLUSIVE Mobile AddOn, was gerade mal 968 EUR sind. Da ich aber nur das AddOn benötige und keine weitere Pro-Lizenz soll ich nur für das AddOn 807 EUR zahlen? Hallo? Kein Rabatt möglich wird mir da gesagt. Ich komm mir echt verarscht vor. Ich sage jetzt nicht, das Xamarin das ultimative Framework ist, wird sicher auch seine Probleme haben gegenüber direkter Entwicklung auf der jeweiligen Plattform. Aber man kann mit VS2017 zumindest damit arbeiten, nehme ich mal an. Mit dem Mobile Addon würde ich glaube gerade die Katze im Sack kaufen. |
AW: Firemonkey vs. Xamarin
Eine weitere Alternative wäre react native.
|
AW: Firemonkey vs. Xamarin
Ich weiss nicht genau wie Xamarin funktioniert, aber ich habe sowas wie PhoneGap im Hinterkopf. Und dazu gibt es eine Meldung bei heise https://www.heise.de/mac-and-i/meldu...b-3751886.html
Zitat:
Sherlock |
AW: Firemonkey vs. Xamarin
Ich bin gerade dabei, mich in Xamarin Forms ein wenig einzuarbeiten.
Wenn du dich mit C# und XAML auskennst, ist das Ganze ein Klacks und funktioniert ganz gut. Zumindest bis jetzt, wobei meine Ansprueche zur Zeit auch nicht sonderlich hoch snd. Ausserdem kostet es nix :-D Unter IOS wird das Ganze AOT kompiliert, unter Android ganz normal gejittet, was meiner Meinung nach nicht unbedingt ideal ist. Der Dialekt ist bei Xamarin Forms anders als bei WPF oder UWP. Microsoft arbeitet an einem XAML Standard, der dann hoffentlich alle Plattformen inkl. Win32 unter einen Hut bringt, mal schauen ob das wirklich auch gelingt. Ich hab' mir in den letzten Wochen fuer eine private App wirklich alles moegliche angesehen - React Native, Xamarin Forms, Kotlin, Android Native, QML, Flutter. Delphi haette mich auch interessiert, ich konnte aber keine ueberzeugende FMX Anwendung finden. Ausserdem funktionert der Online Installer bei mir nicht mehr, ich muesste die 6GB ISO herunterladen, um das Ganze nocheinmal auszuprobieren, was ich mir dann doch nicht antun wollte. Insgesamt gesehen hatte ich mit XF bis jetzt die wenigsten Probleme, weil ich WPF schon kannte. In naher Zukunft glaube ich allerdings, dass Dart/Flutter sie alle einsacken wird. Was da geboten wird, ist schon fantastisch (wenn auch noch nicht ganz fertig). |
AW: Firemonkey vs. Xamarin
Ich habe auch mal ein bisschen mit Xamarin.Forms angefangen. Klar, die Community ist mindestens 10x größer und bislang hat (fast) alles super funktioniert. In der VS2017-Beta ist der Xamarin Live Player drin, das finde ich extrem faszinierend: Damit kann ich meine Anwendungs auf iPhone bringen, sogar debuggen (!!), ganz ohne Mac. Als ich das letzte mal etwas mit FireMonkey/iOS gemacht habe konnte ich noch nicht einmal das echte Kompilat debuggen ;-)
Embarcaderos Roadmap rechne ich ihnen hoch an, das war echt nötig. Bei Xamarin gibt es, auch für .Forms, zwar eine präzisere Roadmap, aber hey. Interessant finde ich persönlich WPF für Xamarin.Forms. Nachdem was ich erlebt habe würde ich persönlich auch nur noch In-House oder Quick & Dirty-Sachen für Android/iOS mit dem RAD Studio machen wollen. Was ich bislang von Xamarin angefasst habe hat sich sehr gut angefühlt. Aber das hat garantiert auch Macken :twisted: |
AW: Firemonkey vs. Xamarin
Ich habe Ende 2012 angefangen mit Xamarin zu arbeiten und bin vollauf zufrieden. Damals gab es Xamarin.Forms noch nicht, sodass ich zunächst je Plattform eine eigene GUI gebaut habe. Das ging aber dank MVVM-Framework ziemlich fix, da ich nur die Oberflächen mehrfach machen musste, während die ViewModels überall identisch waren.
Später als dann Xamarin.Forms kam, bin ich umgestiegen. Anfangs gab es noch ein paar unschöne Bugs aber inzwischen ist es deutlich stabiler. Das liegt wahrscheinlich auch daran, dass es jetzt open source ist. Es gibt generell einen elementaren Unterschied zwischen FireMonkey und Xamarin.Forms: Bei Xamarin werden alle Controls vom Betriebssystem gezeichnet und verwaltet. Dadurch fühlen sich Xamarin-Apps genauso an als ob sie in Swift, Objective-C oder eben Java geschrieben wären. Bei FireMonkey hat man erst nach und nach angefangen native Controls mit rein zu nehmen. Von der App-Store-Reinigung werden Xamarin-Apps nicht betroffen sein. Die Xamarin-Entwickler passen seit jeher penibel auf die Verträglichkeit mit den App-Store-Richtlinien auf. Weder beim Preis noch bei der Qualität kann Delphi im mobilen Bereich derzeit mit Xamarin konkurrieren. Wer nicht unbedingt Delphi benutzen will (oder muss), dem lege ich Xamarin ans Herz. Speziell als Einzelkämpfer ist es ein riesen Vorteil Visual Studio kostenfrei nutzen zu können. Embarcadero scheint an dem Markt leider kein Interesse zu haben. |
AW: Firemonkey vs. Xamarin
Zitat:
Embarcadero hätte sich lieber auf VCL und IDE spezialisieren sollen statt unfertigen, nicht richtig funktionierenden Kram für iOS, Android, Linux und was es nicht alles gibt einzubauen. |
AW: Firemonkey vs. Xamarin
Zitat:
Sherlock |
AW: Firemonkey vs. Xamarin
Zum Thema Controls selbst zeichen oder nicht - Google setzt mit Dart/Flutter auf genau den gleichen Ansatz wie FMX. Vulkan Treiber/Skia (C Vector Grafik Bibliothek) und darauf aufgesetzt die Controls. Und siehe da, die Apps laufen super performant.
Was ich damit sagen will - der Ansatz von Firemonkey ist denke ich gut, nur muss man halt die entsprechende Ressourcen in das Nachbauen der nativen Controls stecken. Wie es geht, zeigt Flutter. Embarcadero muss einfach mehr Geld in die Entwicklung buttern und weniger ins Marketing. |
AW: Firemonkey vs. Xamarin
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:56 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz