Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Hi there,

Right now i'm doing some tests on the LG4400. One interesting problem i have: game is running, an sms is received. User read it, and press CLR, CLR, CLR to go back to the main menu, and start AGAIN the game (ie the user has not resumed the game yet). The app receive a START event (but my SUSPEND returned true..).. I fixed the event handling by assuming that all START events after the first ones are like RESUME ones..

Everything runs ok until i quit the app.. The STOP message is received, but nothing is freed, my freeAppData is never called... I never touch any refs number..
Btw when a standard RESUME event is received, everything's ok..

Any idea??

/kUfa

Maybe you corrupted the phone by writting in some memory part you shouldn´t, some times this can be fixed by rebooting the phone, but some I guess you´ll need a reflash...
is this happenning in the emulator?device?both? if is in this device is this the only applet with bad behavior?

Maybe you corrupted the phone by writting in some memory part you shouldn´t, some times this can be fixed by rebooting the phone, but some I guess you´ll need a reflash...
is this happenning in the emulator?device?both? if is in this device is this the only applet with bad behavior?

Nice test case. Maybe you are confusing the AEEModule? I mean, it might have two entries in its table for your app after you restart that way, and then when you quit it doesn't call your PFNFREEAPPDATA because it thinks there's another instance of it still resident.
That's just speculation. You might want to do some instrumentation of AEEModGen.c and see what happens when you start your app while it's suspended.
This might be related... it's a scenario where you'll get a EVT_APP_START without having AEEClsCreateInstance() called: http://brewforums.qualcomm.com/showthread.php?threadid=1163

Nice test case. Maybe you are confusing the AEEModule? I mean, it might have two entries in its table for your app after you restart that way, and then when you quit it doesn't call your PFNFREEAPPDATA because it thinks there's another instance of it still resident.
That's just speculation. You might want to do some instrumentation of AEEModGen.c and see what happens when you start your app while it's suspended.
This might be related... it's a scenario where you'll get a EVT_APP_START without having AEEClsCreateInstance() called: http://brewforums.qualcomm.com/showthread.php?threadid=1163

Tom: yeah, that's what i thought.. I think i will hack the AAMod_Release like this:
static uint32 AEEMod_Release(IModule *po)
{
AEEMod *pMe = (AEEMod *)po;
// if (--pMe->m_nRefs != 0) {
// return pMe->m_nRefs;
// }
// da kUfa's hack..
pMe->m_nRefs = 0; // doh ..
...
Dunno if it will work well, i'm out the Brew Lab right now, and do not have CDMA here (uk..).. Probably will have to go there again, or is there any other way to test it?? (i doubt)
Marcel:
I cannot have this test case on the emulator, so only on the device, and only on the lg4400. I tried on the T720, works well, since you cannot go back to the main menu to restart the app..
/Kufa

Tom: yeah, that's what i thought.. I think i will hack the AAMod_Release like this:
static uint32 AEEMod_Release(IModule *po)
{
AEEMod *pMe = (AEEMod *)po;
// if (--pMe->m_nRefs != 0) {
// return pMe->m_nRefs;
// }
// da kUfa's hack..
pMe->m_nRefs = 0; // doh ..
...
Dunno if it will work well, i'm out the Brew Lab right now, and do not have CDMA here (uk..).. Probably will have to go there again, or is there any other way to test it?? (i doubt)
Marcel:
I cannot have this test case on the emulator, so only on the device, and only on the lg4400. I tried on the T720, works well, since you cannot go back to the main menu to restart the app..
/Kufa

well doesnt seems to work under the emulator ;)

well doesnt seems to work under the emulator ;)

so this happens when you receives any EVT_APP_SUSPEND, I mean, not only when you get an sms?

so this happens when you receives any EVT_APP_SUSPEND, I mean, not only when you get an sms?

You can test suspend events by setting an alarm. I don't remember if you can navigate to the BREW app manager from an alarm.

