Eddystone not detecting when the app not running in ios about eddystone HOT 13 OPEN

Yup, you should be able to do this. You will need to enable the bluetooth-central background mode, and follow the instructions in the "Adding Support for State Preservation and Restoration" section of the "Core Bluetooth Background Processing for iOS Apps" guide.

I have (successfully) implemented a simple proof of concept a while back—it wasn't with Eddystone, but with another BLE advertising packet, but the idea is exactly the same (only the Service UUID was different). I'll see if I can still find the source code somewhere.

from eddystone.

I found the code, modified it slightly to use Eddystone service, and uploaded it here:

https://github.com/heypiotr/eddystone-ios-background-poc

If somebody wants to take the time to merge this into the ios-eddystone-scanner-sample, feel free!

from eddystone.

Hi,
i tested the above sample code in device, it works fine when the app in background state, but its not detecting the becons when the app is not running("not active" or "not in background" or "terminated"). did i miss any settings ?

from eddystone.

Are you killing the app via the app switcher? iOS won't relaunch apps explicitly killed by the user—if the user explicitly doesn't want your app running, iOS honors this request.

Your app should still be relaunched if it was terminated due to a memory pressure or iOS restart. Here's logs from my testing. I ran the app, then switched to some memory-intensive game. The app got terminated after receiving a memory warning, as expected, but got relaunched 3 seconds later.

Dec  9 09:14:50 Piotrs-iPhone EddyBckgrnd[32072] <Warning>: Received memory warning.
Dec  9 09:15:01 Piotrs-iPhone SpringBoard[61] <Warning>: Application 'UIKitApplication:io.heypiotr.EddyBckgrnd[0xc435]' was killed by jetsam.
Dec  9 09:15:04 Piotrs-iPhone EddyBckgrnd[32131] <Warning>: UIApplicationLaunchOptionsBluetoothCentralsKey = (
            myCentralManagerIdentifier
        )
Dec  9 09:15:04 Piotrs-iPhone EddyBckgrnd[32131] <Warning>: centralManager willRestoreState: ["kCBRestoredScanOptions": {
            kCBScanOptionAllowDuplicates = 1;
        }, "kCBRestoredScanServices": (
            FEAA
        )]
Dec  9 09:15:04 Piotrs-iPhone EddyBckgrnd[32131] <Warning>: centralManagerDidUpdateState: 5
Dec  9 09:15:04 Piotrs-iPhone EddyBckgrnd[32131] <Error>: [CoreBluetooth] WARNING: <CBCentralManager: 0x14ed52ce0> is disabling duplicate filtering, but is using the default queue (main thread) for delegate events
Dec  9 09:15:04 Piotrs-iPhone EddyBckgrnd[32131] <Warning>: discovered Eddystone UID: edd1ebeac04e5defa017d121ef2c6590

from eddystone.

Piotr is basically got it right — you can totally get your app to wake up by doing the things he outlined.

Interesting note: It was definitely true in some older versions of iOS that your app will not be woken up for simple Bluetooth scans if the user explicitly kills it, but we've actually seen this has changed in more recent versions. Whether it's low-memory or explicit user action, our app will get woken up to be told about nearby beacons, which is great.

from eddystone.

@heypiotr — If you want to submit a pull request, we'd love to integrate your fix in the Swift version of the EddystoneScannerSample ^_~ I'll get to the ObjC version later …

from eddystone.

Thanks for your comments,
I also noted some beacons not supported when the app is not running state.
Eddystone support in the Estimote iOS and Android SDKs is based on a single method at this time: Eddystone discovery, which is similar to iBeacon’s ranging(in active state only). It provides proximity estimates and works only when the app is active.

from eddystone.

@marcwan, interesting! I just tested explicitly killing the app on my iOS 9.1 and iPhone 6 Plus, and it wasn't relaunched. Do you mind sharing what setup you've been able to make this work on? (iOS version, iOS device)

As for the pull request—I'm just lazy 😴 and was kind of hoping somebody else might be willing to do it (: But in any case, I'll see if I can pull it off in some spare time!

@anoopmg, yup, we haven't yet added support for relaunching the app upon Eddystone discovery in our Estimote iOS SDK. Please feel free to open an issue on the respective Estimote SDK GitHub repo.

from eddystone.

@heypiotr Hrmm … I tested this a few weeks ago, but it was a 6 with 9.0.something. There's definitely a lag — it took my phone a few minutes before the app was restarted and the device detected, but it defs was …

I'll investigate a bit more. I've been a bit worried they've added hardware filters to the bluetooth support on newer devices, which will change our strategy a bit vis-a-vis iBeacon regions, etc.

(And we'll see who gets around to merging in the restart code first hah!)

Thanks!

from eddystone.

What after device reboot? Will the IOS application detect Eddystones without relaunching the app?

from eddystone.

@parthrparekh93 — If you have background bluetooth-central turned on, implement CBCentralManagerDelegate's centralManager:willRestoreState: AND also implement UIApplicationDelegate's application:willFinishLaunchingWithOptions: and look for the UIApplicationLaunchOptionsBluetoothCentralsKey key, yes, you can have your application woken up in the background when beacons are detected!

from eddystone.

@marcwan Do you have any example of that? Thank you

from eddystone.

Any update on this issue?

from eddystone.