Have you ever had the wish to connect your Laptop or mobile device to the Internet with the help of Qt (in particular in public environments such as airports or the local shopping center )? Well, the Bearer Management API is exactly what you are looking for 
The ability to utilize a large variety of sometimes transient networks is an important feature for any mobile platform such as mobile phones or laptops. The user wants to be online for as long as possible while at the same time cost and speed are optimized for the use case at hand. The Bearer Management API provides important enablers such as the basic ability to start, stop and monitor network access points, access point grouping and roaming capabilities (the process of migrating from one network to the next) and session management. In addition mobile specific functionality such as the discovery of transient and stationary access points (e.g. Ethernet, WLAN or GPRS/3G) is supported.
What other features does this API bring to Qt? Apart from the use cases mentioned above other indirect use cases become possible. For example QNetworkAccessManager based applications (such as Webkit) may simply be able to access the Internet without having to consider whether the device is online already or which access point they should use. HTTP requests could automatically trigger the start of the best (cheapest/fastest etc.) access point and the system would ensure that a network interface does not shutdown until the last user has indicated that the interface is no longer required (session management).
One of the most challenging aspects of this API is the large, and sometimes opposing, variety of system capabilities. Symbian/S60 provides almost all desirable aspects for mobile networking whereas desktop platforms (due to their rather stationary context) are pretty limited. Laptops are usually somewhere in the middle of the feature scale. One of the most obvious desktop issues are missing (public) API’s which could give access to the required feature set and session management. This diversity is reflected by some API elements whose only purpose it is to detect the platform’s capabilities. The most minimalistic feature set supported by all platforms is the ability to asynchronously monitor network interfaces. This is implemented by using busy polling via QNetworkInterface. Where possible more specific platform API’s are used to extend the feature set and avoid polling. The most complete feature set is provided for Symbian/S60 version 3.1 or higher and is based on RConnection.
The current API supports Symbian/S60 3.1+, Windows, Linux (NetworkManager) and a generic QNetworkInterface fallback backend. More platforms are planned. Note that the recently released Qt/S60 Tower pre-release and in particular the updated version of OpenC is required to enable roaming for S60 devices.
The code is available on Gitorious and please feel free to send your comments/feedback to qtmobility at trolltech.com.
6 Responses to “Bearer Management”
Uhhmmm…. I’m missing ConnMan in the list. Or not?
This sounds interesting. But the Linux version depends on a Gnome component? Doesn’t that impose a big stack of dependencies?
@Harry: connman is still too early in development, and not deployed by Linux mainstream distributions. We may in the future, have a connman backend.
@ecloud: The only dependency on Networkmanager is compile time, as we use the dbus interface to control the interfaces. But even the NetworkManager.h include might be removed.
Besides, there will be a generic implementation for linux that does not use NM.
>This is implemented by using busy polling via QNetworkInterface.
Polling is generally considered a bad thing on mobile devices as it prevents the device from entering low power idle modes. Has this been thought through?
>Polling is generally considered a bad thing on mobile devices as it prevents the device from entering low power idle modes. Has this been thought through?
@Hamish: Not every platform has event or notification driven API’s to do interface management. We only use it as the last resort (once the choice is reduced to polling or no support at all). Mobile platforms don’t suffer from this issue because they have proper platform API’s (at least I have not come across such a mobile platform) .
Did you know that there’s already a Qt based API to do something similar coming from the KDE community? Granted it doesn’t have as many backends, but that’s unfortunate that you didn’t work with those devs and reinvented the wheel instead…