I was testing my app in the simulator when suddenly this error appeared on the console. I have no idea what it even relates to - whether it's Firebase, local notifications, or something else. I can't find any information about it online either. Does anybody know what this error means?
[BackgroundTask] Background Task 17 ("APMAnalyticsMeasurementBackgroundTask"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. Remember to call UIApplication.endBackgroundTask(_:) for your task in a timely manner to avoid this.
Related
So, I have an app that runs an HKObserverQuery in the background. We take data from HealthKit and push it up to our server for further analysis.
When we do an app update, however, we usually see a spike in requests made to our server. It usually times from when the app becomes available in the store, and usually dies down a few days later.
My question is - when an app is updated, does it try to resume a particular state or something after the installation occurs? Our data fetch/upload process is called in applicationDidFinishLaunching, and my only hunch is that after the update occurs it tries to resume a state, thus invoking that function.
Any insight in to this would be real helpful. Thanks!
EDIT: my curiosity exists because I can't imagine all of our users opening the app after an update occurs, especially the auto-updaters. So my question revolves around if iOS attempts to load the app after installing an update to verify it, henceforth calling applicationDidFinishLaunching, but without bringing the app to the foreground.
I have been dealing with this issue for weeks and am unsure if it is my code's fault, forge's appPaused event not triggering quickly enough, or Trigger.io's documentation not being nearly clear enough about just how little time iOS gives us to execute clean-up code.
According to the documentation regarding the appPaused event:
iOS: A short amount of time is given for execution, it is generally best to assume that callbacks and timers may not fire until the app is resumed.
My application deals with websockets and ideally I am able to send a close event to my server when a user minimizes my app, or the phone is locked. Currently, all of my clean-up code runs perfectly on Android, but on iOS, my clean-up code doesn't run until the app is resumed. The strange part is sometimes (maybe 1 out of 20 times) the iOS clean-up is correctly run right after the appPaused event is fired.
To test this I have done two things:
I make the very first thing to run after the appPaused event is fired is a message to my websocket server saying "the app is paused". 95% of the time, this message is not actually sent until the app is resumed, but the other 5% of the time my websocket server receives it right after I pause the app.
I then made it so the first thing to run after the appPaused event is fired is a line that stores Date.now() in a global variable. I then then store Date.now() in another global variable when the app is resumed, and find the difference between them. It gets interesting because around 50% of the time the Date.now() line is correctly fired right after the appPaused event is called, but the other half of the time the 2 Date.now() calls are only milliseconds a part, proving that the clean-up code was not run until the app resumed.
So, can I really only expect to sometimes have enough time after appPaused is fired to even store Date.now() in a variable? Is this what everyone else is experiencing when running their Trigger.io applications on iOS? Let me know if anyone could use more information.
Yes, appPaused is not guaranteed to fire on iOS. Note, that it may only fire when the app is resumed.
Any code you want to run on going into the background will probably not run. See the trigger io docs on events. The note on iOS needs careful reading.
That said I have a similar app to yourself dealing in websockets. What i've found is that I can leave the socket open, iOS automatically kills the socket when it suspends the app (Sometime after the paused event is received which corresponds to the ios background state). The server receives the close event and you can of course attach to that event to set any state or cleanup resources. Android requires a manual shutdown of the socket, but appPaused works in a guaranteed way when the app is put into the background.
After rebooting my phone, my app stops getting CoreLocation delegate callbacks, is it an expected behavior? I think I remember reading that you could still get callbacks. If so, is there anywhere in the documentation saying if its possible or not?
This is not normal. An app is supposed to get callbacks to CoreLocation's methods after your phone reboots, and I have built this feature into multiple apps and verified it works.
Three things make this hard to test, so be sure you are taking these into account:
After an iOS device reboots, it does not perform bluetooth scans to look for iBeacons right away. I do not know the exact timing, but it may take a minute or more.
Even after the above time passes, scans for iBeacons are not happening continually when your app is not ranging for iBeacons in the foreground. Make sure you wait up to 15 minutes (16 minutes after reboot) before you declare that you aren't getting background notifications.
In a typical setup, you won't see your logging statements after a reboot. So it is quite possible you are getting callbacks but there is nothing visible happening as a result. Make sure you do something in your callback for testing, like an unconditional local notification, so you know for sure whether you are getting the callbacks or not.
I am developing a VoIP app. When my app is in background I need to check if the server is still there. So I am trying to use setKeepAliveTimeout:handler: to make polls to server while app is in background.
The question is: how to ensure that I receive response or timeout within 5 seconds after I have sent poll message to server? If I don't receive response/timeout within 5 seconds the next opportunity to know that server is dead is only after keepAliveTimeout time which is not that good.
As I understand I can't setup NSTimer in setKeepAliveTimeout:handler: since we are in background (and NSTimer relies on run loop).
I see other possibility which is: make while loop and check for the current time in it. Although I would like to avoid making busy loops.
Could you please suggest me how can I achieve needed behaviour?
I have an application that handles applicationWillResignActive and applicationDidBecomeActive notifications by doing stuff like pausing/unpausing BG music, etc.
I am experiencing a weird bug, in which in every 3-4 times becoming inactive and returning (e.g. locking/unlocking the device), the app seems to be completely stuck for a few minutes - meaning, I see the view I'm supposed to see, but I can't touch anything, and music isn't playing.
I debugged it, and it seems that the applicationDidBecomeActive notification is not getting called what so ever.
I looked at the log of my app and literally didn't see anything there for the entire time the app seemed stuck.
The only interesting thing is that in the device's console I could see this line appearing about 10 seconds after I unlock the device and noticing the stuck application.
Mar 20 11:51:13 unknown MobileStorageMounter[4882] <Notice>: (0x3f4d948c) idle_timer_callback: Exiting after idle timeout
Not sure if it's related.
Anyone had a similar problem?
It could be that a call to TestFlight is timing out, and prior to the timeout the app locks the main thread, which freezes the interface, until the request is processed or times out. This could happen if the request failed to complete before the system pushed the app into an inactive state, meaning that when it returns to an active state it would still be trying to listen for a response to the request that it will never receive, hence the timeout. The same can occur with Flurry Analytics (at least older versions of the SDK that I have used), and they happen to me as well when calling my own homemade API's and API responses are delayed by a second or two.
Turns out it was a bug in the TestFlight SDK, upgraded from 0.8.2 to 0.8.3 and problem was solved