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/

  1. Does that mean that i can only make http request trough the Garmin Connect app ?

  2. 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 ?

  3. Is there any way to check programmatically if the Garmin devies have a built in network support ?
  • Another simulator quirk:

    If you pop a view in the same function where you call Communication.startSync2(), the sync views are pushed to the bottom of the view stack. The sync itself is executed, but the app immediately returns to your current view. The sync views are only displayed later, once you pop the last remaining view of your app.

    This behavior appears to affect only the simulator. On the physical devices I tested, the sync views are displayed immediately, regardless of whether a view is popped in the same function.

    I submitted a bug report for this:  Sync Views Pushed to Bottom of View Stack in Simulator 

  • Another interesting observation:

    On the Epix Pro Gen 2, the response size limit for makeWebRequest to a REST API, resulting in error -402, is significantly smaller when using Wi-Fi sync than when performing a normal request over BLE. This behavior is consistent both in the simulator and on the physical device.

    I also tested this on the Edge 850. On that device, the limit in Wi-Fi mode is higher and appears to be the same as over the BLE connection.

    I am not certain, but this difference may be related to the Edge 850 having more memory available for widgets.

  • so you did find at least one case where your own view stack implementation doesn't agree with the native :)