Online/Offline-Software-Konzept für Win, Apple, Android

[erich.wanker]

Hallo Leute,

nach längerer "Denkphase" würde ich gerne mal eure Ansätze für folgende Idee hören :-)


EINE Codebasis in Delphi Rio 10.3.3 für eine Anwendung, die auf Win, Android und Aplle läuft.

Ein "Datenbank-Zwischenspeicher-Konzept", falls das Win10 Netbook, das iphone oder das Android Table NICHT im Internet ist..

Synchronisierung mit der Datenbank am Server - sobald das Device wieder online ist

• Welche Datenbank sollte ich da am Server verwenden ? (hab hautsächlich Firebird 2.5 bis jetzt im Einsatz)
  
• Wie kann ich so einen "Datenbank-Zwischenspeicher" realisieren
  
• Welche "einheitliche Kommunikationstechnik" könnte für ALLE OS verwendet werden?
  
• Wenn die Verbindung ins Internet "schlecht" ist - soll der Zwischenspeicher verwendet werden
  
• Was passiert bei Verbindungsabbruchen

...


Vielen Dank für Hinweise
Erich

[mkinzler]

Zitat:

Welche Datenbank sollte ich da am Server verwenden ? (hab hautsächlich Firebird 2.5 bis jetzt im Einsatz)

Ist eigentlich irrelevant.

Zitat:

Wie kann ich so einen "Datenbank-Zwischenspeicher" realisieren

Da gibt es verschiedene Ansätze. Man kann z.B. immer loakl arbeiten (Replikation des Datenbestandes) aber je nach Umfang der Daten nicht unbedingt sinnvoll. Oder man arbeitet grundsätzlich "online" und hält nur die wichtigsten Daten lokal.

Zitat:

Welche "einheitliche Kommunikationstechnik" könnte für ALLE OS verwendet werden?

Rest.

[Jumpy]

Zitat:

Zitat von erich.wanker (Beitrag 1453598)

Ein "Datenbank-Zwischenspeicher-Konzept", falls das Win10 Netbook, das iphone oder das Android Table NICHT im Internet ist..
Synchronisierung mit der Datenbank am Server - sobald das Device wieder online ist

Nur mal so als Zwischenfrage zum Konzept: Wo steht der Server? Bei dir oder bei deinen jeweiligen Kunden?

[jobo]

Zitat:

Zitat von erich.wanker (Beitrag 1453598)

• Welche Datenbank sollte ich da am Server verwenden ? (hab hautsächlich Firebird 2.5 bis jetzt im Einsatz)
  
• Wie kann ich so einen "Datenbank-Zwischenspeicher" realisieren
  
• Welche "einheitliche Kommunikationstechnik" könnte für ALLE OS verwendet werden?
  
• Wenn die Verbindung ins Internet "schlecht" ist - soll der Zwischenspeicher verwendet werden
  
• Was passiert bei Verbindungsabbruchen

Firebird ist bestimmt in Ordnung, ich würde aber immer versuchen, mit aktuellen Versionen zu arbeiten.
Als lokaler, einheitlicher Speicher eigenet sich m.E. nur ein einziges RDBMSystem, SQLite.
Denkbar wäre vielleicht auch, lokal ausschließlich mit JSON oder XML zu arbeiten. Ich hab keine Ahnung, welche Daten Du speichern willst und wie flexibel Du sein musst/willst.
Ich sehe zum Datenaustausch auch eine REST Schnittstelle als sinnvoll an.
Ich würde allerdings gar nicht mit 2 Speicherverfahren arbeiten. Natürlich muss die Anwendung die beiden Zustände jederzeit (er)kennen und bei Bedarf auch dem User vermitteln. Aber ich würde immer lokal speichern und nur Änderungen austauschen.
Spannend vielleicht, wie häufig (überhaupt) konkurrierende Datenänderungen gemacht werden und Konflikte entstehen können.

[Rollo62]

Was das "Local DB" betrifft:
Schau dir mal das LocalSql an, da gibt es auch gute Beispiele von Cary Jensen.
https://subscription.packtpub.com/bo...sy-tfdlocalsql
https://www.google.com/url?sa=t&rct=...Ye4IAhmYVFr9B3
https://www.youtube.com/watch?v=tJAO-POBhVc

