Expense of DeviceSettings calls?

Thanks Jim! Makes sense and an easy fix!

System.getDeviceSettings() is pretty expensive, but calling it once an update won't be horrible. I would recommend not calling it more than once an update though. I've seen that done and it can really bog things down.

DaveBrillhart said:

if (devST has :phoneConnected) { ...}

I don't think this check is necessary at all, as DeviceSettings.phoneConnected is available since CIQ 1.1, and there's no CIQ device device type / part number which is configured to have less than CIQ version 1.2.1. Even if a device with CIQ < 1.1 existed in the wild, it wouldn't be able to install your app. (There's also no CIQ 1.* Edge devices afaict.)

You may also be able to do if (System.DeviceSettings has :connectionAvailable ) {}? That may be able to benefit from compile-time optimization with the latest sdk, but I'm not sure if it would or not

I don't understand. I want to show an indicator in my field when the EDGE device is connected to Garmin Connect Mobile. This is needed to detect if/when the EDGE is no longer connect to GCM during the activity, right? You seem to suggest there is a different/better approach? Help me understand.  Thanks!

FlowState IMHO is suggesting that there's no need for the runtime check, because practically all devices support it. He's not suggesting not to call the function. Of course you'll need to call it to determine if it's connected or not.

Yeah, I meant that the has check for :phoneConnected in DeviceSettings (or a local variable of that type) is unnecessary, not the (implied) check of the phoneConnected field itself. Sorry I wasn't clear on that.

Of course if you change your code so that the DeviceSettings has checks are only ever executed once, then it doesn't really matter whether you have a redundant check or not. (Unless you really need to save a handful of bytes in code.)

And if you enable compile-time optimization (as suggested), then any redundant has checks will probably be removed anyway (especially if the code is rewritten to perform has checks against the DeviceSettings class itself, as opposed to a variable of that type).

It was just more of a comment on code readability.

I mean, we could all write has checks before we access any field in the CIQ API, and it might not even make a difference as far memory and CPU usage go, as long as optimization is enabled, and as long the device configuration file is set to remove has checks at compile time - as discussed in another thread, this does have to be enabled by Garmin, and it isn't necessarily enabled for all devices (yet). But it would definitely make a difference as far as code readability goes.

EDIT: to be clear if I were writing a new app, I wouldn't use that has check. If it's an old app / codebase from like 2015, where the has check might have actually been necessary, then that would be a different story. The has check would still not be necessary for any new versions (since you can't build an app that will install on a 1.1 device now), but it would be understandable to have the check in old code.

Got it. Thanks. In hindsight that was clear. I did change it to only execute the "has" once. But great tip.

Stepping back a bit, why are you using phoneConnected and connectionAvailable?  Is it to display something in your app, or is it in relation to something like a makeWebRequest?

(don't do the makeWebrequest if there's no BT/Wifi/LTE)

What you can do is just skip the check in your app, always do the makeWebRequest, and check the error status in it's callback.  -104 will indicate there's no connection, and you just handle it like any other error you may get when doing the makeWebRequest

An example could be you are connected to your phone just fine, but your cell service dropped or is really spotty, you'll get a different error, but you want to handle it in pretty much the same way.