You can test suspend events by setting an alarm. I don't remember if you can navigate to the BREW app manager from an alarm.

Nope, the basic SUSPEND - RESUME process works fine.
The problem comes only with the LG4400, since when you get an SMS, you can return to the main menu and "start again" the game..

Nope, the basic SUSPEND - RESUME process works fine.
The problem comes only with the LG4400, since when you get an SMS, you can return to the main menu and "start again" the game..

so the problem I guess is the hardware..
well, I don´t have any experience with lg4400..
I guess since your app cannot know the difference between a suspend and another, I mean, you get the same event when is a sms, incomming call or any other, and your app works fine with the other cases, the problem is the hardware..
I guess you can stick to your workaround or wait lg releases another version of the firmware that works properly.

so the problem I guess is the hardware..
well, I don´t have any experience with lg4400..
I guess since your app cannot know the difference between a suspend and another, I mean, you get the same event when is a sms, incomming call or any other, and your app works fine with the other cases, the problem is the hardware..
I guess you can stick to your workaround or wait lg releases another version of the firmware that works properly.

BTW, i think you should avoid modifying the AEEModGen.c file except for instrumentation. It's better to understand what's causing the problem and fix it gently.
Perhaps you can maintain a shadow refcount on your AEEApplet object to understand under which conditions it gets confused. Then, under the proper circumstances, you can decrement the refcount on your object by calling IBASE_Release inside your own code. You don't have to modify AEEModGen.c.

BTW, i think you should avoid modifying the AEEModGen.c file except for instrumentation. It's better to understand what's causing the problem and fix it gently.
Perhaps you can maintain a shadow refcount on your AEEApplet object to understand under which conditions it gets confused. Then, under the proper circumstances, you can decrement the refcount on your object by calling IBASE_Release inside your own code. You don't have to modify AEEModGen.c.

Quote:Perhaps you can maintain a shadow refcount on your AEEApplet object to understand under which conditions it gets confused. Then, under the proper circumstances, you can decrement the refcount on your object by calling IBASE_Release inside your own code.DOH! I just took a look at AEEModGen.c and there's no need to do that!
The refcount is openly available to you to examine. Never mind.

Quote:Perhaps you can maintain a shadow refcount on your AEEApplet object to understand under which conditions it gets confused. Then, under the proper circumstances, you can decrement the refcount on your object by calling IBASE_Release inside your own code.DOH! I just took a look at AEEModGen.c and there's no need to do that!
The refcount is openly available to you to examine. Never mind.

Yop, just checked this one too..
Btw, tell me if i'm wrong: before the new start event, an addref is called, so when i catch this one, a basic release should do the job, nope? Too bad i cannot test now..
/kUfa

Yop, just checked this one too..
Btw, tell me if i'm wrong: before the new start event, an addref is called, so when i catch this one, a basic release should do the job, nope? Too bad i cannot test now..
/kUfa

So it looks like you should check when AEEMod_ListAdd and _ListRemove is called. I don't think you should be changing the refcount on AEEMod itself.

So it looks like you should check when AEEMod_ListAdd and _ListRemove is called. I don't think you should be changing the refcount on AEEMod itself.

