# Offline-Fähigkeit von Web-Frameworks



## megachucky (14. Jan 2010)

Hallo zusammen,

ist meine folgende Behauptung richtig, wenn man eine Webanwendung entwickelt:

"Offline-Fähigkeit hängt nicht vom Web-Framework ab, welches man auswählt. Das Konzept muss durch zusätzliche Technologien wie GEARS oder HTML5 realisiert werden."

Seht ihr das auch so, oder liege ich falsch? Wenn ja, warum und welche Frameworks sind dann am besten geeignet für diese Anforderung?

Danke für Ratschläge...


----------



## Noctarius (14. Jan 2010)

Es kommt immer drauf an was du unter Offline verstehst. Ist offline für dich auch, wenn Daten nur während einer Browsersitzung gehalten werden (wenn der Server nicht mehr erreichbar ist) oder auch über mehrere Browsersitzungen hinweg?


----------



## megachucky (14. Jan 2010)

Hallo. 

Ok, ich muss etwas genauer werden, sehe ich ein...

Hier meine Definition von Offlinefähigkeit:

"Offlinefähigkeit bedeutet im Kontext von Webanwendungen, dass der Nutzer eine Anwendung verwenden kann, obwohl keine Verbindung zum Internet besteht. Zwar kann der Nutzer keine neuen Daten mehr vom Server erhalten oder Daten an den Server senden, aber weiterhin mit den bereits auf dem Desktop gespeicherten Daten arbeiten."

Das heißt, es geht nicht nur um eine Session, sondern um eine "richtige" Anwendung, die auch komplett ohne Internet nutzbar sein soll.

Praxisbeispiel: Ein Außendienstmitarbeiter möchte beim Kunden vor Ort etwas verkaufen und die Daten in seine Software eingeben und speichern. Da gerade kein UMTS-Empfang verfügbar ist, wird der Auftrag erst später auf den Server übertragen.


----------



## Noctarius (14. Jan 2010)

Sollte er zwischendurch den Browser geschlossen haben braucht er tatsächlich HTML5 oder eben Gears. Sollte der Browser aber offen bleiben kann ich die Daten im Arbeitsspeicher mit nahezu jedem JavaScript Framework zwischenspeichern und weiternutzen bis zum Wiederherstellen einer Internetverbindung.
Ich kann sogar neue Daten einpflegen und diese beim Wiederverbinden "synchronisieren" und auf dem Server speichern.

Wir benutzen in der Firma letzten Weg, da wir immer nur in einer Browsersession arbeiten. Eine Datenspeicherung über mehrere Browsersessions hinweg ist hier nicht notwendig.

Ob deine Aussage richtig ist hängt also schwer vom gewünschten Anwendungsfall ab.


----------



## megachucky (14. Jan 2010)

Du kannst also bei deiner Lösung im Browser zwischen Seiten hin- und her navigieren und Daten eintragen - also auch z.B. eine Seite mehrfach ausfüllen und trotzdem alle Informationen im Speicher halten?

Die Anwendung muss aber gestartet werden, wenn man online ist, richtig? Oder ist die Anwendung nach erstmaligem Laden auch schon im Cache gespeichert (auch nach Rechnerneustart)?

Kannst du mir vielleicht auch den Anwendungsfall nennen, wo das bei euch verwendet wird? Für mich hört sich das sehr riskant an bezüglich Datenverlust  (beispielsweise, wenn ein Bank-Berater bei einem Kunden einen Vertrag abschließt).

Danke...


----------



## Noctarius (14. Jan 2010)

Nein die Seite arbeitet komplett im Web2.0 System. Heißt die Seite wird komplett durch JavaScript aufgebaut und zur "Laufzeit" geändert. Dadurch verhält sie sich quasi wie eine Desktopanwendung, also ohne Seitenreload. Die Anwendung muss nicht neugestartet werden sobald man wieder online ist, sondern erkennt durch regelmäßiges "Pingen" des Servers ob eine Internetverbindung besteht oder nicht und synchronisiert automatisch wieder wenn der Server erreichbar ist. Sonst wird im Arbeitsspeicher zwischengespeichert bzw der Zwischenspeicher im RAM genutzt. Nach Absturz oder Browserneustart sind damit die Daten selbstverständlich nicht mehr verfügbar.

edit:
Das Ganze wird bei uns für eine Onlineanwendung genutzt welche Einstellungstests- und Bewerbermanagement durchführt. Dabei läd der Bewerber den kompletten Test und kann ihn bearbeiten. Das System ist nicht sessiongebunden, wodurch auch eine Neueinwahl ins Internet oder ein etwas längerer Netzausfall keine Probleme machen.
Solange der Server erreichbar ist werden regelmäßig Zwischenergebnisse und Uhrzeiten übertragen, sodass der Test im schlimmsten Fall auf einem bestimmten Zeitpunkt zurückgesetzt werden kann.

Mehr kann ich da nicht verraten


----------



## megachucky (14. Jan 2010)

Ok, vielen Dank. 

Das ist auf jeden Fall auch eine interessante Möglichkeit, die mir so bisher nicht bewusst war. 


Für meinen Anwendungsfall kommt diese Lösung allerdings nicht in Frage  Gibt es evtl. noch weitere Alternativen außer GEARS und HTML5?

GEARS wird ja wegen dem Offline-HTML5-Feature in Zukunft nicht mehr weiterentwickelt. Meine Schlußfolgerung wäre daher: Längerfristig auf jeden Fall auf HTML5 setzen, außer man braucht jetzt sofort eine fertig implementierbare Lösung, die auch auf diversen Browser(versionen) läuft ?! 

Seht ihr das auch so?


----------



## Noctarius (14. Jan 2010)

Problem mit HTML5 ist, dass es bisher eher mager im Browser implementiert ist. Man kann eine Parallellösung produzieren, da Gears und HTML5 eine sehr ähnliche API nutzen.

Alternativen dazu kenn ich persönlich nur durch eigene Browserplugins, welche bei uns nicht in Frage kamen.


----------