Es läuft auf Sqlite, was automatisch auf allen Platformen die einfachste Lösung ist,
weil es z.B. Android/iOS schon von Haus aus mitbringt.

Ansonsten fände ich für den Server auch FB OK, aber das ist ein weites Feld.

[IBExpert]

ich hatte vor einigen Tagen auf einer Lazarus Konferenz in den Niederlanden mal genau zu dem Thema
eine präsentation gemacht, die dort zwar auf pas2js und lazarus gezeigt wurde, aber da ein teil der
Demo auch auf Basis von TMS Webcore gemacht wurde, das ja auch in Delphi verfügbar ist, deckte das
eigentlich das ab, was du hier erklärst (das hier ist ein Video von der Session mit einigen Demo
Applikationen und auch der https firebird sql schnittstelle).

https://ibexpert.com/hk/lazConf20190129_hk.7z (das video hat evtl keinen ton, da
lief was bei der aufzeichnung falsch)

Die Infos basieren auf realen Kundenprojekten.

Fazit aus meiner Sicht: Native App Entwicklung für mobile devices hängt mit so vielen Faktoren zusammen,
das du früher oder später bei den Tools landen wirst, die der android oder iOS Hersteller
dafür bereitstellen. Ob das um so banalen Kram geht wie nur noch 64 bit usw oder sonstwas ist dabei
eigentlich egal.

Du musst so viel neuen Kram lernen, alleine um das ganze Zeug über die Appstores
verteilen zu können und wirst bekloppt, wenn deine Kunden ein Bugfix brauchen, apple aber wochenlang
nur die alte version im store hat usw. Und auch auf PCs ganz banale Geschichte wie mal eben einen
firebird server zu installieren und zu benutzen, kann dich in der welt der native apps zur
Verzweiflung bringen. Wenn du eine eigene Abteilung mit x erfahren App developern hast, dann kannst du
das so machen, ich vermute aber mal, das du das nicht hast und auch gar nicht haben willst ...

Die erfahrenen Leute, die im Markt bezahlbar und verfügbar sind, sind ausgesprochen selten und Leute mit
Halbwissen kosten nur Geld und Zeit ...

Wir haben uns auf Basis von Kundenprojekten also ausschliesslich auf Webapps auf Basis von
lazarus/pas2js/tmswebcore konzentriert und bieten dafür auch Consulting an (auch im Rahmen
der Hotline).

Da es meistens um Daten aus einem komplexen Backoffice System geht, haben wir aber auch nie den Anspruch,
in einer Offline Situation sämtliche Daten aus allen Tabellen lokal im Handy zu haben, sondern holen
uns über die oben im o.a. Archiv befindliche https Firebird SQL Schnittstelle Daten aus der db, die wir dann
in einem simplen eigenen Format im Webbrowser in der localstorage vorhalten, falls die mal in einem
Offlinezugriff gebraucht werden.

In dem Beispiel oben sind das zum Beispiel daten wie arbeitszeitbuchungen usw.
das schöne an den pas2js anwendungen ist, das die auch offline funktionieren, und du mit so was
wie tms webcore bei bedarf auf datasets und dbgrids daraus füllen kannst, ohne irgeneinen
serverzugriff haben zu müssen. Auch speichern kannst du da, und wenn mal das mal mit der
üblichen Pascalsyntax in lazarus oder delphi gemacht hat, geht die Lernkurve sehr schnell
nach oben.

Man braucht ein wenig Zusatzwissen, um dann die html seite auch lokale auf mobile devices zu cachen,
aber das ist schnell an einigen Beispielen erlernbar.

Das Beispiel in o.a. archiv basiert darauf, das man möglichst einfach vom client per sql
sqls an einen server sendet, der das dann entweder einfach macht oder eine Ergebnismenge liefert.

