I use a single websocket connection for my web app's notification and chat system. Everything works fine except that when using an iPhone, after closing/hiding Safari (which is actually just a hide/un-focus of the window I think) the connection gets lost and there will be no automatic re-connect after re-opening the Safari window. This might also occur on all other smartphones when hiding the browser window.
On desktop browsers this problem can't occur, as closing tab/window/browser will reload everything on the user's next visit ... But on mobile it seems to be more like:
Lose focus/hide window -> Cancel all client/server connections
Show window again -> Just show the rendered DOM and call Interval/Timeout functions
A solution I thought of is running an interval function every X minutes to check if a websocket connection exists otherwise create one ... This is ok, but I don't like this approach too much and was wondering if there is something I am doing wrong or missing on websockets as I used XHR Polling till now.
I use "Rails Action Cable" for my web app's websocket connections. As I use Vue.js for my frontend, so I wrote a custom package to use action cable's client side functionality instead of rail's full integration (https://www.npmjs.com/package/vue-action-cable) but I think the problem is more specific about websocket connections on mobile devices which un-focus the app window.
Experiencing this on an XHR polling app and a websocket app that uses Action Cable and React. The solution I did for the XHR polling was to utilize document.addEventListener('visibilitychange') and trigger on document.hidden to make a API call to the server whenever they come back to the tab. Essentially an "away" and "back" trigger. I plan to use that same trigger idea in React to then make sure the Action Cable connections are good. I can share that solution with you when it's done if you want.
Related
We have some users reporting an odd problem with our Vaadin 23 application in Chrome and Edge. The application randomly "hangs" such that the user can still interact with client-side components, but nothing seems to reach the server. The problem occurs more frequently when the users are connected to their corporate network from home via VPN.
The application is configured to use push with long polling, and is deployed as a WAR file on Tomcat 9 under Java 11.
There are no error messages in the Javascript console
A network trace (screen shot below) shows successful heartbeats, push renegotiations, and UI interactions
The server access logs mirror the requests from the network trace, so we are confident all requests are making it through to the server
What we are seeing is that the XHR POST requests are being generated when the client interacts with the UI (the ?v-r=uidl requests), but no server updates are ever applied to the UI. The application becomes unresponsive to user input. Interactions that are purely client-side (e.g. selecting a tab in a tabbed layout) still work, but no server-side updates ever get applied.
Any clues as to what is going wrong?
EDITED 10-aug-22:
An interesting observation that indicates the problem may be server-side: The XHR POST requests in the network trace above are triggered by clicking on tabs within a Tabs component. I added logging in the tab event handling to log a message every time a tab is clicked. When the application freezes, I can see the XHR requests in the server's access log, but I do not see the event handler log messages.
I am using mqtt and websocket for maintain a realtime comunication with a server, but i am noticed that my client, mqtt.js, don't works when my browser is minimized or tab is not active in my mobile device, any help?????
That's just the way mobile browsers work, they will suspend anything in the background to save battery.
I suggest you look at something like the page lifecycle events covered in this document from Chrome to see how to handle getting notified when the page is suspended and when it gets focus back and is resumed.
I am currently in the process of writing an iOS app and it's now been decided that there will no longer be an in-built real time messaging service. This was the main reason around using Socket.io on the server. So basically when the app is loaded it logged in in the background by sending the login credentials with the connection request. Now that I don't need the messaging service, most of the app is just information requests and the server responds with the relevant information. I could still utilize the real time aspect by sending updated information to the device if it gets updated on the server and some in-app notifications could utilize this too. However I'm pretty sure it can be all done using http requests and I'm not sure how likely I would need real time functionality in a future update.
Ignoring time and money, should I fundamentally re-write the way the server and the app communicate or would it be okay to continue using Socket.io and websockets?
I want to make an iOS application (for iPad specifically), which behave like a web server.
I saw the examples coming with COCOAHTTPSERVER, but i didn't understand something.
Is it possible for my application, while being in background, to receive a request from another application running in the same device?
If it is possible how can i do this?
Otherwise, if it is impossible, what is the meaning of a web server application, that can't work in background?
My exact problem is as follows: I need an iOS application that can receive a request from a javascript application, running on safari, in the same device. Can i create an application behaving like a web server in background (because safari must be in foreground), or there is another way to implement this?
You can run a web server in the background on iOS but unfortunately only for a limited time (up to 10 minutes max) and the OS can stop it at any time. See this tech note [1] for more info.
If that limitation is acceptable to you, you should use an already existing web server like GCDWebServer which handles background mode for you [2].
[1] https://developer.apple.com/library/ios/technotes/tn2277/_index.html
[2] https://github.com/swisspol/GCDWebServer#gcdwebserver--background-mode-for-ios-apps
This library may make your task much easier.
https://github.com/swisspol/GCDWebServer
No, iOS does not support web servers running in the background.
The reason Apple does this is that a web server has to listen for inbound network requests. Listening for inbound network requests requires that the radios be active all the time. Active radios drain the battery.
I just found a very annoying thing about using websockets on iOS Safari (iOS 5.0.1). When sending two messages at very close interval (think 30 - 40ms, for example, sending a message at mousedown on a button and one on mouseup) the two messages arrive at 200 to 300ms of interval on the server.
This makes using WebSockets on iOS really painful for making a remote controller for example...
I'm affraid I know the answer, but is there anyway to make it work better ? It seems like it's a bug in the Websockets implementation of Safari but could it also be coming from the WiFi implementation (I hardly think so...) ?
I just found out some kind of workaround, and that the websockets implementation of Safari Mobile behaves even weirder than what I already found out.
While making some ping tests to validate my theory, I realised that I didn't have the problem anymore. Then I tested again with my original code and I had the same problem again.
Then I realised what changed in my code, compared to the ping test : the server never sends anything to the client. So, whenever my server receives a message from the iPhone, he sends a message back to it. That way, the latency disappears. It's really weird and there's probably something to be done to fix that issue, but in the meantime, this will do...