Hmm if AEEMod_ListAdd is called, then AEEApplet_New must be called, and therefore AEEClsCreateInstance too.. But i do not get any logs from my AEEClsCreateInstace routine (got ALOT of dbgprintf)..
I think that only the AEEMod_CreateInstance is called:
static int AEEMod_CreateInstance(IModule *pIModule,IShell *pIShell,
AEECLSID ClsId,void **ppObj)
{
AEEMod *pme = (AEEMod *)pIModule;
AEEModObj *poObj;
int nErr = 0;
// See if we already have the module in memory...If yes, just increment
// the reference count and return.
poObj = AEEMod_FindObj(pme, ClsId, NULL);
if (poObj) {
IBASE_AddRef((IBase *)poObj);
*ppObj = poObj;
return SUCCESS;
}
...
So i think this AddRef is the origin of all my troubles.. Probably one release when i catch the event (or after, in the next game loop?) will fit, nope?

Hmm if AEEMod_ListAdd is called, then AEEApplet_New must be called, and therefore AEEClsCreateInstance too.. But i do not get any logs from my AEEClsCreateInstace routine (got ALOT of dbgprintf)..
I think that only the AEEMod_CreateInstance is called:
static int AEEMod_CreateInstance(IModule *pIModule,IShell *pIShell,
AEECLSID ClsId,void **ppObj)
{
AEEMod *pme = (AEEMod *)pIModule;
AEEModObj *poObj;
int nErr = 0;
// See if we already have the module in memory...If yes, just increment
// the reference count and return.
poObj = AEEMod_FindObj(pme, ClsId, NULL);
if (poObj) {
IBASE_AddRef((IBase *)poObj);
*ppObj = poObj;
return SUCCESS;
}
...
So i think this AddRef is the origin of all my troubles.. Probably one release when i catch the event (or after, in the next game loop?) will fit, nope?

Oh, right. I got confused by the refcount on the IModule versus on the AEEApplet. So again, maybe you should keep a shadow refcount on the AEEApplet and see if it's really the problem.
I see what you mean about testing it. You can't get back to the BREW app manager from an alarm or an incoming call. You can only do it from an incoming SMS. Too bad BREW Logger doesn't allow you to simulate an incoming SMS over the cable.
If it's any consolation, i just tried it on another game (not my own) and it clearly doesn't handle the situation. After exiting the game, you can't start it up again -- it just locks up. I'd wager there are very few apps that would pass this test.
I don't have time to pursue this further, but when i get to it, i'll post a fix if no one else has.

Oh, right. I got confused by the refcount on the IModule versus on the AEEApplet. So again, maybe you should keep a shadow refcount on the AEEApplet and see if it's really the problem.
I see what you mean about testing it. You can't get back to the BREW app manager from an alarm or an incoming call. You can only do it from an incoming SMS. Too bad BREW Logger doesn't allow you to simulate an incoming SMS over the cable.
If it's any consolation, i just tried it on another game (not my own) and it clearly doesn't handle the situation. After exiting the game, you can't start it up again -- it just locks up. I'd wager there are very few apps that would pass this test.
I don't have time to pursue this further, but when i get to it, i'll post a fix if no one else has.

I will test it friday, and let you know if it will works - otherwise i'll find something else hehe :) -
Btw that's an interesting issue!

I will test it friday, and let you know if it will works - otherwise i'll find something else hehe :) -
Btw that's an interesting issue!

I got similar problem, does the work-around work for you?
Thanks in advance,
Jean

I got similar problem, does the work-around work for you?
Thanks in advance,
Jean

The good thing is that they do not try this in the TBT ;)
Btw we want to make good apps, right? Basically, if i receive another call to start (ie call event with m_nRefs > 1), i call a IApplet_Release.. Havent tested it since a long time, i do not have network here, but sounds to work..
/kUfa

The good thing is that they do not try this in the TBT ;)
Btw we want to make good apps, right? Basically, if i receive another call to start (ie call event with m_nRefs > 1), i call a IApplet_Release.. Havent tested it since a long time, i do not have network here, but sounds to work..
/kUfa

Thank you ^ ^ It works good now with your suggestion!
Regards,
Jean

Thank you ^ ^ It works good now with your suggestion!
Regards,
Jean

Np! Cool! :)

Np! Cool! :)

