Algorithm/approach for full page data field on multiple devices?

Former Member
Former Member
What's the best approach for displaying multiple items on a full page data field for multiple devices? Is there example code or a simple approach, or is this going to be lots of code? I was hoping that layouts.xml would simplify this, but it doesn't seem to.

Thanks, Jonathan
  • Have you looked at the code from the Eclipse Template for a complex data field? File>New>Connect IQ Project, then a DF, complex.

    For me, I do direct dc calls (no layouts), and use things like the the obsurity flags, thedc width and height, etc to set things like x/y/fonts in onLayout, and do things like display a message in the DF if the width or height are too small.

    if you only thinking full screen, a simple test is comparing the dc width and height to the screen width and height.
    var height=dc.getHeight();
    var width=dc.getWidth();

    var swidth=Sys.getDeviceSettings().screenWidth;
    var sheight=Sys.getDeviceSettings().screenHeight;
    Sys.println(""+width+"x"+height+" and "+swidth+"x"+sheight);
    if(width!=swidth || height<sheight-buttonBarH) {
    //not full screen
    }

    "buttonBarH" is to allow for some of the non wearable devices that use part of the screen for something like an on-screen button bar, etc, and setting it to something like 30-40 should be fine.
  • This is just my opinion but I think that there's at least 4 approaches:

    1) layouts.xml, which is device-specific (not generic) and wastes lots of memory afaik

    2) Hardcoded dc.draw() calls. Similar to (1) except the positioning is done in code rather than in the XML data.

    Could save memory over (1), but you still have to hardcode the layouts, and it's a lot of code.

    e.g.
    Flexirunner data field app: https://apps.garmin.com/en-US/apps/c...8-c93edadabe3d
    Source code: https://github.com/imgrant/FlexiRunner

    I think you will find there are a few 7-field apps on the store that seem to be based on this app.

    The downside with this code is that there are four copies of the source for each of round, semiround, tall and wide watches, and there seems to be a lot of duplicated code. So if you make one change, you're making it four times.

    3) Dynamic/generic dc.draw() calls (calculate layouts on the fly), which can be very elegant but will be a lot of code and waste a lot of memory imo.

    e.g.
    GRun: https://apps.garmin.com/en-US/apps/b...6-b2e136b996a9
    Source: https://github.com/gcormier9/GRun

    I will say that the code in this app, while being pretty generic, is also very memory intensive (due to the amount of code), and I don't think it'll even fit on the older watches (e.g. FR230). It's so generic that it supports dynamic recalculation of the layout, if a field is omitted (by configuration).

    I wanted to use this technique, but I found that it just took too much memory for my purposes.

    4) Custom pre-calculated layouts (with your own data + code), which can be very memory efficient but is still-device specific

    ---

    If you don't mind reusing code, and are not worried about wasting memory (that could be used for features), (3) could be a valid option.

    ---

    I prefer (4), which is to write my own code for rendering pre-calculated layouts (represented in my own data structures), because I want to save memory for features. I don't want to go into a lot of details, since it wasn't what you were looking for, but I saved a lot of memory with byte-packing of data and hardcoding layouts for every single screen shape/resolution, which of course was pretty time-consuming.
  • I think the op wants to minimize code and then layouts are the way to go really. One set of code and just a specific XML for each device with the positions for that device, this was made for this.

    if memory becomes a problem you can always go for direct dc draws at that point in time.



  • peterdedecker fair enough, but it all depends on what you mean by "minimize code". Sometimes it just means "minimize code I have to write" and in the case of those apps, the source is available and the layouts have already been created and tested.

    I'm sure XML layouts are the simplest way to go, but then you have to make layouts for all the devices you want to target (as you pointed out), which can be labour-intensive. I've gone through the process of making (custom) fixed layouts for round (218), round (240), semiround, tall, wide, and Edge (3 layouts, including landscape), plus tweaks for various font quirks (VA3/Approach S60), and it isn't fun. Especially when you want to support multiple layouts for a single device....

  • Layout's are probably the right way to go if they work for you, are general enough, and you don't have memory constraints.

    I've generally done as Jim suggests, using dc.draw... functions. I have some helper functions that do appropriate layout and additional alignment from the stock ones. I do conditional stuff based on the shape. Round generally needs a bit of nudging downward compared to semi-round. I have yet to need to write completely separate onUpdate functions for individual devices. That could get to be a PITA. I have one app that has it's own layout handler as Flow suggests. That was one of my first attempts at this but I've moved away from that.

    Bottom line is there is no right answer. Different individuals will feel more comfortable with one vs another, plus the complexity of the app will likely make some solutions better than others.
  • Regardless of how you do this, there are some devices that need a bit of extra attention for any kind of CIQ app if you support them - the Edge 1000, Oregon and Rino.

    The reason being is they have a landscape and portrait mode. On the Edge, it's a setting, but on the Oregon and Rino, it can be set to switch when the device is just turned sideways. So while using a 2x4 screen for for your data and it's fine in portrait mode, in landscape, you might go with 4x2. onLayout is called when a landscape/portrait change occurs, and you can set the mode under settings in the sim for testing.
  • Former Member
    Former Member over 6 years ago
    Thanks everyone! I was hoping for a simple solution, but the code in felxirunner will help.