Gemeinsame Codebasis für Desktop und Mobile???

[BlackGuest]

Zitat von arnof:

Klar gibt es eine gemeinsame Codebasis

Die GUI ist aber unterschiedlich!

Eine App sollte sich schon zwischen Handy und Tablet unterscheiden. Für den Desktop sollte Sie sicher auch optimiert anders aussehen. Sie kann aber die gleiche Codebasis haben

Genau das meinte ich. Für Handy und Tablet kann ich in einem Projekt arbeiten, Für den Desktop brauche ich aber ein neues.?
Von den Möglichkeiten der Darstellung etc. habe ich auf einem Tablet meist Möglichkeiten, die an einen Desktop heranreichen oder gar noch besser sind (Displayauflösung). Kann aber diese beiden Plattformen nicht in einem Projekt bedienen.

Gruß
BlackGuest

[arnof]

es gibt ein Video ich glaube das ist von davidi von der coderange 8 (nicht sicher) der zeigt wie man über einen Trick den Status was für ein Fenster bzw app ist einfach umschaltet via Projectmanager.

Aber wenn Du Funktionen in units auslagerst, so kannst Du diese einfach einbinden. Oder Copy und Paste, das geht auch wenn Du einen neuen Projekttype anlegst.

Was emba mit der Aussage meint, ist das Du alles in einer Umgebung machen kannst ohne alles neu (incl. Grundlagen) neu erlernen musst: xcode mac; eclipse Android; Delphi Windows, hier kann man außer der Logig oder Bildern nichts übertragen.

Also dein Problem ist kein Problem nur Bequemlichkeit!

[BlackGuest]

Zitat von arnof:

Also dein Problem ist kein Problem nur Bequemlichkeit!

Bei mehreren 1.000 Zeilen Code schon ein riesen Problem. Vor allem muss ich bei Änderungen zwei Projekte pflegen. Das ist bei größeren Projekten nicht machbar. Auslagern kann ich leider nicht alles. Es gibt zu viele Komponenten im Formular, die andere in diesem ändern.

Habe gerade mal nachgeschaut, das Projekt, welches ich aktuell für die unterschiedlichen Plattformen umstellen will besitzt 461 Komponenten in einem Formular. Gut, ca. die Hälfte sind Label, da muss ich auf nix reagieren. Der Rest aber hat meist mehrere Ereignisbehandlungsroutinen. Es ist ein kleines Projekt mit nur rund 16.000 Zeilen Quellcode.

Mein Problem hat da nichts mit Bequemlichkeit zu tun.

Ich denke mal, soooo selten ist es nicht, dass man eine Konfigurationssoftware für ein embeddet System für mehrere Plattformen anbieten will.

Zitat:

Was emba mit der Aussage meint, ist das Du alles in einer Umgebung machen kannst ohne alles neu (incl. Grundlagen) neu erlernen musst: xcode mac; eclipse Android; Delphi Windows, hier kann man außer der Logig oder Bildern nichts übertragen.

Das ist Quatsch. Es geht um eine gemeinsame Codebasis!

Gruß
BlackGuest

[Sir Rufo]

Dein Problem ist, dass du für dein Projekt den falschen Ansatz gewählt hast, und sich das nun rächt.

Für eine Mobile-Anwendung wirst du immer eine andere Art der Darstellung nutzen wollen, um es im Zielsystem harmonisch aussehen zu lassen.

Zum einen, weil der Styleguide ein anderer ist, weil der Platz und der Formfaktor anders ist, weil die grundsätzliche Bedienung einfach anders ist.

Auch wenn bei Delphi mit dem RAD geworben wird (Klatschen, Klicken, Kompilieren), bei Multiplatform hat man damit ein Rad ab oder verliert es, wenn man nicht anfängt anders zu programmieren.

Also:
Weg mit dem ganzen Codegeraffel aus den Forms was nicht direkt mit der Darstellung zu schaffen hat
Weg mit der Datenhaltung in der Form/den Controls (dort wird nur angezeigt und/oder entgegengenommen => User Interface)

