How to write toga app with cross-platform access to bluetooth

[BrendanSimon]

Hi, not really an "issue" per se, but I was wondering how to write a cross-platform app with toga (mainly for iOS and Android), to act as a bluetooth BLE client?

Is there a cross-platform library (python I presume) that will work with toga?

Thanks, Brendan.

[freakboy3742]

Toga doesn't currently expose a cross-platform wrapper for Bluetooth services.

That said:

1. The approach we've taken means that accessing native services directly is always an option. If iOS exposes an API, you can invoke that API directly. Obviously, you lose cross-platform capabilities, but if you need a solution right now, it's an option

2. Longer term, writing a cross-platform wrapper layer for system services (like Bluetooth) is something we want to tackle. If this is something that interests you, feel free to do some research and suggest an API design.

For procedural purposes, I'm going to close this ticket; but if you want any more details, feel free to continue the discussion.

[BrendanSimon]

OK. What's the best way to learn how to "invoke the API directly"? Is it through toga source code, or some other related library?

Are there some existing examples or documentation to get started with?

Is Rubicon-ObjC the place to look?

I don't know if this is the best approach, but maybe looking at the PyBluez API would be a good starting point. Bluez works on Linux, macOS, Windows, apparently using D-Bus. That d-bus implementation may not be so relevant but the keeping the high level API might be a good idea for compatibility, provided it has good abstraction.

If there was a beeware cross-platform bluetooth python library for iOS/Android, where would it be maintained? Would it be part of some existing project or a new standalone project?

[freakboy3742]

It varies from platform to platform.

On macOS and iOS, you'll be using Rubicon. Rubicon gives you a Python interface to the official documented macOS/iOS classes; if Apple publishes an XYZController class library, you can wrap that class with Rubicon and use it as if it was a Python class, regardless of whether it's a Bluetooth API or anything else.

