Jungle Aggregations or 153 lines?

I scraped this URL into EXCEL to generate a pivot table.

https://developer.garmin.com/connect-iq/compatible-devices/

What I need to do is split devices that can perform Foreground makeWebRequests vs Background. My data field is pushing memory limits. This will help.

I know CIQ 5.1 can perform Foreground (not sure about the six 5.0 products, I'll check). I need to specify each of the 153 products individually in monkey.jungle in order to point to the appropriate sourcePath, right? There isn't a CIQVersion family as far as I can tell. I could also use excludeAnnotations but same issue.

  • If you're able to scrape the COMPATIBLE DEVICES PAGE into EXCEL, maybe it isn't so much of a STRETCH to auto-generate the MONKEY.JUNGLE file?

    Regardless, flocsy has a tool for doing this kind of thing already. It seems that it can do exactly what you want: generate excludeAnnotation directives in monkey.jungle based on a minimum CIQ API level:

    https://github.com/flocsy/garmin-dev-tools/tree/main/monkey-generator 

    https://github.com/flocsy/garmin-dev-tools/blob/main/monkey-generator/monkey.template.jungle 

    # To define a feature you include one or more line with the feature:
    # monkey_generator_feature_<feature_name>_<keyword> = <value>
    # Feature names can use alphanumeric characters and underscore: '_'
    # If your app has a feature "alert_view" that is only available on devices with minimum CIQ 3.2.0 then you can define it using the `min_ciq` keyword:
    monkey_generator_feature_alert_view_min_ciq = 3.2.0
    # Though it's probably better to use the `has` keyword to check if the device has the method:
    monkey_generator_feature_alert_view_has = showAlert
    # No matter how you define it, your code, resources from the relevant features/[no_]alert_view/ folder will be included and the proper annotations set.

  • While I can relate to the DataField memory limit issue, and I use these differentiations in jungle, it's not that straightforward as it sounds. With almost every feature you either have it (on newer devices) which enables you to use it and it doesn't use much memory, or with older devices you have to choose: either you remove the feature from the app (freeing some space for other features) or you implement the missing function (uses more memory exactly on devices that already have not enough)

    With web requests in the foreground: it's even worse, because you'll need additional code to pass the results to the foreground process, plus everything becomes more complicated. And then there's the same question: if you already implement it with background and it works in an acceptable way, then is it worth to implement it also in the foreground for newer devices? And if yes, then the code will be even more complex.

  • The Toybox.Communications reference page has this note regarding foreground access in Data Fields.

    Note:
    This module was made available to foreground data fields with API 5.0.0