Apple

Oh, yes, you are right. I never used that callback but will keep in mind. :)

2016-01-04 22:31 GMT+01:00 Nick Brook <email@hidden>:

Thanks Andras, that might work.

Kill is different to memory pressure I think as kill will not call applicationWillTerminate.

Nick

W: http://nickbrook.me

On 5 Jan 2016, at 07:30, András Kövi <email@hidden> wrote:

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

On 4 Jan 2016, at 08:15, Nick Brook <email@hidden> wrote:

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.

Nick

M: +44 (0)7986 048 141
W: http://nickbrook.me

On 4 Jan 2016, at 18:53, Darren Jones <email@hidden> wrote:

Im not sure if it still works, but when I needed to test this a few years ago I made this https://github.com/ddaddy/BackgroundKill

Sent from my iPhone

On 4 Jan 2016, at 07:46, Nick Brook <email@hidden> wrote:

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

Nick

W: http://nickbrook.me

On 3 Jan 2016, at 18:18, András Kövi <email@hidden> wrote:

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

2016-01-02 16:26 GMT+01:00 Nick Brook <email@hidden>:
Hi all, hoping someone can help with this.

I want my App to either be connected or attempting to connect to a known peripheral previously discovered or retrieved with -retrievePeripheralsWithIdentifiers or -retrieveConnectedPeripheralsWithServices. When the peripheral disconnects, re-connection should be attempted. In this way, the App receives notifications from the peripheral and presents local push notifications. This works fine when the App is in the foreground or in the background while still running.

In the background, if the App is killed for whatever reason (user closes, memory low) then the system disconnects the peripheral, but the App does not get notified of disconnection, so cannot reconnect automatically to continue receiving notifications. How can I attempt reconnection when the App is quit?

Nick

W: http://nickbrook.me

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References:
	>Background reconnection (From: Nick Brook <email@hidden>)
	>Re: Background reconnection (From: András Kövi <email@hidden>)
	>Re: Background reconnection (From: Nick Brook <email@hidden>)
	>Re: Background reconnection (From: Darren Jones <email@hidden>)
	>Re: Background reconnection (From: Nick Brook <email@hidden>)
	>Re: Background reconnection (From: Darren Jones <email@hidden>)
	>Re: Background reconnection (From: András Kövi <email@hidden>)
	>Re: Background reconnection (From: Nick Brook <email@hidden>)
	>Re: Background reconnection (From: András Kövi <email@hidden>)