#1401 Proposal for introducing an API layer

Open
opened 1 year ago by ffranchina · 2 comments
ffranchina commented 1 year ago (Migrated from github.com)

Hello everyone!

First of all, let me thank you for the effort you make to keep this app updated and working :)

It’s since a while that I’m an happy user of this app and since then I read good part of the wiki and the issues that are opened. It’s clear that more research on reverse engineering should be done but it’s also striking that keeping updated an app full of features like this one requires a lot of energy that sometimes is difficult to deliver.

I have a proposal that came to my mind mostly reading issues here and there (like #744, #1378, #1338, #1299, #924, ...) and that could solve many of the various and specific needs in an easy way. The proposal is actually pretty simple: provide along with the app a layer of “APIs” that could allow the user to exploit fully the potential of the hardware using some 3rd-party software (IFTTT-like). It would completely unleash the power of the devices and will free the developers from writing code for some specific needs. Maintaining an API would also require significantly less time and would unlock new possibilities. This API should expose a standard (across all the devices) set of simple instructions (states of the buttons, get/set alarms, the history of activity, send a request (Accept/Reject) on the watch, ...).

By API I mean “something” (I’m not updated about android world anymore) that could catch or throw some broadcast messages or something equivalent. In this way would be even possible to generate events on the phone that could trigger the watch and would be possible to make them interact more with each other. Example: From a signal generated by my home assistant, I could pass a message (thanks to the API) to GB and it could pass it to the watch asking me for a confirmation (through the API) according to which some choices can be made (like setting an alarm, or send another signal to the home assistant, ...).

In this way GB would act as a sort of gateway for the device and could allow it to become a real smart device.

What do you think about this proposal? Please let me know your idea about it in any case (positive or negative)!

Cheers! :D

Hello everyone! First of all, let me thank you for the effort you make to keep this app updated and working :) It's since a while that I'm an happy user of this app and since then I read good part of the wiki and the issues that are opened. It's clear that more research on reverse engineering should be done but it's also striking that keeping updated an app full of features like this one requires a lot of energy that sometimes is difficult to deliver. I have a proposal that came to my mind mostly reading issues here and there (like #744, #1378, #1338, #1299, #924, ...) and that could solve many of the various and specific needs in an easy way. The proposal is actually pretty simple: provide along with the app a layer of "APIs" that could allow the user to exploit fully the potential of the hardware using some 3rd-party software (IFTTT-like). It would completely unleash the power of the devices and will free the developers from writing code for some specific needs. Maintaining an API would also require significantly less time and would unlock new possibilities. This API should expose a standard (across all the devices) set of simple instructions (states of the buttons, get/set alarms, the history of activity, send a request (Accept/Reject) on the watch, ...). By API I mean "something" (I'm not updated about android world anymore) that could catch or throw some broadcast messages or something equivalent. In this way would be even possible to generate events on the phone that could trigger the watch and would be possible to make them interact more with each other. Example: From a signal generated by my home assistant, I could pass a message (thanks to the API) to GB and it could pass it to the watch asking me for a confirmation (through the API) according to which some choices can be made (like setting an alarm, or send another signal to the home assistant, ...). In this way GB would act as a sort of gateway for the device and could allow it to become a real smart device. What do you think about this proposal? Please let me know your idea about it in any case (positive or negative)! Cheers! :D
cpfeiffer commented 1 year ago
Owner

Yes, very good idea!

Yes, very good idea!
iicurtis commented 1 year ago (Migrated from github.com)
Owner

This is a great idea. I think this would also solve #248, #49. I think that this is possible from an Intent point of view. To copy what I said in #553:

I’m thinking something more like how PasswordStore integrates with OpenKeychain. We could possibly create an OpenIntents method for this similar to what was used in OpenKeychain. I haven’t looked into the Gadgetbridge side yet, so I’m not sure what fields we want to transfer and how it should be serialized.

In short, OpenKeychain and a few other F-droid apps already have this great idea with OpenIntents that provide a nice API for other apps to reach out and request data. I would really love to see this happen with Gadgetbridge. It really opens the door for some crazy cool integrations and functionality. People who want their great idea to work but don’t meet the requirements for Gadgetbridge could implement and bugtrack their own app.

This is a great idea. I think this would also solve #248, #49. I think that this is possible from an Intent point of view. To copy what I said in #553: > I'm thinking something more like how [PasswordStore integrates with OpenKeychain](https://github.com/zeapo/Android-Password-Store/blob/86696c668c08c8e283e840b6c54e40fa043c542a/app/src/main/java/com/zeapo/pwdstore/crypto/PgpActivity.kt). We could possibly create an OpenIntents method for this similar to [what was used in OpenKeychain](https://github.com/open-keychain/openpgp-api/blob/master/openpgp-api/src/main/java/org/openintents/openpgp/util/OpenPgpApi.java). I haven't looked into the Gadgetbridge side yet, so I'm not sure what fields we want to transfer and how it should be serialized. In short, OpenKeychain and a few other F-droid apps already have this great idea with OpenIntents that provide a nice API for other apps to reach out and request data. I would really love to see this happen with Gadgetbridge. It really opens the door for some crazy cool integrations and functionality. People who want their great idea to work but don't meet the requirements for Gadgetbridge could implement and bugtrack their own app.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.