AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Cross-Platform-Entwicklung Gemeinsame Codebasis für Desktop und Mobile???

Gemeinsame Codebasis für Desktop und Mobile???

Ein Thema von BlackGuest · begonnen am 21. Dez 2013 · letzter Beitrag vom 29. Jan 2014
Antwort Antwort
Seite 2 von 3     12 3   
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
8.144 Beiträge
 
Delphi 10.4 Sydney
 
#11

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 22. Dez 2013, 01:06
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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
BlackGuest

Registriert seit: 30. Jan 2009
52 Beiträge
 
Delphi XE7 Professional
 
#12

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 22. Dez 2013, 12:06
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

Geändert von BlackGuest (22. Dez 2013 um 12:22 Uhr)
  Mit Zitat antworten Zitat
BlackGuest

Registriert seit: 30. Jan 2009
52 Beiträge
 
Delphi XE7 Professional
 
#13

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 22. Dez 2013, 14:43
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
Miniaturansicht angehängter Grafiken
unbenannt.png  
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#14

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 22. Dez 2013, 15:17
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)
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli
Online

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.236 Beiträge
 
Delphi 10.4 Sydney
 
#15

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 23. Dez 2013, 13:30
So lange die Gänsefüße kochen kann man zum Thema auch etwas hier nachstöbern: http://www.delphipraxis.net/176478-m...realitaet.html
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
BlackGuest

Registriert seit: 30. Jan 2009
52 Beiträge
 
Delphi XE7 Professional
 
#16

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 27. Dez 2013, 10:22
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.

Geändert von BlackGuest (27. Dez 2013 um 10:33 Uhr)
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#17

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 27. Dez 2013, 12:26
Schon hat man das UI vom eigentlichen Code getrennt und kann das UI auch beliebig austauschen, bzw. für mehrere Plattformen anbieten.
Leider ist das nicht so einfach. Ein ViewModel modelliert ja auch (wie schon erwähnt) die Eingabemetapher, also Auswahllisten, Reaktion auf Eingaben ('OnChanged') usw. Es ist quasi (und daher auch der Name) ein Modell des Frontends (View), das der Benutzer sieht: Und das ist nun einmal auf den Bildschirm, das OS, die Eingabegeräte und den Anwender zugeschnitten (hoffentlich jedenfalls).

Die ViewModels wurden entwickelt, um die Anforderungen an eine moderne (Web)-UI parallel umsetzen zu können und das Frontend bezüglich Layout jederzeit austauschen zu können. ViewModels eignen sich weniger, um Cross-Plattform zu entwickeln, wobei die 'Plattform' hier die Hardware (Bildschirm, Eingabegeräte usw) ist.

Die Codebasis wäre hier (und eigentlich überall) die Businesslogik. Jedes Businessoperation (z.B. Adressänderung) auf einem Businessobjekt (z.B. ein Kunde) wird in einer Klasse gekapselt. Diese Klasse ist dafür zuständig, im Maschinenraum die notwendigen Operationen durchzuführen, um die Adresse eines Kunden zu ändern. Dazu gehören insbesondere die Persistierung sowie Validierungen aber auch die Vorbereitung eines Kundendatensatzes. Diese Klasse ist damit ideal wartbar, höchst flexibel, leicht (und vollständig!) testbar und auch in einem Batchbetrieb zu verwenden. Wenn man irgendwann 1000000 Adressänderungen vornehmen muss (anderes Adressformat, andere PLZ sonstwas), freut man sich, eine derartige Businessoperation fertig (und einsatzbereit, da durch Unittests abgesichert!) in der Schublade zu haben.

Ein Viewmodel wird also für die Adressänderung nur die BO-Klasse instantiieren, die Eigenschaften der BO-Klasse an die eigenen Eigenschaften weiterleiten und Validierungen und Persistierung entsprechend übernehmen. Dabei ist das VM 100% an die entsprechende Oberfläche angepasst bzw. spezialisiert: Es muss wirklich nur diese eine (VCL)-Form bedienen, im Extremfall auch mit genau dieser Auflösung (Auf einem 600x800 Bildschirm kann eine andere Metapher umgesetzt werden). Wenn die FMX-Form zufällig genauso aussieht, wie das VCL-Pendant, gut. Muss es aber nicht. Man muss ja nur das Viewmodel anpassen.

Also: Im Ideallfall kommt ein Formular ganz ohne Code aus (die Bindings stehen in der DFM oder wird über Attribute gesteuert). Das Binding kann auch im FormCreate/FormActivate stehen. Wenn man es nicht ganz auf die Spitze treiben will (pragmatischer Ansatz), kann man ein wenig Speziallogik auch in einem Formular unterbringen (konditionales Einfärben), aber die Tendenz muss sein: Keine Logik im Formular.

Nun kann man trefflich streiten: Wenn das VM doch eh nur für (normalerweise) genau ein Formular gebaut ist, wieso packt man dann nicht diese Logik gleich ins Formular rein? Ist doch weniger Arbeit. Stimmt, aber dieser Code ist so nicht so einfach testbar. Man trennt also VM von UI, um die VM besser und schneller testen zu können (=Unittests für VM). Funktioniert die VM, funktioniert auch das Formular so wie gewünscht.

Für die Button-Logik könnte man Actions (bzw. etwas, das an das WPF-ICommand-Pattern erinnert) nehmen: Dort wird die Kommando-Logik implementiert (diese sind dann auch plattformunabhängig). Der 'Speichere-die-Adressänderung'-Button bzw. das Kommando weiß am Besten, wann es ausführbar ist (Adresse geändert? Kunde vorhanden?). Und es weiß auch am besten, *wie* das Kommando umzusetzen ist (sind Userrechte abzufragen?* Muss geloggt werden? usw.). Dieses Kommando kann dann sowohl in der VCL, als auch der HTML, FMX usw. -Welt verwendet werden. Auch hier gilt: Wieso betreibt man den Schmuh? Antwort: Testbarkeit, Wiederverwendbarkeit. (* Die Sicherungsschicht kann auch in der Businesslogik untergebracht sein, aber eigentlich nur dann, wenn diese so existentiell ist, das selbst Programmierer die Operationen nicht ohne besondere Rechte verwenden sollen.)

Allgemein gesprochen kapselt man die Aktionen der Businessoperationen in Kommandos, abstrahieren die konkrete Ausführung und erweitern die Operation um einen Kontext (Kann das Kommando ausgeführt werden? Hint-Texte, Hilfestellungen, Icons, Benutzerführung usw.)

Es ist nun einmal mehr Arbeit, eine mächtige und flexible Applikation zu implementieren, die auf mehreren Plattformen läuft, als eine hinge-RAD-zte. Diese Mehrarbeit ist jedoch eine Investition in die Zukunft, über die man sich im Klaren sein sollte: Entweder es lohnt sich (bzw. man geht das Risiko ein), oder nicht.
  Mit Zitat antworten Zitat
Thomas_K

Registriert seit: 16. Apr 2006
71 Beiträge
 
Delphi XE8 Professional
 
#18

Software Architektur

  Alt 27. Dez 2013, 13:10
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/.
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#19

AW: Software Architektur

  Alt 27. Dez 2013, 13:27
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.

Geändert von Furtbichler (27. Dez 2013 um 13:32 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer
Online

Registriert seit: 13. Aug 2002
16.911 Beiträge
 
Delphi 10.4 Sydney
 
#20

AW: Software Architektur

  Alt 27. Dez 2013, 13:41
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?
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:44 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf