Network connectivity can be quite a challenge for application developers on mobile devices – especially when the environment surrounding a device is continuously changing in terms of coverage and availability. Yet you might ask yourself: Why would I have to worry about it? Why can’t the platform handle those uncertainties and just let me connect to my URL? If you are asking these questions, you are reading the right blog post.
BlackBerry® smartphones support several transports on top of the transports offered by the carriers that you can leverage to connect to your URLs. Each transport is targeted for a different purpose. Once you know which transport you want to use, you first need to detect if that transport is available and is in coverage – or you at least need to find out if there is any transport in coverage at all. Before we start abusing the terms availability and coverage, here is what they are commonly understood to mean:
Availability is the state of a transport type with respect to the requisite hardware and service book provisioning for the particular transport type being considered. A transport type is considered to be available if the device has the requisite hardware and service record for that transport type.
Coverage is the state of a transport type with respect to all prerequisite conditions including hardware, service book, network conditions and signal level that are needed for connection creation over the transport type being considered. A transport type has sufficient coverage if all the prerequisite conditions for connection creation exist for the transport type being considered.
As a developer, you are probably only concerned with coverage since the requirements for coverage includes availability. However, it goes without saying that connections can still fail due to other reasons such as server outage, failure at a network node, and so on.
Detecting availability and coverage is a bit harder than it seems. To solve this, we introduced the Network API in 5.0, which makes life as easy as saying “connect over WAP2” or “connect over any available transport.”
However, we do recognize the fact that not all developers are targeting 5.0, as there are tons of in market devices that are running on previous versions. As an alternative to Network API, for pre-5.0 OS versions you can leverage the TransportDetective and URLFactory classes which are available in the “What Is – Network API alternative for legacy OS” article with full source code! You can use these classes out of the box to detect availability and coverage of transports as well as generating URLs that will make use of your desired transport. It is also worth mentioning that the new version of Network Diagnostic Tool is based on these two classes, and can be downloaded from the same KB article noted above.
Before I wrap up, please do not forget to go through the following resources if you have not already:
I hope the availability of TransportDetective and URLFactory classes will solve your network transport related issues, and I welcome any feedback you might have on them!