Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Developer
Posts: 4,764
Registered: ‎07-21-2008
My Device: Not Specified

Re: HTTP Connection without APN

BIS-B is the only "carrier agnostic" and the most reliable way to make a connection.

 

Failing that, you might try WAP 2.0, using ";deviceside=true;ConnectionUID=". With WAP 2, you get the UID from the service book, so you don't have to hard-code the WAP gateway info for each carrier.

 

See the article here, and there is also a video on the developer site.

 

http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800451/800563/What_Is...

Highlighted
New Developer
Posts: 9
Registered: ‎10-08-2008
My Device: Not Specified

Re: HTTP Connection without APN

So, part of the difficulty with this is that the user may be BES'ed, and the BES admin may restrict the user's device regarding which parts of the web the user is allowed to get to. While I haven't tested what happens if my application attempts to connect using direct TCP (as opposed to going through the BES) when using a BES'ed device, I would certainly hope that the BES overrules whatever connection request a user (through your application) might make if that connection would violate BES policies. But leave that aside for the next thing:

 

I have come across the "APN is not specified" error in a situation using a BlackBerry Bold 9000 - which fails the first but works the second time the attempt is made. Investigation into this issue showed that the Connector.open() method was throwing an IOException while making the attempt to setup the connection, meaning that the attempt was thwarted before the attempt even reached outside the device. Basically, it appeared to be the OS'es way of saying "I'm sorry Karl, I can't do that....right now." Since the same code had no difficulty performing the same operation on a different device/OS, it was clear that the fault didn't lie in the application code, and instead was an issue within the OS itself. Oh, and the simulator never showed this issue because.....the network connectivity always works on a simulator Smiley Very Happy.

 

The only solution: retry the attempt as a result of an IOException around the Connector.open() call (my implementation was to set a flag before the t/c block and clear it after the Connector.open() because there are other exceptions that can get thrown beyond the Connector.open() in my code). If the Connector.open() call itself throws the exception, retry the attempt some amount of time later. I have not done sufficient testing to determine whether there's a proper amount of time to wait between attempts.

 

Enjoy!

 

Karl