01-21-2011 09:11 PM
Over the years, RIM have had a number of goes at simplifying the way that developers use connections, including the ConnectionFactory in OS 5.0 and now the new messaging classes.
Now I've only looked at the messaging classes, and not tied to implement code using them, however for me, these classes have not overcome the basic problems for new BlackBerry developers attempting to get data from or to a Server, which are:
a) Getting off the Event Thread
b) Logging the processing so that when errors occur, they understand what processing was involved
c) Understanding the principles of the communication, such as the request headers on an http communication.
So does my class add anything? Well, I've not really tried to give you a single class, or even a coherent and complete package. In fact the Sample code is not really intended as production quality code to be bolted into any application. What it does try to do is highlight approaches to solving the issues above that I hope people will find useful, in a relatively simple situation that people will understand. I would like people to take the ideas and use them in their own applications. So comparing the messaging package and the http demo code is not really valid.
BTW, what does excite me about the messaging API is the way they suggest you use the message for interprocess communication on the device itself.
01-24-2011 03:35 AM - edited 01-24-2011 03:36 AM
Thanks. I guess 6.0 addresses point a.) and c.) at least with NonBlockingSenderDestination and Message (method setTransportHeader).
It is still very bad in point b.
01-24-2011 08:03 AM
Understand what you are saying with:
" I guess 6.0 addresses point a.) and c.) at least with NonBlockingSenderDestination and Message (method setTransportHeader)."
However the sort of person who will use the sample wants to block, and the blocking code does not get off the Event Thread. And for me, setTransportHeader() is no easier than setRequestProperty(). If I was starting out and developing, even for OS 6.0, I would use the sample code.
01-24-2011 10:42 PM
Having worked with this code for a while now, I find it very useful. Thanks again.
I have run into a problem relating to the downloading of resources from webpages. I have a class that implements RenderingApplication, which has a callback called getResource(...). getResource() is pretty well glued to the HttpConnection class, which essentially means bypassing all the great connection handling of your code.
Before I start pulling things apart and reimplementing your class functionality for RenderingApplication, may I ask what you would recommend in this situation? I think a few people might run into this problem since is it common web page handling. I'd really like to use your class wherever possible.
01-25-2011 09:43 AM
you should be able to extract the connection suffix builder and use it separately. i do this in these cases, or with ksoap2 for example.
01-25-2011 02:11 PM
Agree with Simon. I would however be interested to see snippet of your code - it might be possible to reword the Runnable so that you can invoke it directly (<runnable>.run()) and perhaps make the http connection available for query if you needed anything directly from that.
01-25-2011 03:29 PM - edited 01-25-2011 03:29 PM
Hi Simon, Peter - earlier reply seems to have got lost in a sign-in mishap.
I am happy to do that in these situations but I like the (end-)user friendliness of HttpLibrary. I ended up just constructing the connection suffix late last night as you say.
One thing that I also did was to add a very slimmed-down copy of HTTPRequestRunnable for the sole purpose of testing initial connection availability (you could liken it to the iPhone Reachability code if that means anything to you). I use this connection test to check if we get a valid response from the server before starting a bunch of resource downloads with RenderingApplication. That way, I get the transport selection, early connectivity error handling and then I use some pretty average code for the remaining downloads!
Peter, I'll PM you some code shortly to keep this thread clean.
02-16-2011 11:26 AM - edited 02-16-2011 11:27 AM
I have prepared an updated version of this code, that detects when it is being run on or off the Event Thread, and actions accordingly. On the Event Thread, it displays the Wait Screen. Off, it will just run the request. Tested and seems to work OK.
Also added another connection 'suffix', which is no suffix at all. Specifying nothing works in some cases, when in fact specifying something fails. For example, we have had BES devices that work when there is no connection suffix but fail if you specify ";deviceside=false". Go figure!
Some minor tidying up too.
If you have previously taken this code and are only using in the foreground, then there is little value in updating your code with this, or even looking at the updates. However if you have the possibility of doing background requests (say because you are collecting GPS data and wish to send it), then look at this code.
Note when you use background processing in anger, you will need to decide how to connect to the Server and force the background processing to use that - because it can't ask the user!
02-21-2011 09:28 AM
Does TransportDetective tells you that if the device has APN setting configured or not? As per the comments shown below, I recon it does. But when I test on my device, it never tells me that the device has APN configured even if I configure APN settings.
public static final int TCP_CELLULAR_APN_SERVICE_BOOK = 64; /* Represents the availability of TCP_CELLULAR service book that as APN information pre-populated. Please note that this is not a new transport. This simply indicates that your application do not need to know the APN information for TCP_CELLULAR since the device already knows it. Please see URLFactory.getHttpTcpCellularUrlUsingServiceRecord
(ServiceRecord tcpServiceRecord) */