Overview of Connect IQ Apps accompanied with source code

I also provide source code for my data fields, the apps are here: https://apps.garmin.com/en-US/developer/40bb30ad-6b08-4c28-aace-1a899b27facc/apps (use the source code link in the app page to access)

Highlights: They're basic data fields, but I tried to make the formatting and unit display as close to built in data fields as possible. Custom unit (km/h or m/h) suffixes drawn with smaller font in two lines and off-center and centered/auto-sized fonts for the actual metric value. Hope it helps...

Peter, I wrote a blog for new developers, see if you can use it:

chariotsolutions.com/.../

Nice, but you don't actually provide any source code...

There's also a section for tutorials on Peter's site.  Not everything includes source code for a full app.

Peter, thank you so much for compiling all of this.

I have a question, on this page: https://starttorun.info/tutorial-layout-by-coding-dc-draw-calls-directly/

you mention that direct draw consumes less memory than an XML layout. What about CPU/power consumption? Isn't a fixed layout, while consuming more memory is easier on the processor and the battery?

Thanks

Joe Berger said:

Isn't a fixed layout, while consuming more memory is easier on the processor and the battery?

Thanks

Behind the scenes the layout is also converted to virtual machine instructions just as the direct dc draws are. 

The layout.xml is easier for development but produces less optimal code. Most likely it's not beneficial in any of the areas you question but i have only investigated memory as that was what concerned me.

Back in the CIQ 1 days when data fields were limited to 16k, a common technique to free up memory was to switch to direct dc calls from layouts.  Like Peter said, layouts eventually end up doing the same things as direct dc calls.

I'll just point out that even in 2021, several current Garmin watches (e.g. Vivoactive 4, Fenix 6, Venu) are limited to 32 KB for datafields, which is still not an incredible amount of memory. To put this in context, the Vivoactive HR also has 32 KB for datafields, and it was released in 2016. Some of these CIQ 1 devices that were alluded to (e.g. FR230) were released in 2015.

I would say that using direct DC calls instead of layouts is still a valuable memory-saver. As a matter of fact, when coding a full-screen 6 field datafield app, I found that using hardcoded, pre-computed device-specific DC layouts (using my own handcoded "layout system") saves a lot of memory (in code) compared to trying to dynamically determine the DC coordinates at runtime (based on device shape and dimensions). A big reason for this is that I can put the layout data in resources, so they consume 0 bytes of code, and they only briefly consume memory for data at init time (while they're not being used, that RAM can be used for something else). But even when the layout data is in code (which is necessary for CIQ 1 devices), there's still savings over writing a function to dynamically compute the layout.)

TL;DR in my experience: Garmin layouts < dynamic DC calls < pre-computed DC calls (i.e. handcoded "layout")

Interesting. Thank you. 

Yes, this was exactly my thinking - fixed layout shouldn't consume CPU time since you're not calculating positions dynamically, every second. 

My app only consumes 49K, so the memory is not an issue, it's the CPU/battery consumption that interests me.

I just don't see a good analytics tool available in the Sim, other than opening an ADB connection and looking at the running processes and their CPU load.