06-11-2009 12:50 AM
I am also facing the same problem . Call connected method is getting called twicw when i disconnect the call and make a call after selecting number from my screen .
06-12-2009 03:54 AM
R u getting the notification in callInitiated() method.Kindly put a log in this method and check.
I dont know the exact reason but i faced the same issue and i figured it out that if you disconnect the native call and create a call from your applicaiton, BlackBerry will create a new PhoneListener instance instance and give callbacks to both the instances.
if you print the REFERENCE of PhoneListener class iside your callInitiated() method and also the call ID, you will see that PhoneListener refernce is differect in both the cases while the call ID is same.
06-12-2009 04:46 AM - edited 06-12-2009 04:49 AM
Excellent observation krishn2.
Cannot confirm but it definitely makes sense.
A workaround: Always memorize the call initiated call ID and the first thing to do inside callInitiated is to check whether the last handled initiated call id != the memorized one (if it isn't than it's a duplicate callback, just ignore it).
int fLastInitiatedCallID = -1;
public void callInitiated(final int aCallID)
if (fLastInitiatedCallID == aCallID)
// used for duplicate callInitiated callback. Just ignore it.
// memorize the current initiated ID
fLastInitiatedCallID = aCallID;
// ... other code ...}
That way there is no chance to do the handling twice (and is safe since there is no way to get two callInitiated callbacks on the same call ID).
06-12-2009 05:58 AM
"since there is no way to get two callInitiated callbacks on the same call ID"
Hate to be the bearer of bad news, but call ids are not guaranteed unique:
Whether you can two at the same time with the same callid I don't know.
06-12-2009 06:10 AM
Thx for the tip.
Bad news, that's for sure, but the mentioned bug does not interfere with the callInitiated callback.
I have never had any problems with the posted workaround which I use in callInitiated and callFailed (just to mention a few).
As for the bug... My guess is someone on the development team misinterpreted the active call to be the call waiting instead of the incoming call .
So, maybe they don't exactly guarantee call ID uniqueness, but I believe we can rely on it (except for the mentioned callWaiting bug).
In any case, even if someone empirically proves that we should not rely on it's uniqueness in callInitiated, we can allways use another guard by using krishn2's finding and with the memorized callID also store the phoneListener's reference.