Memory usage by "Code" in Glance View

I'm having some trouble to support widgets for new devices due to the memory limit of the new "glance" feature. And this is not because I want to provide a very fancy Glance view. Actually I would be fine with the "default" view.

I have a few very "heavy", "complex" widgets. By that I mean a lot of lines of code. When I check the memory in the simulator, their "Code" account for more than 30kB. Yes, that's maybe crazy, but, for now, let's assume this amount of code is really needed, optimised and impossible to refactor.

After some tests and research, I realised that the portion of memory taken by "Code" and "Data" is the same in Glance view as in the full widget run. The "(:glance)" annotation doesn't seem to affect it. So I'm kind of stuck. And I personally find it a bit absurd: the Fenix 3 is able to run widgets that the Fenix 6 can't...

My questions:

- Am I correct in my analysis? Am I overlooking some obvious solution? Is there something "easy" I can do (i.e. besides refactoring)?

- (@Garmin) Is it really the intention? Shouldn't only the annotated code (and the "application entry") be taken into account in Glance view? I guess it shouldn't be too hard to tell that to the complier...

- (@Garmin) Alternatively, couldn't you provide a "default"/"dummy" Glance view that doesn't use anything from the code? So the widget code would actually only be loaded when the user opens it? 

  • What I did was move the meat of my widget to another class.

    I don't create that class in the Glance View.

    Essentially, it's a "deferred loading" of the meat.

    This works in the simulator (I don't have access to a device that supports Glance Views).

    My widget is big. I don't support the "low end" Fenix 5/5s and 6/6s.

  • The way I've been doing glance mode is I basically having 3 classes.  The "Glance view" annotated with :glance, the full screen view (no annotation) and a "helper" class with things used in both the glance view and the full screen view (annotated with :glance)  A couple have a background, annotated with :background, and that's always included.

    Using the annotations definitely work for me.  When running in glance mode, the widget (along with data) is in the 17k range, while in full screen, much larger.

    What SDK are you using?

  • I just use one "helper" class. (My widget doesn't do anything in the Glance View.)

  • Something else it could be, in your run configuration, make sure the target SDK is set to 3.1.x and not 3.0.x.

    If you have it as 3.0.x, it doesn't support glances and the memory usage will be much higher.

  • Maybe just to complement the info in this thread regarding ":glance" annotation and its memory behaviour.
    The ":glance" annotated code IS NOT excluded from devices that do not support it at build time. To exclude your glance logic for devices that don't support it, you need to additionally add your own notation e.g. ":has_glance" and ":no_glance" in your .jungle build annotations to devices that you don't want and want the glance logic to be included in the release code.
    e.g. the Forerunner 935 supports CiQ 3.1, but does not have glance view, its a waste to keep that logic in the final build code.

  • Most of my glance view code is also used in the full screen mode, so the amount of glace specific code is quite small.  And when devices started getting FW with glances, the glances would start working without changes a line of code.

  • True, I just wanted to point out that  ":glance" annotations don't work the same way custom annotations work. i.e. code is not excluded at build time (even if you try explicitly excluding the glance annotation in the .jungle). I assume this behaviour can be generalised for all "system" reserved annotations e.g. ":background".

    Regarding memory usage, I also reuse most of the code in the main widget, but the rendering itself is mostly custom as its a different sized viewport and the graphics cannot be reused (I use a circular progress indicator in the main widget vs. a bar progress indicator in the glance).

    My widget doesn't crash in the simulator, but I had users with e.g. Forerunner 935 complain that the widget would crash when triggering actions that (allegedly) peak the memory beyond the limit. Connect IQ doesn't fail gracefully when out of memory, so I can imagine the frustration (the user has no clue what happened).

    Removing the glance code is not the solution, that is clear - I just noticed this when experimenting around possible optimisation paths.

    The exclude annotations and the "other" annotations are syntactically equal, although semantically differently, I just wanted to make that evident to whoever bumps into this thread.