steamclock / bluejay Goto Github PK

Scan for item (user initiated button), do connect. If the user rescans the item (after successful / unsuccessful scan user hits button again), it will cause a crash.

This can be resolved with bluejay.disconnect, but they are then needed in every scenario - .success, .failure, .expired, error

Currently Bluejay is all one file - we should split it, to the degree it makes sense, by class and/or what is appropriate to get the files to roughly 50-250 lines each.

Updating this issue to capture the newest direction for handling logging:

We've stopped using XCGLogger to avoid dependency conflicts. We've also commented out a lot of logs.

We should add back certain logs in the most crucial areas, as well as add a convenience method to log in a more uniformed format.

Due to how much we're logging, this should be turned off for the time being in favour of allowing scanning with duplicates without blocking the main thread until we get a chance to revisit how to improve logging.

Right now it crashes if the project using Bluejay does not have the "Uses Bluetooth LE accessories" background capability turned on.

We should pick a popular/simple/helpful tool for generating simple API documentation out of our swift code with annotation from our comments.

Bluejay and queue instances should not be singletons.

Using Bluejay discovery example with blacklist, for bluejay.scan "(discoveries, error) in" is fired off even when successful discovery and connection is made milliseconds after. It always seems to fire.

Not show stopper since it can just be ignored.

We should have a logo for Bluejay. Typically we'd bring in a specialist for logo work, but @rachteo here at Steamclock is keen to do some initial experimentation, which is a great way to start. We may come up with something great, or worst case we'd have a starting point for a logo and illustration expert to refine.

Two potential starting points for a logo would be the Bluetooth logo, with its stylized B that if you squint hard enough could evoke a bird:

and obviously the image of a blue jay. Obviously we need to be distinctive and clearly different from the various trademarked blue jay logos out there, but they can serve as some inspiration.

Ideally the logo will look professionally executed but have an element of warmth and personality. One open source logo that I like for this aspect that also happens to depict a bird is the Bower logo:

Using Bluejay SyncPeripheral call writeAndListen, which internally uses Bluejay Peripheral call cache(listeningCharacteristic: CharacteristicIdentifier)

crashes here :

UserDefaults.standard.set([bluejay.uuid.uuidString : newListenCache], forKey: Constant.listenCaches)

writing (example) :

[EAD75440-FEFC-4BCC-81CC-0328EABE2714 : [(serviceUUID: "036C0020-98BA-F401-F139-B510D0C303AD", characteristicUUID: "036C0022-98BA-F401-F139-B510D0C303AD")]

forKey

com.steamclock.bluejay.listenCaches

Consistent crash is Attempt to insert non-property list object

'Attempt to insert non-property list object {
    "EAD75440-FEFC-4BCC-81CC-0328EABE2714" =     (
        "(serviceUUID: \"036C0020-98BA-F401-F139-B510D0C303AD\", characteristicUUID: \"036C0022-98BA-F401-F139-B510D0C303AD\")"
    );
} for key com.steamclock.bluejay.listenCaches'

writeAndListen call :

writeAndListen(
                    writeTo:    OrthopulseBLEConst.SetUp.currentTime,
                    value:      UInt64(28),
                    listenTo:   OrthopulseBLEConst.Log.logEntry,
                    timeoutInSeconds : 20,
                    completion: {...}
   )

OrthopulseBLEConst.SetUp.currentTime is 
currentTime = CharacteristicIdentifier(uuid: "036C0015-98BA-F401-F139-B510D0C303AD", service: OrthopulseBLEConst.setUp)

logEntry is 
logEntry = CharacteristicIdentifier(uuid: "036C0022-98BA-F401-F139-B510D0C303AD", service: OrthopulseBLEConst.log)

Calling any functions requiring CBCentralManager to take an action immediately after app startup will result in a system failure that says Bluetooth is not powered on yet.

Currently these are being handled by preconditions. I think we still want to disallow multiple scan and connect requests, but there should be a way to return the extra calls with an error that can be handled.

Totally forgot there's this useful piece of documentation to help with naming functions and making the API better and more Swifty.

https://swift.org/documentation/api-design-guidelines/

We've incubated Bluejay as part of another project, but it's time to give it its own space here.

Many error messages can be either simplified or expanded upon to include more details when necessary.

This will save time later when testing and debugging.

SyncPeripheral sounds like the Peripheral is synced, and the assumption would be it is asynchronous, the exact opposite of what it does.

