connection = (HttpConnection) Connector.open(url, Connector.READ, true);

to

if (WLANInfo.getWLANState() == WLANInfo.WLAN_STATE_CONNECTED) {
connection = (HttpConnection) Connector.open(url+ “;interface=wifi”,Connector.READ_WRITE,
true);
} else {
connection = (HttpConnection) Connector.open(url+”;deviceside=true”, Connector.READ_WRITE,
true);

}

connection = (HttpConnection) Connector.open(url, Connector.READ, true);

to

if (WLANInfo.getWLANState() == WLANInfo.WLAN_STATE_CONNECTED) {
connection = (HttpConnection) Connector.open(url+ “;interface=wifi”,Connector.READ_WRITE,
true);

Thanks in advance

Thanks for responding to my comments.

Apologies, re point (c), I’ve checked and you are right. Readers, please ignore my comment. If I could edit that out, I would.

Re (b) and (c), I have similar code, which implements an ‘error’ callback, in addition to a data callback. The data callback returns a byte array. The error call back returns a code indicating where the error occurred, a description and the Exception (if any).

As noted, this is a good sample, and I have directed people this way. My comments were made as a result of a poster on a forum who I suspect used this code, without really understanding it, and then could not debug it when it failed. I wanted to make sure that people who used this realised that it was a sample and not a piece of robust production code.

Just so that you are aware, logging is probably the biggest issue that I have with this code, that makes me say it is not production level code.

Whether you make a connection or not can depend on the Service plan of the user and the connection suffix added to the URL. With http requests potentially being passed through proxy servers and gateways, the data you get back to a BlackBerry can depend on the connection method you have used and the Headers you and the Server have put on the http request and response. So when a piece of code like this fails in a customer situation, there has to be some way that the customer can easily provide the developer with information about what it was trying to do and where it has failed. There is only limited information available here (for example there is no logging of the headers returned or the data prior to it being processed).

The fact that there is no logging in a sample is absolutely fine – logging will just complicate the explanation.

I hope this is helpful, I’m sorry if my comments sounded a bit harsh, and also apologies once again for misreading a part of the code, which lead me to think it was faulty.

Thanks for taking the time to suggest some improvements. Point (a) is definitely a change worth making.

You’re right that when we’re dealing with images it doesn’t make a lot of sense to convert the binary data into a string, but the getWebData() method is general purpose, and when grabbing data from the web I’m usually after a string. If you’re taking this code and want to use it just for grabbing images then certainly it might be worth changing.

As for point (c) I think you’re mistaken. Note that any exceptions thrown in the getWebData method are caught, and result in the “Exception…” string being returned. It isn’t the nicest way of handing the error, but if you know of a better way of passing that information to a callback I’d love to know.

Thanks, Ben