In der Firebird Welt hat man ausreichend Mechanismen, um rechte einzuschränken, so das die
Webschnittstelle zB nur über SPs daten bekommt. Bei den meisten Rest Server architekturen
kannst du das auch machen, aber beim rest server hast du meistens 3 Ebenen
client-restserver-datenbank
an denen du übereinstimmung brauchst, bei uns sind das nur 2 ebenen, weil der
restserver in der mitte wegfällt. Und das sich diverse Restserver als wunderschöne
Plattform zum Datenklau eignen sieht man regelmäßig, wenn irgendjemand wieder
irgendwo daten abgegriffen hat, weil der unerfahrene Programmierer der Restserver api
einfach erlaubt, zu einer beliebigen Kundennummer in der url irgendwas abzufragen und
der Datendieb dann einfach mal die nummern hochzählt in der url und schaut was kommt.

Das Problem hast du in allen Welten und je mehr eben du hast, mit denen du keine Erfahrung hast,
um so mehr Problem kann es am ende geben.

Da du dich aber vermutlich mit Frontendprogrammierung in Delphi/pascal ganz gut auskennst
und dir auch firebird nicht komplett fremd ist, kann man durchaus davon ausgehen, das
die zusätzlichen Erfahrungen, die du dafür brauchst, innerhalb von maximal einer Woche
vermittelt werden können, wie das auch bei anderen Kunden mit Delphi/Firebird Erfahrung
ausgereicht hat.

Da in jedem einigermaßen aktuellen Webbrowser in der localstorage 5 bis 10 MB
an Daten speicherbar sind, musst du ggf eh mal hinterfragen, was effektiv an
daten offline gebraucht werden, weil alles eher selten klappen wird.

Wenn du aber mal versuchst, irgendein dbgrid ähnliches Konstrukt auf einem 5 Zoll
Handydisplay mit normal dicken Anwenderfingern bedienen willst, dann landest du
eh irgendwann bei dafür geeigneten javascript libs, die man aber gar nicht alle
komplett kennen muss, um damit auf basis von pas2js Anwendungen zu erzeugen. ob du ein
button im form wie in Delphi selber reinklickst oder die button referenz aus einem
html template zur laufzeit verknüpft, um den dann wie sonst auch ein buttonclick
ereignis in pascalsprache umzuhängen, ist nach kurzer eingewöhnung ziemlich egal.

Die o.a. https firebird sql Schnittstelle kannst du übrigens wie von dir gewünscht
mit jeder plattform abgefragt werden, die https zugriffe beherrscht, ganz ohne
sonstige Treiber, und eine geeignete pascalunit, die die results dann umwandelt, kannst
du auch problemlos so schreiben, das die in pas2js als auch in deine fat client Anwendungen
benutzbar ist.

Die https firebird sql demo ist übrigens ohne jede security konzipiert, das ist aber
einfach zu ergänzen.

[TurboMagic]

Wenn's auch was kosten darf könnte auch Interbase eine Option sein, da es davon explizit auch eine IBLite für mobile Geräte gibt.
Ich hab' jetzt aber keine Ahnung, ob man mittels FireDAC von Android / iOS direkt auf einen IB Server irgendwo verbinden kann.

Für die meisten DB's gibt's m.W. nämlich keinen Client für mobile Platformen.

[mkinzler]

DevART (UniDAC usw.) unterstützt auch iOS/Android. Ich würde aber von mobilen Geräten nie direkt auf Datenbankserver zugreifen, sondern immer eine Middleware (Rest) verwenden.

https://www.devart.com/unidac/docs/compatibility.htm

[Rollo62]

TmsWebCore ist schon eine feine Sache, das stimmt.
Wenn dir das ausreicht, ist es sicher OK.

Ich bin aber nicht sicher ob damit alle Features der Telefone unterstützt werden,
ich denke wohl eher nicht.

Mit Fmx, ohne Nutzung besonderer Features, laufen die Apps auch recht stabil.
Die Probleme fangen bei 1. und 2. da an wenn man tiefer in die FeatureKiste greifen muss.

Wenn es nur einfache DB mit Visualisierung ist, sollte es mit beiden Optionen machbar sein.
Aber es ist richtig das man erstmal eine Menge dazulernen muss, was AppStores etc. betrifft.
Man muss auch sagen das es schon eine Umstellung von Desktop auf Mobile ist, denn da gelten andere Regeln, und man kann nicht mehr Alles machen was man möchte.

