• Replies 96 replies
  • Subscribers 56 subscribers
  • Views 104597 views
  • Users 0 members are here
Options
Related

Overview of Connect IQ Apps accompanied with source code

peterdedecker
over 7 years ago

I've made an overview on my website of the connect iq apps that are accompanied with source code: http://starttorun.info/connect-iq-apps-with-source-code/
This can be a great resource for starting developers to learn how certain things should be achieved.
(When you use something in your own apps be sure to give credit where credit is due and to respect the license of the open source app (usually the license is available in the root of the source code repo))

When I missed a source repo you can comment on the above post in the comments section (or you can also indicate it below with a reply in this forum thread)

Hope it helps to attract new developers to Connect IQ :)

  • over 3 years ago

    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...

  • over 3 years ago

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

    chariotsolutions.com/.../

  • over 3 years ago in reply to Joe Berger

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

  • over 3 years ago in reply to 9256409

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

  • over 3 years ago

    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

  • over 3 years ago in reply to Joe Berger
    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.

  • over 3 years ago in reply to peterdedecker

    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.

  • over 3 years ago in reply to Joe Berger

    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")

  • over 3 years ago in reply to FlowState

    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.