Ticket Created
over 3 years ago

WERETECH-12674

Feature-request: Improve jungle processor

Please improve the jungle processor by adding new features. The idea is to give more power to developers to optimize their code. For example to enable to decrease the code size by giving easily usable directory structure and excludeAnnotations.

1. Hardware related things:

One widely "used" feature that can easily be added to jungle is the memory available for certain app type. This could include sourcePath, resurcePath, excludeAnnotations. For example:

fenix3.sourcePath = source;...;source-datafile-16K
fenix6.sourcePath = source;...;source-datafile-32K
fenix3.resourcePath = resources;...;resources-datafield-16K
fenix6.resourcePath = resources;...;resources-datafield-32K
fenix3.excludeAnnotations = base;...;datafield16K
fenix6.excludeAnnotations = base;...;datafield32K

Of course the same for all the possible app types.

2. Software related things:

This might be a little more tricky, because sometimes things get upgraded (in which case the newly released SDK should have the new information available of course), but it would be nice to have the system-level and maybe the api-level (though this might be redundant if we have the system-level):

I'm not exactly sure what would be the best way, maybe:

fenix3.
excludeAnnotations = base;...;system2;system3;system4;system5
fenix6.excludeAnnotations = base;...;system1;system2;system3

maybe:

fenix3.excludeAnnotations = base;...;system-min-1;system-max-1
fenix6.excludeAnnotations = base;...;system-min-4;system-max-5

Even better if there would also be a way to have similar diferentiations in the resources and source.

The use case is that it can help developers to decide which devices they support. When they decided it can help optimizing code by excluding code that is "too new" for a device. For example there's no need for the following code on system 1 devices with max api level < 2.4.0, because they can never have Properties:

function setConfig(key as Application.PropertyKeyType, val as Application.PropertyValueType) {
    if (App has :Properties) {
        App.Properties.setValue(key, val);
    } else {
        App.AppBase.setProperty(key, val);
    }
}

By knowing this we can save some precious bytes in the memory if we use:

(:system2)
function setConfig(key as Application.PropertyKeyType, val as Application.PropertyValueType) {
    App.AppBase.setProperty(key, val);
}
(:system3)
function setConfig(key as Application.PropertyKeyType, val as Application.PropertyValueType) {
    if (App has :Properties) {
        App.Properties.setValue(key, val);
    } else {
        App.AppBase.setProperty(key, val);
    }
}

  • My post was more to nudge you into thinking of a DIY solution rather than waiting on Garmin, and my code is very site specific.

    Publishing it will probably land me in a world of pain, but here goes:

    https://codeshare.io/3AqRkz

    Be gentle.

  • Sounds useful. Is it available on GitHub or somewhere?

  • I think you're just going to have to bite the bullet on this. Every developer will want their own particular requirements and there's no way that Garmin will be able to cater for all of us.

    The current situation is almost out of control with the existing built-in features.

    I have had to cater for these device configurations: 

    • screen shape: round/rectangle (forget octagon!)
    • screen resolution: 218,240…,416
    • Input: touch/button/both
    • CIQ version: CIQ2, CIQ2+
    • watchApp memory size: small, (<130Kb),  big 

    I have built a suite of PHP scripts accessing my manifest and the SDK Devices files to construct my jungles file. It manages my multiple source and resource folders plus a bunch of annotations.

    A lot of work, but it all works like a dream. Unfortunately probably not useful for anyone else.  

    No doubt next year's batch of new devices will require some more coding!