Best location for registerForTemporalEvent

Hi, hopefully this question will get more traction than my last two ;-)

I have an app that does background processing but when I start the glance or main view, I stop the background process through a call to deleteTemporalEvent in getGlanceView and getInitialView as the main app does the same processing at a shorter interval (and yes, I confirm the onTemporalEvent DO happen even when the main or glance process are running if the background process isn't deleted). Knowing this, where do you think the registerForTemporalEvent should be located? It's currently in the onStop if it's not for the background process but if the app crashes for some reason or the user hard shutoff the device, I'm assuming onStop isn't called and therefore the background process won't be triggered until the user gracefully shuts down the app again.

Thanks.

PS. That was one reason for my question about detecting when onStart is for the background process or not.

Edit: Through println, I can already tell that the background process WON'T restart if the device is shut off WHILE THE APP IS RUNNING (and deleteTemporalEvent was ran). If the app ain't running when the watch is shut down (ie, there is a service delegate registered), then it has no effect and the onTemporalEvent will be called as usual.

Edit2: Shutting the watch 'gracefully' (through the menu) doesn't make the device call the onStop function of the running apps, that sucks :-(

0 flocsy🤠 8 days ago

What does "shutting the app gracefully from the menu" mean?

0 FlowState 7 days ago in reply to flocsy🤠

SylvainGa said:
Edit2: Shutting the watch 'gracefully' (through the menu) doesn't make the device call the onStop function of the running apps, that sucks :-(

flocsy🤠 said:
What does "shutting the app gracefully from the menu" mean?

I think the original sentence was missing a word: "Shutting the watch down 'gracefully' (through the menu...)"

I think he means turning off the watch the standard way through the regular UI. e.g. On a 5-button watch, hold LIGHT for the controls menu, then select the power off icon.

Contrast with a forceful shutdown (sometimes referred to as a hard reset) which is triggered by holding LIGHT.

I think the implication is that a graceful shutdown of the watch might be expected to also gracefully shut down a running CIQ app, while there would be no such expectation for a forceful shutdown.

0 SylvainGa 7 days ago in reply to FlowState

Yes, that's exactly it. Especially when in the onStop routine, Garmin says:

If the application needs to save data to the object store it should be done in this function. Once the function is complete, the application will terminate.

0 SylvainGa 7 days ago

So, I decided to not stop the background process while the app is running. I did that initially because in the simulator, when onBackgroundData is called, it creates a onStart/onBackgroundData/getInitialView (or getGlanceView) sequence as it should but then creates ANOTHER onStart/getInitialVIew (or getGlanceView), which means I now have two sets of data, one with the data received through the onBackgroundData and one that does not have it. The first onStart do NOT have a corresponding onStop so the data received is lost. This scenario does NOT happen on my Fenix 7S Pro and I'm assuming it's (another) simulation hiccups.

0 flocsy🤠 6 days ago in reply to SylvainGa

Something is odd. The background app is not supposed to call getInitialView or getGlanceView. I never saw it happening in the simulator. In fact I do use this to do things in getInitialView that are only needed in the foreground app.

0 SylvainGa 6 days ago in reply to flocsy🤠

No, not the background app, in the Simulator, after the background has ran after a simulated temporal event, it creates two onStart call for the main or glance view, one for the onBackgroundData and another one right after. It's that one that creates issues in my code in the simulator.

0 flocsy🤠 5 days ago in reply to SylvainGa

Even that sounds strange. I haven't played with glances, just watch-apps, but I thought it would be the same more or less: if the foreground app is already running (onStart ran already) then only onBackgroundData is called. And if it's not running, then neither of them is called at the time the background app exits, but rather the next time you (the user) runs the foreground app, then after onStart, the onBackgroundData is called.