HTTP/TCP Connectivity in SDK

The only functionality for accessing data over the web is in the Toybox.Communications module. The two big methods are makeJsonRequest() and makeImageRequest(), and both of these use the Garmin Connect app on a mobile device as a proxy. You have control over the request url and the parameters; everything else is controlled by the framework. This should be sufficient for most needs, but may require you to write a web service that translates from an HTTP get request with parameters to whatever the service you are communicating with expects.

Other than that, there is the mailbox stuff in the same package. It doesn't really allow any more control as far as I can see, so I see no advantage for using this over the provided methods mentioned above.

Travis

thanks for the info! is that limitation by design, or will it be possible to create fully connected web/internet apps in later versions? it seems to me that you're cutting off a huge chunk of very cool and useful and engaging app ideas by limiting the functionality this drastically. after all, the 920xt has wifi and could happily talk to the world on its own, right?

I have serious doubts that you ever see lower level communications from ConnectIQ. Unless you have plans to implement a web browser, I don't see this limitation as cutting off much of anything. There are tons and tons of services that provide their data in JSON format. As mentioned above, if you're trying to interact with a service that doesn't provide a JSON interface directly, you should be able to easily write an intermediary app that does the translation.

Travis

it's useful (but also sad) to know that there will be only very limited connectivity in the SDK. one reason why people usually don't want to go through forced proxying is the lack of privacy and security. another one is that in today's networked world, developers simply expect to be able to connect through internet and web mechanisms, and not through one single channel that is prescribed (and fully monitored) by the environment.
personally, i don't understand why garmin would restrict the connectivity this heavily (now that the hardware is very capable and programmable with apps), but that decision is probably made in a way that has nothing to do with technical features or abilities.

one reason why people usually don't want to go through forced proxying is the lack of privacy and security.

Like I said, if you don't like communicating through the Garmin Connect application using the two provided functions, you have the option of implementing your own proxy app on the smart device or as a web service that speaks json on one side and HTTP on the other. If you control the implementation of both the ConnectIQ app and the proxy, there shouldn't be many fears about privacy or security.

personally, i don't understand why garmin would restrict the connectivity this heavily

I think this is where the we are disagreeing. Garmin isn't prohibiting you from getting what you want. They just aren't giving it to you for free. If you believe that the functionality is necessary (I'm not yet convinced that it is), then the implementation of a proxy application should not be a concern.

Related to this thread, will makeJsonRequest() in the future be able to set HTTP headers using the (undocumented) 'options' dictionary please?

My use case is to be able to set the HTTP If-Modified-Since header on the JSON request, so that server resources that haven't changed since the previous request can return 304 Not Modified. This is particularly important for saving bandwidth and improving response time on mobile connections.

For this to work, we'd also need access to the HTTP response headers, to read the Last-Modified response header. e.g., via an optional argument to 'responseCallback'.

Thanks

thanks for the info! is that limitation by design, or will it be possible to create fully connected web/internet apps in later versions? it seems to me that you're cutting off a huge chunk of very cool and useful and engaging app ideas by limiting the functionality this drastically. after all, the 920xt has wifi and could happily talk to the world on its own, right?

To get the kind of power numbers necessary to allow ultra-marathoners to record 48 hours of GPS, the 920 platform is very very small. The system has 256 KB of total RAM, and the system uses about 130 KB of it. Also, BLE has a transfer speed of about .8 KB a second. My usual joke is "You don't have any memory, but it's okay because you don't have any bandwidth either."

The use cases for our products are focused: triathletes/swimmers/utlramarathoners (920), runners (220/620), and outdoors people (Fenix). I think CIQ will bring a lot of value to these products outside of the use cases. CIQ isn't allowed to override the main use case though. A device for ultramarathoners can't get more powerful resources if it prevents the product from serving the ultra-marathoner use case.My thought has been that for more rich internet access using the mailbox interface with a partner app would be necessary. This isn't out of line with what Pebble or Apple are doing, though Pebble did a lot to improve internet access in SDK 2. The JSON/image APIs are definitely step one, but we're trying to figure out what the next step is considering what we have to work with.

-Alpha Monkey