On Android, the BLE stack didn’t really work in 4.3 and has been getting progressively better since, but runs into all kinds of bugs depending on the platform (this StackOverflow post documents some of those problems very well). There are a lot of reasons, and some history, for why this is the case – but to me that doesn’t matter. As an app developer, all I know is that it’s only semi-stable depending on the manufacturer, OS, time of day, wind conditions, etc…
CoreBluetooth is much more stable in terms of BLE (except on a specific version of iOS which was horribly broken – I think it was iOS 8.1ish territory). However, it’s a little bit low-level and not very well abstracted away (I would say similar about Android BLE to some extent too). Also, iOS in general adds some limitations on how much BLE stack access there is (hard to modify connection intervals and such).
How’s Your API?
Anyways, all of these things got me looking around for libraries that I can put on top of those low-level libraries to make my life easier. For me, I’m all about the API. I’ve noticed that when you start looking at and developing APIs, you’ll find that there are some patterns you like, some you don’t; and that some people make APIs as simple as possible to start using, whereas some people like swiss-army knives – at the ‘expense’ of more code to get started on.
A good example of this is LGBluetooth vs BluetoothKit for iOS. LGBluetooth wants to make things simple, streamlined, and idiot-proof – but BluetoothKit wants a lot of functionality at the expense of somewhat ‘more challenging’ to setup and understand.
Me, personally, I love simplicity with the option to make extensible (extensibility – which, 90% of the time, I don’t use). For example, one of my proudest APIs is this one to control a camera:
Basically 10 lines of code, which controls a cross-platform, custom UVC camera. I have the hooks so that you can independently handle memory management, images, drivers, add custom algorithms, etc… However, to get up and running for 90% of the time, it’s 10ish lines.
That’s just my philosophy. As a developer, even if you make really good stuff, but hard to use, people probably won’t use it.
In my opinion, no one does the API game better than Square.
Back to BLE
So, extending that to the Android BLE API – it’s a nightmare. I have to set up a bunch of code, broadcast receivers, callbacks, etc… Ugh. Horrible.
What’s 90% of all BLE communication? Scanning for devices, getting advertisements, writing to a peripheral, reading from a peripheral… That’s it, so why does anyone really need more than those 4-5 API calls + 1-2 for initialization and maybe tear-down?
It’s a rhetorical question, but that’s what I think about how APIs work. If you want, add in hooks to do deeper levels of control over your library, but encourage people to use your ‘helper’ functions which encapsulate all the underlying cruft.
Lambda, Lambda, Lambda
People… Use lambda functions… “new Callback() {…}” is a lot of weak sauce.
The value of lambdas in BLE communication surrounds the fact that I usually need a callback directly after a successful read/write – so why should I dig through other parts of my code to see what the callback was doing, when it could be right in front of me in the form of “() -> “.
RetroLambda makes this happen.
Callback Hell
This one is prolific in Javascript code, but present in iOS and Android too.
BLE is inherently sequential, meaning that you can generally only do one call at a time (otherwise, you might squash a previous call if it wasn’t finished). If you want to chain calls, you need to nest them in callbacks. Problem is, when you want to read a BLE device’s standard information, that’s 5-6 nested calls. You can read the full post here: http://www.sureshjoshi.com/mobile/bluetooth-bluetooths-blueteeth/
yugo am.
40
replies
On Android, the BLE stack didn’t really work in 4.3 and has been getting progressively better since, but runs into all kinds of bugs depending on the platform (this StackOverflow post documents some of those problems very well). There are a lot of reasons, and some history, for why this is the case – but to me that doesn’t matter. As an app developer, all I know is that it’s only semi-stable depending on the manufacturer, OS, time of day, wind conditions, etc…
CoreBluetooth is much more stable in terms of BLE (except on a specific version of iOS which was horribly broken – I think it was iOS 8.1ish territory). However, it’s a little bit low-level and not very well abstracted away (I would say similar about Android BLE to some extent too). Also, iOS in general adds some limitations on how much BLE stack access there is (hard to modify connection intervals and such). How’s Your API?
Anyways, all of these things got me looking around for libraries that I can put on top of those low-level libraries to make my life easier. For me, I’m all about the API. I’ve noticed that when you start looking at and developing APIs, you’ll find that there are some patterns you like, some you don’t; and that some people make APIs as simple as possible to start using, whereas some people like swiss-army knives – at the ‘expense’ of more code to get started on.
A good example of this is LGBluetooth vs BluetoothKit for iOS. LGBluetooth wants to make things simple, streamlined, and idiot-proof – but BluetoothKit wants a lot of functionality at the expense of somewhat ‘more challenging’ to setup and understand.
Me, personally, I love simplicity with the option to make extensible (extensibility – which, 90% of the time, I don’t use). For example, one of my proudest APIs is this one to control a camera:
Basically 10 lines of code, which controls a cross-platform, custom UVC camera. I have the hooks so that you can independently handle memory management, images, drivers, add custom algorithms, etc… However, to get up and running for 90% of the time, it’s 10ish lines.
That’s just my philosophy. As a developer, even if you make really good stuff, but hard to use, people probably won’t use it.
In my opinion, no one does the API game better than Square. Back to BLE
So, extending that to the Android BLE API – it’s a nightmare. I have to set up a bunch of code, broadcast receivers, callbacks, etc… Ugh. Horrible.
What’s 90% of all BLE communication? Scanning for devices, getting advertisements, writing to a peripheral, reading from a peripheral… That’s it, so why does anyone really need more than those 4-5 API calls + 1-2 for initialization and maybe tear-down?
It’s a rhetorical question, but that’s what I think about how APIs work. If you want, add in hooks to do deeper levels of control over your library, but encourage people to use your ‘helper’ functions which encapsulate all the underlying cruft. Lambda, Lambda, Lambda
People… Use lambda functions… “new Callback() {…}” is a lot of weak sauce.
The value of lambdas in BLE communication surrounds the fact that I usually need a callback directly after a successful read/write – so why should I dig through other parts of my code to see what the callback was doing, when it could be right in front of me in the form of “() -> “.
RetroLambda makes this happen. Callback Hell
This one is prolific in Javascript code, but present in iOS and Android too.
BLE is inherently sequential, meaning that you can generally only do one call at a time (otherwise, you might squash a previous call if it wasn’t finished). If you want to chain calls, you need to nest them in callbacks. Problem is, when you want to read a BLE device’s standard information, that’s 5-6 nested calls. You can read the full post here: http://www.sureshjoshi.com/mobile/bluetooth-bluetooths-blueteeth/