Acknowledged
5 months ago
CIQQA-3116

Simulator: If onAppinstall() or onAppUpdate() are overridden, and (BG) makeWebRequest()'s response callback calls Background.exit(), onBackgroundData() is not called

This problem exists on both Windows and Mac, on SDK 8.1.1 (fr955). I also tested on 7.4.1 and 6.4.2 (fr935), and the same problem exists on those SDKs.

On a real fr955 (built with SDK 8.1.1), this problem does not exist.

Related discussion at: https://forums.garmin.com/developer/connect-iq/f/discussion/408604/onbackgrounddata-not-called-from-when-background-exit-is-called-from-makewebrequest-callback

Code which reproduces this problem: https://litdev.uk/stuff/bgwfApp.mc

(I am not the OP for that thread or code. Sorry for the plain text urls, but the forum is broken)

All credit goes to StevenX for rediscovering the bug and jim_m_58 for finding the workaround.

--

In the code that reproduces the problem:

- the app type is watchface

- onAppInstall and onAppUpdate are overridden

- registerForTemporalEvents is called in the foreground

- the background implements onTemporalEvent(), which calls makeWebRequest

- makeWebRequest's response callback calls Background.exit(). The bug is that onBackgroundData() is never called in this case.

(Note that we are sure the response callback itself is called, because it logs messages to the console)

However, if Background.exit() is called directly from onTemporalEvent(), then onBackgroundData() is called as expected.

This behaviour is not specific to temporal events. The exact same behaviour can be seen with registerForStepsEvent() / onSteps(), for example.

I think the two main elements that trigger the bug are:

1) onAppInstall and onAppUpdate are overridden

2) makeWebRequest is called in the background [during the handling of *some* event, like a temporal event or steps event] and the response callback of makeWebRequest calls Background.exit(). I think it has something to do with the background process "scheduling" a callback via makeWebRequest, returning control to the non-app code without calling Background.exit(), and the "scheduled" callback calling Background.exit(). In other words, if Background.exit() is called before control is initially returned to the non-app code, there's no problem.

I assume that makeImageRequest() would also trigger the bug, but I haven't tried it. I also assume that any other function which can "schedule" a callback would trigger the bug (are there any others besides make*Request(), which can be used in the background?)

flowstate
Parents
  • 5 months ago

    > Are you sure that all that is in the title really needed? I mean does it only happen in case it's a makeWebRequest? My guess is it would also happen in temporal events.

    To answer these questions more simply.

    "Are you sure that all that is in the title really needed? I mean does it only happen in case it's a makeWebRequest?"

    I only reproduced this with makeWebRequest in the BG although you're welcome to try to reproduce it other ways. My guess would be that if Timer.Timer() could be used in the bg, then it would also trigger this bug, but it can't. I'd guess that any other function which can "schedule" a callback for "later" (outside of the current execution context) would also trigger the bug. Surely makeImageRequest() would be a good candidate.

    It seems to me that Garmin has everything they need to reproduce and fix the bug, and that other devs can see this title and make sense of the circumstances which would cause this bug, but again, you are welcome to suggest a better a title.

    "My guess is it would also happen in temporal events."

    This statement makes zero sense, no matter how it's interpreted.

    OP of the other thread already established that this bug does not happen when Background.exit() is called directly from onTemporalEvent(). So if that's what you meant, your guess was already disconfirmed before it was made.

    Furthermore, the code that reproduces this problem involves calling makeWebRequest from onTemporalEvent() and calling Background.exit() from makeWebRequest()'s response callback. So if you meant the bug "also" happens when temporal events are involved in any way, well "also" makes zero sense, since that's literally in the code that reproduces the problem.

Comment
  • 5 months ago

    > Are you sure that all that is in the title really needed? I mean does it only happen in case it's a makeWebRequest? My guess is it would also happen in temporal events.

    To answer these questions more simply.

    "Are you sure that all that is in the title really needed? I mean does it only happen in case it's a makeWebRequest?"

    I only reproduced this with makeWebRequest in the BG although you're welcome to try to reproduce it other ways. My guess would be that if Timer.Timer() could be used in the bg, then it would also trigger this bug, but it can't. I'd guess that any other function which can "schedule" a callback for "later" (outside of the current execution context) would also trigger the bug. Surely makeImageRequest() would be a good candidate.

    It seems to me that Garmin has everything they need to reproduce and fix the bug, and that other devs can see this title and make sense of the circumstances which would cause this bug, but again, you are welcome to suggest a better a title.

    "My guess is it would also happen in temporal events."

    This statement makes zero sense, no matter how it's interpreted.

    OP of the other thread already established that this bug does not happen when Background.exit() is called directly from onTemporalEvent(). So if that's what you meant, your guess was already disconfirmed before it was made.

    Furthermore, the code that reproduces this problem involves calling makeWebRequest from onTemporalEvent() and calling Background.exit() from makeWebRequest()'s response callback. So if you meant the bug "also" happens when temporal events are involved in any way, well "also" makes zero sense, since that's literally in the code that reproduces the problem.

Children
No Data