Currently, once the server is no longer accessible for a few seconds, the web app exits abruptly. For example, in a warehouse, as soon as one moves in a free wifi zone a few seconds, the web app quits.
This is a big weakness of the Xojo framework.
When disconnecting internet, it would be much more effective if:
By default, an alert warns the user that the server is no longer accessible and it takes patience. Once the Internet is available, the alert disappears and the user can continue using the application.
This default behavior can be changed by the developer. For example, using the WebSDK.
I think it would be a major improvement. If you think so too, please vote!
[quote=122782:@olivier vidal]Currently, once the server is no longer accessible for a few seconds, the web app exits abruptly. For example, in a warehouse, as soon as one moves in a free wifi zone a few seconds, the web app quits.
This is a big weakness of the Xojo framework.
When disconnecting internet, it would be much more effective if:
By default, an alert warns the user that the server is no longer accessible and it takes patience. Once the Internet is available, the alert disappears and the user can continue using the application.
This default behavior can be changed by the developer. For example, using the WebSDK.
I think it would be a major improvement. If you think so too, please vote!
I checked with my download app. If I turn the Wi-Fi off after the app has displayed in the browser, it stays displayed. Simply, the button does nothing. When I turn the Wi-Fi back on after one full minute, the button works. There is one issue, though : text entered in the textfields is not seen by the app.
Maybe the unwanted exit happens for another reason ?
[quote=122782:@olivier vidal]Currently, once the server is no longer accessible for a few seconds, the web app exits abruptly. For example, in a warehouse, as soon as one moves in a free wifi zone a few seconds, the web app quits.
This is a big weakness of the Xojo framework.
When disconnecting internet, it would be much more effective if:
By default, an alert warns the user that the server is no longer accessible and it takes patience. Once the Internet is available, the alert disappears and the user can continue using the application.
This default behavior can be changed by the developer. For example, using the WebSDK.
I think it would be a major improvement. If you think so too, please vote!
Most users just walk browse away from the site in my experience and expect to get logged out.
For what it’s worth, when a browser disconnects, we have no way to know if it’s still in sync with the server. Checkboxes may have been checked, menus may have been changed. If the browser were not connected to the app, those messages would disappear into the ether. That’s the reason for the disconnect…
It seems to me that the right solution is to fix the gaps in the wifi network.
For some time, the behavior is inconstant indeed. It is especially on mobile browsers that the problem occurs. I just tried on iPad, Android phones, Windows Phone: the app quits after a few seconds.
This is less true for professional web applications. But anyway, there is always the timeout right?
Indeed, as you said in this thread, requests are not cached. It is a weakness of the framework. It would be a nice improvement to correct that.
Matthew also indicated a solution with HTTP1.1. I saw that WebSocket is implemented in the next version :-)) and the “HTTP1.1” feature request had the status “Scheduled”, maybe this will help?
Frankly, it’s a return to the 90s!
it’s not just the wifi, but also the cellular network, people move now…
There are plenty of situations where the wifi or cell network will be unavailable seconds. In one month, how often a lawyer or a lawyer travelers will have the problem? 10 times? 20 times?
Imagine a lawyer typing text in the waiting room of an airport. He will be furious if he has to regularly relaunch the web app, to be blocked each weakness of the network, he will feel back to Web 1.0!
I think that Greg made a very important point. In order to define the proper behavior that the app should have, it is essential to know whether the user walked away or temporarily lost the connexion.
With my limited telecommunications knowledge, I cannot see how the app can make the difference. In my view, only the use of a longer timeout period can circumvent the issue that you are describing. If you know how the app could distinguish betwen a temporary network loss and a user that simply shut down the browser, I am certainly very interested to learn about it.
This has been my problem with adopting WE - I have clients in Africa, India & other far off shores who have browser access to administer our software hosted here in the UK. Their net access is, er, patchy at best.
Now, I know in theory there’s no difference between a “normal” web app and Xojo losing connection to the server - neither can use the application to communicate with the hosted software. But the “normal” web app just does not a lot (stops realtime updating, etc.) whereas Xojo clears the screen and puts the message that everything has died up. This gives a perception of system failure that is far greater that the “normal” web app, even though they both fail the same amount of times because the problem is their network and not the application.
Also, if the system fails whilst the user is updating some data on a form rather than watching a live activity page, then if the net connection comes back before they hit submit then the “normal” web app will not even indicate that it had an issue. The Xojo app will (assuming it’s dead long enough for the polling to fail).
If I’m being a knob please tell me, but I can’t see a way around that.
The problem is that our web apps don’t run completely on the browser. Just about every action that a user takes sends an event back to the server for processing so that you can write Xojo code. Not javascript, not css, not HTML, XOJO code. That’s wherein this problem lies. The current framework needs a consistently open channel to do most of the interactivity. So no, our web framework is currently not designed for use with spotty internet connectivity.