Memory not consistently being released

Also, this is purely anecdotal, but as a runner I know very few runners who are even aware of Garmin apps, and zero runners who bought a Garmin because apps were available.

At least for runners, I think most of us buy garmins because our friends use them. And because when we try alternatives like other sports watch brands or Apple Watches (a totally different class of device imo), there’s always something that’s lacking (like bad battery life or no physical buttons.) And maybe because the Garmin ecosystem and running support all comes together right out of the box, instead of having to download a million separate apps, like AW.

I know zero about marketing but I think Garmin has apps to keep up with smartwatches (much like all the other “smartwatch” features they added in the past five years), not as a major selling point. I bet music is drawing in so many more customers than Garmin apps ever will. And music still isn’t the primary reason to get a Garmin, otherwise why not get an Apple Watch? The apps are def better. Nobody argues that point.

In my app, I now include the popView() in the first menu (commented "CONTENTIOUS") to manage the view stack.

Yes. This is one way to keep the view stack correct. Provided that it is acceptable for the user to press back from secondMenu and end up at the mainView, this is the solution you should use. If you want a back press from secondMenu to return the user to firstMenu, you need to do two calls to popView() and one call to switchToView() in secondMenuDelegate.onMenuItem(). Both solutions would keep the view stack depth in check.

It seems to me to be a simpler approach than handling the selection in a global.

Agreed. I would not use a global variable for this. As a matter of fact, I strongly discourage the use of globals for any reason.

I don't know how much memory is available on the device, but I'm pretty sure it's in the Mb's not Kb's and if a F/W mod could reallocate just another couple of hundred Kb's for the apps

The devices have a fixed amount of memory available (exactly how much depends on device), and a block of that memory is specifically set aside for ConnectIQ. The rest is reserved for the system. All of the native software running on the device runs in that space. We can't just hand out a bunch of memory to apps, because we (ConnectIQ) doesn't have any more to give.

As pointed out by FlowState above, newer devices do give app developers more memory to work with. This is entirely because they have more physical memory, and so ConnectIQ is given a larger quota. The available memory is likely to be larger for every generation of device, and it is *extremely* unlikely that the memory limits for an existing device will ever be increased.

Yeah, my suggestion of using a global variable was not a good one. There are very few (if any) situations where there isn’t a better way. (I’ve only done it in CIQ when I wanted to save memory on CIQ1 devices, but then I ended up with a lot of pain when I wanted to reuse the same code in a nice way, on devices with more memory....)

Further to Travis’s point, if we wait a few years, then most Garmins in the field will have more memory. I wish it could be today, but it is what it is.