I'm implementing a programmable BLE button. I've managed to implement the
scenario when the app is terminated by the system and then when I press the
button the bluetooth central manager restores its state with the centralManager(_:willRestoreState:):
method. The peripheral is connected and all the services are visible. But this happens only after I
emulate the app termination via kill(getpid(), SIGKILL).
But. When I terminated the app via double clicking the Home button and swiping the app off the screen
the centralManager(_:willRestoreState:): is not called and the app is not returned to the background.
Why is that? It turns out that termination of an app with the ios itself and the manual termination
of an app are different things.
So how can I make so that the app is returned to background not only after ios app termination but
also after manual termination?
This is desired behaviour. IMO there is no way to work around. If user swipe up your application in the app switcher, that means that he/she don't wont to be bothering by app anymore. This is Apple way to respect user's privacy.
The same thing with remote notifications.
Related
I have implemented Agora call in iOS app which works perfectly fine when app is in foreground ... Actually in my case we initiate call through Bluetooth BLE iBeacon. Along with this we call an API which is also working fine.
Problem is when app in background or when phone is locked ... Even when app is in background, app listens bluetooth event and Call API but it never start Agora call until we bring app to foreground. Means call works in foreground or it waits to start call when app enter in foreground.
To handle this I implemented local notification to prompt user to tap notification and bring app to foreground. But we want to do it through Bluetooth iBeacon. That instead of user to tap notification, it press beacon button to bring app in foreground and start call. On beacon button press I can catch the event in background as well but unable to bring the app to foreground.
Could not find some solution of it. But seems like its do-able as with Car tablets which are connected with bluetooth to phone we can dial a number on tablet and through bluetooth communication with phone it makes a call to selected or dial number even when phone is locked.
Means third party bluetooth devices can send command to locked phone and initiate call.
There are two ways using that you can make calls when app is in background or in locked state even your app is in killed state.
Using CallKit Framework provided by apple.
You can send custom push notification to the user and on click of push notification application is wake up and call is happen.
I am working in a chat application where I need to show user status (offline/online).
When my app is in foreground and background then I need to show user as online (managing by VoIP).
But when the user kill the app then it should go to offline.
I have to maintain a flag to show offline which I am managing in delegate function applicationWillTerminate but this function only called when app is in foreground state and user kill it by pressing double tap home button and swipe up.
This function does not get called when app is in background state. I mean simply press home by single tap (app will go in background) then again double tap to swipe up.
Is there any function where I get 100% call either app is in background/foreground state and user kill the app?
Is there any function where I get 100% call either app is in background/foreground state and user kill the app?
No. Just the opposite. If your app is terminated when already in the background, if it is suspended (ie not running in the background due to special entitlement), it is 100% certain you will get no event. You cannot. You are suspended and not running. The app dies in its sleep.
No, As per Apple Document
https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623111-applicationwillterminate?language=objc
For apps that support background execution, this method is generally not called when the user quits the app because the app simply moves to the background in that case.
What you can do execute a method(which hit an API for keeping status online) after few seconds(whatever you find suitable time) when you app goes in Background, If method is calling successfully after that specific seconds then user stay online, if its not call after specified second then server update its status to offline. So It require both server and client handling.
I have a requirement where i need to track the iphone device state like if device is locked or unlocked. I was able to track these events when the app is running in foreground or background. But i also need to track the same when the app is suspended. Something like tracking the user location in background when the app is suspended. But i don't need to track the user location but only the device state.
Please suggest me some steps to solve this issue in objective-c.Thanks in advance.
You can not perform any operations once your app is in suspended state and you can not prevent your app from getting suspended unless you are using one of the background capability mode mentioned in this apple doc
So what you are looking for is not possible if you are not using either of background modes allowed by apple.
EDIT
Even if you go on and enable one of background mode like background audio, your app is likely to be rejected during review process as reviewer will see you do not have a valid reason to use that particular background mode.
We're seeing a strange situation on our iOS app that is impacting our user experience.
When a user background's the app (by pressing the Home button), we can clearly see the app entering the background. When the user then force-closes the app (by double-tappinging the Home button and sliding-up on the app), the app terminates normally. When the app is then re-opened, it follows the normal iOS start-up sequencing.
However, if the user double-taps the Home button while the app is running (resigning the app from active, but not sending it to background) and then force-closes the app (by sliding-up on the app), we're seeing the app terminate (the process gets killed), but then the app immediately re-starts in the background (with a new pid). The app is not designed to start-up or run in the background, and this is causing UX issues.
The app has no entitlements to run in the background, although we do have a couple of third-party libraries that have tasks that wind-down when the app enters the background.
I suspect the issue is a result of the app being force-closed from a non-active state rather than a background-state. If the app enters the background first, the third-party tasks are getting a chance to complete. If the app is force-closed from the non-active state, the tasks never get a change to complete in the background, so iOS is restarting the app in background to give those tasks a change to finish. It's unclear, however, if this is correct behavior.
-Stix
I'm kinda thinking the questions were self-evident, but if not:
Is this correct behavior for iOS? Should iOS be restarting the app in the background when the user force-closes the app w/o putting it into background?
If this is correct behavior, what can cause this to occur? Is it possible some third-party framework - still running a background task that hasn't completed - is the culprit?
The force-close works fine if the app is put into background first (giving background tasks the ability to complete/expire). Is there anyway to force it into background when force-closing the app while it's in a non-active state?
I am trying to force my app to automatically enter the "Suspended" state programmatically, so I can do testing on Core Bluetooth restoration.
I have tried calling
[[UIApplication sharedApplication] performSelector:#selector(suspend)];
but this merely sends it into the background. Am I doing it wrong? Is there a better way? Or is it impossible?
I would like to remind everyone exactly what it means to have an app be suspended, as there is always confusion on the terminology:
(source: apple.com)
An app in the background will get indefinitely suspended if the system needs memory, but Core Bluetooth's restoration can send an app back into the background state temporarily.
I don't know how to do this programmatically, but what I do is to press the home button, then launch a number of heavyweight apps like Safari and graphics-intensive games. The memory pressure causes the system to terminate your app pretty quickly. Core Bluetooth should then initiate the restore process and re-launch your app when it detects activity from a peripheral you are connected to/have asked to connect to.