Firemonkey vs. Xamarin

[mkinzler]

Zitat von mquadrat:

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 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?hl=de&sl=ja&u=http://blogs.embarcadero.com/teamj/2014/07/04/4634/&prev=/search%3Fq%3Dhttp://blogs.embarcadero.com/teamj/2014/07/04/4634/%26client%3Dfirefox-a%26hs%3DFGb%26rls%3Dorg.mozilla:defficial%26cha nnel%3Dsb

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

[mquadrat]

Zitat von mkinzler:

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