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

[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 von erich.wanker:

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 von erich.wanker:

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 von Rollo62:

[*] 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 von Rollo62:

@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.