Firemonkey vs. Xamarin

[mkinzler]

Zitat:

Zitat von mquadrat (Beitrag 1264671)

Ich bin mal gespannt wie der Plan für AppMethod ausschaut. Aktuell scheint man ja das Kundenpotential eher bei den C++ Entwicklern zu sehen, was unter Umständen gar nicht mal so falsch ist.

Ob man das hier in einem Delphiforum genauso sieht?

Zitat:

Auch der Ansatz nicht bei FMX stehen zu bleiben, sondern ein gesamtes Ökosystem aufzuziehen erscheint mir richtig.

AppMethod ist doch alter Wein in neuen Schläuchen. Man mache ein Schleifchen drum und lasse etwas weg ( VCL). AppMethod ist FMX und beinhaltet nichts, was im RadStudio nicht vorhanden wäre.
Die IDE schaut jetzt modern aus, allerdings fehlen noch immer einige Komfort-Features.

Zitat:

Wenn Delphi da einfach mitgezogen wird, fände ich das gut.

Ist es doch. AppMethod basiert nun auf RadStudio XE6. Ohne VCL.

[vagtler]

Mal was ganz anderes: ist es in Delphi eigentlich möglich (wie in Xamarin und Oxygene), Anwendungen für Android Wear und/oder Glassware zu entwickeln?

[mkinzler]

Google Glass auf jeden Fall.

http://delphi.org/2014/02/revisiting-google-glass/

Auch GoogleWear sollte grundsätzlich funktionieren, wenn man die APIs manuell wrappt.

https://twitter.com/malgroves/media

Direkter Support ist angekündigt

Zitat:

Zitat von http://edn.embarcadero.com/article/43677

Direct support for wearable Android devices with particular form factors, particularly Google Glass

[Thomas_K]

Amdroid Wear Emulator mit C++ Builder XE6 http://translate.google.de/translate...26channel%3Dsb

Zumindest erste Gehversuche sind möglich, ich weiß aber nicht wie es mit der Bluetooth 4.0 Kommunikation aussieht.

[mquadrat]

Zitat:

Zitat von mkinzler (Beitrag 1264678)

AppMethod ist doch alter Wein in neuen Schläuchen. Man mache ein Schleifchen drum und lasse etwas weg ( VCL). AppMethod ist FMX und beinhaltet nichts, was im RadStudio nicht vorhanden wäre.
...
Ist es doch. AppMethod basiert nun auf RadStudio XE6. Ohne VCL.

Mir ist schon klar, was AppMethod als IDE ist. Das Geschäftsmodell dahinter sieht aber IMHO noch eine Erweiterung auf Services vor. Und die Services kann ich nur gescheit einbinden, wenn ich neben FMX noch weitere Funktionen bereitstelle. Der x.te Wrapper für die Cross-Plattform-Entwicklung wird nicht reichen um Kunden zu gewinnen. Man muss also - wie z.B. Telerik das ja auch macht - ein ganzes System bauen.

[stahli]

Ich hab´s ja mit dem mobilen Zeug nicht so, aber wäre nicht DevExtreme durchaus interessant?

Überblick
https://www.youtube.com/watch?v=T7oJ...EH_e3b23AA30-z

Cross-Plattforms:
https://www.youtube.com/watch?v=Gxe6...EH_e3b23AA30-z

verschiedene Layouts:
https://www.youtube.com/watch?v=fX_i...AA30-z&index=6

deploy and test:
https://www.youtube.com/watch?v=1VCT...EH_e3b23AA30-z

und noch die komplette Packung ;-)
https://www.youtube.com/watch?v=IKQiPVR7XH4

Ist natürlich HTML5 und JS, scheint mir aber so, als ob man sehr gut damit arbeiten könnte...

[jensw_2000]

DevExtreme hat den Nachteil jedes WebApplication Frameworks.
Die App arbeitet auf dem Device im mobilen Browser und kann dort nur auf die Platform APIs zugreifen:
a) die der Browser für WebApps freigibt.
b) für die passende JS Wrapper im Framework zur Verfügung stehen.

