HTTP request over device Wi-Fi specification

I was reading in the documentation, regarding the http Communications moudule, that:

"Monkey C exposes a high level APIs to allow calls to basic web services through Garmin Connect Mobile"

Soruce: https://developer.garmin.com/connect-iq/core-topics/https/

Does that mean that i can only make http request trough the Garmin Connect app ?
By trying to make a http request with the Communications modules on a simulated device i've notice that i'm able to make a succesfull request even when i'm not connected to a phone device. Does that mean that i can also make a htt request over the Garmin device Wi-fi without passing trough the Garmin Connect app ?
Is there any way to check programmatically if the Garmin devies have a built in network support ?

Top Replies

All Replies

0 RodolpheDumesnil 16 days ago in reply to the-ninth

That's it.

Communications.startSync();

As I remember, there is an exemple in the toolkit.

0 the-ninth 7 days ago in reply to RodolpheDumesnil

RodolpheDumesnil said:
That's it.

Communications.startSync();

Thanks! How do you detect when no BLE connection is available? I couldn’t find a direct method like Communications.checkWifiConnection() for Wi-Fi. Is the only option to use Communications.makeWebRequest() and check for specific error codes?

Also, another question: the HTTPS requirements differ between iOS and Android. Do you know how it works with Wi-Fi connections? Is plain HTTP allowed, or is HTTPS with a valid certificate always required?

0 FlowState 7 days ago in reply to the-ninth

See:

- DeviceSettings.phoneConnected (BLE only)

- DeviceSettings.connectionAvailable and DeviceSettings.connectionInfo (BLE, WiFi, LTE)

Note that in this context, "BLE connected" / "phone connected" really means "BLE is connected and Garmin device is connected to the Connect phone app". (iow if your device is connected to the phone but Connect is closed, these fields will indicate that BLE is not connected)

This differs from the controls menu which is able to distinguish between the following 4 BLE states:

- BLE disabled

- BLE enabled, but no BLE connection

- BLE connected, but Connect closed

- BLE connected, and Connect open

0 the-ninth 7 days ago in reply to FlowState

Thanks!

So, phoneConnected tells me whether making a web request via BLE is possible.

How does connectionAvailable relate to this? If it's true, does that mean I can make a web request immediately? Or could it also be true if, for example, a Wi-Fi connection is available, but I still need to put the app into sync mode before I can use it?

0 jim_m_58 6 days ago in reply to the-ninth

It can depend on the device. For example, on at least some edge devices, it tries to establish wifi as soon as you turn it on. as it does with a phone connection, but will drop wifi as soon as you start recording. When wifi is connected, that can be used by CIQ with no additional code/logic

What I've done for years is just do the makeWebRequest with no checks but then I pay attention to the responseCode for the call. The phone could be connected, but it doesn't have a data connection, or there could be a data connection but the server isn't available. All different errors, but the result is basically the same and need to be handled.

Depending on what you are doing, forcing wifi night not be the best option. There's time involved for scanning for wifi and connecting to a wifi network, where that can take longer than just using BLE. Wifi is generally there for big things, like FW updates and music downloads And it also requires more battery

Requiring wifi means you can't support watches without music

0 the-ninth 6 days ago in reply to jim_m_58

jim_m_58 said:
Depending on what you are doing, forcing wifi night not be the best option. There's time involved for scanning for wifi and connecting to a wifi network, where that can take longer than just using BLE. Wifi is generally there for big things, like FW updates and music downloads And it also requires more battery

In my app, Wi-Fi would be an additional feature layered on top of the phone-based connection. The goal is to use the phone connection if it’s available, and fall back to Wi-Fi if it’s not.

I’m already aware that using Wi-Fi requires setting up a sync delegate and related components, but for now, I’m focused on how to best decide when to trigger the fallback.

My initial idea—same as the approach Jim described—was to make the makeWebRequest using the phone connection and, based on certain response codes, attempt to fall back to Wi-Fi. That still seems like a reasonable approach, but I wanted to check if there’s a cleaner or more reliable way to detect the need for fallback before going further down that path.