Bittersweet news: NSTL is testing this condition now.
I just got hit by this problem on the A8600 and the A8900. I've been playing with the solutions outlined on this thread but I'm not having any success.
This is how I understand the solution that kUfa and jeantsai worked out:
case EVT_APP_START:
if (firstSTART) {
// initialize everything
// start timers, callbacks
firstSTART = false;
return true;
}
else {
while (app->m_nRef > 1) {
IAPPLET_Release((IApplet *)app);
}
}
// fall through...
case EVT_APP_RESUME:
// restore suspended stuff
// restart timers, callbacks
return true;
case EVT_APP_SUSPEND:
// stop timers, callbacks
// suspend stuff
return true;
case EVT_APP_STOP:
// stop timers, callbacks
// stop stuff
return true;
This is still resulting in a crash the second time the user "launches" the app. The funny thing is that the EVT_APP_START signal comes in when the user launches Get It Now... then an EVT_APP_RESUME comes in when the user launches the application icon!?!?
This one is driving me nuts! Has anybody found anything special about the Audiovox/CDM devices that I'm missing?
Thanks,
-jhw

Bittersweet news: NSTL is testing this condition now.
I just got hit by this problem on the A8600 and the A8900. I've been playing with the solutions outlined on this thread but I'm not having any success.
This is how I understand the solution that kUfa and jeantsai worked out:
case EVT_APP_START:
if (firstSTART) {
// initialize everything
// start timers, callbacks
firstSTART = false;
return true;
}
else {
while (app->m_nRef > 1) {
IAPPLET_Release((IApplet *)app);
}
}
// fall through...
case EVT_APP_RESUME:
// restore suspended stuff
// restart timers, callbacks
return true;
case EVT_APP_SUSPEND:
// stop timers, callbacks
// suspend stuff
return true;
case EVT_APP_STOP:
// stop timers, callbacks
// stop stuff
return true;
This is still resulting in a crash the second time the user "launches" the app. The funny thing is that the EVT_APP_START signal comes in when the user launches Get It Now... then an EVT_APP_RESUME comes in when the user launches the application icon!?!?
This one is driving me nuts! Has anybody found anything special about the Audiovox/CDM devices that I'm missing?
Thanks,
-jhw

I am new to Brew stuff and didn't really got into suspend/resume yet ... But have a question :
When the app gets suspended (by an incoming SMS/Call, etc.) it gets interrupted and you get the SUSPEND event.
When you get this event you MUST release all memory, etc. your application uses since it will be killed -> am I right ?
My game is quite complex - so does this mean that I have to save all data about the game (to a file or so) progress so I can then resume it on my own - loading the data back and restoring previous condition ???
OR - is it possible that your game's data still remains in the memory while the call is received and when it RESUMES all you have to do is setup your callbacks, etc as they were before ???
I have tested this with my phone and everytime I get SUSPEND and then RESUME my games just restarts from the start...
as I said - I am on brew only for 3 days so far... ported the whole game to it, so this is kinda next thing to do :)
Best regards,
Tomaz

I am new to Brew stuff and didn't really got into suspend/resume yet ... But have a question :
When the app gets suspended (by an incoming SMS/Call, etc.) it gets interrupted and you get the SUSPEND event.
When you get this event you MUST release all memory, etc. your application uses since it will be killed -> am I right ?
My game is quite complex - so does this mean that I have to save all data about the game (to a file or so) progress so I can then resume it on my own - loading the data back and restoring previous condition ???
OR - is it possible that your game's data still remains in the memory while the call is received and when it RESUMES all you have to do is setup your callbacks, etc as they were before ???
I have tested this with my phone and everytime I get SUSPEND and then RESUME my games just restarts from the start...
as I said - I am on brew only for 3 days so far... ported the whole game to it, so this is kinda next thing to do :)
Best regards,
Tomaz

When you get SUSPEND event, that really does not mean that your applicaiton will be killed. Your application will not get any timer callback, keyevents etc.
However in the suspended state your application will still receive any incoming SMS message or any http data callback (unless you cancel http callback). It is upto you to decide whether you want to release all memory when you get suspend event.
ruben

