Web and WebWorks Development

[davidmccormack]

I'd love if somebody could reproduce the error I describe below - it can be done just using your browser so it should only take a minute!

The Google Static Maps API allows you to retrieve pre-rendered maps for display within an app. I was having problems getting it to work in my widget so I started pasting a few sample URLs into the BlackBerry's browser. It seems the problem isn't necessarily with my widget because I'm finding that some URLs load correctly in the browser and others don't. This one works:

http://maps.google.com/maps/api/staticmap?mobile=false&size=360x240&sensor=false&key=ABQIAAAAqHpyMxD...

But this one does not:

http://maps.google.com/maps/api/staticmap?mobile=true&size=360x240&sensor=false&key=ABQIAAAAqHpyMxDI...

The only difference is that the one that works sets the 'mobile' parameter to 'false' in the query string and the one that fails sets it to 'true'. I did a forensic on the two image files returned. Both are PNG. Both are at 72 dpi. Both use a colour palette instead of RGB. The good image has slightly fewer unique colours in its palette (254 vs 256) and is also slightly smaller (9.42KB vs 10.7KB). Neither image uses transparency.

This is all very weird. Could it be a bug in the browser's image renderer?? Any suggestions greatly appreciated!

[tneil]

Does the image that isn't working come in distorted, or just doesn't show at all?

If you were to save the image to a file and then bring in that direct file into the browser as a direct link instead of the static maps dynamic URL, does it react different?  I'm just curious if the server is sending different headers across with the images and that is causing the display difference.

[davidmccormack]

Hey you might be on to something there. When I saved the two images as static files on my web server I could open both of them. So it must be some difference in the response headers. With my desktop browser, the response headers are the same but I guess that doesn't necessarily mean anything because the request headers, most notably the user-agent, will be quite different for a desktop browser.

Btw, thanks for your prompt reply!

[tneil]

If you request the image via XMLHttpRequest you should be able to pull the headers to see what is returned using the getAllResponseHeaders() method

You can then check to see if there are any differences with the two images and also compared to your desktop browser

[davidmccormack]

OK. My widget just sets the URL as the src on an img element. But I can hack in what you suggest just to see the headers. That will have to wait until morning though because it's 3:15AM here right now and the lids are veeery heavy. Thanks again.

[davidmccormack]

OK, this gets weirder...and scarier. From what I can work out, if you're using the BIS browser config (the so-called 'Internet Browser' on my device) and you try to hit pretty much any maps.google.com URL, something forces the browser to temporarily switch over to the non-BIS browser config ('Vodafone Live!' on my device). It's similar to what happens if you try to watch a YouTube movie when using the BIS browser config. It seems that this forced browser config switch doesn't work so well for an <img> element that has just been assigned a new src.

Does this sound plausible? Just point your BIS browser at one of the links in yesterday's mail and you'll see that if it does open it will have switched your browser to the non-BIS config.

I notice over on the Java BB dev forum there are a few threads in which people have had very similar problems in Java apps when trying to establish HTTP connections to maps.google.com. In this post, the guy complains about getting a "peer refused the connection" exception trying to open the Google maps URL but says that it works fine if he copies the same image to his own server and then just opens that instead, which is the exact same as me.

Could anyone in RIM comment on this? This would obviously be a big problem for anyone trying to use the Google Static Maps API in widgets. Any workarounds?

[davidmccormack]

Just spotted the following in BlackBerry Widget SDK Known Issues List:

If a BlackBerry widget accesses images on an external server, the widget might not be able to establish a network connection and load some images. This behavior is inconsistent, and might affect different images and servers at different times (333344).

This would probably explain what I'm seeing! Any idea when this will be fixed? And will this be fixed in the Widget SDK (good) or is it the sort of thing that requires an OS update (bad)?

I'm still not clear why the static maps URL won't open in the browser...