Windows Desktop Anwendung auch auf mobilen Endgeräten

[delphia]

Ich hoffe ich bin in der richtigen Kategorie.

Ich habe einige Windows-Desktop-Anwendungen erstellt mit DBISAM 2.x/4.x und Delphi. Immer mehr Kunden fragen nach einer Lösung um im ersten Schritt auf ihre Daten von mobilen Geräten lesen zu können. Im zweiten Schritt wollen sie die Daten pflegen. Beispiel Rechnung schreiben: Reparaturdienst will Rechnungen am Desktop im Büro erstellen, Ersatzteilverkauf an der Ladentheke (beides LAN und bereits realisiert) aber auch direkt beim Kunden mit seinem Tablet (mobil).
Alle meine Anwendungen sind mit Mehrbenutzerumgebung mit Fileserver Technik gebaut. Jetzt bin ich auf der Suche Tools für diese Aufgabe oder eine adäquate Lösung. Aufgrund der unterschiedlichen Betriebssystem von mobilen Geräten denke ich an eine Webbrowser Lösung. Irgendwelche anderen Ideen? ich habe schon einiges gefunden (RemObjects, Oxygene, Elevate WebBuilder, AngularJS usw.) jedoch überfordert mich die Vielfalt, ich kann es nicht einsortieren.

Ich bin nicht sehr erfahren in Web-Technologien. HTML-und CSS-Kenntnisse sind ok - aber kein Javascript oder PHP. Ich bin in der Lage, Code-Snippets zu integrieren und sie leicht modifiziert, aber nicht mehr. Zu meiner Schande kenne ich auch die Möglichkeiten von Delphi nicht in diesem Zusammenhang. Meine Fragen:

Drucklösungen, Reports mit Web-Anwendungen? Gerade Rechnungen (Faktura) können sehr komplex sein. Für den Desktop verwende ich Fastreport.
Import / Export von Daten, meist EXCEL-Format?
Responsive Design für Web-Anwendungen?
Sicherheit und Performance?
Ich hatte die Idee, die Daten, meiner Desktop-Anwendung auf einer Web-Store-Lösungen wie SkyDrive speichern und zu lesen / schreiben. Wäre die Frage funktionieren Datensatzsperren bei gleichzeitigem Zugriff mit einer Web-Anwendung? Sonstige Fallstricke?

Ich weiß, viele kurze Fragen für lange Antworten. Aber ich bin ein einzelner Entwickler und ich habe keine Zeit, um all die Papiere und FAQs, die oft nicht meine Fragen beantworten, zu lesen. Viele Feature-Listen oder Produktbeschreibungen kann ich auch nicht einordnen, da ich nicht weiß, was dahinter steckt. Ich weiß, ich muss das alles selbst klar kriegen, aber ich brauche mal einen Anfang, eine Orientierung. Vielen Dank.

[Sir Rufo]

So schlimm ist das auch wieder nicht

Du brauchst aber eine 3-Schichten-Architektur

[himitsu]

Man kann das auch als Webanwendung (HTML und Co.) realisieren, dann würde es überall laufen, wo ein Webbrowser läuft.
- Angefangen beim TidHTTPServer, bis hin zu großen Frameworks.

Das könnte dann notfalls auch ein Windows-Programm sein, welches sich z.B. als Service auch noch mit Delphi 2010 erstellen ließe.



Beim 3-Schichten wäre es ein Server und dann noch extern irgendwelche Klienten (quasi Logik im Server und dann je nach Zielsystem eine entsprechende GUI-Anwendung)
- Hier hat der Server praktisch nur eine Schnittstelle (z.B. SOAP, REST, DataSnap usw.), worüber die Klientanwendungen den ansprechen.


[edit]
http://www.delphipraxis.net/178533-w...-new-post.html

[delphia]

@ himitsu
@ Sir Rufo