When you get SUSPEND event, that really does not mean that your applicaiton will be killed. Your application will not get any timer callback, keyevents etc.
However in the suspended state your application will still receive any incoming SMS message or any http data callback (unless you cancel http callback). It is upto you to decide whether you want to release all memory when you get suspend event.
ruben

Hmm, I tought that might be the case... I wonder why my game then restarts from the beginning... strange... here is my handle event method :
static boolean HandleEvent(IApplet * pi, AEEEvent eCode, uint16 wParam, uint32 dwParam)
{
Globals * glob = (Globals *) pi;
switch (eCode)
{
case EVT_APP_START:
case EVT_APP_RESUME:
glob->time_counter = GETTIMEMS();
ISHELL_SetTimer(glob->a.m_pIShell, 0, (PFNNOTIFY) TimerFunction, (uint32*) glob);
return TRUE;
case EVT_APP_STOP:
ISHELL_CancelTimer(glob->a.m_pIShell, 0, glob);
return TRUE;
case EVT_APP_SUSPEND:
return FALSE;
case EVT_KEY_PRESS: // Process key-down event.
return(((InputBrew *)(glob->inputModel))->SetKey(wParam, true));
break;
case EVT_KEY_RELEASE: // Process key-up event.
return(((InputBrew *)(glob->inputModel))->SetKey(wParam, false));
break;
default:
return TRUE;
break;
}
return FALSE;

Can anyone see what could I be doing wrong ? I basically want to resume where I left it when SUSPEND came in ...
Best regards,
Tomaz

Hmm, I tought that might be the case... I wonder why my game then restarts from the beginning... strange... here is my handle event method :
static boolean HandleEvent(IApplet * pi, AEEEvent eCode, uint16 wParam, uint32 dwParam)
{
Globals * glob = (Globals *) pi;
switch (eCode)
{
case EVT_APP_START:
case EVT_APP_RESUME:
glob->time_counter = GETTIMEMS();
ISHELL_SetTimer(glob->a.m_pIShell, 0, (PFNNOTIFY) TimerFunction, (uint32*) glob);
return TRUE;
case EVT_APP_STOP:
ISHELL_CancelTimer(glob->a.m_pIShell, 0, glob);
return TRUE;
case EVT_APP_SUSPEND:
return FALSE;
case EVT_KEY_PRESS: // Process key-down event.
return(((InputBrew *)(glob->inputModel))->SetKey(wParam, true));
break;
case EVT_KEY_RELEASE: // Process key-up event.
return(((InputBrew *)(glob->inputModel))->SetKey(wParam, false));
break;
default:
return TRUE;
break;
}
return FALSE;

Can anyone see what could I be doing wrong ? I basically want to resume where I left it when SUSPEND came in ...
Best regards,
Tomaz

Quote:
case EVT_APP_SUSPEND:
return FALSE;
instead you should add a canceltimer call here and return TRUE.
ruben

Quote:
case EVT_APP_SUSPEND:
return FALSE;
instead you should add a canceltimer call here and return TRUE.
ruben

Ahh, works perfectly now :) thanx !
TC

Ahh, works perfectly now :) thanx !
TC

tom-cat:
Suspend and Resume handling is clearly spelled out in the Online Knowledge base

tom-cat:
Suspend and Resume handling is clearly spelled out in the Online Knowledge base

