|
Gemeinsame Codebasis für Desktop und Mobile???
Hallo zusammen,
programmiere schon seit Delphi 2 mit diesem PC Anwendungen. Meine letzte lizensierte Version war XE. Jetzt bin ich auf XE5 umgestiegen um damit plattformübergreifend den gleichen Code zu verwenden. Bin also in der Hinsicht noch absoluter Frischling, auch was die FireMonkey Anwendungsumgebung darstellt. Jetzt macht es mich aber schon mal stutzig, dass ich entweder eine Firemonkey Desktop oder eine mobile Firemonkey Anwendung erstellen kann. Klar, dass die Komponenten unterschiedlich auf den unterschiedlichen Systemen aussehen aber der Code kann doch prinzipiell identisch sein, oder wo liegt hier das Problem? Muss ich wirklich alle Funktionen komplett auslagern und im Prinzip für Desktop und Mobile ein extra Projekt anlegen, was aber dann die gleichen Formulare etc. enthält??? Sorry, falls die Frage schon mal da war, dann bitte einen Link. Habe über die Suche nichts gefunden. Gruß BlackGuest |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Es gibt einfach keine gemeinsame Codebasis, weil FMX und VCL völlig unterschiedlich sind. Ausserdem hatte EMBA noch die glorreiche Idee, das Frontend des neuen Mobile-Compilers inkompatibel zu machen. Wirklich 100% common code hast Du nur bei Lazarus. Aber das hat auch schon 20 Jahre Stabilisierung hinter sich.
|
AW: Gemeinsame Codebasis für Desktop und Mobile???
Zitat:
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 :thumb: PS: FMX gibts es auch für den Desktop; beim MAC muss man FMX auch für den Desktop nehmen ;-) |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Zitat:
Nur nach meinem aktuellen Wissensstand muss ich dafür ein Projekt für die Mobile und eines für die Desktop Variante anlegen, mit identischen Komponenten und identischem Code. Das kann es doch nicht sein? Einzigster Unterschied wird evtl der visuelle Aufbau sein. Gruß BlackGuest |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Zitat:
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 |
AW: Gemeinsame Codebasis für Desktop und Mobile???
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! |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Zitat:
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.:wink: Ich denke mal, soooo selten ist es nicht, dass man eine Konfigurationssoftware für ein embeddet System für mehrere Plattformen anbieten will. Zitat:
Gruß BlackGuest |
AW: Gemeinsame Codebasis für Desktop und Mobile???
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. |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Zitat:
Deine Programm-Datenlogik kannst Du hingegen in Units auslagern, die Du mit beiden Projekten verwenden kannst. Da musst Du aber viel mit IFDEF-Direktiven arbeiten. Auch solltest Du nach Möglichkeit mit neueren Delphi-Techniken (z.B. "TPath" --> System.IOUtils.TPath.getDocumentsPath) arbeiten, da diese automatisch auf allen Plattformen das richtige Ergebnis liefern. Ein wenig komplizierter ist es geworden, weil die mobilen Anwendungen nun mit Nullbasierten Strings arbeiten. Da muss man einiges anpassen (ist ein wenig Fleißarbeit). Hier solltest Du Dir mal die TSringBuilder-Klasse ansehen, die liefert z.B. für 1-Basierte und 0-basierte Strings ebenfalls automatisch das richtige Ergebnis zurück. Zudem bieten diese neuen Techniken eine Reihe von Annehmlichkeiten, die man nicht mehr missen möchte, wenn man Sie einmal zu schätzen gelernt hat. |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Zitat:
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... |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Zitat:
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. |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Zitat:
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 |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Liste der Anhänge anzeigen (Anzahl: 1)
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 |
AW: Gemeinsame Codebasis für Desktop und Mobile???
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:
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.
TFooViewModel = class( TViewModel )
public property FirstName : string; property LastName : string; procedure Save; procedure Print; end; 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) |
AW: Gemeinsame Codebasis für Desktop und Mobile???
So lange die Gänsefüße kochen kann man zum Thema auch etwas hier nachstöbern:
 http://www.delphipraxis.net/176478-m...realitaet.html |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Danke noch mal für alle Antworten.