Danke, ich habe alles aufmerksam gelesen, aber so richtig hilft mir das nicht. Mag an meiner Unkenntnis liegen was Web Techologien angeht.

Was ich noch vergass zu erwähnen. Alle meine Programme lassen sich sehr einfach installieren (quasi EinKlick) und laufen auch vom USB Stick. Die Multiuservariante ist ebenso einfach zu installieren. Will sagen, meine Kunden sind Menschen mit wenig bis mittlere Computerkenntnisse. Außerdem wollen Sie nicht viel Geld ausgeben. Für Support erst recht nicht. Eine Lösung sollte daher auch wenig störanfällig, wartungsarm und simpel zu installieren sein. Und es sollte mit einem einfachen WebSpace Account für kleines Geld betreibbar sein, da ich nicht auch noch ein "Rechenzatrum betreiben will. Mich beschleicht gerade der Verdacht, dass das nicht alles unter einen Hut zu bringen ist.

Mal neben bei: Mir kommt diese ganze Webprogrammiererei vor, wie das Programmieren zu DOS Zeiten, mit Bildschirmen mit Text Modus. Jedes Programm brauchte eigene Druckertreiber usw. Hatte damals mit Borland Pascal mit einer Klassenbibliothek für eine grafische Oberfläche ähnlich Geoworks (kennt keiner mehr) ein Programm erstellt. Nix WYSIWYG, Top/Left/Height/width Koordinaten und kompilieren - sehen ob es passt. Komplexe Forms - das war ein Schmerz. So komme ich mir vor, wenn ich heute meine WebSite bearbeite. Hier HTMl, rüber zum Browser - testen, da CSS, zum Browser - testen, Javascript - testen und wieder zurück. Interpreter Sprachen wie Basic - damals verpöhnt. Und heute? Reine Textdateien aus verschieden Töpfen: HTML, CSS; JavaScrpt, php. Ich halte das im Gegensatz zu kompiliertem Code aus einer IDE für einen Rückschritt. Oh, ich beginne zu schwafeln - höchste Zeit mein Post zu beenden.

[Sir Rufo]

Beim Verstehen sollte es eigentlich keine Probleme geben - dafür umso mehr bei der Umsetzung

Dein Programm sieht aktuell so aus

Code:

Anwendung ---+-
   |         | Formulare (UI)
   |         | Logik
   V          +-
FileServer --+-
             | Daten
             +-

und muss nachher so aussehen

Code:

WebClient o.
Android/iOS --+-
   |          | Formulare (UI)
   V           +-
WebService ---+-
   |          | Logik
   V           +-
FileServer ---+-
              | Daten
              +-

Wenn du schon in deiner Anwendung eine lose Kopplung zwischen der Logik und den Formularen vorgesehen hast, dann sollte das recht flott von der Hand gehen. Wenn nicht, dann musst du halt das alles auseinander friemeln

Eine ganz einfache PlugAndPlay Version kannst du mit dem WebService vergessen (schon aufgrund der Sicherheit).
Ist aber auch nicht wirklich das diesen Geheimnis.

[delphia]

Zitat von Sir Rufo:

Beim Verstehen sollte es eigentlich keine Probleme geben - dafür umso mehr bei der Umsetzung

Völlig richtig.

[bcvs]

Hallo delphia,

ich stand vor einem ähnlichen Problem.

Ausgangspunkt:
Windows-Desktop-Anwendung, (übrigens auch mit DBISAM als DB). Ein Teil davon (Arbeitszeiterfassung) sollte auch über ein Web-Frontend oder mobile Apps bedienbar sein.

Meine Lösung:
Eine MySql-Datenbank, die auf einem einfachen 1und1-Hosting-Account läuft. Die Desktopanwendung stellt die für die mobile Bearbeitung notwendigen Daten dort zur Verfügung. Dies geschieht über den Aufruf entsprechender php-Scripte über Indy-Komponenten. Dann gibt es eine Web-Oberfläche, über die Daten eingebenen werden können, die zunächst ebenfalls in der MySql-DB landen.

