MQTT JS don't connect when mobile browser is not active - mqtt

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.

Related

Vaadin Flow UI stops updating

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.

Websocket connections on iPhone get lost when safari is un-focused/hidden

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.

Autostart chrome app on wake up mainly on chromebook to update its data in background

I am new in dart and want to create a chrome app that should work on Chromebook.
I need some data to get updated at particular interval even if app is in background or chromebook has just booted/woke up.
Is there any setting or need to do some kind of programming?
If you want to get your background page active it's more complicated...
First you have to add in your permissions "background" else with the window your background page will be immediately inactive (declare permissions)
After that you need to keep your background page alive and for that you should look at the chrome.alarms API and when your alarms is fired you can call your server to retrieve information

Chat app synchronization on background in IOS

I have a chat application developed by JS. I want to send PING to server once in a while. Its not a problem if app runs on fore ground. The problem is when user minimizes it or open another app. My app looses its focus and gets into suspended state.
I have following two use-cases.
To keep the chat session open I need to send PING to server (Its an IRC server) every X minutes even the app runs in background.
We also need to check for new messages (by ajax on a local http server) and add a local notification to the notification queue so when user clicks on it app can resume
I have found apple does not allow running apps in the background. if they allow they require special permission. I found some apps does it by requesting finite length execution time.
What is the best way to get highest possible background execution time? As a chat app can I request permission for voip, location or any other way ?
Note: the app will be running in an environment where there is no Internet. Hence push notification will not work here.
Update: After doing a lot searching I found background fetch. It seem background fetch will suite it. But still the problem remains, its not called in a timely manner.
This sounds like an interesting problem. From reading the various comments, it sounds like you want this to work when you're on a local network - so you have wifi, but the wifi router/base station isn't connected to the actual internet?
Because background refresh isn't going to be predictable - you'll never know when it is going to update - you might want to get creative.
You could look into exploiting iOS VOIP support, only without the Voice! Apple has some tips on VOIP here. VOIP basically uses something called SIP (Session Initiation Protocol), which is signalling layer of the call, and a lot like HTTP. It's this SIP layer that you want to take advantage of.
This isn't going to be terribly easy, but it should be achievable. Setup your app to use VOIP, and then look into something like PJSip as your SIP library. Then, on your local network have a SIP Server (I'm sure there are plenty open source implementations) that you can register your iPhone against (so your server knows where your phone is, pretending to be a VOIP phone). This should work, because it doesn't need to go through Apple as far as I am aware... And will run happily on your local network.
Then, the server can send a message via SIP to the handset, as if it were instigating a VOIP session. You app is awoken, gets the messages - ideally from the SIP message if possible - and then just doesn't start the session. SIP was designed just for creating sessions, not just VOIP. When I worked in Telecoms R&D (a long time ago) we were using it to swap between Text/Voice/Video, all using local servers.
You'll have to jump a lot of hoops to make this work, but it would be pretty awesome. I have never tried this actual use case - especially with iOS, but I'm fairly sure it will work. It is a bit of a fudge, but should get you where you need to go.
Good luck!
You can use something like PubNub to build this chat app with iOS using native Objective-C code, or with the Phonegap (Cordova) libs.
The beauty with using a real-time messaging network like PubNub is that when the app goes to the background, you can easily have the chat messages come in on APNS.
When the app is in the foreground, it can just receive them as the native (PubNub) message. And if it needs to "catch-up" with the messages it missed while in the background (but received via APNS), its trivial to implement.
Also, PubNub is platform agnostic -- so you can easily also use it on Web, Android, BB, Windows Phone, etc.
http://www.pubnub.com/blog/build-real-time-chat-10-lines-code/
http://www.pubnub.com/blog/html5-websockets-beautiful-real-time-chat-on-mobile-using-pubnubs-channel-presence/
https://github.com/pubnub/objective-c/tree/master/iOS
https://github.com/pubnub/javascript/tree/master/phonegap
geremy

How can I determine if an iOS device has come back into Network coverage if the user has closed the app?

We are building an enterprise class Work Order application where the users will often be in areas with no network coverage. We want to be sure that when they come back into coverage, any work that they have done on locally stored work orders is sent back to the server ASAP. This is easy to do if the user keeps the app running, but in our situation it is very likely that they will switch between apps, and the Work Order app may not be running when they come back into coverage.
We have thought of having the app fire an email to a server side listener when it senses that it is out of coverage. When the device comes back into coverage, the email should get delivered, and the server can send a push notification to the user to open the app. This feels like a bit of a hack... is there a better way to handle this situation?
As you already noticed, push notifications is the way to go, but even with them its not guaranteed that the user will send the data or even open the app.
I would suggest that you make the data itself expire after a limited time and alert the users when they minimize or even close the application.
You can also use local notification to alert about expiration.
So long as this is an enterprise application that doesn't have to be distributed through the App Store, you can abuse the audio background processing mode to keep your application running at all times. All you have to do is play a silent audio file on a loop as if you were a media player. This will keep your application running in the background, where you can retry connections to the server as you'd like.

Resources