The Android story is currently a bit broken (we've got funding to address this), but follows much the same pattern; there's a bridging library that exposes Android Java classes as if they were Python classes.

If a cross platform library were to exist, it would either be part of Toga, or a new standalone project. The determining factor would be the extent to which the library needs to integrate with the lifecycle of an application. If there's extensive lifecycle integration required, the benefits of having this as a standalone library are likely to be minimal, compared to the simplicity of integrating into the main Toga stack.

[WesleyVercoutere]

I'm looking to create an Android app (no need for cross-platform) with Beeware ...

The Android story is currently a bit broken (we've got funding to address this), but follows much the same pattern; there's a bridging library that exposes Android Java classes as if they were Python classes.

How does the bridging thing works? The app needs bluetooth and the vibrate function. Is there some example for this?

[freakboy3742]

@WesleyVercoutere We don't have any examples of using Rubicon to access Bluetooth classes; however, the toga-android codebase has plenty of examples of the use of Rubicon, and the principles are the same. Broadly speaking, the approach is that you build a wrapped representation of any Java class that you want to use, and then you use it as if it were a Python class. The APIs are then whatever Android provides.

[BrendanSimon]

@freakboy3742 is the Bluetooth situation still the same in 2023?

I'm looking to write a fairly simple Toga app for iOS and Android, which will retrieve some basic status information from a Linux device. I'm thinking primarily Bluetooth as the comms technology - WiFi might be another option (though I'm not sure if mobile devices can connect via WiFI without assuming all internet traffic will go through the WiFi interface - i.e. hot spotting).

[BrendanSimon]

I'm wondering if something like BLEAK is suitable or not?
https://github.com/hbldh/bleak

NOTE: BLEAK doesn't have iOS support as yet :(

[mhsmith]

Bleak has support for Android with Kivy, so we tried to adapt that to BeeWare here, but it turned out to be quite complicated.

[BrendanSimon]

I'm primarily an iOS user so that is my initial development target. I don't actually have Android devices or done anything targeting Android, but it is a popular platform and I will need a solution for that at some stage.

I asked the BLEAK guys about plans for iOS. Answer was nothing planned but porting from macOS code shouldn't be difficult. They are concerned about it not being maintained, like Android port is non maintained, and it seems due to the complexity of having to build so much stuff to be able to test things (including building python itself).

hbldh/bleak#1248

My gut feel is that those issues are not relevant for iOS (but I could be overly optimistic?). I'll leave Android to later ;-)

Given the support for iOS in Beeware ecosystem (which I assume doesn't exist with BLEAK?), what would be the best approach to port BLEAK to Beeware/Toga?

• Port/build BLEAK for iOS in the Toga project?
• Try to use the BLEAK development environment to port to iOS? (I'm worried about the testing, simulator side of things)
• other?

[freakboy3742]

I'm not sure why you'd think the issues are different - they seem identical to me: they're concerned that they'll have a bunch of code contributed, without any ongoing commitment to maintain that code.

In terms of ways forward, I can see a couple of options:

1. A hard fork. Not appealing as an option, but it would work.

2. A soft fork. BeeWare maintains a separate repo maintaining the Android and iOS backend, up merging any changes in the core BLEAK repo, and publishes binary wheels for iOS and Android in the pip repositories that support Briefcase. There's some interesting trademark issues in this, but if we're upfront about what we're doing, there's no reason for this to be "hostile"; and in the long term, might even lead to the soft fork being merged into the core project (as we'd be able to establish a long term relationship demonstrating platform support).

3. Work with BLEAK to make their platform support a pluggable feature. I can't speak for the BLEAK team, but this would be my preferred option from a purely architectural perspective. If there's a core BLEAK API, and backends that are independently installable for each platform, it means there's scope for a third party to provide their own backend(s) for Android, iOS, or whatever other odd platform they want to support. It would also mean BeeWare could maintain an iOS backend using Rubicon APIs rather than PyObjC, and an Android port using Chaquopy APIs.

4. Start from scratch. Ignore BLEAK entirely, and start a clean project for Bluetooth support under the BeeWare umbrella. Again, it would work, but it's not the ideal option.

[BrendanSimon]

David at BLEAK stated "you can't just run a script on Android for a quick test, you have to build a full app and compile the entire Python runtime, so it just takes too much time". Based on my brief experience of running a Toga app on the iOS on the simulator I thought these issues were not a problem (at least I can't remember having to build python runtime, etc). If it's easy to test (unit test) then there's less chance of of code becoming stale (assuming there is good coverage).

David also states "it would probably be fairly trivial to port the existing PyObjC for macOS backend to rubicon-objc", so if BLEAK could maintain an iOS port using Rubicon then that would work for Toga too, yes?

@freakboy3742 Is this option 3 above? Would it make sense for BLEAK to have an Android port using Chaquopy, or would that likely be maintained within Toga as it's own port?

[freakboy3742]

Without knowing the internals of BLEAK, I can't say for certain. It could be either (2) or (3), depending on how BLEAK is implemented. From a quick poke at their source tree, they appear to have a "backends" system already; however, it's not immediately clear to me whether those backends need to live in the bleak Python namespace, or they can live externally. I can't spot any obvious mechanism for selecting/specifying a backend at runtime (although I'll also admit I haven't looked that hard). If backends need to be in the bleak namespace and specifically enabled as part of the bleak codebase, it's likely (2); if they can live in an external package that can be selected at runtime, then it's (3).

FWIW, it's also entirely possible they don't know anything about Briefcase, so they may not be aware that options exist for running test suites on Android and iOS that don't involve compiling the entire Python runtime.

[BrendanSimon]

I certainly have mentioned it on the BLEAK discussion ;-)
hbldh/bleak#1248

[mhsmith]

David at BLEAK stated "you can't just run a script on Android for a quick test, you have to build a full app and compile the entire Python runtime, so it just takes too much time". Based on my brief experience of running a Toga app on the iOS on the simulator I thought these issues were not a problem

It's a problem on Kivy, but BeeWare provides pre-built Python binaries for iOS and Android.

Would it make sense for BLEAK to have an Android port using Chaquopy, or would that likely be maintained within Toga as it's own port?

Since we found here that modifying Bleak to use Chaquopy required a lot of changes, I think the best thing to try next would be to implement an emulation layer on top of Chaquopy to support the Kivy API, allowing an unmodified copy of Bleak to be used.

We already did that here for rubicon-java, which was BeeWare's previous Java/Python bridge. However, in this case we'd also need to support some higher-level features like requesting permissions.

This approach may run into some limitations in Chaquopy's subclassing support, but it's better to fix them once and potentially enable other packages with existing Kivy-based Android support, rather than modifying all of those packages one at a time.