Schon ist man einen Schritt weiter um mit einer gemeinsamen Codebasis Multiplatform-Anwendungen zu schreiben.

[Harry Stahl]

Zitat von Sir Rufo:

Weg mit dem ganzen Codegeraffel aus den Forms was nicht direkt mit der Darstellung zu schaffen hat
Weg mit der Datenhaltung in der Form/den Controls (dort wird nur angezeigt und/oder entgegengenommen => User Interface)

Schon ist man einen Schritt weiter um mit einer gemeinsamen Codebasis Multiplatform-Anwendungen zu schreiben.

Auch dieser Aussage von Sir Rufo kann ich nur beipflichten. Erfreulicherweise hatte ich schon vor einiger Zeit angefangen, meine Projekte in dieser Hinsicht zu entwickeln, dass macht mir den Umstieg auf FireMonkey jetzt um einiges leichter.

Auch wenn es so schön verführerisch ist, in jeden Button-Klick-Event alles reinzupacken: Vermeide es, wo es geht. Versuche insbesondere die Darstellung der Oberfläche von deiner Datenlogik zu trennen. CrossPlatttform-Entwicklung zwingt einen, sich etwas mehr Gedanken um seine Programmstrukturen zu machen, aber das kann ja nicht schaden...

[jaenicke]

Zitat von BlackGuest:

Habe gerade mal nachgeschaut, das Projekt, welches ich aktuell für die unterschiedlichen Plattformen umstellen will besitzt 461 Komponenten in einem Formular. Gut, ca. die Hälfte sind Label, da muss ich auf nix reagieren. Der Rest aber hat meist mehrere Ereignisbehandlungsroutinen.

Dass die Ereignisse nur auf die entsprechenden gemeinsamen Methoden der GUI-Ansteuerung verweisen sollten, wurde ja schon geschrieben.
Vor allem kannst du ein solches Riesenformular aber ohnehin nicht für mobile Apps 1:1 benutzen. Wie soll man das denn bedienen?

Man kann die reine GUI in den meisten Fällen nicht wirklich 100% Cross-Platform hinbekommen, egal mit welchem Tool. Einfach weil es verschiedene Eingabekonzepte sind. Man muss immer ein wenig an die konkrete Zielplattform denken und z.B. entsprechend viele oder weniger Komponenten auf das Fenster packen. Einfach weil auf die kleineren Bildschirme von Smartphones oder Tablets auch weniger draufpasst.

Und gerade für ein Konfigurationstool gilt das umso mehr. Da muss man die einzelnen Punkte erst recht am Smartphone viel mehr aufbereiten als auf dem Desktop.

[BlackGuest]

Zitat von jaenicke:

Dass die Ereignisse nur auf die entsprechenden gemeinsamen Methoden der GUI-Ansteuerung verweisen sollten, wurde ja schon geschrieben.
Vor allem kannst du ein solches Riesenformular aber ohnehin nicht für mobile Apps 1:1 benutzen. Wie soll man das denn bedienen?

Man kann die reine GUI in den meisten Fällen nicht wirklich 100% Cross-Platform hinbekommen, egal mit welchem Tool. Einfach weil es verschiedene Eingabekonzepte sind. Man muss immer ein wenig an die konkrete Zielplattform denken und z.B. entsprechend viele oder weniger Komponenten auf das Fenster packen. Einfach weil auf die kleineren Bildschirme von Smartphones oder Tablets auch weniger draufpasst.

Und gerade für ein Konfigurationstool gilt das umso mehr. Da muss man die einzelnen Punkte erst recht am Smartphone viel mehr aufbereiten als auf dem Desktop.

Es sind zwar recht viele Komponenten, die sind aber natürlich nicht alle auf einmal sichtbar. Sie sind zu meist in einem bzw. in mehreren TabSheets untergebracht. Die aktuelle Software auf dem Windows Desktop ist nur ein kleines Toolfenster (550x430) mit seehr großer Schrift in den Komponenten. Das würde genau so in der Art auch auf ein Smartphone passen.

