makeWebRequest behaving differently on watch than simulator?

I've created a successful call to an authenticated service via makeWebRequest on the simulator. All's good, right? Nah. On the watch it's returning with a 400 return code.

When I move the app over to my Fenix 5, the web request fails. I added the openWebPage to see what the url was returning and the url that was sent does not include the params or options (and the response from the server is the same response you get if you hit the url with no parameters.)

What am I missing?

Here's my code:

var url = "api.aerisapi.com/.../" + Math.toDegrees(latlon[0]) + "," + Math.toDegrees(latlon[1]); // set the url

var params = { // set the parameters
"client_id" => "<my_id>",
"client_secret" => "<my_secret>",
"filter" => "1hr",
"limit" => "12",
"fields" => ["periods.timestamp","periods.pop"],
"from" => "now"
};
var options = { // set the options

"Content-Type" => Communications.REQUEST_CONTENT_TYPE_URL_ENCODED
};
var responseCallback = method(:onReceive);

Communications.openWebPage(
url,
params,
options
);

Communications.makeWebRequest(
url,
params,
options,
responseCallback
);


And here's the url openWebPage asks for:

https://api.aerisapi.com/forecasts/34.088840,-84.193510

And here's the response I get:

{"success":false,"error":{"code":"invalid_client","description":"A valid \"client_id\" and \"client_secret\" were not provided."},"response":[]}

Any ideas?

  • do you see 400 or -400?

    if the openWebPage has a problem, I'm just skip that as it's not needed (I can't recall anyone posting a question about openWebPage before)

    The one thing that looks a bit odd to me is the "fields" param, as I'm not sure what happens when you're passing an array. What does the doc for the API say that param should look like?

    update: Oh, the other thing, are you using Android or iOS on your phone? It could be that what you're doing works on one but not the other.
  • Jim,

    good questions. I’m actually receiving a “400” response which I’m assuming is coming from the server (as I interpret the doc to say that the connectIQ web methods would return a -400.)

    Youre right in the fields params: it does look odd, but I’ve confirmed this is correct through documentation and other memeber’s posts, but more importantly it works correctly in the simulator.

    So, that brings us to the real question: why doesn’t it work on the actual watch?

    Im using an iOS device for my internet connection. Perhaps that’s an issue, but I have other apps installed that successfully make web calls... so it’s obviiusly something I’m doing differently.

    When i I get a few minutes, I’m going to try removing the array from the fields param and see if I get a successful call.

    In in the meantime, I’m curious if anyone had any recommendations on him to better verify the actual web call that’s being made by makeWebRequest than by using openWebPage?
  • What does the API doc say "fields" should look like? It might be safer if you could just use a string, as something like how the array is handled could differ between the sim, iOS and Android. In the sim, are you on a PC or Mac? Your app could work fine with Android and the sim. I've seen cases like that in the past.

    For example, would

    "fields" => "[periods.timestamp,periods.pop]",

    work per the API doc?

    Maybe first try commenting out the line for fields and see if you still get the error, as there might be another cause.
  • In in the meantime, I’m curious if anyone had any recommendations on him to better verify the actual web call that’s being made by makeWebRequest than by using openWebPage?


    Try using a proxy such as Fiddler (PC/Mac) to capture the traffic between the phone and the site:
    https://docs.telerik.com/fiddler/Con...onfigureForiOS
    http://docs.telerik.com/fiddler/Conf...gureForAndroid

    I haven't used Fiddler for mobile debugging, but I can confirm it works pretty great for desktop development.

    Or if you don't need a response from the real site, just configure a local web server on your PC/Mac and temporarily change the URL of your web request to point there. (That won't take you as far as using a proxy, though). Then you can look at your server logs and/or use Wireshark to trace local network traffic.

    (I was also curious about the array in params. Looking at the doc, it's really not clear how an array value in the params dictionary, as opposed to a string value, is supposed to be translated to a URL parameter. Comma-separated values? Repeated keys? JSON-encoded array? I'm sure if everyone's using it, it works, but it's just another thing I wish the docs were clearer on. The doc says to use a dictionary, but says nothing about how values of different types are to be treated.)
  • Jim,

    You nailed it. The app works a bit different on the fenix5/iOS than it does on the sim. I re-checked the aeris API doc and (again, you nailed it :cool:) I didn't need the array -- somehow I had convinced myself that the more complicated array was necessary, but a string works perfectly on both the sim and on the fenix5/iOS combo. Sending mucho kudos your way.

    FlowState, I haven't had a chance to try your method, but so good to know! I'm quite sure I'll have a change to try it soon ;-).
  • Glad I could help!

    Hey, by any chance, did you still have openWebPage() called when you tested? I'm curious if the change to "fields" also cleared up that issue. If not, no need to go back and try, but if it didn't resolve that, maybe submit a bug report in that subforum.