idevicesinc/sweetblue

BLE on Android, the easy way. THIS IS NOW DEPRECATED. Please visit website for info on new versions.

sweetblue's Issues

Some kind of phone-home analytics. (?)

Obviously opt-in...for UhOhs, asserts, maybe logging, etc., send a json packet to our server, perhaps then forwarded to flurry or whatever...direct flurry integration would be an annoying dependency but maybe there's some lightweight way to do it...hit their REST API directly or something.

Tighter integration of crash resolver.

Keep track of history for connection fail events.

Can be passed as an additional array field in the connection fail info struct.

Add GATT server support.

Including latest API-level 21 features.

Proper build system.

Should take pull requests, do some static analysis, code linting, etc., run against unit tests. Also have that fancy build:passing image (travis ci?) at the top of our README.

Pretty big task so it may get broken up more in the future.

Configurable pauses before/after tasks.

Have option for explicit disconnect to actually force disconnect.

This means that user can invoke a disconnect and then try to connect right after that. For now, if it's done fast enough, the disconnect task is cancelled out by the subsequent connect task and natively speaking the device never actually disconnects.

Write a high-level manual, especially for those previously using native API.

Finer-grained configuration for retention/undiscovery of explicitly created devices (?)

Timeout for bonding (?)

Don't remember bonding requests ever spinning indefinitely...default is 10 second timeout for now though, so maybe make this configurable.

Try to use fetchUuidsWithSdp() to get services when using classic discovery.

Might have some other uses too...not sure.

Wifi state management.

Anecdotal evidence suggests that BLE can work better with WiFi disabled. If it's the case, and managing WiFi state is more than a simple method or two, then we can add explicit methods to the API so that user can disable WiFi before connecting, before OTAs, etc.

In addition, we can have config options (off by default of course) that gate whether WiFi is turned off automatically for such operations.

Integrate BluetoothGatt.refresh()

This supposedly clears the discovered services cache, which is necessary for any devices that can change their services on the fly.

Add time parameters to connection fail listener.

This can help aid the user in making a decision on whether to continue retrying the connection.

End implicit bonding tasks (more) correctly.

This was in the old TODO file...will have to dig into code to see what this actually means.

Make BleDevice, BleManager, etc. Parcelable (?)

Connection fail reason for stack turning off (?)

Probably only possible for explicit turn-offs.

Store implicitly disconnected devices on disk and auto reconnect on discovery.

Obviously gated behind a config option.

Bump priority for scan task in certain situations.

It's theoretically possible that a scan task is indefinitely subject to line-cutting in the task queue. Perhaps have some time limit (configurable) past which (if we're autoscanning or infinitely scanning) the scan task is given the same priority as reads/writes. Also argument to be made that an explicit startScan() call should have a higher priority as well.

Scan record parser as part of BleManagerConfig

Right now this is handled by a static method and hardcoded in library guts.

Attempt to use RSSI for a consistent, 1-100, or perhaps enumerated signal strength indicator.

Have overload txn fail() method that takes a read/write result.

This will let the connection fail callback provide more information as to why a txn failed.

gattStatus field added to state change listener event for device.

Persist devices in BleManager after a nuke or BLE off/on cycle (?)

Might gate this behind a BleManagerConfig option. Currently app logic has to take care of reconnect after an off/on cycle.

Do something about potential queue flooding.

One can potentially flood the queue, putting tasks onto it faster than the queue can process them. Perhaps have enumerations for read/write/connect-fail callbacks indicating such a scenario, like if the queue has more than 100 tasks backed up. Actually maybe just for the read/write callback.

More progress, info, error conditions added to ResetEvent.

Overloads of device.write() for ints, shorts, etc.

Integration of TimeEstimator into firmware update transaction.

Currently user has to hook things up themselves...not a big lift for them but might be nice to have this done for them.

Psuedo-notification for RSSI change.

Add hooks for unit testing.

Need to have the back-end work with dependency injection, and not interface with Android Gatt layer directly. After that library logic will be unit-testable using a simulated gatt layer.

Read/Write callback still called for operations that return after timeout limit (?)

A read or write can fail do to exceeding timeout of 10 seconds or whatever it is. Is it useful for users to be able to set a backstop listener that catches operations that do end up succeeding after this time limit. This case hasn't been observed but is technically possible.

Use the "redundant" task ending state in more places, for bonding, etc.

Finer-grained config option for when autobonding occurs.

Before connecting, after connecting, after discovering services, etc.

Add support for miscellaneous Android API-level 21 features.

Add native equivalent for write without callback if necessary.

Option to save autoConnect preference to disk.

Have bonding fail connection process?

User might want bonding to be a prerequisite to connecting, in which case we should fail connection with the appropriate reason.

Throw exception when calling library from other than main thread (?)

This is what Android does with its View stack. Maybe helpful for us too?

Add Descriptor read/write support (?)

Most of the wiring's in place in the back end...just a question of it being useful to expose this in the public API.

Add actual gatt operation attempt to isBleSupported().

Some devices return true for this method even though BLE doesn't actually work. Perhaps there's a way to perform a fast side-effect-free operation to see if ble truly is supported.

Config option for when to invoke autoConnect.

That is, how many connection fail attempts it takes to say OK, let's use autoConnect.

Try forcing service discovery right after connections on a per-device basis.

That is, don't interleave such tasks across devices. See if this clears up the 129 error on experia when connecting to multiple devices, like at start up.

Finer-grained logging config options, public/private, etc.

This means flushing out and standardizing logs meant for user of library, and then also gating public/private behind two config options, or perhaps a bitwise option for finer-grained control.

Methods for retrieving known devices from disk across app sessions.

Not really sure of the use case or what the API would look like yet, but we are tracking this already so maybe some interface to it would be helpful. For example an app that is meant to work with one device (e.g. fitness tracker) may want to forgo scanning on app start up if the mac address is known...i.e. they create a new device explicitly and just try to connect.

Refactor BleDevice and BleManager into more package private classes.

Both of these classes are around 2000 lines of code...a lot of this is API docs but still a little bloated. Lots of their implementation is already pushed out into sub components, but should see if more can be done here.

Be able to set override config options on a per-device basis.

This will involve splitting out a super class of BleManagerConfig and putting all the device-specific options in there, then having a method on BleDevice called setConfig. This is actually not a breaking change so can be implemented post v1.

Methods to convert raw data on read/write result into more directly useable forms.

data_int(), data_long(), data_string(), etc.

Timeout for ble on/off (?)

Never seen this take very long or spin indefinitely, but maybe should have a configurable limit.

Abstract method in state tracker that notifies of each state bit change.

This will allow state trackers to assert if/where they want to.

Add Android Studio instructions to README.