Thank you for visiting the BlackBerry Support Community Forums.
BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)
BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.
"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."
- Kevin Michaluk, Founder, CrackBerry.com
Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.
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.