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

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!
  • This is just a basic framework of a watch face with a background process, but shows the basics.

    If you want to do something like a makeWebRequest() in the background, that can be done! You'll need to set the proper permissions for the app, and there are a few things to note.

    first of all, you don't have a lot of memory in the background (I think it's 32k), so keep your request such that you don't get a bunch of data in the response. Also, the background will run at most 30 seconds.

    When it comes to passing something to the background, the way I do that is in either the Object Store or as a property.

    The way to pass something back, is the Background.exit() call. Within the background, you can not write to the Object Store or property, as that will throw an exception.

    Another thing to note is things like initialize() in your App Class runs not only for the watch face, but also runs each time the background runs. That's a case where you'll see the difference in the .txt file if you long on a device.
  • Thanks Jim. I have not looked at the zip file yet, but this looks exactly like the sort of thing I was after.
  • How you do things in the background can be a bit tricky (and no, I won't post complete source for one of mine! :) ) but in the case of a makeWebRequest(), you may want to consider things like passing back not only the data received, but also be able to handle errors, so if (for example) the data is old because there wasn't a BT connection to the phone when the background ran, you can show that on the watchface. And there can be other comm errors you also want to show.

    And another thing you won't see in the sample is making the time for the Temporal Event configurable using app settings. Some users might not mind any extra battery/cell data costs of getting data every 5 minutes, but others might be OK with every 15 or 30 minutes instead.
  • Thanks Jim.

    After looking at your sample I have been able to build a watch face that obtains weather from a background service and displays this on the watch face. It's not pretty, but once I add the partial updates to display seconds all the time I should have a good template which I can use for my own watch faces.
  • Adding the partial updates for always on seconds is trivial. at least for digital watch faces. For analogue faces using a second hand this is more complex, but anyone who has a digital watch face which shows seconds in high power mode should be able to be modified very easily.

    So, now I have my watch face template with seconds and weather, I just need to design my watch face. If only I was a graphic designed and not a techie!
  • gasterpod - you may want to consider doing a couple different ones (link to the same BG process code). Go simple with just the temperature (which you might be able to just add to something you already have), or go bigger with more of the data you get back from the weather source. I posted a screenshot of one I'm working on that displays 5 things, including the timestamp from the weather source for the data, for example, but that means the time/date/etc are smaller so there is space.
  • Jim,

    is there any way to pull a more recent value of the Heartrate rather than the last data point on the 4hr widget that is updated every 1-2 minutes. it would be so nice to somehow make use of more frequent HR data. as it is, and you've convinced me, unless u are just sitting at your desk, the value shown on the screen isn't all that useful since it doesn't really show any of the real life variability...but something updated every 10-15 seconds would be much more useful.
  • Jim,

    is there any way to pull a more recent value of the Heartrate rather than the last data point on the 4hr widget that is updated every 1-2 minutes. it would be so nice to somehow make use of more frequent HR data. as it is, and you've convinced me, unless u are just sitting at your desk, the value shown on the screen isn't all that useful since it doesn't really show any of the real life variability...but something updated every 10-15 seconds would be much more useful.


    Nope. Using a temporal event background process, you can access sensors, but the BG can only run at most every 5 minutes. So every 5 minutes you could fire up the HRM (for 30 seconds at most), so you'd see the HR less often than you can using Sensor History. The only advantage is you could get HR from an external sensor, but I don't think many users would wear their external HRM 24/7.

    Look at Activity.Info.currentHeartRate, as on some devices you might see HR more often if they have a OHRM.
  • Nice work Jim. You've done it again!

    "Master" doesn't do it justice. We need to convince the forum admins to add the "Wizard" class. &#128513;