Inside WLClient.h mention this comment.
#note The client sends a heartbeat signal to the server only when
the application is in the foreground. When the application is sent to
the background, the client stops sending heartbeat signals. The client
resumes sending heartbeat signals when the application is brought to
the foreground again.
I set my setHeartBeatInterval to 420. which is default. But when the app goes into background with lock screen. It still will call the heartbeat after 420 seconds. Then my app crash.
Is there anyway to disable the heartbeat call when the app goes into background?
Thanks so much =)
On MFP 7.1, we are not seeing any issue with heartbeat in both iOS 9.3.5 and iOS 10. In both iOS versions, when the app is in background(by pressing home or behind the lock screen), the heartbeats are paused and are not sent.
We see this behavior in the latest v7.1 iFix version and on iOS devices running iOS9.3.5 and iOS10.
However, on iOS10 simulator, we can see couple of heartbeat requests are made when the screen is locked or if the home button is pressed. But, even here, when the app is resumed, there is no crash. This seems to be a behavior with iOS 10 simulator only.
Related
Previously, I had been using Xcode 13 to receive socket messages in the background state on iOS 15.5, and it was working perfectly. However, when I tried the same approach on iOS 16.2, the messages were not being received. I then updated to Xcode 14, but I'm still not getting any messages in either iOS version. Is there a way to receive messages in the background state from a socket in iOS 15.5 and 16.2?
I checked the socket is not disconnected in background state.
I have setup WSo2 EMM correctly. Noticed that device information and Get All Applications Notifications go pending and are never delivered to the devices. The status of these notifications in the database table is also P.
The only way to deliver these messages are by pushing the Camera Enable/Disable Operation or some other notifications, then the older pending notifications get delivered.
Seems they are stuck. This also happens to policy enforcement notifications. I have to manually push camera disable/enable to make these works.
Why does this happen? The notifications should be delivered instantly, like they do in Camera Enable/Disable case.
I am connected in Production Mode. Any pointers to sort this out?
I was using Java 1.6 earlier. Once I switched the JDK to 1.7, it appears to so far work well.
Background Info
I downloaded the Thread Pool Sample for Windows Phone 8.1 (C++) and modified it so that the periodic timer sends UDP packets to a remote IP on a regular interval.
Problem
I noticed the following:
The UDP packets are sent out regularly when the app is launched from MSVS 2013 regardless of what you do on the phone
The UDP packets stop being sent out when the app is launched from the phone's program list when the app is put in background.
Question
How do you create a periodic task on Windows Phone 8.1 which runs every 10 seconds? The periodic task must send out a UDP packet to a pre-defined IP:PORT address regardless of what the user is doing on the phone.
I had a look at this one:
http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh977059.aspx
but I don't see the possibility of having the timed task run every 10 seconds.
How to reproduce the problem
Link To Test Project
The test project includes instructions on how to reproduce the problem that I've described.
Unfortunately, what you're after is not possible on Windows Phone. Once the application is no longer active on the phone, it is tombstoned and no longer runs.
You can achieve something similar with Background Agents, but they are restricted in what they can do and they only run every 30 minutes.
There are other background agents that respond to different phone events, including location changes, network availability changes and geofencing triggers.
There's a slightly hacky method available to force a background tasks, and that's to impersonate an audio player task. It's not a great solution though.
I'm developing an app which relies on C2DM to be notified of some new data to be fetched from a REST service. I have successfully implemented the C2DM android feature, but the behavior over Wifi is different from the connection over 3G. The messages are received instantly over 3G, but I have to manually turn Wifi off and on to have a "grace period" of ~1 min in which I receive them instantly.
My question is: Is there any way I can programmatically restart the connection, or trigger the notification fetch?
EDIT:
I've implemented an AsyncTask that periodically "reassociates" the connection to the access point (using WifiManager.reassociate()) every minute and a half. Not so sure about the correctness of this solution, though.
I've seen similar issues. It seems that under some circumstances C2DM messages are not delivered over wifi connections, when they are over 3G. On a related note I've also seen Android devices "drop" the push connection, so messages are not delivered (in my case the solution can be to put the device in airplane mode and then turn the network back on).
This reinforces the fact that all applications that use C2DM should be built so that even if push messaging fails, the app still works (even if messages/updates are slower because there's occasional polling to the server)
I wouldn't personally want to mess with the wifi connection as that's something that may cause problems for the user.
I'm building a voip app for iOS and I'm handling working at background.
So far, i have iOS listening to the voip socket while app sleeps and wake it uppon incoming data.
My question is:
When the reachability has changed (Wifi -> 3G, Wifi -> Other Wifi, etc)
and the app is suspended, can I get some notification in order to reconnect my voip socket?
Thanks.
Answer was both Yes and No:
Register to Reachability network changes notifications.
If App goes to background suspended while its voip socket (see link) is connected, then uppon network changes app will wake up at background for 10 seconds.
If App goes to background suspended while its voip socket is NOT connected, then uppon network changes app will NOT wake up.
The solution for the scenario of network loss and going to background with no connection may be fixing the connection in the Keep-Alive block that you can schedule at UIApplication.
Note: during the mentioned 10 sec, you may ask for a background task in order to finish the reconnection job.
Links:
VoIP socket in iOS
VoIP socket wakeups - iOS 5 Watchdog
If you have a backgrounding socket you can subscribe to reachability notifications and they will fire while backgrounded so you can perform actions on the reachability changes. If you don't unsubscribe to the notifications when you hit the background you'll still get them if the object subscribing to the notifications is your app delegate.