@ryanbis Do you think you could give me access to a onCharacteristicWritten callback(without any thread switching) for the device? This way I'd be able to have the writeCharacteristic/onCharacteristicWritten on a tight loop for OTA. Perhaps you could have a BluetoothGattCallback proxy object which is setable on the device for people which would like to use the native stack callbacks for certain things? On another note, do you increase the priority of the thread/looper which the OtaTransaction runs on?

We are using sweetblue v2 with xamarin. I needed to basically create a java wrapper interface around the bledevice methods which required callbacks/listeners. The bindings compilation had issues with the generic type java features being used with the listeners, so I just call to my java wrapper object from c# which has simple listeners and the binding generation has no issues with. I've attached our wrapper's source code for you to use, it filters the scans without needing to call back into c# too which was a huge performance improvement.sweetbluewrapper

What you did works, however, I would suggest using -dontwarn com.idevicesinc.**

@CTirendi has this been published on the maven servers yet?

We're looking at around 2 weeks or so before we put out the official release.

Yes, those trigger. We added those when we noticed that the times we set in taskTimeoutRequestFilter or DefaultTaskTimeoutRequestFilter weren't triggering.

1 & 2. That's great! Looking forward to future updates on this topic

You can put it in a library if you want, you would just have to get a license for each app that it goes into. If you're looking to have many apps using SweetBlue, an Enterprise license may be more what you're looking for. If that's the case, email us at sweetblue@idevicesinc.com, and we can discuss your situation.

Well, it's mostly the connecting itself which is the issue... The scanning/finding is pretty consistent now...

@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

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.