Java Development

[yyzTim]

Apologies if this has been asked and answered but is anyone aware of a problem re-detecting coverage with a 5.0 OS on a 9700 after disabling and re-enabling the radio?  One of my test users has reported that after they re-eanble the radio after testing some offline functionality of the app the app continues to tell them they have no coverage. 

The user has waited hours to be sure it wasn't a lag and can still use the browser and email.  Soft restart doesn't fix it but a hard restart resets it so that the same functions work.  It is reproducable each time the user disables and re-enables the radio.  They do not use wifi and are not USB connected.  The BES was up during this period and I was on it without issue at the same time with the same code.

The code works fine on my 4.6 8900.  I disable then re-enable and within seconds it is able to detect coverage and allows me to do what I want.

The app is an internal corporate app using BES/MDS and Sun WTK generate stubs although I don't believe that is relevant because it is failing on the pre checks I do for coverage and doesn't get to the actual web service calls.  I make a check each time I want to access the web service so it is not old data hanging around.  Basically it works perfect for me but not for my user under the exact same circumstances.

if ((RadioInfo.getState() != RadioInfo.STATE_OFF && (RadioInfo.getNetworkService() & RadioInfo.NETWORK_SERVICE_DATA ) != 0) && CoverageInfo.isCoverageSufficient(CoverageInfo.COVERAGE_MDS)) {
	return true;
}else{
	return false;		
}

The code is based on the code found in the article 'How To - Determine when to route data'

http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800451/800563/How_To_... 

Thanks

Tim

[yyzTim]

bump

[yyzTim]

bump

[darkberry]

I 've had similar problems checking BIS coverage in devices with new OS (Bold 2, storm 1 & 2). But in my case, I don't have to disable and enable again the radio. With the radio enabled from the beggining, and with full coverage, apps compiled in 4.7 or above always fail at that checking.

The funny thing is that compiling for OS 4.5 there's no problem on the same devices.

Mr Sohm performed the same test and replied me (on other post) that he had encountered no problem. So I think it has to do with the carrier.

[yyzTim]

Who is your carrier?  I am in Canada and I think for  the  most part we are Rogers.  I think I may have similar problems on the 4.7 as you are as well.  My device is 4.6 and seems to work ok.

What type of check are  you using and did you find a type of check that would work?  I am going to start mixing and matching different types of checks to see if certain ones work and others don't but my user with the problem device isn't available right now so I won't come up with anything in the short run.

[klyubin]

See if CoverageInfo.getCoverageStatus works correctly. If I recall correctly, isCoverageSufficient and getCoverageStatus can report different results in certain cases.

[darkberry]

You are right, klyubin. I was using getCoverageStatus and it didn't work. I changed to isCoverageSufficient and now works.

Thanks for the info, it was really useful. I don't know why this is not mentioned on the API documentation.

[yyzTim]

I will give getcoveragestatus a try but I think you posted somewhere that they operate on the same underlying data so I am hoping but not confident.  The users with issues are also on 3G whereas I am on Rogers/Edge so not sure if that is a factor.

[yyzTim · Accepted solution]

I believe I have found the issue for myself, athough yours was obviously different darkberry.  Mine was I believe as a result of sloppiness on my part (the shame of it!) although since i couldn't reproduce the problem I can't swear to that.

I had a sneaking suspicion that my problem might be related to pesky network threads hanging around and timing out at inopportune times.  Possibly related I also noticed that upon recently receiving pushs then disabling and re-enabling the network that it always took significantly longer to get connectivity in the app back up.  Beyond that I had no problem but my other user as described above did.  I had gotten a little sloppy about taking care of network controller object references but when I changed to the model whereby the app always stays running and just goes into the background this came back to bite me for obvious reasons.  Once I went back through and ensured I was removing callbacks and nulling objects etc the problem regarding the user not having the network detected upon re-enabling the their radio all went away.