Simulator Randomizer

Interesting idea. For my apps, I've just created a test mode where I interject the values rather than using the ones I get from the randomizer. Sometimes random, sometimes an array of values I know I want to test, sometimes just a simple offset (like dog locations from a Garmin Alpha for showing my track and that of the dogs on a map). Gives me full control over the data I'm using. This is particularly necessary when dealing with Ant+ channels that aren't directly supported by the devices. Doing as you suggest might get overly complicated and still not satisfy everyone.

Yeah, would not want it complicated. Default behavior would simply be as it is today. For advanced control, you just select a metric (eg: POWER), and then can enter in 3 values. AVERAGE, VARIANCE, and DRIFT. That's all. Not complicated. Probably not sufficient for some uses. But certainly helpful for many.

Sure it wouldn’t be complicated for the end user (devs). Maybe.

But as we know, every change they make has to be tested, in both the UI and functionality, possibly across the full range of devices.

Whaf if someone enters 99999 or -1 for average power. Do they have to support entering either speed or pace? How about units? Should the sim values be based on device units? Everything has to be validated and end user-friendly now.

Cool idea, but I don’t see it happening. I do think it’s annoying how every device seems to have slightly different sim ranges for things like pace, and how running paces are often not realistic.

I'd just like to add that having your own test code lets you test it on actual devices as well. Anything added to the simulator is simulator only. And simple code is never simple code from my 35 years of programming experience.

Yep. The simplest change can break something, and to be frank, there have been enough bugs in the simulator without any extra functionality.

Theres really no reason you can’t just hardcode/generate your own data unless you’re out of memory or something, in which case you can temporarily comment out some other code you’re not testing.

Unit tests through run no evil give you peace of mind (read my blog on the topic).

preferably I'd like to see the connect iq framework evolve to running the impacted unit tests automatically but currently we're a long wat of from that (being able to run the unit tests without a Simulator instance would be a first step in the right direction)

peterdedecker I would also like to see the opposite: run the simulator automatically, for the whole range of devices, in a normal app context. i.e. not unit test, but system/integration test.

I want to be able to script the simulator so I can test an app / data field for all devices without doing it manually. It would be ideal if we could script the config, too.

The default UX just for launching the simulator and selecting a target is not ideal. Especially with how when you save settings, the sim likes to reset your settings to default unless you kill the app first. (Here I'm referring to a data field).

But you can't load settings without having a running app first (assuming you have different settings schema per-platform), because you can't select the build target on the app settings page. I'm also fairly sure that you won't get the correct (non-default) settings unless the device is running, too.

So the workflow is:
- Run app for given device
- Get settings
- Make settings changes but don't you dare save yet
- Kill app
- Save settings
- Run app for given device, again

Six steps to do something which should take 3 or 4.

Run configurations are better, but once you set one, you lose the ability to choose on the fly, so you'll have to create a run configuration for every target / family, for every project. So once again if you have significant differences per-platform, it's useless / impractical.

(I really, really, really hope there isn't already a way to do this >_>)

For me it's the stuff that isn't in the fit file that is of issue. Lately it's been accelerometer data. But more often it is data that I get directly from devices through the Ant+ interface. Like running footpod data specific to Runscribe, or data from a Ant+ Tracker profile with information about dog distance and location. This just shows more that anything that gets implemented in the simulator will have it's limitations and people will constantly want more.

You do need to run the app once in the sim to do the app settings editor. The first time it's run, the <your app>.set file is created with the default properties in the \apps\garmin\settings\directory and that's what the app settings editor in eclipse uses for the current settings. I have no idea why "Kill app" is needed unless you exceed available memory when you change settings. I change settings in currently running apps literally all the time. It's how you test onSettingsChanged logic.

1) These are datafields I'm referring to, to be clear

2) I don't implement onSettingsChanged() logic in my datafields, because usually:
2a) My datafields are too close to the memory limit to have the luxury of that code
2b) If your datafields track metrics which are selectable in settings, things like lap metrics and activity averages can't be really be selected after an activity starts, because they have to be calculated from the beginning of the activity. On the same token, no datafield that tracks lap metrics will work 100% properly if you add it after the activity is started. So for those settings, implementing onSettingsChanged won't really work properly in many cases.

3) I have the problem of settings being reset to default all the time, even on the large memory platforms with lots of memory available. The only way I can be sure settings won't be reset to default is to kill the app before saving settings.

I think the problem is that I implement conditional settings per-platform, to include, exclude and modify available options based on the platform. This might have something to do with the problem I am seeing.

Running the app once before loading is very annoying when rapidly switching between different platforms. e.g. I might have different feature sets for CIQ1, CIQ2 small memory and CIQ3 / large memory. I might have additional feature sets for multisport versus non-multisport. Coupled with the reset behaviour I am seeing, it's at least 5 steps per family / feature set just to test one change to settings that affect multiple families. Again, it's

1) Run app just to ensure the build type is correct
2) Load settings
3) Kill app
4) Save settings
5) Run app and test
6) Go to 1) for next device/family

I have also seen an issue where settings are not accepted no matter what I do. In that case, I just give up and hardcode the settings I want to test in the properties xml. Unfortunately I don't know how to recreate this.

I would like for the settings dialog to have a drop-down for device type, beside the Rebuild checkbox. What's the point of rebuilding if you don't know what device will be built? Or even worse, if it's the default build? That only works when your settings don't change based on device type.

This goes back to an earlier comment I made where I suggested that the default build should always have a device type associated with it.

As it is now, I have to set up "dummy" defaults for the default build, as if it were targeting a specific device type.