WebSDK significantly expands the WE possibilities.
It is even possible to work only with the WebSDK.
In this case, it is sometimes interesting that the framework does not close the client side when the communication with the server is turned off.
Indeed, with the WebSDK, it is possible to have a virtually autonomous page (in the browser).
For example, if we had a ‘server not available’ browser event, we may decide to close the client side (as now) or not (and in this case, it would be up to us to deal with the fact that the client side can not communicate with our server app, temporarily or not).
It would be a big breakthrough!
Note: We already have the “disconnect” event, but works in the other direction: Notify the server that the client is closed.
Fwiw, there is a disconnect event described on page 26 of the Web Control SDK book. It doesn’t let you intercept the event, but at least you know that it has happened.
Yes, thank you Greg, this event actually triggers client side when the browser can not access the server.
But it is useless in this case.
Apparently, the framework sends a ‘serverevent’ query about every 3 seconds. If the request fails about three times, the error page is displayed and the session is broken.
So if internet is inaccessible for about 10 seconds, the session is broken.
10 seconds, it is very short. With a mobile, sometimes passing through a tunnel, the subway, etc… Even in a business or a warehouse, a user will sometimes move in an area where there is no wifi.
My clients do not understand why we must restart the web app each time they pass a few seconds in an area without wifi or 4G.
They understand the need to wait and wait for the response from the server until the network is available again, but they do not understand that we should restart the application.
My initial request was malformed, the event is already there. We actually need a timeout in this event.
At first glance, the major hurdle we have is that the framework doesn’t cache requests being sent to/from the browser, so the big problem here is that once the connection fails we’re already out of sync with no chance of getting it back. The framework (including subclasses of WebControlWrapper) rely on the server and browser being in sync for certain operations, so we’d need to overhaul the event transmission system to handle this better. I’m not saying “No” to your request, just “Not Yet”.
FWIW, the traditional Ajax mechanism that we use for non-iOS devices was removed when iOS6 was released and we moved to the HTML5 ServerEvents mechanism (for iOS only). The frequency of the ServerEvents is determined by the browser, and they’re actually a form of Push mechanism. Basically, they’ll be closer together depending on whether the device is plugged in and its network connection (Wifi or Cellular). It’s all about saving power.
So it’s not so much about whether the browser can reach the server, but rather whether the server is getting any requests from the browser to maintain the ServerEvents connection.
Using an http1.1 protocol would a “resume connection” by session be a solution? This would definitely be a great feature. But im sure a lot would have to be done framework side before such could be implemented.
Now that Xojo Cloud is finished, it could actually be the new big challenge: rework the communication between the server and the browsers: HTTP 1.1 / websocket / cache requests.
[quote=154618:@Brock Nash]I wish it were - the WebFramework needs a major overhaul not just for ClientSide scripting and caching but also webstyles and layout etc…
I really believe the Web framework will be the future. Even more-so than the mobile frameworks we want now.[/quote]
Actually, both are becoming intertwined more and more transparently. It would be nice to have a higher level of integration between desktop, iOS and WE.