Complete
over 3 years ago

WERETECH-10904

We don’t plan to revert this change to Garmin Connect Mobile because it was not a documented requirement that the makeImageRequest API work with a mobile service, but we will consider the use case for future API improvement.

Connect Mobile 4.40 makeImageRequest localhost error

Hello, I have a small Garmin app, that connects to my Android phone who has a running http server that serves png images by url get encoding: Example http://127.0.0.1:9977/?imageId=9154752

So far, everything was working like a charm, but after updating to Android Garmin Connect Mobile 4.40 it stop working. The makeImageRequest returns a BLE_HOST_TIMEOUT as a responseCode and never downloads the image. Also debugging the Android http server, never receives the request for any picture. (Other requests such as webRequests are properly received as explained bellow, but not imageRequest)

 // Set up the responseCallback function to return an image or null
    function responseCallback(responseCode, data) {
        responseCode = responseCode;
        if (responseCode == 200) {
            image = data;
        } else {
           System.println(Lang.format("Error code $1$",[responseCode]));
           image = null;
        }
    }

    // wrap the request in a function
    function requestImageinGallery(imageId) {
        var url = "http://127.0.0.1:9977/";           // set the image url
        var parameters = { "imageId" => imageId};     // set the parameters
        var options = {                                         // set the options
            :palette => [ Gfx.COLOR_ORANGE,                     // set the palette
                          Gfx.COLOR_DK_BLUE,
                          Gfx.COLOR_BLUE,
                          Gfx.COLOR_BLACK ],
            :maxWidth => 200,                                   // set the max width
            :maxHeight => 200,                                  // set the max height
            :dithering => Communications.IMAGE_DITHERING_NONE   // set the dithering
        };

        // Make the image request
        Communications.makeImageRequest(url, parameters, options, method(:responseCallback));
    }



The makeWebRequest works perfectly and receives the response from the the httpServer as is running.

 function checkIfServerIsRunning() {
      
  var url = "http://127.0.0.1:9977/";           // set the image url
  var params = { "check" => "isAlive"};     // set the parameters

   var options = { // set the options
    :method => Communications.HTTP_REQUEST_METHOD_GET, // set HTTP method
    :headers => { // set headers
    "Content-Type" => Communications.REQUEST_CONTENT_TYPE_JSON}, // set response type
    :responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_JSON };
    
    Communications.makeWebRequest(url, params, options, method(:onReceive)); }



Can anyone help me?

PS: I did create a small webserver ngnix/node.js online to test it, with the same configuration as my android HttpServer. And accessing it by IP, same as above with (just changing the ip), with same port number, and request parameters, it works perfectly. There must be something with 127.0.0.1 that is blocked (I also tested with http://localhost, and does not work either).

Thank you in advance.

Parents
  • I've seen that the original discussion was closed, but it is not clear for me that this is solved or an acceptable answer.

    Please do not take this comment as directed to you, as I am aware by your comment that it is not your direct responsibility or your department.

    But it is not clear to me that Garmin is taking responsibility or guaranteeing a solution to this unilateral change. What about all the apps affect by this decision? Why is Garmin deciding this kind of changes without informing or taking developers into consideration?

    From my point of view, this kind of changes should be announced with at least 4 months in advance, so developers could foresee this changes and adapt their apps to them. Also it seems there are apps that users have paid for, What this developers should do if they can't serve the promised service or product due to this changes?

    Please we need solution so the apps could keep on working as they were before. And keep working in the future

Comment
  • I've seen that the original discussion was closed, but it is not clear for me that this is solved or an acceptable answer.

    Please do not take this comment as directed to you, as I am aware by your comment that it is not your direct responsibility or your department.

    But it is not clear to me that Garmin is taking responsibility or guaranteeing a solution to this unilateral change. What about all the apps affect by this decision? Why is Garmin deciding this kind of changes without informing or taking developers into consideration?

    From my point of view, this kind of changes should be announced with at least 4 months in advance, so developers could foresee this changes and adapt their apps to them. Also it seems there are apps that users have paid for, What this developers should do if they can't serve the promised service or product due to this changes?

    Please we need solution so the apps could keep on working as they were before. And keep working in the future

Children
  • "I've seen that the original discussion was closed, but it is not clear for me that this is solved or an acceptable answer."

    I closed the original thread since we moved the conversation here and marked Travis' response as the answer because it explains the current situation. I did not intend for that to me that more will not be done or that we won't consider solutions. :) I'll clarify that on the other thread. I simply wanted to keep all future discussion regarding this issue in one place, on this bug report.