RAD Studio XE7: Was Entwickler davon halten...

[Harry Stahl]

Zu Delphi XE7 kann ich noch nicht allzu viel sagen, außer, dass es bislang einen guten Eindruck macht und ich den Multidesigner-Ansatz wirklich revolutionär finde. Produktiv habe ich damit derzeit eine neue IOS- und Android App erstellt und in den IOS-Store gebracht (Android-Apps vertreibe ich derzeit noch über meine Homepage).

Ansonsten laufen aktuelle Projekte noch unter

D2007 (meine kommerziell erfolgreichsten Produkte sind hier noch überwiegend)
Delphi XE
Delphi XE2
Delphi XE3
Delphi XE4
Delphi XE5

(XE6 habe ich nicht verwendet, da alte FMX-Projekte nicht akzeptabel übernommen wurden, bzw. nur mit zu viel Aufwand, hatte ich ja schon mal drüber berichtet).

Delphi 5 und Delphi 7 waren meine Favoriten von den älteren Versionen, damit arbeite ich aber nicht mehr.

Lieber arbeite ich mit den neueren Versionen ab XE aufwärts, nicht nur wegen der Klasse-Erweiterungen im Sprachumfang (einmal verwendet, will man nie mehr drauf verzichten, sei es TDictionary, TPath, TDirectory, TFile, Diagnostics, Erweiterungen von DateUtils, usw.), sondern auch wegen des Handlings in der IDE, welches die Verwaltung von Projekt- und Build-Gruppen deutlich vereinfacht. Davon abgesehen haben die einzelnen VCL-Komponenten mit der Zeit zusätzliche Properties und Optionen erhalten, die auch sehr hilfreich sind (z.B. "Texthint", welches in Delphi 2007 und früher noch nicht existierte, oder Dropdown-Menü für TButton, der dann als Split-Button verwendet werden kann). Nützlich auch die neuen Open- und Save-Dialoge, die sich die Position und Größe der Fenster merken können und wo man anwendungsspezifische Favoriten-Links in den Dialogen anzeigen lassen kann.

Und als FMX-Überzeugter ist mir ab XE2 natürlich die Entwicklung für neue Plattformen wichtig.

[MichaelT]

Ich merke das bei höheren Auflösungen. Auf meinem Laptop muss auf 200% vergrößern der hat 4k bei 17" aber Touch und Gestures. Da merkt man dann bei den Windows Applikationen losgelöst von Delphi wer welche Settings wo zieht. Da muss ich mir den FMX mal anschauen zu dem Thema. 200% geht noch aber bei 150% und 250% stimmt der Gesamteindruck obwohl technisch korrekt egal welche Applikation womit implementiert und Windows das bügelt. Ich kanns für die VCL jetzt noch nicht beurteilen.

Es sind zwar an sich nur die Kalter Boys (PL-SQL Developer) so 'wahnsinnig' und ignorieren die Vergrößerung komplett - da liest man nicht mehr viel bei 1:1. Beim Standgerät 1:1 gibt das etwas her.

Zitat von Harry Stahl:

Und als FMX-Überzeugter ist mir ab XE2 natürlich die Entwicklung für neue Plattformen wichtig.

[RWarnecke]

Ich muss sagen, dass Delphi für Windows nach meiner Meinung immer noch eine sehr gute Entwicklungsumgebung ist. Ich bin mit XE2 in die mobile Entwicklung eingestiegen, was ich aber deutlich zu umständlich fand. Erst richtig mit der mobilen Entwicklung habe ich bei XE4 losgelegt und habe es bis XE6 auch durchgezogen. Aber diesen Updatezyklus von Emba kann ich beim besten Willen nicht mehr verstehen. Beim Update von XE5 auf XE6 habe ich bis heute bei einer Komponente warten müssen, bis diese für XE6 verfügbar war. Als ich die Nachricht lass, war mein erster Gedanke muss ich jetzt wieder bis XE8 warten, bis die Komponente für XE7 verfügbar ist. Nein, es war nicht so, die haben in die neue Version gleich den Support für XE6 und XE7 reingepackt.

