05-10-2012 09:56 AM
Thanks for the link Peter.
I actually solveed that problem in a fit of desperation by taking out the offending parameter, to find that it wasn't required! I've hit the same problem again further down the line though, another url which works perfectly well over wi-fi but returns a weird time-out error in this sort of form:
\u0000\u0003\u0001The request has timed out!\u0000\u0003\u0001
Is there any readon why the transports should be treated differently? I developed the same app for Android with none of these issues. It seems insanely difficult to handle web traffic for Blackberry. I'm on the point of giving up despite having put a huge amount of effort into this.
05-11-2012 05:59 AM
Networking is always an issue on BlackBerry. Both Apple and Google have had an advantage in that they came later to the networking world and have had not had to incrementally add WiFi, WAP 2.0 etc. And they have not suffered the whims of various networks that RIM has suffered.
That said, I believe you will still get issues in Android land anyway with data being different over WiFi and wireless. As I understand it, this is because there is a network gateway in the way and the carriers will try to 'optimize' these to get the most that they can from the wireless network. So you will find that by coding various headers that the gateways interpret you can usually get things through. And sending only Latin-1 text (no binary, no UTF-8) will stop gateways trying to interpret things wrong. And making sure you set the content type and length correctly will help too.
Enough general stuff, what is happening here?
I can't really tell, I have never seen anything like this before. What I would do is print out the headers that come back on the http request. They will tell you the server/gateway that actually sent you the timeout message. It didn't come from the BlackBerry, at least I have never seen anything like this. Do you know what connection method you are using and which carrier you are on?
05-11-2012 06:52 AM
Thanks again Peter for your continued support, it is very much appreciated.
As background, the app is to give access to an online squash court booking system which it does by interpreting the html from the website and building the urls it expects to receive.
My carrier is O2 (UK) but I'm afraid I don't know which connection method I'm using. I am using a prepay sim if that's any indication.
I'm afraid I don't know how to access the headers, so any pointers would be appreciated.
Another oddity with the data which doesn't happen with Android but does over both wifi and wireless with BlackBerry is that the £ symbol in the court price is changed to ? in the data received from the website. I don't know whether that's a clue to anything or not!
05-11-2012 07:18 AM
If you are using a prepay SIM on BlackBerry and you have no added the BlackBerry extension (I tyhink such a thing exists in O2), then you are almost certainly using WAP and going through the O" gateway.
If this happens over both WiFi and wireless on BlckBerry, then my suggestion is not applicable however.
What you most like have is an encoding issue. I've found the best way to resolve these issues is to look at the raw bytes and the resultant character that is displayed. Given you previous code, the key line is:
pageContent = new String(data, "UTF-8");
data is the raw bytes, pageContent is the String (character) data. You need to look through the data bytes, find the character that gets converted incorrectly, then tell us what it actually contains.
if you are not using UTF-8 in your conversion of data to String, then you might like ot change this first.
Do you see this on a Simualtor?
05-13-2012 03:53 PM
I was using UTF-8 conversion, having removed that the £ is no longer being converted to ?
I do have the O2 Blackberry extension.
The last issue I have is the following url which still doesn't work over the mobile network:
which gives a response code of 400. I've tried replacing the £ and : with url encoding but that also returns an error. Is there anything about the url that you think could cause the problem?
05-13-2012 06:41 PM
You will have to URL encode this before you send it. Can you convert it, then paste the non converted and the converted URL in here and we will check that your code is converting it correctly.
05-14-2012 02:23 PM
Oddly the encoded version gives the same 400 over the network but an IllegalArgumentException over wifi.
05-14-2012 05:04 PM
he correctly coverted URL should be
Are you aware that you have to encode the URL and the parameters?
05-14-2012 08:45 PM
Opps my mistake. The http:// should not be encoded.