Gemeinsame Codebasis für Desktop und Mobile???

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

[stahli]

So lange die Gänsefüße kochen kann man zum Thema auch etwas hier nachstöbern: http://www.delphipraxis.net/176478-m...realitaet.html

[BlackGuest]

Danke noch mal für alle Antworten.
Hatte mir auch ein paar Tage Auszeit gegönnt. Hoffe mal alle haben die Feiertage gut überstanden.

Ich werde mich wohl oder übel von der Herangehensweise etwas umstellen müssen.
Ist auch kein Problem das Projekt komplett neu aufzuziehen. An realen Aufgaben lernt man am Besten.

@Harry Stahl
Ist das hier -->http://www.amazon.de/Cross-Platform-...rds=delphi+xe5 von dir?

Werde ich mir gleich mal holen. Dann muss ich euch auch nicht mit zu vielen (dämlichen) Fragen nerven.

Gruß
BlackGuest

[Edit]
@Stahli
Danke für den Link. Hat mir schon mal sehr geholfen.

[Thomas_K]

Das Thema "Testen, Änderen, Erweitern, Wiederverwenden" von Quellcode findet meiner Meinung nach eine zu geringe Bedeutung in Delphi bzw. unter Delphi Entwicklern, mich eingeschlossen. Die grundlegende Problematik ist nicht neu und das Internet bietet zu dem Thema viel - nur mit guten Delphi Beispielen sieht es nicht ganz so rosig aus. Es gibt zwar hier und da ein altes Schulprojekt und auch mal ein Blog Post, doch umfassend für Delphi hab ich noch nix finden können. Ein interesanten Einstieg zu diesem Thema bietet dieser Artikel http://www.christian-rehn.de/2012/09...igen-systemen/.

[Furtbichler]

Zitat von Thomas_K:

Das Thema "Testen, Änderen, Erweitern, Wiederverwenden" von Quellcode findet meiner Meinung nach eine zu geringe Bedeutung in Delphi bzw. unter Delphi Entwicklern, mich eingeschlossen.

Mich früher auch.

Es fehlt der mutige Projektleiter, der die Investition in die Nachhaltigkeit (aka höheres Budget) gegenüber den Stakeholdern durchsetzt. Solange der Kunde meint, ein Programm für Dreifuffzich ist genauso gut wie eins für Fünfndreisssch, wird der arme Softwareentwickler nie in der Lage sein, das Thema 'Testen' ernsthaft anzugehen.

Es ist nun einmal so, das ordentliche (Unit-Tests) 40-60% des gesamten Codes ausmachen.

[Bernhard Geyer]

Zitat von Furtbichler:

Es fehlt der mutige Projektleiter, der die Investition in die Nachhaltigkeit (aka höheres Budget) gegenüber den Stakeholdern durchsetzt. Solange der Kunde meint, ein Programm für Dreifuffzich ist genauso gut wie eins für Fünfndreisssch, wird der arme Softwareentwickler nie in der Lage sein, das Thema 'Testen' ernsthaft anzugehen.

Vielleicht sollt aber der "arme SW-Entwickler" einfach seine Aufwandsabschätzungen immer nur incl. Test und Dokumentation abgeben und diesen Punkt nicht extra ausweisen?

[Mavarik]

Zitat von Furtbichler:

Es ist nun einmal so, das ordentliche (Unit-Tests) 40-60% des gesamten Codes ausmachen.

Echt?

Wir hatten diese Thema auch auf unserem letzten Delphi-Frühstück.

Auch da lasse ich mich gerne eines besseren belehren, aber wir waren zu 70:30 der Meinung, dass wenn ich in der Lage bin die richtige Testroutine zu schreiben, kann ich auch den "richtigen" Code schreiben.
Bzw. die Fehler, die heute in "unseren" Programmen auftreten sind genau die, die eine Testroutine auch nicht gefunden hätte.

Vielleicht sieht es anders aus, wenn man bei einem neuen Projekt vom ersten Tag an die Tests mit programmiert, aber was ist mit unzähligen Routinen die man immer verwendet?

Bist Du der Meinung es loht sich im nachhinein dafür Testroutinen zu schreiben?

Mavarik

[Bernhard Geyer]

Zitat von Mavarik:

Auch da lasse ich mich gerne eines besseren belehren, aber wir waren zu 70:30 der Meinung, dass wenn ich in der Lage bin die richtige Testroutine zu schreiben, kann ich auch den "richtigen" Code schreiben.
Bzw. die Fehler, die heute in "unseren" Programmen auftreten sind genau die, die eine Testroutine auch nicht gefunden hätte.

Das Testroutinen auch nur Quellcode ist, ist er nicht perfekt. Wenn ein Fehler auftritt kann man ja auch die Testroutinen ergänzen das er in Zukunft auch geprüft wird.

Zitat von Mavarik:

