Android Apps mit Delphi

[mkinzler]

Wobei Cooper bisher m.W. kein Produkt vom EM sondern von RO ist.

[BoolString]

Gehört hier vielleicht nicht ganz her, aber die meisten dieser Punkte beziehen sich wohl auf den Zeitpunkt, wenn man ein Projekt beginnt.

Ich habe hier ein (in den Jahren gewachsenes) Projekt von >40000 Lines of Code in Delphi 7 begonnen und in Delphi 2009 weitergeführt. Die meisten -nicht standard- Komponenten habe ich selbst geschrieben. Allerdings verwende ich auch die TCharts von Steema (in einer lizensierten Vollversion (ohne Sourcen).

Gibt es für so etwas auch Möglichkeiten entsprechende Projekte mit vertretbarem Aufwand auf andere Plattformen zu portieren. Es handelt sich um ein Projekt zur Datenbearbeitung im wissenschaftlichen Sektor (keine Vollzeitentwicklung). Mit den neuen Möglichkeiten, wie iPad und Android-Tablets, entstehen hier interessante Optionen, um so etwas auch auf mobilen Geräten einzusetzen. Aber die VCL wird ja sicherlich nicht einfach für etwas anderes portierbar sein. Hat sich da schon mal jemand mit beschäftigt oder kann mir sagen, wie da mögliche Zukunftsperspektiven aussehen?

Jan

[mkinzler]

Ein bestehendes Projekt wird sich wohl nicht einfach 1:1 portieren lassen. Das hat verschiedene Gründe:
-Die Plattformen sind verschieden
-Die VCL gibt es nur für Windows
-Die Architektur von mobilen Plattformnen ist anders
...

[CCRDude]

Zitat von Bernhard Geyer:

Zitat von arbu man:

Gibt es denn schon eine Version von Cooper zum download?

Als Beta-Tester der nächsten Delphi.Prism-Version evtl.

Oder als Beta-Tester von Cooper?
Sieht sehr fein aus, soweit ich das in einem Tag bisher evaluieren konnte.

Zitat von BoolString:

Gibt es für so etwas auch Möglichkeiten entsprechende Projekte mit vertretbarem Aufwand auf andere Plattformen zu portieren.

Ich glaube, "vertretbar" hängt da extrem stark havon ab, wie gekapselt Du programmiert hast. Sind Funktion und GUI ordentlich voneinander getrennt (gerade Delphi verleitet ja zum Gegenteil)? Ist die Funktionalität entsprechend gekapselt? Beispiel: alle Zugriffe aufs Internet nicht direkt per Indy, sondern in einer platformabhängig austauschbaren Zwischenschicht? Sind direkte API-Calls ebenfalls gekapselt?

Dann lässt sich ganz unten eine Schicht austauschen, und oben kommt eine neue GUI drauf, aber das, was richtig Zeit gekostet hat, die wirkliche Programmlogik, geht problemlos rüber.

Anderenfalls ist neuschreiben vermutlich fast schneller, bzw. ordentliches Trennen, um es in der laufenden Entwicklung zu machen.

[BoolString]

@mkinzler:

Zitat:

Ein bestehendes Projekt wird sich wohl nicht einfach 1:1 portieren lassen. Das hat verschiedene Gründe:
-Die Plattformen sind verschieden
-Die VCL gibt es nur für Windows
-Die Architektur von mobilen Plattformnen ist anders

Das die Plattformen verschieden sind ist klar. Die Geschichte mit der VCL ist auch soweithin klar; für die meisten Elemente gibt es ja aber in den verschiedenen Sprachen Äquivalente. Ich erinner mich grob, daß Borland bei seinen Compilern erst in eine Zwischenschicht übersetzt hat/haben soll, damit man Executables aus Delphi & C Projekte z.B. mit dem gleichen finalen Compiler aus der selben Zwischenschicht erzeugen konnte. Dies wäre ja ein Ansatz, daß man vielleicht eines Tages auch auf andere Zielplattformen spekulieren kann.
Die Architektur ist auch ein wichtiger Punkt. Wenn die eigentlich relevante Programmlogik allerdings universell gekapselt ist, dann würde ich darauf setzen, daß so etwas 'mit vertretbarem Aufwand' möglich sein könnte.

@CCRDude:

Zitat:

Ich glaube, "vertretbar" hängt da extrem stark havon ab, wie gekapselt Du programmiert hast. Sind Funktion und GUI ordentlich voneinander getrennt (gerade Delphi verleitet ja zum Gegenteil)? Ist die Funktionalität entsprechend gekapselt? Beispiel: alle Zugriffe aufs Internet nicht direkt per Indy, sondern in einer platformabhängig austauschbaren Zwischenschicht? Sind direkte API-Calls ebenfalls gekapselt?

Dann lässt sich ganz unten eine Schicht austauschen, und oben kommt eine neue GUI drauf, aber das, was richtig Zeit gekostet hat, die wirkliche Programmlogik, geht problemlos rüber.

Anderenfalls ist neuschreiben vermutlich fast schneller, bzw. ordentliches Trennen, um es in der laufenden Entwicklung zu machen.

Die Vertretbarkeit ist natürlich immer eine Sache der Programmierung. Ich habe in den letzten 10 Jahren sicherlich einiges dazugelernt, wie man entsprechende Geschichten trennt, obgleich Programmierung für mich immer nur Mittel zum Zweck war und ich das niemals hauptberuflich gemacht habe. Aus dem Grund hab ich da sicherlich auch Grenzwissen, was deine angemerkten Punkte betrifft. Ich bin eh dabei das ursprüngliche Projekt neu aufzusetzen, dan es sich dabei um eine zu schnell gewachsene Software handelt, die ursprünglich nur einen mystishes Datenformat in Tabellenform bringen sollte. Daraus sind dann aber schnell neue Wünsche und Forderungen entstanden die mit dem initialen Design einfach nicht mehr sauber machbar waren, aber entsprechende Workaround erforderten.

Ich habe (inzwischen) eigentlich alle (z.B.) GUI-Datenformulare von der entsprechenden Funktionaltät getrennt und in eigenen Units ausgelagert. Trotzdem gibt es immer noch Bereich (wie du ja schön angemerkt hast ) wo solche Dinge icht immer ganz trennbar sind.
Es fängt damit an, daß ich einen Datenmanager habe, der sämtliche geladenen Datensätze und die Zugriffsrechte durch einzelne Module steuert. Hier fängt es ja schon an, wie entsprechende TObjects auf einzelne Plattformen protierbar wären.

Internetzugriffe, etc. hab ich ja eigentlich gar nicht. Bei mir geht es um die Verarbeitung von Datensätzen, die je nach Format aus ASCII-Plain bis Binär in eine Matrixstruktur übertragen werden und dann Grundlage für die weiteren Verarbeitungen werden um strukturaufdeckende oder strukturprüfende Verfahren anzuwenden oder geokodierte Formate zu erzeugen, die in entsprechenden marinen Visualisierungswerkzeugen weiterverarbeitet werden können.

Auf Grund diverser Anfragen würde es mir im ersten Durchgang ja schon ausreichen, wenn ich zügig eine Linux und Mac Variante anbieten kann. Die ursprüngliche Software (obgleich schon zum damaligen Zeitpunkt weder auf Logikdesign-, wie auf auf GUI-Ebene vertretbar) hat es immerhin geschafft im UNESCO Ocean Teachers Programm für freie Software gelistet zu werden. Ich sitz seit 2-3 Jahren daran endlich mal etwas zu stricken, was zeitgemäß ist; immer mal wieder ein paar Stunden. Und für diese Arbeit würde mich auch eine breitere Basis als Win-Only interessieren.

Jan

[Robotiker]

Zitat von BoolString:

Ich erinner mich grob, daß Borland bei seinen Compilern erst in eine Zwischenschicht übersetzt hat/haben soll, damit man Executables aus Delphi & C Projekte z.B. mit dem gleichen finalen Compiler aus der selben Zwischenschicht erzeugen konnte.

Es ist wohl eher so, dass der Compilerfrontend, der die Programmiersprache parst, unterschiedlich ist und der Backend, der den Binärcode erzeugt, identisch ist. Zumindest ist das, laut Aussagen in den Newsgroups, für den neuen Compiler so geplant. Ob die jetztigen Delphi- und C++-Compiler gemeinsame Teile haben, kann ich nicht sagen. Allerdings erzeugen sie kompatible Ausgabedateien und zumindest der Linker vom C++-Builder kann beides zusammenpacken.

Zitat von BoolString:

Auf Grund diverser Anfragen würde es mir im ersten Durchgang ja schon ausreichen, wenn ich zügig eine Linux und Mac Variante anbieten kann. [...] Ich sitz seit 2-3 Jahren daran endlich mal etwas zu stricken, was zeitgemäß ist; immer mal wieder ein paar Stunden. Und für diese Arbeit würde mich auch eine breitere Basis als Win-Only interessieren.

Hier geht es in Zukunft nicht nur um die Sprache Pascal, sondern in erster Linie um das Bibliotheksdesign. Es ist ja schön , wenn Delphi, Prism und Cooper dieselbe "Muttersprache" haben, aber wenn der ganze Überbau unterschiedlich ist, kann man im besten Fall seine Programmlogik portabel machen, muss aber die GUI überall anders bauen. (Wie aber schon gesagt wurde, wegen unterschiedlicher Bedienkonzepte muss man das sowieso.)

Ich denke mal, wenn die nächste Delphi-Version rauskommt, sieht man da etwas klarer. Die 64-Bit Einführung dürfte die VCL, ähnlich wie die Unicodeumstellung, ohne allzugroße Änderungen verkraften. Aber andere Ziele wie Mac, Linux und sicher auch die neue GUI von Windows 8 dürften doch größere Neubauten erfordern. (Und nach meinen Abenteuern mit Kylix und dem C++ Builder X, werde ich erstmal eine Weile zuschauen, wie sich das entwickelt.)

[hanspeter]

Zitat von Robotiker:

Es ist ja schön , wenn Delphi, Prism und Cooper dieselbe "Muttersprache" haben, aber wenn der ganze Überbau unterschiedlich ist, kann man im besten Fall seine Programmlogik portabel machen, muss aber die GUI überall anders bauen. )

