search

termux / termux-api

Termux add-on app which exposes device functionality as API to command line programs.
https://f-droid.org/en/packages/com.termux.api/
2.35k stars 460 forks source link

Add bluetooth scanning #686

Open Munchax10 opened 5 months ago

Munchax10 commented 5 months ago

Feel free to review and make changes!

termux-api-package pull request: https://github.com/termux/termux-api-package/pull/187

Munchax10 commented 4 months ago

I think this is not quite the right API to expose. IIUC what you've got is:

  • start - begin collecting discovered devices in the background
  • info - return a time-ordered but untimestamped list of every device-sighting since start (ed: corrected this after the initial comment)
  • stop - stop collecting devices and return that list one last time

Two things feel wrong about this to me: 1) This sorta kinda resembles how bluetooth discovery UIs work, but you're building a programmatic interface. You don't need to keep history inside this API because it's going to be consumed by code, not by human eyes that might look away for a second and miss something. 2) You don't have any last-seen tracking, which means that if I wait to scan for more than a handful of seconds, I have no way to distinguish between devices I just saw and devices I saw once, right after start, and never again.

I spent a day chewing on this and imo this should be:

  • start - as above
  • dump or poll - return devices seen since the last dump or poll (info isn't a good verb whether you change the semantics or not)
  • stop - just stop scanning, no devices returned

What do you think?

This was my initial thought process, but i realized that force quitting the process would not stop discovery. I do not have time atm, but i would be happy if someone made it automatically discover and keep the process running (so that info would be removed, so would the list).

tstein commented 4 months ago

I don't follow. My suggestion was purely about the ergonomics and usefulness of the API; the fact that discovery would continue if you force-stopped the main termux process (I think that's what you meant) seems the same either way.

Munchax10 commented 4 months ago

If the api was written in java, this would not be the case. Currently its getting through 2 languages, so its pretty hard to manage. If the api used jni, you could share types and objects (but it would be harder for a normal user to implement). If we want to include more features, we would probably need an api rework.

tstein commented 4 months ago

Right, but that's not an option. I'm saying that I think you can and should make those changes within the constraints of a normal termux-api API, to produce a more useful and more comfortable shell interface.