Edit:
Noch was zu den "Problemen" mit Mobile-Platformen:
Du musst nicht glauben das die Android/XCcode Plattformen komplett Problemfrei sind.
Ich recherchiere dauernd auch in Android/iOS Foren, und die sind IMHO genauso voll von Problemen.
Vieles geht da leichter, maches geht aber auch dort nicht so einfach.
Das Delphi da nochmal was obendrauf setzt ist richtig, aber damit kennt man sich wenigstens besser aus.

[jobo]

Zitat:

Zitat von IBExpert (Beitrag 1453626)

..
Wir haben uns auf Basis von Kundenprojekten also ausschliesslich auf Webapps auf Basis von
lazarus/pas2js/tmswebcore konzentriert und bieten dafür auch Consulting an (auch im Rahmen
der Hotline).

Wir machen auch viel mit Webapps. Das ist erstmal ganz simpel eine Webseite für alle Plattformen.
Dann natürlich Größenunterschiede berücksichtigen und natürlich auch oft bauartbedingt funktionale Unterschiede.
Am Ende wird bei Bedarf auch eine (unsichtbare,) native Rahmenapp verwendet.

Puristen und Fans stört dann wahrscheinlich die Optik, die nicht dem Gerätestandard entspricht. Fachanwender freuen sich dagegen, dass jedes Gerät gleich zu bedienen und navigieren ist.

[Rollo62]

@jobo
Nimmst Du dafür TmsWebCode ?
Bleibt das auch performant wenn man mal größere Apps, statt der einfachen Demos baut ?

[erich.wanker]

Danke für die vielen hilfreichen Hinweise


Hallo Jumpy
.. der Server sollte dann beim Kunden stehen

Hallo jobo
SQLite auf den Endgeräten ist sicherlich die beste Lösung

Hallo Rollo62
Wenn ich bei Firebird bleiben kann - würde ich es natürlich bevorzugen ;-)

Hallo IBExpert...
Wow .. ein sehr ausführliches Posting .. mit vielen Hilfreichen Informationen .. DANKE !!!

P.S.: Ich selbst arbeite seit Jahren mit der UniGUI .. und bin sehr zufrieden damit.
Der einzige Nachteil ist die Internetverbindung .. ich habe Kunden die auf 2500 Meter Seehöhe arbeiten und teilweise keine Verbindung haben.

Hallo mkinzler..
"...sondern immer eine Middleware (Rest) verwenden." ist ein wichtiger Hinweis .. DANKE !!!

[Rollo62]

Zitat:

Zitat von erich.wanker (Beitrag 1453687)

Danke für die vielen hilfreichen Hinweise

Hallo Rollo62
Wenn ich bei Firebird bleiben kann - würde ich es natürlich bevorzugen ;-)

Ich will Dir Firebird gar nicht ausreden, das ist auch mein Favorit.
Aber man sollte klarstellen wie und wo Du den dann nutzt:

• Desktop: Kein Problem
  
• Server : Kein Problem
• TmsWebCore = Server: Sollte kein Problem sein, habe aber mit TMS noch keine Projekte gemacht.
• Tms mit PWA: Serverseitig wohl kein Problem, aber lokal läuft dann was eigenes
  (mit TMS checken, ich denke HTML5 offline DB per JS).
• Mobil via REST Server: Serverseitig FB ist kein Problem, das wäre für so eine Anwendung wo ich REST nehmen würde
• Ausnahme
  Mobile : (D.h. wenn Du direkt auf iOS/Android mit FMX auch lokal arbeiten möchtest)
  Da würde ich ausser Sqlite und IbToGo erstmal nichts anderes nehmen, andere lokale DB können ziemlich hakeln, wohl auch der FB (falls das überhaupt geht).

[mkinzler]

FireBird embedded gibt es auch für Android und iOS. Für 2. ist aber der Ansatz problematisch für den Vertrieb über den AppStore.

[jaenicke]

Ich vermisse bei TMS noch den Hinweis auf TMS Aurelius und TMS Echo. Mit Echo kann man die Daten direkt replizieren ohne sich darum zu kümmern:
https://www.tmssoftware.com/site/tmsecho.asp

