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.

  • 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...

  • Alright, here's the final verdict. We are unifying the underlying image conversion to all work under a unified service which will help us maintain and improve the service. Unfortunately, we weren’t aware that using localhost for image requests is a use case for this API. 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.

  • "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.

  • There doesn't seem to be any simple and quick workaround available by using makeWebRequest() to fetch a bitmap resource from localhost. Even if I do try to encode the bitmap into Base64 string on my server side and receive the bitmap through plain text using makeWebRequest(), it doesn't seem to be possible to convert that byte array into a BitmapResource to be able to be drawn on screen using drawBitmap(). My bitmaps are always 1-bit in my app so what if I can encode it in my way and draw it using drawPoint(), but even by thinking of it I feel it's very ridiculous. I as a CIQ developer I feel ashamed I even chose to develop on this platform. Frustration everywhere.

  • [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