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.

ArsonLarna
Parents
  • over 3 years ago

    So let me rephrase it and correct me if I am wrong:

    - CIQ team didn't document properly how makeImageRequest is working so
    - CIQ team wasn't aware that makeImageRequest was internally using local image conversion of GCM (even if it was discussed several times before)
    - CIQ team find out about recent change of GCM only after several days of researching what happened based on DEVs reports
    - DEVs during development of their project correctly followed your documentation and didn't violate anything against it
    - CIQ team decided to handle the issue by leaving all unexpectedly broken apps in their current state reasoning it is good for improving the service. 
    - DEVs should now come up with some reason for their users and remove affected apps from the CIQ Store
    - in some cases DEVS should somehow handle refunds in the costs way more than your monthly salary

    If this is correct, you really don't find it as total amateurism and insult to the developers? No apology, just chaotic plain statement and go on?

    Lots of companies have system issues which at least some of their employees tries to compensate within their roles in the company. Based on your communication, you are just another piece of the puzzle of bigger issue and your avatar is unhappily relevant, sorry.

    One might really ask why do you all doing that or what is really purpose of the CIQ platform: 
    - Focusing on big partners? Even the apps of you biggest partners suffers a lot from the state of the platform and one can easily see that even on their users review. Few of them had to be already migrated to solution not utilising CIQ. 
    - Focusing on extended value of Garmin product for your customers? So why to piss of even smaller developers like that all the time? 
    - Just to check top-management bullet to have solution for third party content? Then why bother to still rushing with new CIQ major versions and releasing untested builds even after negative feedback from your test team? 

    It is obvious that even you guys don't know this. Proof me wrong please. Or don't bother, but in this case, let also us to don't bother...

Comment
  • over 3 years ago

    So let me rephrase it and correct me if I am wrong:

    - CIQ team didn't document properly how makeImageRequest is working so
    - CIQ team wasn't aware that makeImageRequest was internally using local image conversion of GCM (even if it was discussed several times before)
    - CIQ team find out about recent change of GCM only after several days of researching what happened based on DEVs reports
    - DEVs during development of their project correctly followed your documentation and didn't violate anything against it
    - CIQ team decided to handle the issue by leaving all unexpectedly broken apps in their current state reasoning it is good for improving the service. 
    - DEVs should now come up with some reason for their users and remove affected apps from the CIQ Store
    - in some cases DEVS should somehow handle refunds in the costs way more than your monthly salary

    If this is correct, you really don't find it as total amateurism and insult to the developers? No apology, just chaotic plain statement and go on?

    Lots of companies have system issues which at least some of their employees tries to compensate within their roles in the company. Based on your communication, you are just another piece of the puzzle of bigger issue and your avatar is unhappily relevant, sorry.

    One might really ask why do you all doing that or what is really purpose of the CIQ platform: 
    - Focusing on big partners? Even the apps of you biggest partners suffers a lot from the state of the platform and one can easily see that even on their users review. Few of them had to be already migrated to solution not utilising CIQ. 
    - Focusing on extended value of Garmin product for your customers? So why to piss of even smaller developers like that all the time? 
    - Just to check top-management bullet to have solution for third party content? Then why bother to still rushing with new CIQ major versions and releasing untested builds even after negative feedback from your test team? 

    It is obvious that even you guys don't know this. Proof me wrong please. Or don't bother, but in this case, let also us to don't bother...

Children