The web app must not close if the server is unavailable

Wouldn’t it be an idea to disable all controls (checkboxes, textfields, buttons etc.) for the time there is no connection ?
I could resume and re-activate after the xojo connectection JS to Xojo is restored?

There’s no way to reliably restore a connection and make sure everything would be in sync.

There is always a way to rome.

Unlikely without a complete redesign of the protocol.

There could be some way, but it is not exactly simple.

In a web app, everything is tied to the session. So effectively, when the session ends, all webpages, database connections, sockets, whatever, turn vapor. Since the app disconnects almost immediately when the mobile browser gets out of range, all the session context disappears.

Here is an idea :

  • In Session Open, a Hashtag is added to the URL with a unique ID corresponding to the device
  • A database in App records the state of the app whenever a change occurs : placement and state of controls, variables, opened database name and stuff. Everything.
  • Upon disconnection, opened databases are closed and saved.

Upon reconnection, when the browser refreshes, it creates a new session which identifies the hashtag, and restores all the context from the app database.

It is not simple to do and depends on the complexity of the app, but it seems possible. In the case of the example from the OP of an app in a warehouse, the catch is that no data must be entered while there is no connection. It would not be taken into account since the app would restore the situation prior to loss of connectivity.

Maybe in that specific example, I would rather use a thick client written in Xojo iOS (or B4A for non Apple tablets) which connects to the app through a web service. That way it would work just fine whatever the connectivity in all corners of the warehouse, and transparently update the database when it has a chance. As far as I can tell, that is the way a lot of apps proceed.

Do Xojo’s disconnect timeouts vary depending on the events used? For example, if an app doesn’t utilise selection change or other chatty events, then should it not be given a longer timeout to increase robustness?

Also it would be nice if Xojo had the option of letting the developer decide how to handle a re-connection. For example if the app is a stock ticker or other information providing app there is no reason why a network failure of several seconds should force end users to be kicked off the server.

Finally, it would be nice if there was a feature which allowed automatic re-connection when the network comes back up a bit like how Gmail waits for the connection to come back. Meanwhile the UI could be frozen (with an optional developer-defined message to the user) until the connection returned to prevent synchronization problems.

[quote=217950:@Michel Bujardet]There could be some way, but it is not exactly simple.

In a web app, everything is tied to the session. So effectively, when the session ends, all webpages, database connections, sockets, whatever, turn vapor. Since the app disconnects almost immediately when the mobile browser gets out of range, all the session context disappears.

Here is an idea :

  • In Session Open, a Hashtag is added to the URL with a unique ID corresponding to the device
  • A database in App records the state of the app whenever a change occurs : placement and state of controls, variables, opened database name and stuff. Everything.
  • Upon disconnection, opened databases are closed and saved.

Upon reconnection, when the browser refreshes, it creates a new session which identifies the hashtag, and restores all the context from the app database.

It is not simple to do and depends on the complexity of the app, but it seems possible. In the case of the example from the OP of an app in a warehouse, the catch is that no data must be entered while there is no connection. It would not be taken into account since the app would restore the situation prior to loss of connectivity.

Maybe in that specific example, I would rather use a thick client written in Xojo iOS (or B4A for non Apple tablets) which connects to the app through a web service. That way it would work just fine whatever the connectivity in all corners of the warehouse, and transparently update the database when it has a chance. As far as I can tell, that is the way a lot of apps proceed.[/quote]

I have thought about that, too. Two ideas for the web framework:

  • an easy way to save and restore a websession (preferably built into the framework). So when a session times out or disconnects, it can be saved and restored later (maybe using cookies or your hastag idea)
  • possibility to have a custom webpage which is shown when the disconnection appears (no redirect) or at least a feature to have an optional button on the standard disconnect page to “restore” or “resume” the session

Abort, retry, fail?

I don’t think that it is feasible. The main obstacle is that the web framework is event driven and events are sent from the client framework to the server framework. This is different from almost all other web framework, where most of the events are handled on the client side.

Any lost event due to an interrupted connection could transfer the client app into an inconsistent state. So each event sent to the server would need to be confirmed by the server and until this confirmation has arrived on the client side, the client app would have to hold back any other events which need to be sent to the server. And this each time for almost each event including key presses and mouse moves.

IMHO the only way to change that would be to create a new web framework which runs XojoScript on the client side. But then one would lose the security which now comes with the application specific code running on the server.

This could be addressed by freezing the client which might not even be noticed if the end user was reading not typing. A session might be suspended for a minute or two to allow such re-connection before being terminated. Booting users off the server seems a bit harsh…

[quote=217950:@Michel Bujardet]There could be some way, but it is not exactly simple.

In a web app, everything is tied to the session. So effectively, when the session ends, all webpages, database connections, sockets, whatever, turn vapor. Since the app disconnects almost immediately when the mobile browser gets out of range, all the session context disappears.