Yep, missed the thing when I was going through all the docs online :( I have been doing the BREW thingy for 3 days only so far... so I kinda missed a few things in the hurry. Currently the game works quite nicely in the 2.0 emu... having only a bit of problems with memory - .BMP files take up too much space and for some reason I cannot get the .BCI files to work with IDISPLAY_BitBlt() function - always get an empty bitmap :(
Best regards,

Yep, missed the thing when I was going through all the docs online :( I have been doing the BREW thingy for 3 days only so far... so I kinda missed a few things in the hurry. Currently the game works quite nicely in the 2.0 emu... having only a bit of problems with memory - .BMP files take up too much space and for some reason I cannot get the .BCI files to work with IDISPLAY_BitBlt() function - always get an empty bitmap :(
Best regards,

I am pleased that tom-cat got some good direction here, but I would gently like to reclaim this thread for the topic we were dealing with originally.
We're seeing suspend/resume situations which are *not* spelled out clearly in the online knowledge base.
We're not (only) seeing things like:
SUSPEND
RESUME
or:
SUSPEND
STOP
We're seeing things like:
SUSPEND (SMS)
(user chooses not to resume)
(user relaunches Get It Now)
SUSPEND
(user relaunces application)
START (refcount > 1)
RESUME
RESUME
STOP (refcount back to 1)
(no FreeAppData call)
None of which is anticipated by any of the formal documentation.
I've tried to follow kUfa's method for the VX4400 outlined above, but on the A8600 I'm not getting any cleaner behavior: anybody?
Thanks,
-JHW

I am pleased that tom-cat got some good direction here, but I would gently like to reclaim this thread for the topic we were dealing with originally.
We're seeing suspend/resume situations which are *not* spelled out clearly in the online knowledge base.
We're not (only) seeing things like:
SUSPEND
RESUME
or:
SUSPEND
STOP
We're seeing things like:
SUSPEND (SMS)
(user chooses not to resume)
(user relaunches Get It Now)
SUSPEND
(user relaunces application)
START (refcount > 1)
RESUME
RESUME
STOP (refcount back to 1)
(no FreeAppData call)
None of which is anticipated by any of the formal documentation.
I've tried to follow kUfa's method for the VX4400 outlined above, but on the A8600 I'm not getting any cleaner behavior: anybody?
Thanks,
-JHW

Sorry to have taken over the thread for a day or so, jhw. Was frustated since I didn't quite understand the docs, and this seemed like the perfect place to ask. I hope you will get your code fixed soon !
Best regards,
Tomaz

Sorry to have taken over the thread for a day or so, jhw. Was frustated since I didn't quite understand the docs, and this seemed like the perfect place to ask. I hope you will get your code fixed soon !
Best regards,
Tomaz

Amen to the frusteration, tom-cat, and no problem. I would have kept my mouth shut but I know some folks (like me) have a habit of only reading the last couple of posts in a thread, and I didn't want to vanish :)
-jhw

Amen to the frusteration, tom-cat, and no problem. I would have kept my mouth shut but I know some folks (like me) have a habit of only reading the last couple of posts in a thread, and I didn't want to vanish :)
-jhw

jhw,
Any solution to this problem?
-Aaron

jhw,
Any solution to this problem?
-Aaron

Well, I have been told that QUALCOMM is now considering this an issue with the device and is instructing NSTL to handle it differently. So we *might* not be responsible for it anymore.
Please only consider this a rumor: this is second hand information and I'm not in a position to find a reference right now. There might be an announcement over on the business development threads or the extra net to this effect.
-jhw

Well, I have been told that QUALCOMM is now considering this an issue with the device and is instructing NSTL to handle it differently. So we *might* not be responsible for it anymore.
Please only consider this a rumor: this is second hand information and I'm not in a position to find a reference right now. There might be an announcement over on the business development threads or the extra net to this effect.
-jhw

I will try to get a definitive answer from Qualcomm.
-Aaron

I will try to get a definitive answer from Qualcomm.
-Aaron

The DDS for the 8600 mentions this issue:Quote:Resuming BREW after a BREW App. was suspended but not resumed when a user receives a voices call while in a BREW app and if the clamp shell is closed to end the voice call, opening the clamp shell does NOT resume the suspended app) may cause unpredictable behavior.
Note that there seem to be several different methods to recreate this specific behavior.

The DDS for the 8600 mentions this issue:Quote:Resuming BREW after a BREW App. was suspended but not resumed when a user receives a voices call while in a BREW app and if the clamp shell is closed to end the voice call, opening the clamp shell does NOT resume the suspended app) may cause unpredictable behavior.
Note that there seem to be several different methods to recreate this specific behavior.

Dear mohlendo,
Great to see lots of activity from you on the forums recently! Its extremely helpful for the developers to have a Qualcomm representative around to answer questions.
What is DDS?
Does this mean that developers are or are not responsible for handling this case?
-Aaron

Dear mohlendo,
Great to see lots of activity from you on the forums recently! Its extremely helpful for the developers to have a Qualcomm representative around to answer questions.
What is DDS?
Does this mean that developers are or are not responsible for handling this case?
-Aaron

The DDS is the device data sheet, which is available on the developer extranet. It contains a listing of important information for specific handset models, including known issues and possible workarounds.
Generally, if there is an issue with a handset and no workaround available, NSTL will not penalize developers.

The DDS is the device data sheet, which is available on the developer extranet. It contains a listing of important information for specific handset models, including known issues and possible workarounds.
Generally, if there is an issue with a handset and no workaround available, NSTL will not penalize developers.

mohlendo,
Thank you for the explaination. I have typically found NSTL/Qualcomm to not penalize developers for these kinds of bugs (I had a SMS suspend audio problem with the Samsung a530 that was excused).
However "markcaz" WAS penalized for this error. (see http://brewforums.qualcomm.com/showthread.php?s=&threadid=3507)
Because of the confusion regarding this topic, can you or someone else from Qualcomm give us a definitive "yes" or "no" on if we need to fix this phone bug before submitting to testing?
Sorry to be so pedantic about this point, but developers can't afford to risk $1000, nor can we afford to spend days working around obscure phone bugs if we don't need to.
If "yes", can Qualcomm supply us with sample code that would effectively pass NSTL testing?
Thank you for your time; I really appreciate the help.
Sincerely,
-Aaron

mohlendo,
Thank you for the explaination. I have typically found NSTL/Qualcomm to not penalize developers for these kinds of bugs (I had a SMS suspend audio problem with the Samsung a530 that was excused).
However "markcaz" WAS penalized for this error. (see http://brewforums.qualcomm.com/showthread.php?s=&threadid=3507)
Because of the confusion regarding this topic, can you or someone else from Qualcomm give us a definitive "yes" or "no" on if we need to fix this phone bug before submitting to testing?
Sorry to be so pedantic about this point, but developers can't afford to risk $1000, nor can we afford to spend days working around obscure phone bugs if we don't need to.
If "yes", can Qualcomm supply us with sample code that would effectively pass NSTL testing?
Thank you for your time; I really appreciate the help.
Sincerely,
-Aaron

If your application failed NSTL for a handset issue, you should contact NSTL at eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%4e%53%54%4c%53%75%70%70%6f%72%74%40%6e%73%74%6c%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%4e%53%54%4c%53%75%70%70%6f%72%74%40%6e%73%74%6c%2e%63%6f%6d%3c%2f%61%3e%27%29%3b')). This particular issue was confirmed to be a problem with the mobile platform, and NSTL is no longer failing applications exhibiting this behavior. Again, if your application was affected, you should contact NSTL support.

If your application failed NSTL for a handset issue, you should contact NSTL at eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%4e%53%54%4c%53%75%70%70%6f%72%74%40%6e%73%74%6c%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%4e%53%54%4c%53%75%70%70%6f%72%74%40%6e%73%74%6c%2e%63%6f%6d%3c%2f%61%3e%27%29%3b')). This particular issue was confirmed to be a problem with the mobile platform, and NSTL is no longer failing applications exhibiting this behavior. Again, if your application was affected, you should contact NSTL support.

mohlendo wrote:The DDS is the device data sheet, which is available on the developer extranet. It contains a listing of important information for specific handset models, including known issues and possible workarounds.
Generally, if there is an issue with a handset and no workaround available, NSTL will not penalize developers.
There still does not appear to be any information on the 4400 problem on either the DDS or the 'known issues' sheet on the extranet.
Can you clairfy this?

mohlendo wrote:The DDS is the device data sheet, which is available on the developer extranet. It contains a listing of important information for specific handset models, including known issues and possible workarounds.
Generally, if there is an issue with a handset and no workaround available, NSTL will not penalize developers.
There still does not appear to be any information on the 4400 problem on either the DDS or the 'known issues' sheet on the extranet.
Can you clairfy this?

mohlendo wrote:The DDS for the 8600 mentions this issue:
Note that there seem to be several different methods to recreate this specific behavior.
Our app notices the following situation: EVT_APP_SUSPEND, EVT_APP_MESSAGE, EVT_APP_STOP, and if so, it uses ISHELL_SetTimer() to 'wake itself back up' so that it can inform the user of the SMS that came in during the call, even if they end the call (and the app) by closing the clam.
On the 8600, this _can't_ work, since the app only gets EVT_APP_SUSPEND and EVT_APP_MESSAGE. If they close the clam, they need to manually open it back up and go into the BREW app manager (e.g., "Get It Now!" on Verizon). At that point, the app is resumed.
I'm considering a workaround whereby I use a timer to regularly check whether the app is on a call. If it was suspended due to a call, and then the call ends but we don't get an EVT_APP_RESUME, it will call ISHELL_CloseApplet() to end itself, causing the re-launch timer to be set, and all to be well.
Of course, this won't handle suspend events due to other circumstances (e.g., a non-app-directed SMS message, aka TXT Msg), but it's at least a start.
In the meantime, has anyone got any other suggestions? :)
Thanks

mohlendo wrote:The DDS for the 8600 mentions this issue:
Note that there seem to be several different methods to recreate this specific behavior.
Our app notices the following situation: EVT_APP_SUSPEND, EVT_APP_MESSAGE, EVT_APP_STOP, and if so, it uses ISHELL_SetTimer() to 'wake itself back up' so that it can inform the user of the SMS that came in during the call, even if they end the call (and the app) by closing the clam.
On the 8600, this _can't_ work, since the app only gets EVT_APP_SUSPEND and EVT_APP_MESSAGE. If they close the clam, they need to manually open it back up and go into the BREW app manager (e.g., "Get It Now!" on Verizon). At that point, the app is resumed.
I'm considering a workaround whereby I use a timer to regularly check whether the app is on a call. If it was suspended due to a call, and then the call ends but we don't get an EVT_APP_RESUME, it will call ISHELL_CloseApplet() to end itself, causing the re-launch timer to be set, and all to be well.
Of course, this won't handle suspend events due to other circumstances (e.g., a non-app-directed SMS message, aka TXT Msg), but it's at least a start.
In the meantime, has anyone got any other suggestions? :)
Thanks

billkendrick wrote:I'm considering a workaround whereby I use a timer to regularly check whether the app is on a call. If it was suspended due to a call, and then the call ends but we don't get an EVT_APP_RESUME, it will call ISHELL_CloseApplet() to end itself, causing the re-launch timer to be set, and all to be well.
This was an unacceptable solution, as when the app was quit, the BREW App Manager (e.g., Get It Now!) screen didn't redraw properly. I don't believe there's a solution for this, with the current version of the S/W on the 8600s.

billkendrick wrote:I'm considering a workaround whereby I use a timer to regularly check whether the app is on a call. If it was suspended due to a call, and then the call ends but we don't get an EVT_APP_RESUME, it will call ISHELL_CloseApplet() to end itself, causing the re-launch timer to be set, and all to be well.
This was an unacceptable solution, as when the app was quit, the BREW App Manager (e.g., Get It Now!) screen didn't redraw properly. I don't believe there's a solution for this, with the current version of the S/W on the 8600s.