Thanks Andras, that might work.
Kill is different to memory pressure I think as kill will not call applicationWillTerminate. Nick
If your app is killed, it is killed completely. As far as I remember, the bluetooth restoration registration is also deleted. It is not preserved between reboots either. (Maybe different on iOS 9) But significant location monitoring is a lot stronger facility. I revives your apps after reboot, maybe even after kill from the task bar. (http://stackoverflow.com/questions/16226536/location-services-still-running-after-app-is-killed) The first location update happened about 3 minutes after reboot on iOS 8 and an iPhone 4S, in my case. In this update you can reinitiate the connection request. Bluetooth advertisement cannot be started from the background. To kill your app, the easiest way is to create a button the executes the following code: kill(getpid(), SIGKILL);
Works only if xcode is not connected to the app in debug mode. Darren's way of exhausting memory also works but it takes a lot longer. Br, Andras On Mon, Jan 4, 2016, 9:21 AM Darren Jones < email@hidden> wrote: I don't believe there is a way around it in afraid. Just like when your app is first installed, it won't do anything until the user first launched it.
Sent from my iPhone Thanks Darren, that allowed me to test the system killing it, so my App continues to work in that case.
Just hoping to figure out a way around the ‘user kills it’ case now.
Would it be possible to scan for devices instead, so if the user kills the App and the device disconnects then it would be picked up advertising again and start the App in the background? I don’t really want to do this, because it will run down the battery by scanning unnecessarily, but I would like to ensure the App is always connected to the device if possible.
Is there a way to simulate the App being killed in the background by the system?
Thanks
Hi Nick,
if your app is killed by the user, then you are done. There is nothing to prevent or act upon it.
If your app is killed by the system, then state restoration should do its job, given you set up the connectPeripheral:options: options correctly. Please look up the related documentation and tons of StackOverflow Qs.
To keep your app connected, you should issue connectPeripheral with the same parameters as previously, as soon as you receive the disconnected callback.
Thanks, Andras
|