12-15-2010 01:24 AM - edited 12-15-2010 01:26 AM
First of all, Thanks for the nice library. I was exactly looking for such kind of code for months.
But i have a problem compiling the code.
The below classes are used in "HTTPRequestRunable", which are not available in the Library.
and an import statement "import com.sample.HttpGetAndPostDemo.Utilities.*;"
I think these classes are packed inside Utilities package, but there is no Utilities package in the Library zip file.
Where can i find the missing references? Please help.
12-15-2010 01:41 AM
Found the solution myself.
There are two classes in the library with similar naming.
We should delete the second one. It is not being used any where.
12-15-2010 05:02 AM
Thaks for finding this, you are correct. HttpRunable is an old version that got included in the zip archie by mistake. Will be removed for the next 'release'
12-15-2010 09:34 AM - edited 12-15-2010 10:24 AM
The "TransportDetective" class is very complex for my understanding and a small query on this.
Earlier i used to hardcode the carrier internet apn name in my code with connection string like
"deviceside=true;apn=www; for diect TCP connetions.
Even the NetworkDiagnosticsTool, for Direct TCP connections it is just taking the apn name from the users.
Is there any solution available in the library to get the apn name i.e "www" dynamically?
Thanks in advance,
12-15-2010 10:43 AM
The Http library does not support Direct TCP and I no plans to include it.
Attempting to use Direct TCP (or Carrier TCP) complicates the processing, without helping people understand what is going on. In addition, as you have found out, there is not one APN setting that works for all. Finally I am concerned about what happens with the data, because Direct TCP will go through carrier gateways that may well transcode the data.
If you don't have a need to stream, I don't think you need to use Direct TCP. If you have a need to stream, then this code is no good for you.
Regarding getting the APN name, you will probably find the the DevCon 2010 session COM16, available here:
will help you. I suggest you review it. You will have to sign in to Dev Zone to see this.
12-15-2010 11:22 AM - edited 12-15-2010 11:24 AM
Thanks for the reply.
Yes you are right, currently we are using the Direct TCP connections
for streaming media and for normal servlet hits we are using WAP2 apn.
I will surely check the COM16 session. Could you pls give the quick overview of the session.
Is the session acts like a Road map for developing next version of BB OS?
Are Black Berry developers working on it or Does the session gives any clue on getting the apn name dynamically in the current implementations?
12-16-2010 09:31 PM - edited 12-16-2010 10:24 PM
You mention applying for BIS-B Push. I am looking at the BlackBerry Push Service Evaluation form and wondering if I have the correct form. Is there a non-BIS-B service? Or is it the same thing...?
Basically, TCP was my back-up option for connectivity, but you recommend not using it. I guess most end users will not have the correct APN settings by default and will not know how to get them, so maybe it's not worth relying on this after all. Of course, it would be impractical to try and use a global APN settings database. I just don't want my users to get the app and find there is no way to connect because of no TCP support. Do you think this is a problem?
Edit: I went through the evaluation registration. It lets you select transport (i.e. BIS-B) half way down. They say it takes a couple of working days. Some info for others:
- for the evaluation registration you need the IP address that pushes will originate from
- for the production push registration, you need the Evaluation Application ID (from RIM when they approve your evaluation), the over-the-air-download link and the regular traffic info you filled out in the eval.
Hopefully they will be happy with my answers...
12-17-2010 03:51 AM
@magnetix (slightly OT):
there is also BES push, but you cannot subscribe for it.
12-17-2010 06:28 AM
You have the correct form. You might find this forum has some useful information too:
As Simon says, there is BES Push, but this is used for corporates and pushes through the company BES.
I'm not sure I have recommended that people not use Direct TCP. I think other connections are easier to establish, and as a first choice for a backup, I would use WAP 2, since you can choose that connection option without needing any configuration data. But I see no problem having a Direct TCP option in your kit bag too. If you have a user that is struggling to connect, then they will not mind going into a configuration screen. But the idea behind this code is to get people started, doing the right things (off the Event Thread and logging), and Direct TCP support is perhaps a distraction to these objectives.