Can a "misbehaving" watch face cause a battery drain

Hi,

I am just beginning with Connect IQ (having some experience in Java and Objective C) - you say that you can draw a real arc in Connect IQ instead of using polygons - how would you do that? Is there a dedicated class?

Thanks,
CJ

could some form of profiling be added to the simulator that shows something like "API calls per minute" as a gauge to how much a watchface impacts the battery and the high ones be rejected?

The number of API calls isn't necessarily a good metric to determine the cost (in terms of power used). A single API call to turn on the backlight is going to cost much more than an API call to set the color of a single pixel. Likewise, drawing an arc as a big colored circle with a smaller black circle over the top of it may be much more expensive than a multiple calls to draw smaller polygons.

you say that you can draw a real arc in Connect IQ instead of using polygons - how would you do that? Is there a dedicated class?

There is currently no dedicated class to do this. Until one is provided, you can build up an array of (up to 64) points using some simple trigonometry and then render that. You could also use the hack mentioned above... draw a big colored circle, a smaller circle that is the color of the background (this part is static so it could be done with a layout), and then draw triangles to clip the colored circle as you see fit.

Travis

This isn't something I've seen, but in the vivoactive forum, there are some folks that are seeing a crazy amount of battery drain. (I mean like 70% to zero over night). People are thinking GPS and BT, but I'm betting that many people have a CIQ watchface.

We all know about low-power mode, but is is possible that something in the code of a watchface is causing a drain? (I mean in the watchface itself, and not in the VM).

For an example, what if the watch face starts it's own 500ms timer that always runs, even in low power, or maybe something that runs until it's stopped by the watchdog timer on a regular basis?

Maybe just things that are CPU intensive even every minute or second? (based on "low power" mode)

I don't know what happens when something is submitted to the app store, but is there something like a "code check" to catch such things?

I've had this happen to me with the default watch face, so my guess is that it's not related to CIQ (at least I hope it's not). The product team is aware of the issue and is looking into it.

I've had this happen to me with the default watch face, so my guess is that it's not related to CIQ (at least I hope it's not). The product team is aware of the issue and is looking into it.

I created (and testing) my own watch face which uses the code from Travis for arc and using it, I noticed a subtle delay when changing menus from watch face to the other garmin widgets.

I can't say for sure, but it dpsure does look like it's taking a toll at least on processor speed. Battery life, can't tell yet. Had the watch for a week and been plugging in and out so many times it's hard to get an accurate pic / profile of batt life.

I'm still wondering if there is any kind of "code review" done when something is submitted to the CIQ app store. This is kind of done when something is submitted to the Google and Apple store, for example. I can see where a "misbehaving" watchface can cause battery drain. Someone posted today in the vivoactive forum that the CIQ watchface they are using can drain 30% of the battery each day, but it sounded like with the default, it gets back to a normal drain.

We don't have plans to review each app in depth. The main purpose of the submission process is to avoid any offensive material from being posted to the store, and to avoid copyright or trademark infringement. If, however, an app developer receives feedback from customers that their app is causing issues (especially device crashes), we're more than happy to help track down the root of the problem.

* We need to be certain that the issue isn't a Connect IQ bug.
* We're aware that many app developers don't have access to hardware, and the simulator isn't a perfect substitute (yet).
* It gives us a chance to encourage coding practices that produce apps that perform well.
* I'd like to think it helps build the developer community. :)

You can either post here on the forums, or contact the team directly at [email protected]. I'd recommend the forums first, because you'll have the entire community to help you out. This email box is something I'd save for more extreme situations, where other attempts to address an issue have been unsuccessful. Either way, there are several of us at Garmin monitoring both the forums and the inbox.

I just read a case where someone is using a bunch of polygons to draw an arc, for example. Drawing an arc itself should require one or two CIQ calls, but drawing it with polygons is probably more like 20-100 calls, depending on how smooth you want the arc. This is a whole bunch of extra calls, every minute or second! (and surely drains the battery more)

Maybe not for us yet but for the app store folks, could some form of profiling be added to the simulator that shows something like "API calls per minute" as a gauge to how much a watchface impacts the battery and the high ones be rejected? "Pretty" does not equate to low power in some cases! 200 api calls a minute might be ok, but 200,00 probably isn't! And this may be needed not only on the initial submission, but on updates as it might be a new bug.

Yea, the one fenix arcwatch app can end up calling up to 5x300 circles to draw each second. It lags so bad that it takes about 1/2 second to finish the arcs, so you can noticeably see the text update happening well separated from when the arcs finish updating. It drains the watch pretty good.

While it is something to keep an eye on when you get/create a new watch face, there's enough leaks/bugs at this point in the firmware's life that I don't think poorly done watch faces are to blame for all the drainage.