So wie ich die Sache jetzt sehe bekomme ich das Ganze nur wirklich plattformübergreifend hin, wenn ich komplett alle Komponenten im Desktop-Projekt kopiere, dann in das Mobile Projekt einfüge und genau so mit meiner Software verfahre. Ist aber trotzdem doppelte Arbeit, die man bei ständigen Änderungen nicht unterschätzen sollte. Das muss doch irgendwie anders gehen.

Es geht mir auch weniger darum, das GUI plattformübergreifend hinzubekommen. Da ist klar, dass mehr oder weniger kleine Änderungen druchgeführt werden müssen. Aber die Codebasis wird (jedenfalls für das GUI) für alle Plattformen die gleich bleiben.

@Sir Rufo & Harry Stahl
Danke für eure Hinweise. Allerdings habe ich nicht den falschen Ansatz gewählt. Es geht darum ein bestehendes Projekt dahingehend abzuändern, dass es plattformübergreifend verwendet werden kann. Dass dort einiges im Code geändert werden muss ist schon klar.
Was das unterschiedliche Aussehen auf den unterschiedlichen Plattformen anbetrifft, das ist auch klar. Aber die Codebasis kann doch die gleiche bleiben.

Vor ein paar Jahren, ich glaube das war noch unter Delphi 5 habe ich mal eine mehrsprachige Anwendung entwickelt. Ist schon lange her, aber da konnte man doch auch die ganzen Formulare für jede Sprache anpassen. Ich hatte eine Vorlage und konnte für jede Sprache die Eigenschaften der Komponenten (Größe, Position etc.) extra anpassen.
So in der Art müsste es doch auch für die unterschiedlichen Plattformen funktionieren, wenn man für alle Plattformen kompatible Komponenten verwendet. Für die FMX trifft das ja zu.

Gruß
BlackGuest

[BlackGuest]

So würde es funktionieren, würde aber auch einfacher gehen.

--> siehe Anhang

Für jede Umgebung ein Projekt, diese in einer Projektgruppe zusammengefasst.

Das Projekt enthält nur die Oberfläche und einen Verweis auf die auszuführenden Funktionen für jedes Steuerelement. Einmal für Windows (Project2.exe / windows_GUI.pas) und einmal für Android (libProject3.so / Android_GUI.pas). Alle Funktionen lagere ich in die gemeinsame AllFunctions.pas aus. Zum Beispiel OnClick für einen Button. So würde es denke ich funktionieren. Die beiden Oberflächen lassen sich unabhängig voneinander anpassen und ich habe eine gemeinsame Codebasis.

Allerdings muss ich, wenn ich einen zusätzlichen Button einfüge diesen in beide Formulare einfügen UND den Verweis auf die Behandlungsroutine in der AllFunktions.pas. Letzteren Schritt könnte man allerdings einsparen.

Gruß
BlackGuest

[Sir Rufo]

Also ich (und wohl einige andere hier auch) hatten mehr ein ViewModel, das als Fassade implementiert ist, im Kopf.

Dann gibt es nur noch Eigenschaften und simple Methoden ohne Parameter:

Delphi-Quellcode:

TFooViewModel = class( TViewModel )
public
  property FirstName : string;
  property LastName : string;

  procedure Save;
  procedure Print;
end;

Jetzt können diese ViewModels mit den Forms verdrahtet werden, wobei lediglich die Eigenschaftswerte vom ViewModel an die Controls übergeben werden und umgekehrt bei Änderungen am Control diese Werte zurück zum ViewModel geschrieben werden.

Aktions-Events (Button, etc.) rufen einfach die entsprechenden Methoden des ViewModels auf.

Schon hat man das UI vom eigentlichen Code getrennt und kann das UI auch beliebig austauschen, bzw. für mehrere Plattformen anbieten.

(Wenn in der Küche jetzt nicht ein paar Gänsefüße auf mich warten würden, würde ich auch ein Beispiel-Projekt anhängen - kommt aber später noch)