BlackBerry Connection Transport Descriptors

2
votes

I'm wondering if someone could point me in the right direction for this problem. A bit of introduction:

In an app we maintan we just rewrote our network layer to remove support for OS 4. We're using the cleaner ConnectionFactory provided in OS 5. Please note the issues we're encountering are device-only, not simulator related.

There are two ways or app has connectivity, a data thread that polls specific urls and stores data, and a "generic web view" (a BrowserField).

So far it seems there's no problems with the data thread connectivity, it properly builds the urls based off transport type and downloads the data correctly. In the BrowserField we have a different problem. There's an OS 6 curve causing problems (no other OS 6 device though) when we open the BrowserField with a URL there's a chance it will show a "Could not select proper transport descriptor" message - the most common culprit is WAP2.

I guess we're a bit baffled that BlackBerry doesn't seem to handle the transport descriptor choosing as well as we had hoped. Does anyone have any recommendations?

Due to its length, I've posted our connection utility class on gist: https://gist.github.com/3490101

The most common connection form, used by the data thread, is the getUrlAsString(String etag) function, which does a GET and caches the response based off the etag/url.

To build URLs for our BrowserField we use the buildURLTransport(String url) function, which gets a connection on the url, determines the transport information, and returns the built URL.

TL;DR: There's an oddity in a BrowserField we can't seem to debug, we'd appreciate a new set of eyes: we think there's something wrong in the above posted gist in the buildURLTransport(String url) function.

Thanks a tonne in advance.

1
blackberry

1 Answers

4
votes

Be careful with your code because getUrlAsString isn't thread safe. I didn't understand why you keep reference to the ConnectionFactory sometimes why you don't for other.

I aslo didn't understand why do you need method buildUrlTransport. Why don't use BrowserFieldConfig together with ConnectionFactory for BrowserField as here.

So I would instantiate one ConnectionFactory, configure it with your specific parameters and use it everywhere. In case of preferences change I would recreate ConnectionFactory and update BrowserFieldConfig. Sure this code should be thread safe.

Also be more consistent - sometimes you use quick connection check, sometimes you don't.