Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Common API for communication back to phone apps #112

Open
Tracked by #124
jakkra opened this issue Nov 16, 2023 · 7 comments
Open
Tracked by #124

Common API for communication back to phone apps #112

jakkra opened this issue Nov 16, 2023 · 7 comments
Labels
BLE Bluetooth related

Comments

@jakkra
Copy link
Owner

jakkra commented Nov 16, 2023

This can remove #ifdefs in all application code that sends information back to a phone.

Suggested to create a header file with necessary functions such as "next track" etc.

Then we have two implemementations for it, one for Gadgetbridge and one for iOS.
We choose which one to compile depending on if the compile for Android or iOS

@Kampi Kampi added the BLE Bluetooth related label Nov 17, 2023
@ldab
Copy link
Collaborator

ldab commented Nov 18, 2023

I think the FW should be build for both phones and from the connection it can know what type of command to use, no ifdefs, no different headers

@jakkra
Copy link
Owner Author

jakkra commented Nov 18, 2023

I think the FW should be build for both phones and from the connection it can know what type of command to use, no ifdefs, no different headers

Yes true, can be dynamic, it's easily detectable as we know directly if the phone have the apple services, it's an iPhone.

@ldab
Copy link
Collaborator

ldab commented Nov 18, 2023

I was thinking we can use the company identifier to determine the device.

alternatively hook the play/pause etc action to a Zbus fire and forget, down the line the GATT client will not be able to write if the service is not available, sanitising it that way, very simple, I do not see the downside of doing it that way

@Kampi
Copy link
Collaborator

Kampi commented Nov 18, 2023

Maybe we can add both variants? Build up Android and iOS separately, enable both by default, and let the user decide to disable one of those to save code space. IMHO for me iOS isn´t relevant and I don´t need it, because I´m using Android. What do you think about the idea?

@jakkra
Copy link
Owner Author

jakkra commented Nov 18, 2023

I don't care which way, the only reason I see to have it a compile thing is that it will not work with upstream Zephyr and need NCS, and that is handy as sometimes when needed to try some patch etc. only available upstream.
But should not make it much more complicated to keep them compile options but allow both, just need to think a bit how to structure it.

@ldab
Copy link
Collaborator

ldab commented Nov 18, 2023

I haven’t tried but theoretically one can set the zephyr downstream version if needed on the west.yml

@jakkra
Copy link
Owner Author

jakkra commented Nov 18, 2023

You can, but often it won't compile as the ncs stuff is not compatilbe with newer zephyr

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BLE Bluetooth related
Projects
None yet
Development

No branches or pull requests

3 participants