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