[Jumpy]

Zitat:

Zitat von erich.wanker (Beitrag 1453687)

Hallo Jumpy
.. der Server sollte dann beim Kunden stehen

Der Hintergrund der Frage ist der: Ich hab nie verstanden (weil nicht mein Gebiet), wie das in den App-Stores mit Apps funktioniert, die eigentlich für nur mehrere ausgewählt Kunden ist. Muss man dann als Anwender beim ersten Start der App aus der Liste der Kunden den wählen, für den man arbeitet (damit sich die App nachher mit dem richtigen Server verbindet)? Oder macht man pro Kunde eine eigene App, wobei die App eigentlich immer die selbe ist, nur die Serveradresse entsprechend hinterlegt?

[mkinzler]

Beides ist möglich und wird so auch praktiziert.

[Dumpfbacke]

Zitat:

Zitat von Rollo62 (Beitrag 1453689)

[*] Mobil via REST Server: Serverseitig FB ist kein Problem, das wäre für so eine Anwendung wo ich REST nehmen würde[*] [*] Ausnahme
Mobile : (D.h. wenn Du direkt auf iOS/Android mit FMX auch lokal arbeiten möchtest)
Da würde ich ausser Sqlite und IbToGo erstmal nichts anderes nehmen, andere lokale DB können ziemlich hakeln, wohl auch der FB (falls das überhaupt geht).[/LIST]

Hallo Rollo62,
kann man die Übertragung der Daten eigentlich bei REST verschlüsseln ? Also geht das ganze über HTTPS ? Ist es auch möglich das der Server nur dann Daten "rausrückt" wenn man sich bei jeden Anfrage extra anmeldet mit Benutzername und Passwort ? Hast du eventuell auch ein Beispeil Code dazu ?

[mkinzler]

Rest geht über http oder https. Es wird dann auch die Authentifizierungs/Sessionmöglichkeiten ageboten.
Schau Dir mal die die Beispiele der oben genannten Lösungen an.

[jobo]

Zitat:

Zitat von Rollo62 (Beitrag 1453675)

@jobo
Nimmst Du dafür TmsWebCode ?
...

Nein, das ist eine Eigenentwicklung, hat nichts mit Delphi zu tun.
Ich wollte mit dem Beitrag nur betonen, dass man HTML(5) plus Frontend Scripting gut als Geräte übergreifende UI verwenden kann. Der Online Aspekt ist allerdings bei uns in dem Fall anders. Es gibt gemeinsame Inhalte (Mediendateien) und dadurch sozusagen Online "Zwang". Die Offline Funktionalität ist dadurch sehr übersichtlich und würde noch mal extra Aufwand erfordern, wenn es nahtlos weitergehen sollte ohne I-Net.
Echte On-/Offline Apps haben wir bis jetzt nur nativ für Android gemacht. Das läuft über Postgres Server, SQLite und JSON/Rest.

[Rollo62]

[QUOTE=Dumpfbacke;1453724]

Zitat:

Zitat von Rollo62 (Beitrag 1453689)

kann man die Übertragung der Daten eigentlich bei REST verschlüsseln ? Also geht das ganze über HTTPS ? Ist es auch möglich das der Server nur dann Daten "rausrückt" wenn man sich bei jeden Anfrage extra anmeldet mit Benutzername und Passwort ? Hast du eventuell auch ein Beispeil Code dazu ?

Hier ist eingentlich eine Menge dabei.
Aber generell heisst REST-Server (mal vereinfacht gesagt):
- es ist ein HTTP Server (oder HTTPS)
- man benutzt POST/GET/DELETE/ etc. für die Steuerung (wird vomn haus aus im HTTP unterstützt)
- man sollte "Resourcen" abrufbar haben, i.d.R. als Pfade www.server.de/Resource1?id=25 ... so in der Art
- zur Authentifizierung kann man Token austauschen, oder Basic HTTP Authentifikation nutzen, etc.
- Ansonsten kann man dort eigentlich machen was man will

Ich denke es fällt Alles mögliche unter den Begriff REST, da ist nicht viel standarisiert
(Bitte nicht erschlagen für Pauschalaussagen :stupid:).