10

Title sums it up. Same question is here. Posting on SO to see if I can get any help. I also made an almost minimal project to demonstrate the problem I'm facing, so links that follow point to the piece of code being mentioned.

Nothing fancy on what I'm currently doing:

  1. My watchface is notified that the bluetooth connection with the phone is up, using .pebble_app_connection_handler.
  2. In that bluetooth callback I set up, I send a message to the phone using app_message_outbox_send(). When BT connection is up, of course.
  3. My Android app has a BroadcastReceiver that listens to these messages and calls an IntentService.
  4. This IntentService calculates the data, pushes it to the watch and sets itself to run again after some time.

What I expect:

  1. When the BT connection is up, the connection handler to be called.
  2. app_message_outbox_send() return a value telling if the message initiation had any errors. Normally, this is APP_MSG_OK, but it can be APP_MSG_BUSY, and I'm perfectly aware of that.
  3. The app message callbacks (app_message_register_inbox_received and friends) be called to indicate if the asynchronous process of sending message to phone really worked. This is stated in the docs.

What I'm seeing:

The expected steps happen when the watchface is loaded, because I trigger the update manually. However, when the update is triggered by a BT connection event, expected steps 1 and 2 happen, but not the step 3.

This is particularly aggravating when I get APP_MSG_OK in step 2, because I should reasonably expect that everything on the watch went OK, and I should prepare myself to receive something inside the app message callbacks. Basically, I'm told by the docs to wait for a call that never arrives.

This happens 100% of the time.

Thank you for any help. I have another solution that works, using the watch to keep track of the update interval, but I believe this one allows me to save more battery by making use of recent Android features.

davidcesarino
  • 16,160
  • 16
  • 68
  • 109
  • If you come here after all these years wondering why this question isn't marked as answered, it is because I do not consider it answered satisfactorily. I believe it was a bug. For details, see the comments below the bounty[-automatically]-awarded answer below. – davidcesarino Jun 26 '23 at 23:37

1 Answers1

3

From documentation :

To also be notified of connection events relating to any PebbleKit companion apps associated with this watchapp, also assign a handler to the pebblekit_connection_handler field. This will be called when the status of the connection to the PebbleKit app changes.

Maybe it is what you need

Gregoire
  • 117
  • 4
  • “allows you to determine whether the watch is connected to the _Pebble mobile app_ by subscribing to the `pebble_app_connection_handler` […] also allows you to determine if the Pebble watch can establish a connection to a _PebbleKit companion app_ by subscribing to the `pebblekit_connection_handler` […] this will return _true for Android_ anytime a connection with the _Pebble mobile app_ is established (since PebbleKit messages are routed through the Android app)” Source: https://developer.pebble.com/docs/c/Foundation/Event_Service/ConnectionService/ – davidcesarino Feb 25 '16 at 19:17
  • Besides, just noticed that `connection_service_peek_pebblekit_connection` returns `true` even when bluetooth is off or I leave the watch disconnected in the Pebble app. Only `connection_service_peek_pebble_app_connection` seems to have any effect. – davidcesarino Feb 25 '16 at 20:08