Im Normalfall sind das immer nur die gängigen Sensoren. Mit Glück noch Mail, Kalender, Kontakte, Foto und Kamera.
Gegenüber FMX hat DX den Vorteil, dass alle gängigen Devices unterstützt werden und dass die Qualitätssicherung bei DevExpress sehr gut ist.
Wenn die App aber irgendwann mehr werden soll als ein "Datenanzeiger" oder eine "Yes-No-Perhaps Machine" steht man mit DevExtrem genauso schnell vor der Tür wie mit FMX. Wrapper und Skins können den vollen Zugriff auf die Platform APIs einfach nie ersetzen oder gar verbessern.

[Dejan Vu]

Hast Du mal vielleicht eine konkrete Anwendung, die man mit DX nicht entwickeln kann? Also eine 'gängige' Anwendung? Mich würde mal interessieren, wie eingeschränkt man mit den Lösungen ist, die über HTML5/JScript arbeiten. Das man irgendwie eingeschränkt ist, mag sein. Aber wie sehr?

Ach, Du meinst, das man eben nur deviceunabhängige Anwendungen schreiben kann. Das ist ein Vorteil, kann aber ein Nachteil sein, wenn eine Firm z.B. 10 Acer FooBooks mit Zuffnicksensor hat und Du das SuperDispoTool für genau diesen Sensor schreiben musst. Die API ist für Java und C vorhanden, aber...

So in der Art?

[stahli]

Für mich machen (selbst entwickelte) mobile Apps eigentlich nur Sinn für die einfache Datenverarbeitung - z.B. mobiler Zugriff auf Projektdaten, ein kleiner Umrechner o.ä.

Für Spiele und anspruchsvolle gerätespezifische Anwendungen sollte man vielleicht eher die nativen Entwicklungsumgebungen nutzen.

Bis auf Tests aus Interesse wird m.E. von uns Normalos sich kaum jemand ERNSTHAFTE mobile Anwendungen entwickeln, die über ein paar einfache Dateneingaben heraus gehen - sonst würden mich mal Beispiele interessieren, die gut verkauft werden.

Also muss man erst einmal entscheiden, ob man mehr als 08/15-Anforderungen überhaupt braucht.
Wenn nicht, erscheint mir DevExtrem schon ganz komfortabel.

[jensw_2000]

DevExtreme nutzt PhoneGap. Ich habe gerade erstaunt festgestellt, dass es dafür doch eine ganze Reihe an Plugins zum Zugriff auf die "Device Innereien" gibt. Die meisten davon kommen allerdings von 3rd Party Entwicklern. Da hätte ich schon die Befürchtung, dass Updates und Support schnell mal vernachlässigt werden könnten.

Ok, da geht etwas mehr mit als ich dachte. Das Schandmaul wieder zu schnell aufgerissen. :duck:
Trotzdem. Allein unter iOS 7 gibt es 57 Frameworks mit zig tausenden darunterliegenden APIs. Mit iOS 8, Android, Windows Phone, Blackberry & Co. kommen noch Unmengen devicespezifischer SDKs hinzu. Kann mit keiner erzählen, dass man die ALLE in ordentlich 10KB große JavaScript Wrapper verpacken kann ...

Zumindest für iOS würde ich persönlich immer mit den nativen Frameworks arbeiten. Plattformen die man nicht kennt - vielleicht erstmal doch mit DevExtreme, um sie später nativ nachzuprogrammieren.

[sh17]

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.

[Darlo]

Eine weitere Alternative wäre react native.

[Sherlock]

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:

TechCrunch spekuliert, dass auch beliebte Toolkits wie PhoneGap oder TapJet betroffen sein könnten – ob das wirklich der Fall ist, bleibt aber unklar.

Leider habe ich sonst nicht wirklich viel zu dieser Meldung finden können. Ich möchte wirklich kein FUD verbreiten, das hier habe ich lediglich als Nebeninfo anbieten wollen.

Sherlock

[delphirocks]

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).

[Der schöne Günther]

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:

[Wosi]

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.

[SneakyBagels]

Zitat:

Embarcadero scheint an dem Markt leider kein Interesse zu haben.

