• Replies 4 replies
  • Subscribers 18 subscribers
  • Views 132 views
  • Users 0 members are here
Options
Related

isSimulator global variable?

8633535

To develop a WF, I've been using [System.getDeviceSettings().uniqueIdentifier](https://developer.garmin.com/connect-iq/api-docs/Toybox/System/DeviceSettings.html#uniqueIdentifier-var) which is always the same for my simulator. That seems dirty, and because it happens at runtime, it sounds like it wouldn't be optimized out.

Is there something like a global `const isSimulator` I could access and use in if statements so it gets optimized out?

I realize that if I'm trying to optimize performance/memory this is unlikely to be a big enough concern, I'm just wondering if there is a cleaner pattern.

Alternatively, if you have development vs production server, what do you use to tell the watch which one to use? I'd prefer not to expose the development url in the built face, and I would rather not have to manually edit a const before sideloading or uploading to CIQ. The compiler supports a release flag, maybe that can be used somehow?

Thank you Slight smile

  • Yes, in my apps I do use the (:debug) and (:release) annotations. Typically, (:debug) code remains when running in the simulator and when building for side-loading, while the exports for CIQ Store uploads are built as releases and therefore include the (:release) code. For example, you could define a server name as a class constant in two variants, one annotated with (:debug) and one with (:release).

    Sometimes this distinction is not sufficient. For instance, in debug builds you might want to use the app settings in the simulator but hardcode certain values for side-loaded builds, since the app settings cannot be edited there. In that case, you can create variants of properties or classes that hold constants and switch them manually. If you need this often, you can automate it in VS Code with tasks or commands, for example by creating a "Build for sideload" task.

  • in reply to the-ninth

    Wow thank you! Amazing, I had not realized annotations were a feature. For anyone else: https://developer.garmin.com/connect-iq/monkey-c/annotations/

    (:debug) class TestMethods
{
    (:test) static function testThisClass( x )
}

// :debug
// Code blocks decorated with this annotation will not be included in release builds at compile time.

// :release
// Code blocks decorated with this annotation will not be included in debug builds at compile time.

  • in reply to 8633535
    8633535 said:
    Wow thank you! Amazing, I had not realized annotations were a feature.

    Particularly the exclude annotations can be very helpful when building for different device classes without increasing the memory footprint for all of them. For example, you can provide different implementations of certain functions for button-based and touch-based devices, or for round and rectangular screens.