Vielleicht sieht es anders aus, wenn man bei einem neuen Projekt vom ersten Tag an die Tests mit programmiert, aber was ist mit unzähligen Routinen die man immer verwendet?
Bist Du der Meinung es loht sich im nachhinein dafür Testroutinen zu schreiben?

Wenn das Programm noch nicht sein EOL erreicht hat ja. Denn dann lebt ja der Code noch und wird in den nächsten Jahren u.U. auch verändert. Dann ist es gut wenn man Testroutinen hat die die Funktionsfähigkeit nach der Änderung einfach überprüfen kann.

[Harry Stahl]

Zitat von BlackGuest:

@Harry Stahl
Ist das hier -->http://www.amazon.de/Cross-Platform-...rds=delphi+xe5 von dir?

Werde ich mir gleich mal holen. Dann muss ich euch auch nicht mit zu vielen (dämlichen) Fragen nerven.

Ja, ist es. Hoffe, es hat Dir zumindest einige Fragen beantwortet. Generell ist anzumerken, dass es "nur" die Plattformen Windows / MAC abdeckt, aber selbst da ist ja schon einiges, was man wissen muss. Für Mobile (Android / IOS) werde ich wohl noch ein eigenständiges Buch machen (eigenständig, weil nicht alle Entwickler wirklich alle Plattformen abdecken wollen, nicht wenige wollen nur Desktop oder nur Mobile). Derzeit bin ich dabei mein PC-Adreßzz! für IOS (pc-adress), welches ich noch mit XE2 gemacht habe, auf XE5 (IOS und Android) zu portieren. Das wird mit XE5 viel besser, schneller und nativer. Bin schon fast fertig, ging einfacher als gedacht, erfreulicherweise konnte ich viel vom XE2-Code weiterverwenden (selbst viele Form-Bestandteile ließen sich per Copy und Paste in XE5-Formulare übernehmen).

Hier war insofern auch schon eine Hilfe, dass die Datenlogik außerhalb der Formulare lag und liegt.

Die Android-Version entsteht dabei quasi nebenbei automatisch (OK, abgesehen von einigen Plattform-Spezifikas). Auf Android freue ich mich wirklich riesig, da hier Vertrieb und Update-Zyklen außerhalb des Google-Play-Stores einfacher zu gestalten sind und für mich daher einen großen Anreiz darstellen.

[BlackGuest]

Sorry, dass ich mich erst jetzt wieder zum Thema melde. Ich musste mich zwischenzeitlich um eine andere Geschichte kümmern.

@Harry Stahl
Super Buch. Ich bin zwar noch nicht komplett durch aber es hat mir schon sehr geholfen. Vor allem, wenn man bedenkt, dass meine letzte Version Delphi XE war. Hat sich doch einiges geändert.

Ich denke ich sollte wie folgt vorgehen:

Für den Datenaustausch mit dem Embedded System habe ich bereits eine fertige Komponente, die den Datenverkehr mit dem Endsystem übernimmt.
Aktuell ist das eine Sammlung von Befehlen, mit der ich bestimmte Daten abfragen kann. Die einzelnen Funktionen liefern mir direkt die Daten, die ich haben will.

--> Für eine Plattformübergreifende Anwendung ungeeignet

Also definiere ich mir die Datenfelder als Property dieser Komponente und kann diese dann über die Live-Bindings mit den visuellen Komponenten auf dem UI verknüpfen.

Die Komponente muss ich dann natürlich noch so weit anpassen, dass der Teil, der auf die Schnittstellen zugreift entsprechend der Zielplattform den richtigen Code verwendet. Da muss ich noch einigen Hirnschmalz reinstecken. Aber wenn ich es konsequent für Windows umsetze sollte die Erweiterung auf die anderen Plattformen kein Thema sein.
Ebenfalls in diese Komponente müssen die Timergesteuerten Funktionen wie zyklische Abfragen bestimmter Prozessparameter. Die Implementation ist dann auch wieder Plattformabhängig.

Bei konsequenter Umsetzung kann ich wirklich mit dem reinen UI ohne jede Zeile Code (in diesem) arbeiten und habe damit eine wirklich plattformübergreifende Lösung.

Die Portierung von der Windows Desktop Anwendung auf eine mobile Umgebung ist dann auch recht einfach. Wenn ich nur visuelle Komponenten verwende, die für alle Plattformen verfügbar sind kann ich einfach den Inhalt meiner Form in das Android Projekt kopieren. Design anpassen, compilieren und fertig.

Sollte doch vom Ansatz her so realisierbar sein oder?

Gruß
BlackGuest

PS: Sorry, dass ich mich am Anfang etwas blöde angestellt habe aber Live-Binndings gabe es unter Delphi XE noch nicht. Die Möglichkeiten waren mir von daher noch gar nicht bekannt. Immer gut, wenn man mal über seinen Tellerrand hinausschaut.