@ryanbis Ah, good to know. I will be sure to test this thoroughly. Thanks for the tip!

@Activ84HealthEU, I need a bit more info in order to help you. Does it actually ble connect to the device? (You may have to look at logcat). When the write fails in the transaction, what is the status()? That should at least give you a hint at what's going on. NOTE: When using any transaction, you MUST call either succeed(), or fail(). Otherwise, even if the write went through, it would just stall out and do nothing afterward (and the DeviceConnectListener onEvent will never get called, at least not for being connected).

`Well, the Sweetblue library does already make a big improvement on connection time, and the amount of phones even being able to connect... I'm mostly worried about the phones that sometimes don't connect at all, but so far, I've only seen that on a Sony in my small test team... Too bad the guy doesn't want to test again to see if my latest fixes work for that issue :S

Today was a busy day. When 3.0.3 was initially pushed to our Maven server, it somehow jammed up the works, and thus began 5 hours of work. Finally after slaying the Archiva demon, we were able to successfully get the new version up and ready for the masses. We'll be adding older versions over the next day, so if there's an older version you need, it will be up soon. So onto the changelist! We now have a new kind of API key. This key is meant for licensed customers to be able to deploy debug/alpha/beta versions of their app internally. This key will cause an Exception to be thrown if the app was installed from a public app store (Google, Amazon, Samsung, etc). This key will allow you to use one key for several variations of the app. These new keys will only work on 3.0.3 and up. BleDeviceConfig.tryBondingWhileDisconnected_manageOnDisk has been deprecated, and will be removed in the next minor release (3.2.X, so a while away). Fixed an issue where early outs weren't being emitted to the listener when calling enableNotify/disableNotify. Updated some logic when calling update on BleDevices, which eliminates some ASSERT exceptions that would get posted to Logcat. These messages don't apply anymore since moving to version 3. Fixed NPE that could happen when calling ReadWriteEvent.isNull() in certain scenarios. Bumped gradle plugin version to 3.3.0 Fixed issue where DeviceReconnectFilter wasn't being used, or honored when it is set via BleDevice.setListener_DeviceReconnect() or BleManager.setListener_DeviceReconnect() Added NoReconnectFilter convenience class if you don't want SweetBlue to reconnect at all. Fixed an issue where SweetBlue would unintentionally spam log messages in certain situations when scanning. Fixed a remote issue where SweetBlue should reconnect, but wouldn't. Added check to see if the BleServer has been instantiated before trying to clean it up (this was causing some exceptions to get printed to logcat).

Unfortunately those line numbers are WAY off. If you're using proguard, please add these lines to your proguard file: -keep class com.idevicesinc.sweetblue.** { *; } -keepattributes SourceFile,LineNumberTable,Signature,*Annotation*,EnclosingMethod -dontwarn com.idevicesinc.sweetblue.**

That shouldn't matter (where you set the config). However, if you want it to apply to all devices, I would just set the options in the BleManagerConfig when instantiating the BleManager instance. (BleManagerConfig extends BleDeviceConfig mainly for this purpose). Try doing this, and see if you get any different results.

@ryanbis Awesome! We look forward to the release. Cheers, Gunnar

Happy Holidays to you all! Wish you all the best in this season and into 2019.

Glad to hear! Looking forward to the next release.

Got it, thanks! Will look to alternative solutions like keeping a service in the background. Our goal is to provide push notification capabilities to the custom BLE device.

Excellent, please let me know if you still see the problem.

Great suggestion, thanks!

I'm having the same problems on v3.0.2, where as I connect, turn Bluetooth off and on again, it'll automatically reconnect (at least that's what the sensor says),but a NATIVE_CONNECTION_FAILED is given.

Removing all the calls to unbond() from our side does not mitigate the automatic reconnection.

The sample projects should be published here: https://forum.sweetblue.io/category/6/sample-apps Hope they upload some soon.

Gotcha, sounds great!

I've updated the logic for enabling/disabling notifications. Now if you pass in a notification listener in a BleNotify instance, it will set that listener as the default only if there are no other NotificationListeners set for the device. This will be in the next version.

Bjoern, How are you setting your reconnect filter?