json from resource

Thanks for posting this script! Looks very useful

I have one analog watchface right now that works on every watch Monkey C supports that is at least CIQ 1.3, and it has one jungle file that I don't need to touch just because new devices come along. The only thing in the jungle file of consequence are the devices that don't support background so I have an exclude annotation for them. That works for me. Just as others have pointed out before, "has" solves most compatibility issues.

Maybe if I decide I have a need for an app I can't find in the store that suits me then I'll give another app a go. The new "give out your email to the world" thing is a little off putting, and the bugs I've found that just won't be fixed (like makeImageRequest) doesn't inspire me either.

It seems to me that using a tool to maintain jungle files isn't much different than maintaining jungle files, so we'll just have to agree to disagree about that.

you still haven't read or understand my comments IMHO

Just because I don't agree doesn't mean I don't understand. Your tool is over a thousand lines long and has thirtyish support files. Per the history you've been at this over a year. Now, the latest SDK's have somewhat working form for editing the manifest.xml. It would be nice if someone could do the same for the jungle file. Is this where you are headed?

I've been doing apps since long before jungles even existed, and to this day, I keep my jungles files very simple.

A big change was actually moving from eclipse to VSC.  eclipse had it's own links that you could pull shared code into an app that way.  With VSC, I use jungles to do that.  The way I did it was to start with a file that referenced my shared code and then a series of lines where for a given app, I simply had to uncomment a single line to pull in what that app required.

Like this:

###############################
#watchfaces, etc
###############################
#using fields and sun
#base.sourcePath=$(srcBase);$(barClkFields);$(barClkIcons);$(barClkMisc);$(barClkSettings);$(barClkSun)

#using goals
#base.sourcePath=$(srcBase);$(barClkGoals);$(barClkIcons);$(barClkMisc);$(barClkSettings)

#using goals and sun
base.sourcePath=$(srcBase);$(barClkGoals);$(barClkIcons);$(barClkMisc);$(barClkSettings);$(barClkSun)

The other thing I use jungles for is some significant items, such as complications, on-device maps. and B&W displays (instinct2)

When a new device is added with complications, it's copying a single line and pasting it with the new device. Like this:

No. I confused you by showing the generator. BEFORE THAT (https://forums.garmin.com/developer/connect-iq/f/discussion/283853/json-from-resource/1740322#1740322) I gave you a static example that doesn't need any changes to the jungle file from now until the end of the world.

andyj713 said:

I'll just keep doing it the hard way. One resource file for everyone, and a dozen lines of code to parse a string into an array that only needs to run at app start.

JSON resources are very useful for memory-constrained applications, like data fields, as they have the lowest overhead of any other alternative, including the string parsing approach (which I've also used.)

There's plenty of devices which support CIQ >= 2 but still have a very low amount of memory available for CIQ data fields.

If memory isn't that tight, then I don't see a problem with string parsing except for the possibility that the watchdog timer could be tripped if you have large amounts of data to parse.

I'm not using data fields. It's an analog watch face with analog indicators for data and events. The problem for me isn't  json vs string, I'd definitely use jsonData if all watches could because it is a lot easier. However having one way to initialize an array is easier than having two. The real problem is that communication isn't available to watch faces before CIQ 2 (needs background). It looks to be another unsolvable problem where I get a feature working then find out I can't actually use it on a watch face because of a permission limitation.

You sound like going through similar "steps" like I had with my DF. I did everything in my power to keep the minApi on 1.2.0 to support as many devices as possible. It does have it's toll though. I wasted lot of time on that which is partially fun, but the same time also could've been used in better ways. 

Anyway some tools I use are:

Prettier Monkey C: it's an optimizer that enables both to squeeze more features for older devices and to learn some tricks how to write "better" (aka smaller when compiled, run) code. It also has a nice syntax highlighting feature.

Jungles - at the beginning manually edited them. It definitely helps for example in the last thing you mention: to keep the app small by having only the real code that each device actually uses. For example instead of having: if (A has :b) {...} else {...} I only include the relevant code which saves both the unnecessary code block and the if. (With SDK 7 it seems like we'll have some of this optimization for "free")

One of the biggest problems I have is psychological: if I knew how many users (or even just a rough percentage) use "old" watches it would give me the power to decide not to support them. For example I have some function that uses String.toCharArray. In one of my apps I do have another function to use instead. But do I even have 1 user out if 150k who uses it on epic? I have no idea, though probably no. So if I didn't have this "FOMO" I could just increase the minApi level and save me lot of complexity and time.

One place I do use jungles that I am "proud" of is to have the exact settings for the device. Lots if watchfaces I know have some settings with labels like "Feature foo (on supported devices)". I hate these, and in my apps I try to only display relevant settings to the user .