Layout Device Indepndency vs. Samples

Hi 2 all
As a seasoned developer, it's a interesting challenge to investigate on the SW dev side of the Garmin eco System.
While trying to develop a sustainable app, some challenges arouse. It's, for understandable reasons, advised to put all device dependencies (especially layout stuff) into kindof an externalized layout XML files. OTOH, all the provided samples do prouduce their respective output in an absolute way, deeply embdded into the code, especially when it comes to data output (absolute positioning of dynamic data elements).
I might have overseen something.
What would be supposed to be appropritae would be to have some mechanics like static text fields and data driven text fields defined exclusively in layout files, the application being fully agnostic of absolute coordinates.
Something like having a Label/data field defined in a resource, changing it'sc ontent dynamically w/o "knowing" it's screeen positioning by adressing an resorce identifier.
I will gladly report any progess on this topic here, but there remains the feeling that something elementary has been overseen by me.
Thank you for any best practice advise.
  • The layout system already does this. You create a layout that places items at specified coordinates. You can then use View.findDrawableById() to get the given drawable and modify it as you see fit.
  • I prefer to use dynamic calculated coordinates - rather that than re-doing the layout for 4 different devices :-)
  • Works. Thank you.

    Layout:
    <layout id="L3FA">
    ...
    <label id="LAT" x="56" y="5" text="Lat." font="Gfx.FONT_SMALL"
    color="Gfx.COLOR_WHITE" />
    ...

    Code:
    function onLayout(dc) {
    setLayout(Rez.Layouts.L3FA(dc));
    ...
    fLatitude = findDrawableById("LAT");

    fLatitude.setText("this works");
  • Thanks for hinting on that.
    Really, that's a general Gretchenfrage.
    Something like a one-size-fits all generalized 85% solution or some individual custom-taylored 100% solutions, both approaches with different price tags.
    Generically supporting round vs. square watches, computations might be a little challenging.
  • Thanks for hinting on that.
    ...
    Generically supporting round vs. square watches, computations might be a little challenging.


    You are so right!!

    By a bit of work with dc.getHeight(), dc.getHeight(), and friends does the work for me in 95% of the cases... I think I have found a way to work with fenix3 as well with only a few changes to the code. So for now will stick with the calculated approach.

    Maybe if someone would provide a WYSIWYG editor for the layouts, I might reconsider :-)