Connect version 4.20 broke local http access?

Hello Stephen, 

according to my knowledge lots of the apps using local http communication are based on nanohttpd webserver just like the open sourced gimporter app: 
https://apps.garmin.com/en-US/apps/de11adc4-fdbb-40b5-86ac-7f93b47ea5bb
https://github.com/gimportexportdevs/gimporter

Uses cases are nicely visible here. Http is used both for sending JSON data and also for supported binary data (courses). I believe its commonly known how much are  requested apps allowing users to import content to their garmins directly from their phone. In this case all must be initiated on Garmin device by the user. Those JSON data should be able to be transferred also via phone messaging but then it will not work with the edge and other devices which doesn't support them unexpectedly from some time ago. 

In case of our Locus Map for Garmin app we spent lots of time to implement connectivity via phone messaging only to realise that it keeps failing for periodically sent data (https://forums.garmin.com/developer/connect-iq/i/bug-reports/failure_during_transfer) in real world. So now we are using hybrid comm via http in phone>android and Android SDK in other direction and also for wake up app from the phone. Via HTTP server in android we are transferring lots of datasets via JSON, FIT courses, and in near future image data. The architecture of the this connectivity is massively affected by abilities of CIQ.

Of course having remote http server on the internet is not the option for this kind of app as it is connecting to other API service in the phone and because it must maintain app to work even without access to internet. For now Locus Map for Android is supported only by watches which supports Android SDK and we are still trying to figure out how to port it to edge devices without loosing its features.

If there will be considered to add exception for local communication to GCM as used on other platforms, what time frame we can expect? Days or weeks? Thanks

Hello Stephen, 

according to my knowledge lots of the apps using local http communication are based on nanohttpd webserver just like the open sourced gimporter app: 
https://apps.garmin.com/en-US/apps/de11adc4-fdbb-40b5-86ac-7f93b47ea5bb
https://github.com/gimportexportdevs/gimporter

Uses cases are nicely visible here. Http is used both for sending JSON data and also for supported binary data (courses). I believe its commonly known how much are  requested apps allowing users to import content to their garmins directly from their phone. In this case all must be initiated on Garmin device by the user. Those JSON data should be able to be transferred also via phone messaging but then it will not work with the edge and other devices which doesn't support them unexpectedly from some time ago. 

In case of our Locus Map for Garmin app we spent lots of time to implement connectivity via phone messaging only to realise that it keeps failing for periodically sent data (https://forums.garmin.com/developer/connect-iq/i/bug-reports/failure_during_transfer) in real world. So now we are using hybrid comm via http in phone>android and Android SDK in other direction and also for wake up app from the phone. Via HTTP server in android we are transferring lots of datasets via JSON, FIT courses, and in near future image data. The architecture of the this connectivity is massively affected by abilities of CIQ.

Of course having remote http server on the internet is not the option for this kind of app as it is connecting to other API service in the phone and because it must maintain app to work even without access to internet. For now Locus Map for Android is supported only by watches which supports Android SDK and we are still trying to figure out how to port it to edge devices without loosing its features.

If there will be considered to add exception for local communication to GCM as used on other platforms, what time frame we can expect? Days or weeks? Thanks

And 2nd important thing to add to my elaborate: Using web server for such local communication is of course really far from ideal as having running web server all the time in the background in mobile platform is exactly the thing what nobody wants. So there comes the tricks how to wake up the web server from user input in Garmin device - a discipline on its own.  I believe this should be put also in consideration when thinking about this topic. 

I forgot to mention, I can speak only about Android platform - doesn't have experience with iOS yet..