• Replies 90 replies
  • Subscribers 26 subscribers
  • Views 28371 views
  • Users 0 members are here
Options
Related

VERY Simple sample of a watch face with a background process.

jim_m_58
over 7 years ago
This one really doesn't do much. It displays the time, an indication if it's on a device that supports background processes (you can see how that's checked in the App Class), The count of the times the background process has run, and the data returned from the background. It does cache data in the object store, so after the first time the background runs, it will have data.


The background process is a Temporal event, and runs every 5 minutes. All the background does is return a string with a time stamp (HH:MM). There are a number of Sys.println() calls to see what's going on. If you have a watch that supports background processes (f5's,chronos,935,735,va-hr), create a <myapp>.txt in logs to catch the println() calls, as you see kind of a neat thing where those that come from the background are marked as such!

This runs in the sim can you can use the code to build a sideload. In addition to devices that support background processes, I included the fenix 3 as a target so you can see how it works on a watch that doesn't.

if you have questions about the code, just ask!
  • over 7 years ago
    There's really not much different than doing makeJsonRequest() in a regular process. Thing that are needed for the call (apikey, etc) the main app puts in the object store (if it's not in properties already), and then in the background, from within onTemporalEvent, make the call, and supply a callback.

    Then in the callback, use Background.exit() to pass back what you want, be it the data or an error status. The blog post I did talks about some of this in more detail. (see post 14 in this thread) You do want to be careful about the amount of data you're getting back, in that the background is only 32k at most.
  • over 7 years ago
    Thanks for the input. First time playing with makeJsonRequest/makeWebRequest and background process... New stuff to figure out :-)
    Are you using makeJsonRequest or makeWebRequest for querying darksky?
  • over 7 years ago
    I've switched all my comm to use makeWebRequest. If you've not used it before, maybe do a simple widget or watchapp and get it to work in the foreground before you involve the backgrounding. Just building the request and handling the returned data would be a first step.
  • over 6 years ago
    If you have any questions about the blog post, go ahead and post them here.


    thanks for the sample, this thread & the blog post, very helpful. my question: with watchface (or data field) is there a way to do an initial makeWebRequest from the background process so we don't have to wait 5 minutes for the first data to load?
  • over 6 years ago
    For DFs, I've used deleteTemporalEvent in onExit so that the background doesn't run except when the DF is used in the current activity, and registerTemporalEven when it start, and that seems to allow the background to run right away most times.

    In both a DF and WF, I save off the last result from the background in the object store, so there is data available right away to be displayed while waiting for the next time the background runs.

    Assume you have temporal events set for every 5 minutes.

    Consider a watch face. The background runs, then you move to the widget loop and back to the watch face. The next time the temporal event will run may be 4 minutes later, but by saving the data off, there's data that can be displayed for that 4 minutes. (it's as if you never left the watch face).

    If you have a temporal event set for every 5 minutes and run a watch-app for 20 minutes, the temporal event might not run at all for that 20 minutes, but as soon as you leave the watch-app, the temporal event may run right away. With a native app, the background will probably run on it's "every 5 minutes, so the background might run 4 times in that 20 minutes. In the simple case, the data from the last time the background ran will be available when the main app runs.

  • over 6 years ago
    For DFs, I've used deleteTemporalEvent in onExit so that the background doesn't run except when the DF is used in the current activity, and registerTemporalEven when it start, and that seems to allow the background to run right away most times.


    when you say "right away" there, you mean it will start the timer and then kick off the background process to fetch data in 5 minutes (minimum), correct?

    I get what you're saying about the saving off of the last result, but for more timely data (e.g., health related, not weather, where 20 minute old data is not very helpful, e.g., if you had set a different watchface for a while), or even for the very first result after installing the background-data watchface/datafield? is there a way to avoid waiting 5 minutes to find out if you've set it up properly (e.g., a url setting)?
  • over 6 years ago
    Once the background is set for temporal events at say every 5 minutes, you're kind of in that mode. You can try things with deleteTemporalEvent, but you probably won't get it to have the background run as soon as you go to the watchface in all cases (go to the widget loop and come back 30 seconds later, etc).

    When it comes to caching in the Object store, if 20 minutes does work for your case, you probably still want to do it, but add a check for the age of the data - if the cached data is only 3 minutes old, just use it. If you're away from your watchface for more than 5 minutes (if that the period you use), you'll see the latest in obBackgroundData
  • over 6 years ago
    Once the background is set for temporal events at say every 5 minutes, you're kind of in that mode. You can try things with deleteTemporalEvent, but you probably won't get it to have the background run as soon as you go to the watchface in all cases (go to the widget loop and come back 30 seconds later, etc).


    i tried to set the initial registerForTemporalEvent with a moment that was <5 minutes and it just fails (on the simulator) with an error about <5 minutes (the docs say the 5-minute restriction flag is only cleared at startup for watch-apps and widgets).

    it just seems broken to me to force a user to wait 5 minutes to figure out if the initial setup of a watchface is working or not.
  • over 6 years ago
    Yes.. 5 mins is the minimum when you register the temporal event, but you may want to look at when you register it (or delete it).

    In the simple case, someone installs your WF and runs it. If it regisiters the temporal events when it first starts, the background will run every 5 minutes after that.

    But in a case when something (a login/apikey/etc) is needed, the background will just error out every 5 minutes, and if the user goes in to settings and provides the needed itfo, it could be 5 minutes before the background runs again.

    One thing I've done is not register the temporal event until the needed data is available. So I don't register each time the app starts, but only after the settings have been loaded (or reloaded in onSettingschanged()) and the needed data is there. If the needed data isn't there, delete the temporal event. You could even consider checking for phioneConnected before doing the register.

    With that, user installs the watch face, but since the needed credentials aren't there, there's no call to register, and any existing temporal event is deleted.. User then goes into settings, provides the credentials. onSettingsChanged() is called in the app, and since the credentials are there, the call to register is done. The background will run right away.
  • over 6 years ago
    The background will run right away.


    i think i am seeing this now - i wasn't before because i just kept using the same simulator target device, but the simulator seems to remember the temporal event even if you close the simulator and restart it, if using the same device. if you switch between devices it seems to forget, and then the background process will start right away. thanks, that makes a lot more sense now.