Nun aber zu XE7. Ich arbeite mittlerweile nur noch mit einem Mac und darauf habe ich eine Parallels VM mit Windows 8.1. Bis XE6 konnte ich mir einen Ordner vom Mac als Netzlaufwerk verbinden und dann darauf die Projekte von Delphi ablegen. Seit XE7 bekomme ich unter Android hier immer einen Fehler und kann somit kein Android-Projekt mehr sauber und vernüftig kompilieren. Hier dazu der Beitrag im Forum und der QC-Eintrag. Der Multidesigner ist aus meiner Sicht auch nicht das gelbe vom Ei. Verändere ich etwas im Master, wird dieses nicht auf die angelegten Ansichten durchgereicht, um nur ein Beispiel zu nennen. Aus meiner Sicht ist XE7 zur Zeit für mich so nicht einsetzbar. Ich werde zum heutigen Zeitpunkt Emba noch die Chance geben es mit Service Packs und XE8 die verschiedenen Dinge zu beheben. Sollte das nicht passieren, werde ich meinen Wartungsvertrag im nächsten Jahr auslaufen lassen. Meine Euphorie in Sachen Android-Studio und XCode ist derzeit Größer als mit Delphi Apps für Smartphones und Tablets zu entwickeln. Viele Dinge, die in XCode und/oder Android selbstverständlich sind musste ich in Delphi erst umständlich selber realisieren.

Aus meiner Sicht, muss man bei solchen Crosscompilern immer Kompromisse eingehen. Ich will die Aussage nicht über einen Kamm scheren, aber mir wird zumindest seitens Emba diese Meinung deutlich vermittelt.

[Mavarik]

Zitat von RWarnecke:

Aus meiner Sicht, muss man bei solchen Crosscompilern immer Kompromisse eingehen. Ich will die Aussage nicht über einen Kamm scheren, aber mir wird zumindest seitens Emba diese Meinung deutlich vermittelt.

Also der neue Designer aus XE7 ist für mich auch überhaupt nicht zu gebrauchen. Ich habe mir aus Ermangelung eines solchen, unter XE5 schon einen Fenster/Frame Handler geschrieben, der eigentlich genau das macht... Device unabhängig meine Forms darstellen und zwar ohne Kompromisse auf allen Plattformen...

Und nein ich will gar nicht das es so aussieht wie alle Apps je nach Plattform unterschiedlich... Meine App soll wie meine App aussehen und zwar überall gleich... Also Premium-Style verwenden, anpassen und fertig.

Meine App sieht auf iOS, Android, Windows, MacOS immer gleich aus...
Ein Sourcecode!
Nur in meiner eigenen Mobilen-Helper-Unit sind die IFDEF's der Rest ist Plattform unabhängig...

XE6 war hier schon richtig gut. Aber an XE7 kommt man nicht vorbei, denn nur in XE7 sind die Bugs behoben. Außer denen die immer noch drin sind. ;-(

Zum Vergleich die erste compilierfähige Version für Android war auf meinem Nexus 10 so langsam, dass man nicht mit arbeiten konnte. Mit XE7 ist die Android App um ein vielfaches schneller als auf meinem iPad und immer noch schneller als auf meinem iPhone 5.

Es hat sich also einiges verändert...

Mavarik

[RWarnecke]

Meine Aussage mit den Kompromissen bezieht sich nicht nur auf das designen der GUI sondern auf alles. Für mich ist es immer noch ein Rätsel, wie ich API-Befehle von iOS entsprechend für Delphi umsetze. Bei XCode kann ich den API-Befehl entsprechend anwenden und funktioniert auf Anhieb. Das gleiche ist mit der Windows-API. Hier habe ich eine ähnliche Konstellation. Einfach im MSDN nachschauen, wie der Befehl aufgebaut ist und das ganze entsprechend nach Delphi übersetzen. Das nenne ich einfache und schnelle Entwicklung.

Die genannten Beispiele vermisse ich sehnlichst bei Firemonkey. Wenn ich erst hier und da etwas casten muss und dann noch irgendwo zwischen speichern oder sonst irgendwas machen muss, behindert mich das nur in meiner Arbeit. Ein gutes Beispiel ist die Komponente TLocationSensor. Dieser hat bei mir schon seit XE4 nicht richtig funktioniert. Ich habe lediglich nur die Ermittlung der Geo-Koordinaten von der Komponente abgezogen und den Rest selber berechnet und ausgewertet. Aber es ist ja nicht nur die Komponente, einfach das ganze Aussehen, die oft schon angesprochene Performance der Apps. Eine Delphi iOS App macht einfach nicht das her, was eine XCode App her macht. Das ist zumindest meine Meinung, nach jetzt 4 Versionen von Delphi, womit man iOS und Android Apps erstellen kann.