Das ist es, was ich schon seit langer Zeit sehe.
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.

[Sherlock]

Zitat:

Zitat von Wosi (Beitrag 1375449)

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.

Gut zu wissen! Danke!

Sherlock

[delphirocks]

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.

[SneakyBagels]

Zitat:

Embarcadero muss einfach mehr Geld in die Entwicklung buttern und weniger ins Marketing.

Bevor das passiert, wird VisualStudio Delphi-Support haben :lol:

[delphirocks]

Ja, leider. Aber die Hoffnung stirbt zuletzt.

[Rollo62]

Bei allem was da passiert frage ich mich wie ist die Unterstützung von real world applications.
Buttons und Edits bekomme ich ja überall gut hin, Xamarin, Flutter, Phonegap, etc.
Also eine reine Controls App sollte überall gut laufen.

Wo es für mich interessant wird sind die Sensoren, Kameras, Systemintegration, etc.
Wie sieht es denn dabei mit den anderen IDEs / Frameworks aus, hat da jemand schonmal was Komplexeres gemacht ?
Ich sehe das es bei den Frameworks möglich ist, aber momöglich muss man da 100% die Grundlagen selber legen.
Oder täusche ich mich da, und die Hardwae von iOS/Android wird schon 100% gekapselt und unterstützt ?

Rollo

[DeddyH]

Ich habe von Xamarin keine Ahnung, beschäftige mich aber gerade mit Hybrid-Apps und der Kombination Angular/Cordova/Ionic (ehemals PhoneGap). Und da ist die Liste der unterstützten Plugins nicht gerade kurz.

[Rollo62]

Ja, Phonegap scheint da ziemlich weit zu sein, wenn das auch wirklich Alles sauber funktioniert.
Ich hatte gerade mal bei Flutter geschaut, entweder gut versteckt oder es ist nur sehr wenig da.

Benutzt das denn jemand sehr intensiv, und ist das dann sehr stabil.
Die üblichen Verdächtigen sind GeoLocation, AccelerationSensor, BackgroundServices, PushNotifications, Camera, Interner Zugriff (Contacts, Calendar, SMS, Telefon), Mail.

Ich denke das müsste eigentlich in fast jeder App mal mehr oder weniger vorkommen.
Gibt es da vielleicht irgendwo einen realistischen Vergleich wie weit die verschiedenen Frameworks sind.

Rollo

[Wosi]

Zitat:

Zitat von delphirocks (Beitrag 1375471)

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.

Es geht mir auch gar nicht um die Performance. Die kann bei nachgebauten Controls auch durchaus schneller sein, wenn die GPU effizient genutzt wird. Es geht mir eher um die Akzeptanz der User. Ich weiß nicht genau wie es heute aussieht, aber zumindest bis letztes Jahr waren Apps, die nicht auf die systemeigenen UI-Komponenten gesetzt haben in den App-Stores selten gut bewertet (Außnahmen bilden hier Spiele und manche Media-Player).

Über Flutter kann ich gerade nichts sagen. Das befindet sich noch im Alpha-Stadium.

Zitat:

Zitat von Rollo62 (Beitrag 1375494)

Wo es für mich interessant wird sind die Sensoren, Kameras, Systemintegration, etc.
Wie sieht es denn dabei mit den anderen IDEs / Frameworks aus, hat da jemand schonmal was Komplexeres gemacht ?
Ich sehe das es bei den Frameworks möglich ist, aber momöglich muss man da 100% die Grundlagen selber legen.
Oder täusche ich mich da, und die Hardwae von iOS/Android wird schon 100% gekapselt und unterstützt ?

Ich spreche jetzt nur über Xamarin. Bei den anderen Frameworks fehlt mir die Erfahrung.
Mit Xamarin hast du zunächst vollen Zugriff auf die nativen APIs jeder Plattform. Das heißt, du kannst mit Xamarin prinzipiell jede bestehende App nachbauen.
Nun willst du aber vermutlich nicht alle doppelt oder gar dreifach implementieren müssen, nur um ein Foto mit der Kamera aufzunehmen und es per REST-Call auf einem Server abzulegen. Dafür ist in Xamarin vieles gekapselt. Es gibt zahlreiche Bibliotheken, die Zugriffe auf native APIs hinter plattformunabhängigen Interfaces verstecken. Hier ein Beispiel aus MVVM-Cross: https://www.mvvmcross.com/documentat...er?scroll=1208

