Anyone else been checking out the new features in the 2.3.0.beta1 SDK?

I've been checking out a few:

  • the "Always active" watchfaces (kind of a marketing term, as users have been able to see a watchface at any time on garmins, and really a "1hz update with watchfaces" so always on seconds, and 1 hz update of other things on the display!)
  • The whole background process part (WAY cool!)
  • The debugger ("lions, and tigers, and breakpoints, oh my!" - Hey, Garmin is in Kansas! :) )


Initial reaction:

  • 1hz - Once you learn the technique, doing seconds on a digital WF is fairly straightforward. When to clip, and when to clear the clip!. Analog watch faces with a second hand, a bit more is involved, but the Analog sample in the SDK shows you how... The thing to note here, is while a WF can update parts of the screen at 1hz, the underlying data is still changing at the same rate as before, For example,if you update the HR on the watchface at 1hz, it doesn't change that getHeartRateHisory() still will only changed every minute or two.
  • background processes are VERY COOL. No more details on what I'm trying so I can publish my apps first! :)
  • Debugger - still a bit green IMHO, but this is a beta and garmin is looking for feedback. I have used it a number of times to set a breakpoint and check out what's in certain variables, and avoid the Sys.println() that never seem to be commented out when building for the store!
  • Former Member
    Former Member over 8 years ago
    Thanks Brian!

    The problem for me is that for my watch face the analog hands do pass over the digits ;)
    But now I at least know what caused the exception and can work from there :)

    -Torstein
  • Former Member
    Former Member over 8 years ago
    You do want to be very careful about what you do in general. I hear that trying to load resources is something to avoid at all costs, for example!

    Loading resources in general, or loading them in the onPartialUpdate() method?

    I'm working on an analog watchface with a seconds hand, and have trouble keeping within the power budget. I do load resources, but only during initialization, as I figured that shouldn't impact power use when the watchface is running...
  • In onPartialUpdate(). That's where the power budget comes into play. I guess I'd look at the size of the setClip(). Brian was saying something with the analog sample, that the position of the second hand means more or less time, where for example, if the hand is horizontal it used the least, while vertical, the most (the number of display rows comes into play here). As a test, maybe make the hand shorter (smaller clip in all cases) and see if that helps and then build up from there? The budget is the avg over a minute, and you can get by exceeding it occasionally, as long as the 1 min avg stays under 30ms. That's why the delegate gets called at the top of the minute, and can take a couple minutes to happen as it's looking at the 1min avg.
  • Former Member
    Former Member over 8 years ago
    Thanks a lot!
    I had a rather inefficient and costly calculation in the onPartialUpdate() method. After some optimizations my watch face has been running for hours now without exeeding the budget.

    Thanks again for pointing me in the right direction:)
  • The 30ms avg for the power budget can be a bit harsh, and the key is to only do what you have to in onPartialUpdate() in the most efficient way you can, and only setClip() what you really need to clip!
  • Help!

    Jim,

    Would you mind sharing some example code for a basic watch face which uses a background process to get data from the internet every X minutes? Now that the 2.3.1 SDK is out I started to look at this but have been disappointed with the documentation and single example.

    Unless I am mistaken there is only a single example of an app using a background process and I'm struggling to understand it from the source code and this is the only explanation there is. I'd have hoped there would have been a watch face example as I expect this to be a major use case, but sadly there is not.

    The documentation for the samples tells you what they do, but does not give any explanation of how this is achieved. ie. all you have to go on is the code itself. And there are not enough comments for me to understand how it works in enough detail for me to understand what would be needed to translate this into what I want. I have to say that Garmin could do a much better job of helping people here. Or maybe I miss something since for me, the sample code and reference documentation is not nearly enough.


    Another neat thing I've been checking out is the new background processes (f5 family and 935), where a watchface for example, can go out and get data off the internet that can be displayed on the watch face! In this case, I get weather data every 15 minutes.



    The tricky thing here is background processes have limited memory (I believe it's 32k, but possible lower), and often the data you get is a bit complex, so you could have a bit of a memory problem. Also, with the whole "HTTPS only" bit Apple is kind of forcing with iPhones, the simulator now gives you and error if you use http, so smaller data and https are a good guidelines!

    Next test, a background process for a widget!
  • I got a really simple sample of a bg process in a WF. I'm not using the internet in it, just passing a timestamp back to the WF when it's called, but it shows the setup. I'll post it later today or tomorrow.

    update: I posted the .zip of the simple wf with background in a new thread.
  • partialUpdatesAllowed

    Hey,

    Testing the "new" 2.3.1 SDK myself.
    Any idea where and when the partialUpdatesAllowed is set back to true in the Analog code sample, once power budget has been exceeded ?

    Thanks !
  • partialUpdatesAllowed is enabled in the AnalogView initialize function. This is run whenever the watch face is initialized such as when returning to it from a widget.

    Therefore, I'd expect the partial updates to start working again at this time. Until then the watch face will revert to a more traditional behaviour without partial updates.
  • It isn't. Once you exceed the power budget, you won't see onPartialUpdate() again until you restart the watch face.

    The key is, you never want to exceed the power budget if you what to keep displaying seconds all the time.