Here is an idea :

  • In Session Open, a Hashtag is added to the URL with a unique ID corresponding to the device
  • A database in App records the state of the app whenever a change occurs : placement and state of controls, variables, opened database name and stuff. Everything.
  • Upon disconnection, opened databases are closed and saved.

Upon reconnection, when the browser refreshes, it creates a new session which identifies the hashtag, and restores all the context from the app database.

It is not simple to do and depends on the complexity of the app, but it seems possible. In the case of the example from the OP of an app in a warehouse, the catch is that no data must be entered while there is no connection. It would not be taken into account since the app would restore the situation prior to loss of connectivity.

Maybe in that specific example, I would rather use a thick client written in Xojo iOS (or B4A for non Apple tablets) which connects to the app through a web service. That way it would work just fine whatever the connectivity in all corners of the warehouse, and transparently update the database when it has a chance. As far as I can tell, that is the way a lot of apps proceed.[/quote]
This depends on being able to serialize and unserialize Xojo objects, since the data inside the session properties, its windows, etc are not all intrinsic. In order for this to work, EVERYTHING that represents a session must be serializable and unserializable. When developing WE originally, this is a door I beat on very heavily. It isn’t going to happen.

We considered an event where the developer could manually encode and decode objects, but this idea was generally regarded as awful.

Connection recovery in any environment is a complicated subject. HTTP is stateless and short-term, so most web pages have zero issue with this. But what WE does is basically abuse of HTTP, and options are limited. If this were a custom protocol, we’d absolutely be having a different conversation.

I find myself working heavily with containers in WE, it makes developing WE apps way easier IMHO. Mostly doing database applications.

Most of the containers do have some sort of initialisation method (not using the constructor as I experienced inconsistencies/bugs there) to preload data, e.g. details of a customer record. I use my own ORM and subclassed webcontrols to manage display/update data automagically (to some extent at least). From there, it shouldn’t be a huge leap to build restore capabilities I suppose.

Just wondering if there’s a more generic way to accomplish that instead of coding the same procedure for each webview (container, page, dialog, …) over again (not talking about general serialisation though).

Increasingly a user’s data is going to have to be serialised upon disconnection anyway because people don’t want to re-enter previous screens of data. So the session is going to have to be rebuilt one way or another. The question is will Xojo do it or does the Xojo developer have to do it. If the latter is best, then the Xojo developer needs a reference from the dead session to initialise a new session. One way might be hashtaging the URL but that relies on the end user to refresh. It might be nice if the remnant of the dead session in the browser tried to refresh periodically for a time to allow a graceful restart of the app by the Xojo developer. Because at the end of the day serializing the session wholesale might be expensive for Xojo Inc. and not provide flexibility for the Xojo developer to pick up a broken session from a place where it makes business sense to restart. For example, a person’s credit card details are better destroyed than serialized by Xojo in a session object – meaning the user might need to be restarted in another place in the app anyway.

Another way to do this is what we did for XDC this year… Build the front end as an iOS app and then only connect to the web app (via HandleUrl) when the client needs to send data. One major advantage is that through Jason’s samples, you can scan barcodes on the client side.

Well that’s a case-in-point against serialising the session rather than the session’s data and rebuilding the session: Let’s say the iOS battery gives up and the user logs into the Web app on a desktop. They can then be restarted by the Xojo developer in the Web app from iOS app where it makes sense and vise-verse. But if the session is serialised you could be stuck with the platform and/or your app version.

Haven’t read all posts here but anyway…
A load balancer like HA-Proxy can be used to keep a session alive when walking between wifi, 4G or temporarily loosing internet connection.

Could be a working solution for now?

Won’t the Xojo server kill the session if the client disapears (especially if it has dropped down to AJAX if WebSockets aren’t available) ?

Exactly what I was describing as thick client. I did not realize you had already used that technique for the XDC app.

Back in the early eighties I was working for the French network CalvaCom, a local equivalent of Compuserve. Since the thing was text only and as slow as everything modem then, we had apps for Mac, Apple II and PC that provided the UI on each machine with it’s particular look and feel.

The advantage of the thick client over any other session resume system is that there is no data loss while connectivity is out.

The load balancer will keep the connection alive since it’s the load balancer that is connected to the app and the browser is connected to the load balancer :slight_smile:

There are settings for load balancers to keep sessions open for a set period of time.
http://john-joyce.com/xojo-and-load-balancing-with-haproxy/

That’s not how this system works. Both the browser and the Web App expect to have pings from each other periodically. If the browser doesn’t hear from the server, it shows the “disconnected” overlay. If the Web App doesn’t hear from the browser for 3+ minutes, it ends the session. Adding a load balancer to the middle will not affect this.

What you DO get from the load balancer is that it will always send the browser to the same instance of the app, so if you have 2 or more copies of the app running on separate ports, they can all appear to be the same app.