Um ein Foto auf egal welcher Platffform aufzunehmen würde es daher prinzipiell reichen Folgendes zu tun:

Code:

var task = Mvx.Resolve<IMvxPictureChooserTask>().TakePicture((*Die Parameter lasse ich mal weg*))

Abstraktionen gibt es inzwischen für nahezu alles im Xamarin-Umfeld.

Beispiele gibt es für alles mögliche:
https://developer.xamarin.com/sample...rin-forms/all/
https://github.com/MvvmCross/MvvmCross

[greenmile]

Zitat:

Zitat von Wosi (Beitrag 1375537)

Es geht mir auch gar nicht um die Performance. Die kann bei nachgebauten Controls auch durchaus schneller sein, wenn die GPU effizient genutzt wird. Es geht mir eher um die Akzeptanz der User. Ich weiß nicht genau wie es heute aussieht, aber zumindest bis letztes Jahr waren Apps, die nicht auf die systemeigenen UI-Komponenten gesetzt haben in den App-Stores selten gut bewertet (Außnahmen bilden hier Spiele und manche Media-Player).

Ich möchte an dieser Stelle nicht haten, aber meine Erfahrung nach x Jahren Firemonkey ist: Finger weg von Firemonkey, wenn es um Produkte für die Masse geht. Ich habe es bei den x verschiedenen Handy's, Tab's, Mac-Version usw nie richtig in den Griff bekommen. Mal sahen Controls anders aus, mal verschoben, fast immer unkontrollierbare Abstürze. Mal funktionierte es bei einer neueren XE Version wieder nicht, mal wurden Properties entfernt und es gab kaum einen Workaround. Ich nutze Firemonkey bzw auch den Mac-"Compiler", seitdem sie verfügbar sind, setze es aber in keinem neueren Projekt mehr ein. Verschwendete Zeit.

In Summe: Es kann, egal was Du nimmst, nur besser werden. Du wirst FMX früher oder später in irgendeiner Art und Weise bitter bereuen.

Just my 2 Cent

[Darlo]

Immerhin starten und laufen die FMX-Apps auch unter iOS 9.

[RWarnecke]

Zitat:

Zitat von Darlo (Beitrag 1375542)

Immerhin starten und laufen die FMX-Apps auch unter iOS 9.

:thumb:, wo iOS 11 schon fast vor der Tür steht.

Zitat:

Zitat von greenmile (Beitrag 1375539)

Ich möchte an dieser Stelle nicht haten, aber meine Erfahrung nach x Jahren Firemonkey ist: Finger weg von Firemonkey, wenn es um Produkte für die Masse geht. Ich habe es bei den x verschiedenen Handy's, Tab's, Mac-Version usw nie richtig in den Griff bekommen. Mal sahen Controls anders aus, mal verschoben, fast immer unkontrollierbare Abstürze. Mal funktionierte es bei einer neueren XE Version wieder nicht, mal wurden Properties entfernt und es gab kaum einen Workaround. Ich nutze Firemonkey bzw auch den Mac-"Compiler", seitdem sie verfügbar sind, setze es aber in keinem neueren Projekt mehr ein. Verschwendete Zeit.

In Summe: Es kann, egal was Du nimmst, nur besser werden. Du wirst FMX früher oder später in irgendeiner Art und Weise bitter bereuen.

Just my 2 Cent

:thumb::thumb: Bekommst meine volle Zustimmung.

[Darlo]

Zitat:

Zitat von Darlo (Beitrag 1375542)

Immerhin starten und laufen die FMX-Apps auch unter iOS 9.

Ups, natürlich 11 😅

[sh17]

Nanu? 50% auf Mobile AddOn Pack. Ich bin überrascht.

http://s608.t.en25.com/e/es?s=608&e=...=22724&elqat=1