Intro and question on field layouts


As an intro, I have 50+ years of software development experience, mainly in the field of industrial automation (robotics and such stuff). Since I retired 10 years ago, I got into Android development to keep my brain from going soft and still support a couple of apps in the store. I’m also a runner and cyclist who has been using Garmin fitness devices since the first FR101 and would like to develop something for Connect IQ for my own use, if not publicly distributed. After all, what’s another O/S and language after all the others I’ve learned (and mostly forgotten!).

I’ve been reading the docs and playing with some samples, but I’d like to know if there’s someplace that gives a good explanation on the use of layouts (or direct drawing) and the general issues of programming data fields for different watch sizes and pixel dimensions. For example, on my Edge 1000 I can have the cadence shown in a field: it shows the cadence value and has the units – “RPM” – displayed to the right in a vertically-stacked small font. The size of the fonts varies according to how many fields are defined for the screen it’s on. How does this work? I looked at the XML generated when you start a new project in Eclipse and was nothing but confused on what was there...

I know that Android has similar issues of supporting a wide variety of screen sizes and pixel densities, but I think its layout mechanisms are more flexible and the O/S takes care of many of the scaling issues. But it looks like most of this must be done “manually” in CIQ? If anyone can direct me to a place in the docs or to a relevant example of creating a data field for multiple devices and field sizes, I’d appreciate it!
  • With DFs there are two basic types - Simple and Complex.
    In a simple DF, you return what you want from compute(), and based on what it is, the correct fount will be used - both in size and number vs alphanumeric

    In complex, you control the display, with things like colors, fonts, position, etc. The dc is yours to do what you want, and things are displayed with onUpdate.

    In a complex, there are two ways basic ways to do things - with CIQ layouts or direct dc calls.(or you can use a mixture) Which you do is a bit of personal preference. But if you are tight on memory, direct dc can save a bit of memory.


  • part 2 - the forums acting up

    With complex, no matter what you use, you want to handle the different options for data field layout - the number of DFs on the screen. There are things like the obscurity flags that can be used, but that's really only needed for round and semi-round displays, where for example, the "rounded" part could be at the top/bottom/right/left -or a combo of them, and the other thing is the width/height of the DF to go by. I do these checks in onLayout, so onUpdate() has what it needs to do, and the checks aren't done there every second. This would include loading the CIQ layout if used, setting what font sizes should be, and the x/y for direct dc calls. For fonts, you can use custom fonts (they take memory) or use native fonts that have a fixed size (that can vary by devices) Fonts like FONT_XTINY through FONT_LARGE, and FONT_NUMBER_MILD through FONT_NUMBER_THAI_HOT.

    On the specific thing about a vertical "MPH", etc, there's no rotation for text, so it's something you have to do yourself. If using CIQ layouts, 3 fields for the three letters, or with direct dc, draw the M, move down a line, draw the P, down a line, the H. You could do something like a custom font where "MPH" would be a single character with the letters vertical, or a bitmap, but you may need multiples to handle the difference between a full screen DF or one of 10 DFs on a screen and in the case of bitmaps, the colors of the background.

    In addition to the SDK samples, in Eclipse when you create a new project, there are templates - so you can select a DF project, and then simple or complex.

    While the Programmer's Guide and Ux Guide goes into some of this, the best source may be the samples, templates, and just asking questions here. Lots of folks have done lots of DFs, and each one can be a bit unique when it comes to what's displayed and how.
  • While the Programmer's Guide and Ux Guide goes into some of this, the best source may be the samples, templates, and just asking questions here. Lots of folks have done lots of DFs, and each one can be a bit unique when it comes to what's displayed and how.

    Thanks, Jim. I have been looking at those and just worked through the tutorial from Peter and found it very useful. However, in the example where he positions the data in a field on a multi-field display, there is this arcane-looking piece of code:

    if (isSingleFieldLayout()) {
    dc.drawText(width / 2, height / 2 - 40, Gfx.FONT_TINY, label, textCenter);
    dc.drawText(width / 2, height / 2 + 7, Gfx.FONT_NUMBER_THAI_HOT, mValue.format(valueFormat), textCenter);
    } else {
    dc.drawText(width / 2, 5 + (height - 55) / 2, Gfx.FONT_TINY, label, textCenter);
    dc.drawText(width / 2, (height - 23) - (height - 55) / 2 - 1, Gfx.FONT_NUMBER_HOT, mValue.format(valueFormat), textCenter);
    }

    I understand what this is trying to accomplish, but I wish he had explained the origin of the constants used in that last line. I assume he's taking account of the font height, line spacing, and margin allowance, but where does this come from? Also, are these specific to the F735xt that the project is targeting, or would they be the same for any device? I would also think that it would be better to look up the height of the font, etc. with the appropriate methods and use some of those values, but maybe they are all known values to the author. (And is that -1 pixel adjustment really necessary?)
  • In looking at this, where things like "height-xx" is used, yes, it's for spacing. May not be the font height itself, like you say.

    To get the font height, again in onLayout, I generally do something like

    font1Height=dc.getFontHeight(font1);

    with height from

    height=dc.getHeight();

    The numbers he uses are likely specific to the 735. To get info on fonts, check out Appendix B of the UX Guide in the SDK, (for Edge devices, some might not be quite correct so if you have the device, that helps)