Hatte mir auch ein paar Tage Auszeit gegönnt. Hoffe mal alle haben die Feiertage gut überstanden.:wink: 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. |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Zitat:
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. |
Software Architektur
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/. |
AW: Software Architektur
Zitat:
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. |
AW: Software Architektur
Zitat:
|
AW: Software Architektur
Zitat:
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 |
AW: Software Architektur
Zitat:
Zitat:
|
AW: Gemeinsame Codebasis für Desktop und Mobile???
Nehmen wir mal an es gibt eine sehr komplexe Berechnungsformel, die unter bestimmten Umständen versagt.
Beim Entwickeln war einem dieser Umstand nicht bekannt und darum ist dort jetzt ein Fehler. Kunde A beschwert sich und bevor man sich an den Code macht, erweitert man den Test um diese Konstellation und fängt an den Code zu prüfen und zu fixen. Wann ist der Fix fertig? Wenn alle anderen und der neue Test fehlerfrei durchlaufen. Ein wenig später kommt die Erkenntnis, dass man alles viel einfacher umsetzen/berechnen könnte. Also einfach die neue Berechnungsformel implementieren. Wann ist man fertig? Wenn alle Tests fehlerfrei durchlaufen. Ein Test ist nur so gut wie die Testbedingungen, aber die sind nicht in Stein gemeißelt, sondern dynamisch und wachsen eben mit. Dadurch vermeidet man aber auf jeden Fall Fehler aus der Vergangenheit nochmals zu begehen. BTW Tests mit Idealbedingungen zeigen nur, ob der Code im Idealfall funktioniert. Robusten Code testet man aber mit Bedingungen die zwar abwegig, aber möglich sind (werden Exceptions richtig geworfen, etc.) EDIT Dazu fällt mir gerade folgendes noch ein (reallifeexperince, allerdings kein Delphi aber egal) Eine Funktion zum Ermitteln des Brutto-Preises:
Delphi-Quellcode:
Tja, und wer jetzt die Tests nur mit 19% macht fällt hier auf die Nase.
function GetBrutto( Preis : currency; MwSt : currency ) : currency;
begin Result := ( Preis * ( 100 + 19 ) ) / 100; // ja, war hardcoded! end; Vor allem, wenn sich dieser Fehler nach 2 Releases wieder ins Programm schleicht (ein VCS kannten die nicht) :wall: Und vorsorglich haben die gar keine Tests drin gehabt, sondern die Funktion mit einem Artikel getestet. So würde ich diese Funktion testen
Delphi-Quellcode:
// Idealbedingung
CheckEquals( 119, GetBrutto( 100, 19 ) ); // Variationen CheckEquals( 100, GetBrutto( 100, 0 ) ); CheckEquals( 107, GetBrutto( 100, 7 ) ); // Abwegig, aber möglich CheckEquals( 110.5, GetBrutto( 100, 10.5 ) ); CheckEquals( 90, GetBrutto( 100, -10 ) ); // Weitere Variationen CheckEquals( 1190, GetBrutto( 1000, 19 ) ); // Fehler von Kunden gemeldet (bei Bedarf erweitern) CheckEquals( 0, GetBrutto( 0, 19 ), 'case 0815'); |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Da sollte man beinahe einen eigenen Thread für aufmachen.
Zitat:
(* Bei der Funktion 'Schuhe ab Größe 45 sind kosten 5 Euro mehr') haben wir einen Parameter (Schuhgröße) mit zwei Äquivalenzklassen: Größen bis 45 und Größen ab 45. Man testet dann mit einem Wert aus jeder Klasse, sowie 1-2 Werten aus den Grenzen zwischen den Klassen, also: 30, 44,45,46, 50. Genauergenommen haben wir hier 5 Tests!) So, nun hast Du also Code, der deinen eigentlichen Code testet, bzw. eine Aussage treffen kann, ob der Code das macht, was er machen soll. Super und ziemlich banal das Ganze. Nun kommt eine Änderung rein, oder eine Optimierung, ein Refactoring o.ä. Mit deinen Testroutinen kannst du munter drauflosoptimieren, redigieren, verändern usw. Solange dein Test 'grün' ist, ist die Welt in Ordnung. Zum Schluß noch eine Verifikation am lebenden Objekt und Du kannst dir nun ziemlich sicher sein, das der Kunde nicht gleich anruft und sich beschwert. Findet der Kunde einen Bug, ist klar, das Du keine 100% Codeabdeckung hast, und dieser blöde Käfer durch die (Test-) Maschen geflutscht ist. Aber weil Du schon Tests geschrieben hast, schreibst Du halt noch einen Test, der den Bug prüft (so ein Bug ist ja i.a. nur fehlerhaftes Verhalten bei bestimmten Eingabeparametern). DIESER Bug wird nie wieder auftreten, egal an welchen Schrauben Du in Zukunft noch drehen wirst. Zitat:
Zitat:
TDD (Test Driven Development) ist ja so, das zuerst Testcode für eine zu implementierende Funktionalität geschrieben wird und danach erst die Funktionalität selbst. Ich mag das nicht, weil man den eigentlichen Code zu sehr an den Testcode anlehnt. Man schreibt also nicht guten Code der auch gut testbar ist, sondern in erster Linie einfach testbaren Code. Da leidet die Lesbarkeit ein wenig. Muss aber jeder selbst herausfinden. Wir machen das so, das wir eine Businessoperation implementieren und gleich dazu die Tests für Validierung und Persitierung. Danach das Viewmodel und Kommandos und gleich die Tests dafür. Ich habe Basiskommandos durchgesetzt, wobei die Grundlogik in der abstrakten Klasse umgesetzt ist (sowas Banales wie: 'Es sind ungespeicherte Änderungen. Speichern? [Ja] [Nein] [Abbrechen]'). Dieses Verhalten wird einmal getestet und alle abgeleiteten Kommandos teste ich nur noch, ob sie vom Basiskommando ableiten und dann noch, ob die überschriebene Methode das macht, was sie machen soll. Anfangs ging das etwas ruckelig mit den Tests und einige der Programmierer wissen immer noch nicht, was sie eigentlich testen sollen, aber mit der Zeit gewöhnt man sich daran. Ich schreibe mittlerweile das Formular zum Schluss, sozusagen als Sahnehäubchen. Denn ich weiß ja, das Operation, Viewmodel etc. super funktionieren. Das ist das komplette Gegenteil von RAD, aber auch nicht schlecht. Man muss eben mehr planen und mit Wireframes arbeiten. Zitat:
Gottseidank macht sich Qualitätsbewustsein langsam bei den Kunden bemerkbar: Eine Anforderung eines großen deutschen Krankenkasse (SOAP-Anbindung) musste inklusive Architektur und Unittests umgesetzt werden (Vorgabe der IT-Abteilung). Klasse. Ich merke gerade: Ich hab Ferien und sülze hier rum... |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Zitat:
Oder das als Einstiegspreise ansetzen und den Gewinn dann über Customizing im eingeführten Programm wieder reinholen. |
AW: Gemeinsame Codebasis für Desktop und Mobile???
Zitat:
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. |
AW: Gemeinsame Codebasis für Desktop und Mobile???
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. ;-) |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 14:45 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz