Java Development

[magnetix]

I have a problem determining the best way to monitor connection changes and types using the available APIs. Originally, I wanted to listen for change in connection so that I could reliably monitor data usage on the phone by counting bytes. This does not seem to be possible, however I still want to offer some information to the user by counting total bytes, and also some approximation of bytes transported over Wi-Fi. This, specifically, may not be the best approximation, so I am asking if anyone can tell me the best way to monitor Wi-Fi connection change, and if there is another, better way to approximate free/paid data usage.

Further info:

I have found the following listeners that may be of use. As you can see, there's quite a lot to choose from and I'm sure there's a right and wrong way to do this...

Listeners

system.GlobalEventListener [API ?]
Can be used for service book changes as described here.
====> Application.addGlobalEventListener(GlobalEventListener) [API ?]

system.RadioListener [API 3.6.0]
No callbacks or usage documented.
====> Application.addRadioListener(int WAFFilter, RadioListener) [API 4.2.1]

system.RadioStatusListener [API 3.6.0]
Inherits from system.RadioListener. Deals with PDP contexts. Partly deprecated.
    Type flags include:
    NETWORK_SERVICE_* (see below)

servicebook.ServiceRoutingListener [API 4.1.0]
Monitors data service routing changes (serial bypass - phone hooked up to a PC - or Bluetooth).
====> ServiceRouting.addListener(ServiceRoutinglistener) [API 4.1.0]
    
system.CoverageStatusListener [API 4.2.0]
Aggregate-only coverage info for WAFs, Bluetooth and serial bypass. Docs recommend usage of Application.addRadioListener(int WAFFilter, RadioListener) for WAF-specific radio events and servicebook.ServiceRouting.addListener(ServiceRoutinglistener) for serial bypass and Bluetooth events.

    Type flags include:

    COVERAGE_BIS_B
    COVERAGE_DIRECT
    COVERAGE_MDS
    COVERAGE_NONE
====> CoverageInfo.addListener(system.CoverageStatusListener) [API 4.2.0]

io.transport.CoverageStatusListener [API 6.0.0]
Information about transport types. A change in coverage can have several sources, including the addition or deletion of service books, changes to signal strength, transport specific communication requirements, and others.
    Type flags include:
    TRANSPORT_BIS_B
    TRANSPORT_MDS
    TRANSPORT_TCP_CELLULAR
    TRANSPORT_TCP_WIFI
    TRANSPORT_WAP
    TRANSPORT_WAP2
====> TransportInfo.addListener(CoverageStatusListener) [API 6.0.0]

system.WLANListener [API 4.3.0]
====> WLANInfo.addListener(WLANListener) [API 4.3.0]

Direct Calls:

For use during scheduled coverage checks:

RadioInfo:
==> system.RadioInfo.getNumberOfPacketsSent() [API 4.0.0]
==> system.RadioInfo.getNumberOfPacketsReceived() [API 4.0.0]
==> system.RadioInfo.getActiveWAFs() [API 4.2.1]
        Only indicates the option is enabled, not that there is a WiFi network connected.
        Flags returned:
        WAF_3GPP
        WAF_CDMA
        WAF_IDEN
        WAF_WLAN
==> system.RadioInfo.getNetworkService(int waf) [API 4.5.0]
        Flags returned:
        NETWORK_SERVICE_DATA
        NETWORK_SERVICE_DIRECT_CONNECT
        NETWORK_SERVICE_E911_CALLBACK_MODE
        NETWORK_SERVICE_EDGE
        NETWORK_SERVICE_EMERGENCY_ONLY
        NETWORK_SERVICE_EVDO
        NETWORK_SERVICE_EVDO_ONLY
        NETWORK_SERVICE_EVDO_REV0
        NETWORK_SERVICE_EVDO_REV0_ONLY
        NETWORK_SERVICE_EVDO_REVA
        NETWORK_SERVICE_EVDO_REVA_ONLY
        NETWORK_SERVICE_GAN
        NETWORK_SERVICE_IN_CITY_ZONE
        NETWORK_SERVICE_IN_HOME_ZONE
        NETWORK_SERVICE_MODEM_MODE_ENABLED
        NETWORK_SERVICE_ROAMING
        NETWORK_SERVICE_ROAMING_OFF_CAMPUS
        NETWORK_SERVICE_SDGC
        NETWORK_SERVICE_SUPPRESS_ROAMING
        NETWORK_SERVICE_UMTS
        NETWORK_SERVICE_VOICE
==> system.RadioInfo.isDataServiceOperational(int wafs) [API 6.0.0]
TransportInfo:
==> io.transport.TransportInfo.getCoverageStatus() [API 6.0.0]
WLANInfo:
==> system.WLANInfo.getWLANState() [API 4.3.0]

edit: formatting, flags

[simon_hain]

I use CoverageStatusListener for the main processing (connection available or not), but it is not called when the route changes.
for that i would suggest a combination of radiolistener and wlanlistener, but be aware of a wlan being connected and the connection being routed over the wlan are two separate events.

[magnetix]

Thanks Simon - do you mean system.CoverageStatusListener or io.transport.CoverageStatusListener?

Also, most of the callbacks for the RadioStatusListener relate to PDP context which I do not really understand yet. I'm more software engineer than telephone engineer, do you know what callbacks/flags I should be responding to with this class? This subclasses RadioListener which has no documented callbacks, so I guess I cannot use the basic RadioListener class per se?

[simon_hain]

RadioStatusListener is the correct interface. You are right, it has a lot of methods that don't help you, but you can just leave them empty.

this is the main method you can use:
http://www.blackberry.com/developers/docs/7.1.0api/net/rim/device/api/system/RadioStatusListener.htm... int)

Each time it is triggered i am using http://www.blackberry.com/developers/docs/7.1.0api/net/rim/device/api/system/CoverageInfo.html#isCov... to check for coverage, in your case the same method with more parameters would give you useful information if you call it multiple times with different parameters.

you can use the service flag to see what kind of network you have, it is a bit-flag so you should use logical operators, for example:
(service & RadioInfo.NETWORK_SERVICE_UMTS) > 0

regarding the coverage listener: both work similar, but the one from the io package is 6.0+ only, so i use the other one.
I guess RIM was trying to move away from the bitflags as they were difficult to understand for inexperienced developers.

[magnetix]

Hi Simon, thanks for your second reply. I wanted to try some things before coming back. In my limited testing environment, I tried the listeners you suggested and only really got a reliable WiFi connection event from WLANListener. So I'll be receiving events from this and polling with WLANInfo.getWLANState() on start up. I may add further connection code (as per your suggestion) depending on ongoing testing. While I was going through the APIs I discovered the TransportDescriptor which seemed to provide access to current routing information. I wondered if it might give more accurate info about currently active routes and improve data monitoring... Maybe that will help someone...?

[simon_hain]

that may well be, i don't use it because my applications have a lower base-OS.

a problem i encountered when using the wlan api was that there is an event for the connected state, but this is not the same as being routed by wifi as it takes some time for the BES/BIS connection to establish over wifi. i did not find a listener for that, maybe the new APIs provide that.