Android Apps mit Delphi

[Phoenix]

Zitat:

Zitat von mkinzler (Beitrag 1106823)

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

Stimmt. In welcher Form es tatsächlich auf den Markt kommt ist noch nicht ganz raus (oder zumindest habe ich davon bisher noch gar nichts gehört).

Wenn man ernsthaftes Interesse an der Beta von Cooper hat, bitte mal eine Mail an jim at remobjects.com schicken. Er kümmert sich dann darum.


Zum Thema Portierung von Bestandsanwendungen:
In 99,999% aller Fälle macht das so gar keinen Sinn. Insbesondere mobile Geräte haben ganz spezielle Use-Cases und, und das ist vielleicht die wichtigste Einschränkung gegenüber Desktop-Anwendungen, a) nicht immer eine Netzwerkverbindung und b) vor allem noch begrenzte Ressourcen.

Zudem erfordert die Oberfläche von mobilen Geräten in aller Regel Berührungs- und Gestengesteuerte Interaktion (die kleinen Tablet-PC's mit Tastatur mal ausgenommen, die inzwischen am aussterben sind), und das lässt sich eigentlich nie auf bestehende Oberflächen mappen.

Das heisst eine Anwendung Mobil-Fähig zu machen bedeutet vor allem eines:
Die bisherige Anwendung mit einer sauberen Architektur versehen.

Dazu gehört, wenn man eine wie auch immer geartete zentrale Datenhaltung hat, diese in einen Application Server auslagern (Stichwort N-Tier Architektur) und die *ganze* Business-Logik aus den Forms in den Application Server umziehen. Das ganze Zeug muss Head-Less (ohne UI) laufen können, und das UI muss derart umgestaltet werden, dass es ausschliesslich ein bisschen Code beinhaltet um das UI zu steuern. Zwischen Backend und UI fehlt dann logischerweise der 'Kleber' (Glue-Code), den man wenn man alles richtig macht dann z.B. in Delphi mit dem MVC-Pattern relativ flott hin bekommt.

Im nächsten Schritt kann man dann die neuen mobilen Applikationen mit einem für die jeweilige Plattform spezifischen UI an den Application Server anhängen. Hier hat man dann zumindest mit .NET und Delphi Prism die Möglichkeit den Code für die Kommunikation mit dem Application Server und das Clientseitige Model zentral zu pflegen und muss das Model dann nur noch mit den jeweiligen GUI-Toolkits auf die Geräte bringen.

Alles in allem: Ja, das ist ein massiger Aufwand. Wenn man den aber nicht betreibt und seine Altlasten für mobile Anwendungen Umbiegt holt man sich damit massive Probleme ins Haus deren Behebung dann a) viel aufwendiger ist als es gleich richtig zu machen und b) Seiteneffekte auf den Altcode hat der nochmal aufwand erzeugt und man um das zu vermeiden die Codebasis trennt und dann bei Änderungen c) doppelten / dreifachen / vierfachen (je nach Anzahl Zielplattformen halt) Pflegeaufwand hat.

[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:

Zitat von BoolString (Beitrag 1107066)

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:

Zitat von BoolString (Beitrag 1107066)

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

[Bernhard Geyer]

Zitat:

Zitat von BoolString (Beitrag 1107066)

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.

[hanspeter]

Zitat:

Zitat von Robotiker (Beitrag 1107081)

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

[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:

Zitat von mschaefer (Beitrag 1107124)

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.