Die Desktopanwendung schaut von Zeit zu Zeit nach, ob neue mobile Datensätze vorhanden sind, lädt diese herunter und integriert sie in die lokale DB. Das Herunterladen erfolgt ebenfalls über ein php-Script, dass die neuen Daten aus der MySql-DB liest und sie in einem für die Desktopanwendung verständlichen Format ausgibt.

Damit sich die Daten verschiedener Anwender nicht in die Quere kommen, gibt es Accounts mit Login. Falls es einmal zu viele Anwender werden (ist momentan noch überschaubar), kann man das Ganze auch auf mehrere MySql-Dbs verteilen.

Vorteil: Der Anwender braucht nichts zu installieren. Er braucht lediglich einen Web-Browser, seine Login-Daten und kann loslegen.

[delphia]

@bcvs

In diese Richtung habe ich auch schon überlegt. Wäre zumindest ein Ansatz um Nur-Lese-Daten mobil verfügbar zu machen. Gibt es keine Klassen oder Komponenten, die MySQL direkt aus Delphi schreiben können? Aber wahrscheinlich kommt man per FTP an die MySQL DBS nicht heran, bei den LowCost Accounts. Könnte man einfach die Files überschreiben.

[Sir Rufo]

Zitat von delphia:

Gibt es keine Klassen oder Komponenten, die MySQL direkt aus Delphi schreiben können? Aber wahrscheinlich kommt man per FTP an die MySQL DBS nicht heran, bei den LowCost Accounts. Könnte man einfach die Files überschreiben.

Nein, und wozu denn auch?

MySQL ist ein Datenbank-Server mit dem man (über ein Protokoll) sprechen kann, und das sollte man auch dann machen.

[jensw_2000]

Datenbanken auf Webservern sind im Grunde ein No-Go.
Für die Webcontents von Content Management Systemen sind sie natürlich OK, aber Produktivdaten gehören da keinesfalls mit drauf.

Wenn es für Kunden ist, dann wird sicher auch der eine oder andere Euro für ein fertige kommerzielle Drittanbieter Komponente drin sein, oder?
Ich habe damals ein eigenes kleines Paket für 3-Tier Anwendungen gebaut. Der Pflegeaufwand war enorm und bei jeder neuen Anforderung kam das Panik "P", besonders wenn die Kunden ihren Datenschutzbeauftragten bei den Projektbesprechungen mit ins Boot geholt haben. Die Kunden haben auch nicht verstanden, dass eine "kleine Anpassung" oft viel Aufwand in den anderen Schichten nach sich gezogen hat.

Letztendlich bin ich bei DataAbstract und dem RemObjects SDK hängengeblieben und bin mehr als glücklich damit. Damit sind 3-Tier Datenbank- oder Serviceapplikationen kein "kompliziertes" Thema mehr. Alle gängigen Protokolle, Verschlüsselung und Redundanz
werden unterstützt. Der Support ist wirklich gut und der Einarbeitungsaufwand eher klein.
Ehrlich. Ich bin auch Einzelkämpfer und würde nie wieder auf die Idee kommen, derart komplexe Frameworks selbst zu bauen und zu pflegen. Der Aufwand refinanziert sich nicht mal ansatzweise und an die Qualität und den Funktionsumfang kommt man bei Weitem nicht heran.

http://www.remobjects.com/products/
Es gibt natürlich auch Trialversionen zum reinschnuppern.

RemObjects baut allerdings seit XE2 keine FMX Komponenten mehr.
Windows RT, .Net, iOS, OSX und Android werden daher "nur noch" nativ unterstützt.
Die plattformspezifischen Libraries von RemObjects nehmen einem dabei aber das ganze komplizierte Protokollimplementieren ab.

PS: Ich bekomme keine Provision von Denen . Ich bin einfach nur glücklich sie gefunden zu haben.