Transmit in BackgroundService only happens in every other cases

Hi!

I've a really weird behavior with Communicating with a companion app in BackgroundService on a watchface.
This is my BackgroundService: https://pastebin.com/BZRfzcUv
and this is what is logged: https://pastebin.com/g9k6QjN8

As you can see only every other run of the backgrounddelegate the onTemporalEvent is called, and when it does, the answer is not recevied in the 30sec timeframe, only the second run of the backgrounddelegate gets the data that was sent from the companion, and in this second run the onTemporalEvent is not called and this pattern repeats.

Any idea what's going on?

Simulator: Vivoactive 3
SDK: 2.3.5
Android SDK: 1.4

jim_m_58 over 8 years ago

Looks to be you are doing this in the sim and based on the time stamp, and that you are manually triggering the temporal event there about every minute. What happens if you just let the temporal event run on it's own?

DEXTER over 8 years ago

The exact same thing happens if I just wait for it to happen on its own.

Former Member over 8 years ago

I can explain one of your issues, but am not sure on the other.

onTemporalEvent is getting called each time.

When you register for messages with this line:
Comm.registerForPhoneAppMessages(method(:on_received));
If there are messages already in your message queue, your callback will get triggered for each message that is available prior to your registration returning.

This means that your data is received and Background.exit() is called before you reach the lines of code that print your debug messages and send the ping to your partner application.

I do not know why you are not receiving callbacks on your listener when it is registered at the point they are received. That is something we may need to investigate. It seems the message is getting sent (it is there the next time you trigger), but the callback is not being triggered.

DEXTER over 8 years ago

Ohh.. I see. Now on that line then I've just placed theComm.registerForPhoneAppMessages(method(:on_received));
after

Comm.transmit(MyComms.MESSAGE_TYPE_GET_DATA, null, new GetDataListener());
          System.println("BackgroundServiceDelegate::onTemporalEvent - after transmit");

and now it seems it works every time. I really don't know why that is, but I still consider this as as bug, because it seems then that the registerForPhoneAppMessages must come after the transmit which is not at all logical.
But thanks for the explanation. At first I thought that the on_received callback is called on another thread (as is usual in other languages) so that the transmit should have been called parallel, but it is either not in another thread, or the other one just exits fast enough for the transmit not be called.
(Bit confusing for me that the api never-ever mentions threads, and I'm always thinking about it when something is registered with a callback)

Former Member over 8 years ago

We have no threads (currently and for the foreseeable future). Nothing will ever run on another thread.

What you originally wrote should work, and I think the change you made could still fail if the phone was too slow to respond because it appears something is not working correctly.

The callback should run (on the one and only thread) as soon as the onTemporalEvent method returns if data was sent by the phone. There appears to be a bug here that we will investigate. It appears to only succeed if the data is already on the device when you register for it, which should not be the case.

DEXTER over 8 years ago

I see. Thanks for the explanation, and thanks for the upcoming investigation.

DEXTER over 8 years ago

Brian.ConnectIQ do you have any updates on the investigation? Users starting to notice this issue on my watchface. I was hoping to see a fix with the release of 2.4.1 but seeing that the android sdk was not updated (and that has a bug too) not believing this was fixed either (though I haven't tried it yet).

Former Member over 8 years ago

The ticket I created for the callback bug in the device VM, was not included in 2.4.1. It is currently scheduled for the next release, but there is always a chance it could get pushed back further.

DEXTER over 8 years ago

I see.
It'd be better if we could see the ticket itself because right now you have to post between us and your internal ticketing system whenever someone wants to find out the status of a ticket and it must be very time consuming.

But Thanks anyways.