Acknowledged
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?)

Parents
  • So in my never-ending quest to write the most accurate and useful bug report titles possible (thanks for the motivation flocsy), I also did the following test:

    - leave onAppInstall() and onAppUpdate() in the code

    - Remove registerForTemporalEvent() from code

    - Add registerForStepsEvent()

    - in the service delegate:

    -- rename onTemporalEvent() to onSteps()

    Test A:

    - onSteps() calls Background.exit() directly: bug does not occur

    Test B:

    - onSteps() calls makeWebRequest, whose response callback calls Background.exit(): bug occurs

    - If I remove onAppInstall() and onAppUpdate(), the bug goes away

    So actually, I think my bug report title is pretty ok. afaict, it neither says too much or too little. But if anyone else wants to suggest an improved version, go for it.

Comment
  • So in my never-ending quest to write the most accurate and useful bug report titles possible (thanks for the motivation flocsy), I also did the following test:

    - leave onAppInstall() and onAppUpdate() in the code

    - Remove registerForTemporalEvent() from code

    - Add registerForStepsEvent()

    - in the service delegate:

    -- rename onTemporalEvent() to onSteps()

    Test A:

    - onSteps() calls Background.exit() directly: bug does not occur

    Test B:

    - onSteps() calls makeWebRequest, whose response callback calls Background.exit(): bug occurs

    - If I remove onAppInstall() and onAppUpdate(), the bug goes away

    So actually, I think my bug report title is pretty ok. afaict, it neither says too much or too little. But if anyone else wants to suggest an improved version, go for it.

Children
No Data