Wäre schön wenn es so wäre. Prism und Cooper haben einen wesentlich moderneren Sprachansatz als Delphi und sind nicht compatibel.
In Prism geht vieles, was man sich für Delphi seit Jahren schon wünscht.

Peter

[Bernhard Geyer]

Zitat von BoolString:

Ich erinner mich grob, daß Borland bei seinen Compilern erst in eine Zwischenschicht übersetzt hat/haben soll, damit man Executables aus Delphi & C Projekte z.B. mit dem gleichen finalen Compiler aus der selben Zwischenschicht erzeugen konnte.

Das waren Urzeiten von Pascal als man noch nicht an Delphi und C++-Builder gedacht hat.

[mschaefer]

Ist ja bei gcc-Pascal auch heute noch so, aber auch bei dem neuen Compiler war eine Aufteilung in Front- und Backend im Gespräch. Wenn sie überleben wollen, dann sind mindestens zwei Plattformen, besser drei zu bedienen. Das Aquireiren von Projekten mit Delphi ist derzeit sowas wie die Bernsteinsuche.

PS: Lieber wir hören einige Wochen länger nichts von Embra. als dass was Halbherziges kommt.

[Robotiker]

Zitat von mschaefer:

PS: Lieber wir hören einige Wochen länger nichts von Embra. als dass was Halbherziges kommt.

Ja, was neue Produkte angeht stimmt das.

Aber ich habe auch das Gefühl, dass sich die Emba-Leute auch in den Foren rar machen. Bestes Beispiel ist David Dean, der als C++ QA Engineer viele Fragen zu Compilerproblemen beantwortet hat. Als er zu Apple gegangen ist, hat man sein Blog mit vielen Infos zum C++ Builder gelöscht. Die Frage wer seinen Job übernimmt, blieb im Forum unbeantwortet.
https://forums.embarcadero.com/threa...51252&tstart=0

Zur Adaption einer neuen Entwicklungsplattform gehört auch ein gewisses Vertrauen. Daran mangelt es bei mir im Moment etwas. Für Win32 Anwendungen macht sich der C++ Builder XE als Zweit-IDE neben Visual Studio bewährt gut. Aber für Cross-Plattform hat man in C++ viele Möglichkeiten, da müsste man schon was bieten, was deutlich über kostenlose Dinge wie Qt hinausgeht, um die Kundschaft zu erreichen.