A little help understanding App/View lifecycles

Hey,

I'm creating a watch face that has an AppBase, a WatchUi.View and a ServiceDelegate. My background service goes and fetches some data from the internet, passes it to the App which then passes it to the View. I've got a few questions:

1. Is AppBase onStart the appropriate place to kick off the Background service (call registerForTemporalEvent)?

2. My View has a member variable called data that holds the data passed to it from the AppBase. Looking at logging from an actual device, this occasionally gets reset to null and I don't know why. Does the View get killed and a new one get created?

3. If so, what is the View's lifecycle? Should it contain non-constant variables at all? (I had a look at the docs but I couldn't find much.)

4. If so, can I trigger this on the simulator?

5. In AppBase, onStart "is called on application start up" and onStop "is called when your application is exiting". Am I correct in thinking that for an active Watch Face, my app will start only when the device is turned on and stop only when it's turned off? Or if I switch screens is it stopped and started again? (What about if I get a notification?)

6. If that's the case, what happens to the AppBase class?

7. If that's the case, what happens to the background process?

Thanks in advanced!

0 jim_m_58 over 4 years ago

1. Not really, as that runs for both the foreground and background. I do it in getInitialView, which is only run by the main app.

2. Each time the WF starts, you lose what's in the class variables. You want to save the data you want in Application.Storage and then load it back when the app starts.

5. It's going to start and stop often. each time you move to a widget, an activity, etc. Think of it as when you don't see the wf and see it again, the app has started a new.

Here's a general blog post about backgrounding https://developer.garmin.com/index.php/blog/post/guest-post-creating-a-connect-iq-background-service

0 3775626 over 4 years ago in reply to jim_m_58

Thanks for your response.

Do you have any recommendation on which class should be loading and saving the data to Application.Storage? The AppBase or the View? Or can the background service save the data to Application.Storage and then the View just read it?

Is reading from Application.Storage something that's appropriate to do on the View's onUpdate?

Finally, where can registerForTemporalEvent be called from? I had attempted to call it from the background service, but that didn't seem to work. (I wanted the background service to query the internet and if the request was successful, schedule itself again for an hour, if not, five minutes.)

0 jim_m_58 over 4 years ago in reply to 3775626

Some of this is based on your specific app - how and when you do things.

First of all, you can't save to Storage in a background process. It's something you do in the main app.

Consider a case where you have a WF that has a background process that reads weather data from an external source.

The main app sees that by way of onBackgroundData, so that's a good place to save the data to Storage, so next time the watch face runs, it can get the data from Storage, and the watch face can display the data and not wait for the background to run again. A good place to do that could be in getInitialView. getInitialView is also a good place to call registerForTemperalEvent.

For something like weather, you might need lat/lon, and a good place to save that is in the main app - when you're starting up, so that's a case where it's handled differently than the data from the background. (you're providing data to the background, vs the background returning data)

Some sites require an API key, and that's something a user often sets with App settings from a phone or GE, so then in the background, it reads that from Application.Properties and not saved by the main app at all.

In AppBase, there are some things called only by the background, some only called by the main app, and some called by both. When learning this stuff, put some println calls in a bunch of places so you can see what's being called and when, including in the background.

0 6893645 over 1 year ago in reply to jim_m_58

Do you also lose data in global variable? (outside of Application.AppBase)

Is it recommended to load the data back from Storage within onStart()? (Location data for example)