Glance View - how sliding text animation is realized in native apps?

Sliding text animation in native app is very smooth. How it is realized?

I've tried with timer or animate method but it does look good enough.

I belive there is simpler way, see menus for example.

  • Native views aren't written in CIQ and can do things that CIQ can't  While a timer may work, you also have the case where a glance ignores WatchUi.requestUpdate.  See https://developer.garmin.com/connect-iq/core-topics/glances/#glances

  • So, there is no better way than using timer?
    How about Spotify widget - the glance view seems to be very smooth. Isn't written in CIQ?

  • Spotify is a music app.  Not a glance,  The native player is involved to play the music.

  • I see, my mistake. It is still native app Wink Thanks for making it clear.

  • This probably doesn't help, but I think a good balance of smoothness and scrolling speed is to scroll by 2 pixels every 50 ms. (This is for a proof of concept full screen device app, not a glance, though). Def doesn't seem as smooth as the native music player glance.

    e.g.

    https://forums.garmin.com/developer/connect-iq/f/discussion/258627/anybody-have-example-of-sliding-text/1235847#1235847

    (There's nothing special in the example, but Iinked it in case anyone reading this thread wants to look at the code.)

  • Understand a key word in this thread is "Glance", and Glances have rules you don't have in a device app.  The non pro f6 devices, as well as the fr245 use Background UI Update

    See https://developer.garmin.com/connect-iq/core-topics/glances/#glances

    Glance Lifecycle

    Depending on a device’s resource limitations, GlanceView can be updated in two different ways.

    Live UI Update

    Devices that have ample resources [1] will start the Widget in Glance mode, and keep it alive. The provided GlanceView will be updated as needed by the system, and calls to WatchUi.requestUpdate() will trigger a View update as expected.

    Note: It’s highly recommended that the update rate should be kept under 1HZ to provide a better scrolling experience.

    Background UI Update

    Devices that have less memory [2] will start the app only when the system deems it appropriate, and calls to WatchUi.requestUpdate() will have no effect. Such a device could update their glance view when it becomes visible (activated) and at least 30 seconds since last update.

  • The non pro f6 devices, as well as the fr245 use Background UI Update

    I'm well aware of that, thanks. And you already mentioned it upthread. Not to state the obvious, but the entire discussion is irrelevant to devices which don't have live UI updates for glances. We could also point out that older devices don't even have glances.

    Note: It’s highly recommended that the update rate should be kept under 1HZ to provide a better scrolling experience.

    Good point, thanks for reminding me. The only glance with live updates that I've implemented in a real app uses 1 Hz updates.

    It's funny how some native glances update far more frequently than this and also how some native glances can cause scrolling to lag/stop for a couple of seconds (like when I scroll to Notifications, or when I scroll from Music to Weather, for example -- or maybe it's because the History glance is coming into view?).

    I did adapt my example to an actual glance/widget app and I tried it out on a real 945 LTE (which has live updates). It works fine with a 50 ms update period (20 Hz), and scrolling 2 pixels per update. (1 pixel per update would be smoother, but then the scrolling speed would be too slow imo.) I don't know of any way to make the updates go faster than 20 Hz, since 50 ms is the minimum timer interval.

    I don't see any noticeable lag when I scroll past my glance (especially when I compare it to the lag I see when scrolling past certain system glances, as mentioned above)

    So assuming that all live glance update-enabled watches are sufficiently fast enough to render scrolling text like this without damaging the user experience, I'd say it's worth a shot. (Yes, I know it's a big assumption)

    As far as release dates and hardware capabilities go, I think 945 LTE is somewhere between the oldest generation (e.g. 245M?) and newest generation (e.g. Fenix 7) of watches which support live glances. If you can find the slowest watch which supports live glance updates and test it on that.... Or maybe you could use jungles to limit scrolling to devices which you're reasonably sure can handle it (e.g. 945 LTE and newer?)

    EDIT: And obviously with your real app/glance, you wouldn't be scrolling 24/7/365 like my proof of concept. You'd probably be more like the Music glance, which doesn't start scrolling until a few seconds after it comes into view. And after a single full scroll, it waits a few seconds before it scrolls again. That could mitigate user experience / battery life concerns.

    Here's a video (sorry for the terrible quality lol).