Weird URL creation behavior on some devices - CIQ crash

In my WUradar widget, I am experiencing some weird behaviour on certain devices, like the Edge 1000, Oregon 750 and possibly others, with how the URL is being created for retrieving the image. I am using the following line of code to build the URL for the makeImageRequest command.

var imgurl="api.wunderground.com/.../image.gif

wuapikey is pulled from the app setting and is provided by the user and is required by weather underground to get the image.
latlog array is the taken from the device position
imgzoom and imgradunits are look up arrays which provide the zoom level options where zoomindex and unitindex are taken from the GMC settings to determine what zoom level is used in the request.
scrwdth = getWidth()
scrhgth = getHeight()

All of this works fine in the simulator. I can go in and use the set application settings in the eclipse plugin and check the settings for each zoom level I have configured and the simulator is able to retrieve the image and display it. I have pushed this out through the store, and have been able to get the application to run successfully at all zoom levels on my FR230. The weirdness starts when I try to run the app on my Edge 1000. When the zoom level for 5 units is selected on the Edge 1000 zoomindex=0, I get a IQ! On the display. All other settings for the zoom level work without issue. I am still working through some additional troubleshooting steps, but first thing I did was to create a test build to side load so I can set up debugging. Using the following to select the zoom level used in the URL.

var imgzoom = [5, 10, 15, 20, 25, 50, 75, 100];
var imgradunits = ["km", "nm"];
var zoomindex = 0;
var unitindex = 1;

This sets the zoom level to 5 nm in the URL. When loaded on the edge 1000 it will fail and I get the following message.

ERROR: System Error
DETAILS: failed inside handle_image_callback

From this I can only guess that the makeImageRequest is choking on the specific URL. In my app log, I print out the URL that is created. If I hard code the imgurl to the string output into the log, and sideload the build for my device, the image will be displayed on my Edge 1000 and not crash but I loose all selectability of the image. If I change just the zoomindex to 1-7, the app will run fine without crashing.

Since the the URL created appears to work find on at least one device, my FR230, at all zoom levels, I am starting to wonder if the cause of my app failures are symptoms of devices specific bugs. The problem I have is trying to identify the change I can make to the code to make it work as I still can not determine what is happening when building the URL.

Has anyone else seen anything like this or have a suggestion on a check I can do to the the string before passing it to the makeImageRequest command?

jim_m_58 over 7 years ago

You want to simplify the URL and use params in the makeWebRequest is my guess. Having the params right in the URL don't always do what you expect,based on a few things (sim vs Android vs iOs for example)

sabeard over 7 years ago

Jim,

Thanks for the suggestion. I will play with it tonight to see if I can get things working using parameters. If it works, it may solve all the other error message issues I am seeing.

sabeard over 7 years ago

I have been successful in switching the set up from a single long URL to a shorter url with parameters. Beyond making the code easier to read, I did not find a change in behavior, the edge unit would still crash when passing the a specific combination of parameters to the WU server. Below is a code snipit which will crash on the my edge 1000 running FW 14.20 every time, but run successful in the simulator and on my FR230.

imgzoom = [5, 10, 15, 20]; // Lookup array for settings zoom size.
imgradunits = ["km", "nm"]; // Lookup array for zoom units.
zoomindex = 0;  //This is simulate reading the settings
unitindex = 1;  //This is simulate reading the settings
wuapikey = "WUkey"  //This is simulate reading the settings.  To test replace WUkey with a weather underground api developer key

imgurl="api.wunderground.com/.../image.gif";
imgparam = {
   "centerlat"=>latlon.position.toDegrees()[0],  // latlon variable is created using a onetime position request.
   "centerlon"=>latlon.position.toDegrees()[1],
   "radius"=>imgzoom[zoomindex],
   "radunits"=>imgradunits[unitindex],
   "width"=>dc.getWidth(),
   "height"=>dc.getHeight(),
   "newmaps"=>1
};
Comm.makeImageRequest(imgurl, imgparam, {}, method(:onReceiveImage));

On my edge device, I can make the above code work as long as the value that gets assigned to radius is >=9, such as set zoomindex to 1, 2, or 3, or I can hard code all the parameters to fixed values like the following example which does provide an example to show that using a radius below 9 should work the Edge1000. As soon as any value is replaced with variable in the below parameters dictionary, the unit will crash unless the value of radius is >=9. This limitation kind of defeats the purpose of trying to request an image based on the device position.

imgurl="api.wunderground.com/.../image.gif";
imgparam = {
   "centerlat"=>38.862897,
   "centerlon"=>-94.804457,
   "radius"=>2,
   "radunits"=>"nm",
   "width"=>240,
   "height"=>360,
   "newmaps"=>1
};
Comm.makeImageRequest(imgurl, imgparam, {}, method(:onReceiveImage));

For all of my testing, I am using Eclipse version 4.7.1 on Window 7 with the ConnectIQ SDK plugin 2.3.4. In the end, I believe there is a bug in the Edge1000 14.20 FW with regard to how the image request is being processed. To me it should be expected that as long as the parameters being passed to the image server are valid parameters and the server can return an image, then the CIQ device should be able to display it. I have confirmed that Weather Underground does provide an image for a URL using the parameters which are being generated by my application, and the same code works properly on my FR230 watch.

sabeard over 7 years ago

Well, I believe I have narrowed down the issue. After much more troubleshooting, and starting to get failures on my FR230 and also starting to see them in the simulator including on code I have not touched in over a week, I can only conclude that I am not seeing a bug in CIQ or with my code. As it turns out some time over the past 2-2.5 weeks my weather source has been having unresolved intermittent radar image issues. It would appear that nearly all my requests from my edge device would somehow get routed to the problem server but my watch, even though connected to the same phone would get connected to a more reliable server. All of the problems became more clear when I started noticing during my ride on Saturday that neither my edge nor my forerunner were able to download the radar image, then when I got home, my weather station site was not able to retrieve the image using a similar URL. As of this evening, it appears Weather Underground is behaving better, but who knows for how long.

I am sorry for improperly reporting bugs, it took a while to start to see the proper pattern. I also appreciate the guidance and assistance I have received from the developer community. Now it is off to see if I can find a second option for radar image sources.

Former Member over 7 years ago

Sabeard,

Thank you for the update! I have been keeping an eye on this and trying to figure out what is going on as you have rolled out more information. I wasn't seeing where you were doing anything wrong and I'm glad to know that nothing is broken for either of us. Don't worry about an extra report on this one at all. We appreciate our developers!

Thanks,
-Coleman

sabeard over 7 years ago

Coleman,

One observation I might add is since the GCM acts as a proxy between the CIQ devices. It might be a nice developer feature if some type of CIQ communications log could be added to GCM. I notice that there is a nice Device Sync Audit which can show details on when a device has synced with the GC servers. For most users, I am sure this never gets looked at but can be used to help diagnose sync errors. If a CIQ comm log could put a time stamp on the requests and responses, it may make troubleshooting things a bit easier. The error messages on the device provide some details, but more often I was seeing app crashes, so I could never see the error message. If I had one more place to look, I may be able to get an idea what GCM received and tried to pass to pass back to the device.

I am not sure what all could be logged, just throwing it out as a thought.

Former Member over 7 years ago

Hey,

Not a bad idea. I've created a ticket to investigate how hard it would be to implement.

Thanks,
-Coleman