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
    [quote userid="117737" url="~/developer/connect-iq/f/discussion/256721/connect-mobile-4-40-makeimagerequest-localhost-error/1226813#1226813"]

     is 100% correct here.

    All images must be converted to a device-compatible format before they are displayed on device. We have always had a web service for this, and for some reason GCM/Android wasn't using it. It is my understanding that GCM/Android was updated to remove the built-in image conversion code, and start using the web service as GCM/iOS and other bits of our system do.

    This change was made intentionally so that we would not have to roll a new GCM/Android release in order to add support for new devices. We can roll a small tweak to the service and all clients of the service will be able to properly support them.

    It is not my decision to make as to whether or not this is a bug. It looks like the issue has already been filed. I've added some comments to the issue.

    [/quote]


    You guys know that I spilled lots of negativity and criticism across the forum in the past years. And currently what I feel is only sadness. What a fun would be develop quality and rich apps for Garmin wearable devices. But nothing changed - your team still rushing somewhere without aware what actual developers of your platform needs. And it is not that you don't getting the feedback - you even have dedicated team for that, right? Thanks to critically bad management of your team, it even look from outside that you have zero impact on rest of Garmin technical teams and are getting info from them only when the new products are already out. Do you guys even meet each other on meetings? What drives your priorities is also mystery for most because of that. 

    Trust me, this is not about this particular issue. But I believe case of "my" Locus Map app is good example here. The app which you awarded in last year CIQ awards. In the past 2 years it was "down" for several months in total because of unexpected issues coming from side of Garmin systems/platforms, every time with days or even weeks of waiting for confirmation from your side that you are at least aware of the issue. Sure, the app tries to utilise really wide range of your platform capabilities, but that is not excuse. 

    Because I saw great potential in your platform initially I made brand WearSoft and providing B2B Connect IQ development. That never was reason for you to accept my offer for vide-call tu discuss general needs of clients considering to target to your platform. Interesting. 

    Once you make up your mind how to officially respond to this particular issue, please let us know so we will be able to decide whether to

    • wait for your further update in this topic
    • try to come up with some solution on our side
    • remove affected apps from the store and for the case of paid apps handle the refunds

    Thanks

Comment
  • over 3 years ago
    [quote userid="117737" url="~/developer/connect-iq/f/discussion/256721/connect-mobile-4-40-makeimagerequest-localhost-error/1226813#1226813"]

     is 100% correct here.

    All images must be converted to a device-compatible format before they are displayed on device. We have always had a web service for this, and for some reason GCM/Android wasn't using it. It is my understanding that GCM/Android was updated to remove the built-in image conversion code, and start using the web service as GCM/iOS and other bits of our system do.

    This change was made intentionally so that we would not have to roll a new GCM/Android release in order to add support for new devices. We can roll a small tweak to the service and all clients of the service will be able to properly support them.

    It is not my decision to make as to whether or not this is a bug. It looks like the issue has already been filed. I've added some comments to the issue.

    [/quote]


    You guys know that I spilled lots of negativity and criticism across the forum in the past years. And currently what I feel is only sadness. What a fun would be develop quality and rich apps for Garmin wearable devices. But nothing changed - your team still rushing somewhere without aware what actual developers of your platform needs. And it is not that you don't getting the feedback - you even have dedicated team for that, right? Thanks to critically bad management of your team, it even look from outside that you have zero impact on rest of Garmin technical teams and are getting info from them only when the new products are already out. Do you guys even meet each other on meetings? What drives your priorities is also mystery for most because of that. 

    Trust me, this is not about this particular issue. But I believe case of "my" Locus Map app is good example here. The app which you awarded in last year CIQ awards. In the past 2 years it was "down" for several months in total because of unexpected issues coming from side of Garmin systems/platforms, every time with days or even weeks of waiting for confirmation from your side that you are at least aware of the issue. Sure, the app tries to utilise really wide range of your platform capabilities, but that is not excuse. 

    Because I saw great potential in your platform initially I made brand WearSoft and providing B2B Connect IQ development. That never was reason for you to accept my offer for vide-call tu discuss general needs of clients considering to target to your platform. Interesting. 

    Once you make up your mind how to officially respond to this particular issue, please let us know so we will be able to decide whether to

    • wait for your further update in this topic
    • try to come up with some solution on our side
    • remove affected apps from the store and for the case of paid apps handle the refunds

    Thanks

Children
No Data