RemObjects XE4

[jbucher]

Hallo zusammen,

wir setzen erfolgreich und gerne das RemObjects SDK ein. Nun sind wir gerade am Wechseln auf XE4 und ich habe in einem RO-Forum gelesen, dass das SDK (zumindest vorerst) nicht in Richtung FMX/IOS/... weiter entwickelt werden wird.
Gibt es Alternativen???

viele Grüße
Jürgen Bucher

[jaenicke]

DataSnap ist ja bei Delphi dabei (ab Enterprise). Das setzen wir ein. Allerdings nicht weil es besser ist (das RO SDK habe ich gehört soll besser sein und bietet wohl auch mehr, selbst aus Erfahrung kenne ich es nicht), sondern weil wir uns (nach schlechten Erfahrungen) nach Möglichkeit nicht von 3rd-Party Komponenten zusätzlich abhängig machen möchten.

Zudem funktioniert DataSnap für unsere Zwecke bisher wirklich gut, so dass wir auch gar keinen echten Grund haben nach Alternativen zu suchen, die wir dann zusätzlich zu Delphi auch immer aktualisieren müssten.

[jensw_2000]

Zitat:

Zitat von jbucher (Beitrag 1216876)

Gibt es Alternativen???

Jetzt mache ich mich bestimmt wieder unbeliebt ..
Ja.
- Delphi+VCL+"ROSDK for Delphi" für die Windows Entwicklung
- Oxygene+"ROSDK for Xcode" für OSX und iOS
- Oxygene+"ROSDK for Java" für "Java" und Android Projekte
- Oxygene+"ROSDK for .NET" für alle .Net Projekte
- Firemonkey in den Spint

Der Weg zum Lernen von echter Multi-Platform Entwicklung ist zwar etwas härter gepflastert, aber die ersten Ergebnisse sind aus meiner Sicht überzeugend.

[jaenicke]

Zitat:

Zitat von jensw_2000 (Beitrag 1216911)

Der Weg zum Lernen von echter Multi-Platform Entwicklung ist zwar etwas härter gepflastert, aber die ersten Ergebnisse sind aus meiner Sicht überzeugend.

Wobei es da weniger nur ums Lernen geht. Denn selbst wenn man die Sprachen schon kennt, bleibt das viel größere Problem:
Man muss Logik (und dabei dann nicht nur Logik der GUI) mehrfach implementieren, während das bei reinem Delphi Code wirklich nur die reine GUI betrifft, die logischerweise etwas anders gestaltet ist.

Deshalb muss man da schon abwägen wie wichtig welcher Faktor ist. Echte native Entwicklung inkl. nativer GUI in der entsprechenden Umgebung mit entsprechend deutlich höheren Entwicklungskosten und längerer Entwicklungszeit oder ein schnellerer Weg auf die entsprechenden Geräte mit moderaterem Aufwand. Wenn man die Manpower dafür hat, ist die einzelne Umsetzung für die Plattformen denke ich auch der bessere Weg. Als kleine Firma ist es aber schwierig das zu stemmen, da macht das für die meisten Fälle wohl weniger Sinn. Zumal der reine Endverbraucher den Unterschied eher nicht mitbekommt.

[jensw_2000]

@Jeanicke

Teilweise gebe ich dir recht.

Man muss aber nur den Code plattformspezifisch neu entwickeln, der mit den nativen Klassen der Platform arbeitet. alles andere ist reiner Oxygene Code. Bedeutet, je sauberer man die "Units" trennt, desto weniger muss man für andere Systeme doppelt schreiben..o
Das Problem ist beim ROSDK aber ohnehin recht gut entschärft, weil die echte Business Logik im 'Normalfall' ja doch im Service umgesetzt wird. Den Service kann man bequem unter Windows laufen lassen. Da braucht man sich nicht von Delphi trennen.

Nachteile von Oxygene sind aus meiner Sicht:
es dauert wirklich viel länger um zu einem Ergebnis zu kommen. Besonders weil alles neu ist und man sich komplett neu reindenken muss.
Vorteil ist: native Controls, voller Zugriff auf die APIs und Komponenten, jedes Xcode oder Android Demo kann man schnell für Oxygene umbauen. Wenn mit iOS 7 wirklich der Cocoa style geändert wird, dann muss man nicht jedes Control im Delphi neu 'malen'. Ist einfach da, weil nativ....


Vorteil von Oxygene ist ebenfalls, dass der Akku bei normalen cocoa Apps nicht nach 3 Stunden leer ist, weil dort keine FMx OpenGL Clone- UI Komponenten gerendert werden müssen. Und das iPhone bleibt beim benutzen der App kalt und... Android geht dort auch schon 'nativ' 8-). Die Cocoa Controls haben dann natürlich auch ein 100% natürliches Verhalten. Das merken die Anwender dann auch irgendwie (zumindest unterbewusst).

Das ROSDK ist mit Delphi und Oxygene für alle Plattformen verfügbar. Das war auch ein Punkt, warum ich mich gegen FMX entschieden habe.

(Auf dem Handy getippt. Bitte Typos ignorieren)