openble / openble Goto Github PK

We have the ability, and almost no one uses it, to put our CBPeripheral events into a dispatch queue, serial or concurrent, instead of the main queue.

Ive seen VERY few ble examples do it, but this guys 'competing' firmata does and it made me question my implementation
https://github.com/Xadow/XadowApps

Just tried downloading a fresh version. CocoaPods downloads dependancies ok, but during build I get the following warnings/errors:

Ld /Users/mansion/Library/Developer/Xcode/DerivedData/OpenBLE-cvjfcfjsjwwfytcnnqeftqmpajex/Build/Products/Debug-iphonesimulator/OpenBLE.app/OpenBLE normal x86_64
cd "/Users/mansion/Library/Mobile Documents/comappleCloudDocs/xcode projects/OpenBLE/examples/OpenBle"
export IPHONEOS_DEPLOYMENT_TARGET=6.0
export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator8.1.sdk -L/Users/mansion/Library/Developer/Xcode/DerivedData/OpenBLE-cvjfcfjsjwwfytcnnqeftqmpajex/Build/Products/Debug-iphonesimulator -L/Users/jacobrosenthal/Documents/Code/OpenBLE/examples/OpenBle/Pods/build/Debug-iphoneos -F/Users/mansion/Library/Developer/Xcode/DerivedData/OpenBLE-cvjfcfjsjwwfytcnnqeftqmpajex/Build/Products/Debug-iphonesimulator -filelist /Users/mansion/Library/Developer/Xcode/DerivedData/OpenBLE-cvjfcfjsjwwfytcnnqeftqmpajex/Build/Intermediates/OpenBLE.build/Debug-iphonesimulator/OpenBLE.build/Objects-normal/x86_64/OpenBLE.LinkFileList -Xlinker -objc_abi_version -Xlinker 2 -ObjC -lPods-OpenBLE -lPods-TPKeyboardAvoiding -framework CoreBluetooth -fobjc-arc -fobjc-link-runtime -Xlinker -no_implicit_dylibs -mios-simulator-version-min=6.0 -lPods -framework CoreBluetooth -framework CoreGraphics -framework UIKit -framework Foundation -Xlinker -dependency_info -Xlinker /Users/mansion/Library/Developer/Xcode/DerivedData/OpenBLE-cvjfcfjsjwwfytcnnqeftqmpajex/Build/Intermediates/OpenBLE.build/Debug-iphonesimulator/OpenBLE.build/Objects-normal/x86_64/OpenBLE_dependency_info.dat -o /Users/mansion/Library/Developer/Xcode/DerivedData/OpenBLE-cvjfcfjsjwwfytcnnqeftqmpajex/Build/Products/Debug-iphonesimulator/OpenBLE.app/OpenBLE

ld: warning: directory not found for option '-L/Users/jacobrosenthal/Documents/Code/OpenBLE/examples/OpenBle/Pods/build/Debug-iphoneos'
ld: library not found for -lPods-OpenBLE
clang: error: linker command failed with exit code 1 (use -v to see invocation)

LeDataService is a poor class to subclass. I've tried protocol delegate methods out of it and I dont like it. I think LeDataService should be one type of service, and should maybe subclass from a more general service class. At the very least I want to store all the known SPP UUIDs and give services some interface to conform to.

In order to dodge this for the time being, as of 4636310 I'm going to have the discover class deal only in peripherals and not in services.

But I definitely still don't feel like this is the final solution. Input welcome

I want to explore scanning in background and connecting to devices that arent currently in range, and also reconnecting and restarting known services as they go in and out of range.

The chat example might be actually be a decent example to explore backgrounding as the arduino could send you text and we could re open the app and respond...

Look into the saved devices support that came from the original ios ble examples.

We should be able to like.. star a device and try to connect to it even if we dont see it.

Honestly though, we're currently not exploring background connecting in our example so maybe it doesnt fit yet?

Hi there. Looking at line 243 (in 9b7cd25 -> https://github.com/OpenBLE/OpenBLE/blob/master/Classes/LeDataService.m#L243), I see the following:

if([writeWithResponseCBUUIDs containsObject:writeCharacteristic])

Shouldn't that be checking writeCharacteristic.UUID?

I tested this change locally and it seemed to fix my write issues with my BLE Shield (a RedBear v.2012.07). Making that change correctly identified the characteristic as a write without response call.

Also, as a side note, shouldn't writeWithResponseCBUUIDs and related variables be called writeWithoutResponseCBUUIDs? The fact that it's called writeWITH totally confused me while debugging my issue...

Would this be a good pod? How are we better/different than this guy https://github.com/ruiking/ble

methods in LeDiscovery.m are depreciated in iOS9.0

as title, thanks！