views:

167

answers:

4

I read some of the similar posts on this site that deal with what seems to be the same issue and the responses didn't really seem to clarify things for me.

My application works fine in the simulator. I believe I'm on Bold 9000 with OS 4.6. The app is signed.

My app makes an HTTP call via 3G to fetch an XML result. type is application/xhtml+xml. In the device, it gives no error. it makes no visual sign of error. I tell the try catch to print the results to the screen and I get nothing. HttpConnection was taken right out of the demos and works fine in sim.

Since it gives no error, I begin to reflect back on things I recall reading back when the project began. deviceside=true? Something like that? My request is simply HttpConnection connection = (HttpConnection)Connector.open(url); where url is just a standard url, no get vars. Based on the amount of time I see the connection arrows in the corner of the screen, I assume the app is launching the initial communication to my server, then either getting a bad result, or it gets results and the persistent store is not functioning as expected.

I have no idea where to begin with this. Posting code would be ridiculous since it would be basically my whole app.

I guess my question is if anyone knows of any major differences with device versus simulator that could cause something like http connection or persistent store to fail? A build setting? An OS restriction? Any standard procedure I may have just not known about that everyone should do before beginning device testing?

Thanks

+2  A: 

Just providing the URL will not work. You will have to append some info after the URL to determine the transport method your HTTP connection will use. For instance http://example.com;deviceside=true will use DirectTCP (you might also have to supply APN information but that's saved on the device for my phone). http://example.com;interface=wifi will use wi-fi. On OS 5 there's a ConnectionFactory class that makes this a lot easier. Here's a link that goes into more detail.

Jonathan
A: 

It's probably an issue with the APN not being specified. See my answer for this question for details: http://stackoverflow.com/questions/2981534/video-streaming-over-http-in-blackberry/2983043#2983043

Marc Novakowski
A: 

I would make this a comment, but I think I don't have enough rep yet for that... So I'll just answer and hope this doesn't get hosed for just pasting in some links.

I've been working on this exact sort of networking issue on our app this past week, and it is indeed tricky as some others have pointed out. Here are two links which really helped us out using HTTP on different devices, especially older devices which do not provide ConnectionFactory.

http://www.localytics.com/blog/post/how-to-reliably-establish-a-network-connection-on-any-blackberry-device/

http://supportforums.blackberry.com/t5/Java-Development/Connecting-your-BlackBerry-http-and-socket-connections-to-the/td-p/206242

The first one has some code examples, including demonstration of querying the system's ServiceBook and CoverageInfo classes to make a decision about what kind of connection will work.

spacemanaki
+1  A: 

This was a tough one for me! As Jonathan said you have to put some parameters in the url to make it work on the device. You shouldn't do it by hand but use the ConnectionFactory instead.

As you may thing this would just make it work but it doesn't!

The real problem is that not the url has been altered because it has ;interface=wifi;deviceside=true in it (in my case). Depending on the webserver accepting your request this could broke the code.

A solution I tried and that works is try to happend a fake parameter like

&foo=true -> &foo=true;deviceside=true

This will result as a standard parameter for the webserver but your device would use it to driver your connection.

On the simulator this work without this extra code because behind it there is a BIS server for you. On the device (as in my case) there isn't because I'm using a development device unregistered and without SIM (just wifi).

Another point is that the HttpConnection class doesn't handle HTTP 302 Redirect and if you get one you have to handle it manually.

Davide Vosti