Once we've done the autodoc pass in #5, we should take and incorporate API feedback from the team, and then some community members.

Should probably make the error object and/or messages available for reading by the operation caller.

Right now in the middle of reorganizing our source code, there are times when it is not immediately clear what level of access certain code should have.

This is just an issue serving as a reminder to do a sanity check on our library's access control, and making sure we only expose what is critical.

Mainly just want to avoid giving developers too much access, especially to certain instance or static variables. Most accessible variables should probably be read only anyway, and I think a good API shouldn't require writing too much, or any, assignments.

While fully unit testing Bluejay will need to wait until we have mocking in #8, we should at least build some way to do automated smoke testing and sanity checking. @nbrooke proposed a way of doing testing against an app running on a second iPhone, which would probably be a good start and be simpler than needing to run against specific Bluetooth hardware and firmware.

With Bluejay being potentially our first major Swift open source library, we should keep the style of our code consistent by following this fairly sensible style guide: https://github.com/raywenderlich/swift-style-guide

This issue serves as a reminder to do at least one pass of review and updating of our code to make sure it follows the style as closely as reasonable.

Allow developers to restore listening callbacks on resuming the app.

Bluejay async call needs a better name

The description in Bluejay is great, but the name doesn't reflect what it does -
"Run a background task using a syncrounous interface to the Bluetooth device."
(ps. spelling error - synchronous)

If the reason was "DispatchQueue.main.async", that works because it is dispatching a QUEUE asynchronously. The queue keyword provides the hint of how the call will work.

runTask (previous name ?) was better IMO.

Bluejay.runTasksAsync ?
Bluejay.queueAsync ?

Create a demo project that can show example usage of the Bluejay API.

The import module already provides sufficient namespace handling, and we've agreed that the Bluejay prefix is pretty much redundant and not as "Swifty".

If a characteristic is simply of a common type such as an integer, float, or string, and if there's no need for other handling, we shouldn't require developers to create structs for those.

Find out what are minimum steps to use the current version of Bluejay effectively, and get an overall sense of its strengths and weaknesses, so that we can better improve its API.

Jazzy considers 43% of Bluejay to be documented. Some fairly large classes are "Undocumented" - let's pass through and give at least a sentence for each one.

https://steamclock.github.io/bluejay/

CoreBluetooth does not time out stale connection attempts.

As a continuation of #39, we should allow Bluejay instances to be deallocated gracefully, all pending queuables cancelled, and look out for memory leaks.

There are a few TODO's in the library.

We should review and take care as many of them as possible.

Similar to #11, but for discovering a characteristic.

Should probably make the error object and/or messages available for reading by the operation caller.

Typically when you hit the Jazzy docs of a library, it defaults to the readme (for example http://rnine.github.io/AMCoreAudio/). It's great that we have docs now, but we should figure out how to configure them so the main page is the readme and not a blank page like we have now.

• SwiftyUserDefaults
• XCGLogger

There's a bunch of common services such as, the heart rate service, or characteristics like the serial number, that can be encapsulated in the Bluejay library, so that developers do not need to look up the Bluetooth specs for their UUID.

Should probably also rename the current scan function, as it connects on a successful scan.

Probably don't need the helper class at all, and the join function should belong elsewhere, as well as being renamed to combine or append instead.

README hasn't been updated, but we've made some significant changes towards 0.1. Time to do a full-pass of the README and update as necessary.

From WWDC lab, it seems like setting allowDuplicates to true and service identifiers to nil won't work when the app is background.

If that is true, Bluejay may need to explicitly call the stopped block and provide clear error messages explaining the situation.

For Biolux, and this is also a more user-friendly approach in most cases.

For example, we could get three Phillips Hue bulbs and do a video screencast of writing a test app to have them rotate colors or something fun lik ethat.

When the library is ready, !

Before we make Bluejay public, we should fill out a clear and concise Readme about what it's for and how to use it.

"disconected" should be spelt disconnected. In the Bluejay swift class

This is surprisingly complicated and gnarly to do, but would be a valuable thing both for maintaining Bluejay and our various Bluetooth apps. Ideally we could simulate specific cases such as backgrounding, communication failures, and so on. These are challenging to mock and simulate because they depend on measuring and reproducing what iOS is doing in various edge cases.

In addition to being helpful for automated testing, mocking would allow folks to do basic testing in the simulator, which would be quite helpful.