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

Developer

Forums

Forums:

An app of ours has failed NSTL testing on the Motorola RAZR because "[when] handset receives an SMS message while the application is running, the application does not suspend. The user is able to view the SMS only after the application has been exited."

We don't have a RAZR on-hand right now, but will soon. In the meantime, I thought I'd ask around here.

Motorolas have a bad tendency to not actually suspend an app when calls or SMSes come in. Instead, the app keeps running in the background while an OEM pop-up covers it up, asking "Answer, or Ignore?" Only when the user actually answers the call, does the app receive EVT_APP_SUSPEND.

So, we work around that bug by checking with ITAPI for incoming calls, and by registering to handle an event when incoming SMSes come in. This solved the OEM stupidity on the Motorolas we had on hand (e.g., the V710).

I'm just wondering, has anyone got experience with this with the RAZR? Is there anything we can do to get around it? Our app uses network, so it could be an issue with the network being active, or (more likely) lingering. I've seen crazier things on other phones. :^/

Thanks,

-bill!

Is this during a data call? If so, the behavior you describe is correct. This is actually a VZW requirement to have the app not interrupted during a data call. This shouldn't fail TBT.

Is this during a data call? If so, the behavior you describe is correct. This is actually a VZW requirement to have the app not interrupted during a data call. This shouldn't fail TBT.

The SMS notification app on the V3C is a BREW app (most of the UI is BREW), so when it pops up the running app will be suspended. So the old workaround won't be necessary.
Don't know why the notification app isn't popping up when the SMS arrives, though. I was able to get it to pop up over the Get It Now app while the data connection was open (this was on a V325, but it's pretty much the same thing as the V3C). Maybe your workaround is causing your app to resume after the SMS notifier suspends it?
-Erik

The SMS notification app on the V3C is a BREW app (most of the UI is BREW), so when it pops up the running app will be suspended. So the old workaround won't be necessary.
Don't know why the notification app isn't popping up when the SMS arrives, though. I was able to get it to pop up over the Get It Now app while the data connection was open (this was on a V325, but it's pretty much the same thing as the V3C). Maybe your workaround is causing your app to resume after the SMS notifier suspends it?
-Erik

billkendrick wrote:Motorolas have a bad tendency to not actually suspend an app when calls or SMSes come in. Instead, the app keeps running in the background while an OEM pop-up covers it up, asking "Answer, or Ignore?" Only when the user actually answers the call, does the app receive EVT_APP_SUSPEND.
Actually, another one of our applications, where aforementioned Motorola-specific workaround was NOT implemented, also failed on the RAZR for the same reason.
So the score so far:
* Network-enabled app which uses ITAPI to work around incoming call and SMS alerts on some Motorolas -- FAILED
* Non-networked app which uses ITAPI workaround -- FAILED
* Non-networked app with no workaround -- FAILED
Ugh

billkendrick wrote:Motorolas have a bad tendency to not actually suspend an app when calls or SMSes come in. Instead, the app keeps running in the background while an OEM pop-up covers it up, asking "Answer, or Ignore?" Only when the user actually answers the call, does the app receive EVT_APP_SUSPEND.
Actually, another one of our applications, where aforementioned Motorola-specific workaround was NOT implemented, also failed on the RAZR for the same reason.
So the score so far:
* Network-enabled app which uses ITAPI to work around incoming call and SMS alerts on some Motorolas -- FAILED
* Non-networked app which uses ITAPI workaround -- FAILED
* Non-networked app with no workaround -- FAILED
Ugh

ebrowne wrote:Maybe your workaround is causing your app to resume after the SMS notifier suspends it?
Apparently not. (Since a different app. where the workaround wasn't implemented, which passed fine on numerous other handsets using the exact same MOD, also failed for the same reason.) (See my other post in this thread from moments ago)
Thanks, though.
-bill!

ebrowne wrote:Maybe your workaround is causing your app to resume after the SMS notifier suspends it?
Apparently not. (Since a different app. where the workaround wasn't implemented, which passed fine on numerous other handsets using the exact same MOD, also failed for the same reason.) (See my other post in this thread from moments ago)
Thanks, though.
-bill!

That's weird. Like I said, the SMS notifier screen is just a BREW app, so it should suspend whatever app was running. I just tested it on some random game I downloaded, and it worked fine.
-Erik

That's weird. Like I said, the SMS notifier screen is just a BREW app, so it should suspend whatever app was running. I just tested it on some random game I downloaded, and it worked fine.
-Erik

Does IPORT interface work in case of BREW 3.1, motorola v3c device?

Does IPORT interface work in case of BREW 3.1, motorola v3c device?

We just had 2 applications fail for the same reason as you mentioned and probably more to come. We are handling the typical app suspend and app resume events, and it works on every single phone, except the RAZR. We downloaded some other apps and they are working fine, so apparently there is a way around the problem. Would appreciate anyone posting a work around for this.
Oh BTW, the app suspend and resume works perfectly for an incoming call, just not an SMS.

We just had 2 applications fail for the same reason as you mentioned and probably more to come. We are handling the typical app suspend and app resume events, and it works on every single phone, except the RAZR. We downloaded some other apps and they are working fine, so apparently there is a way around the problem. Would appreciate anyone posting a work around for this.
Oh BTW, the app suspend and resume works perfectly for an incoming call, just not an SMS.

sforbes42 wrote:We just had 2 applications fail for the same reason as you mentioned and probably more to come. We are handling the typical app suspend and app resume events, and it works on every single phone, except the RAZR. We downloaded some other apps and they are working fine, so apparently there is a way around the problem. Would appreciate anyone posting a work around for this.
Oh BTW, the app suspend and resume works perfectly for an incoming call, just not an SMS.
Just as a followup (this might be obvious), after looking at Logs the RAZR does not send the App_Resume and App_Suspend events AT ALL.
BTW, the Alltel and U.S. Cellular versions work correctly. The Verizon version does not. Sounds to me like the carrier needs to get it straight with Motorola.

sforbes42 wrote:We just had 2 applications fail for the same reason as you mentioned and probably more to come. We are handling the typical app suspend and app resume events, and it works on every single phone, except the RAZR. We downloaded some other apps and they are working fine, so apparently there is a way around the problem. Would appreciate anyone posting a work around for this.
Oh BTW, the app suspend and resume works perfectly for an incoming call, just not an SMS.
Just as a followup (this might be obvious), after looking at Logs the RAZR does not send the App_Resume and App_Suspend events AT ALL.
BTW, the Alltel and U.S. Cellular versions work correctly. The Verizon version does not. Sounds to me like the carrier needs to get it straight with Motorola.

Since the SMS client on this device is implemented on BREW, it's possible that if your application does not suspend properly (for instance, by handling EVT_BUSY), the SMS client would not be able to start. This behavior would be masked when running on devices where the SMS client was not implemented in BREW, because it might just seize control of the display anyway.

Since the SMS client on this device is implemented on BREW, it's possible that if your application does not suspend properly (for instance, by handling EVT_BUSY), the SMS client would not be able to start. This behavior would be masked when running on devices where the SMS client was not implemented in BREW, because it might just seize control of the display anyway.

mohlendo wrote:Since the SMS client on this device is implemented on BREW, it's possible that if your application does not suspend properly (for instance, by handling EVT_BUSY), the SMS client would not be able to start. This behavior would be masked when running on devices where the SMS client was not implemented in BREW, because it might just seize control of the display anyway.
If I am not using the EVT_BUSY event, is it best to return TRUE or return FALSE? In all cases, I am returning TRUE. However, it sounds like, based on other posts I've read about EVT_BUSY, that returning FALSE may be the way to go, as you mentioned that the SMS client on this device is implemened in BREW.

mohlendo wrote:Since the SMS client on this device is implemented on BREW, it's possible that if your application does not suspend properly (for instance, by handling EVT_BUSY), the SMS client would not be able to start. This behavior would be masked when running on devices where the SMS client was not implemented in BREW, because it might just seize control of the display anyway.
If I am not using the EVT_BUSY event, is it best to return TRUE or return FALSE? In all cases, I am returning TRUE. However, it sounds like, based on other posts I've read about EVT_BUSY, that returning FALSE may be the way to go, as you mentioned that the SMS client on this device is implemened in BREW.

I have confirmed that returning FALSE for an EVT_BUSY event will allow the SMS to come through. My problem with this is that now any BREW app can interrupt my application, including those irritating screen savers.
So, can anyone explain how we prevent all apps except the SMS client from interrupting our applications?

I have confirmed that returning FALSE for an EVT_BUSY event will allow the SMS to come through. My problem with this is that now any BREW app can interrupt my application, including those irritating screen savers.
So, can anyone explain how we prevent all apps except the SMS client from interrupting our applications?

You should not be blocking other applications from interrupting your application. Doing so will cause your application to fail TBT (ref. TBT procedures section 3.3). For this reason, you should be returning FALSE to EVT_BUSY.

You should not be blocking other applications from interrupting your application. Doing so will cause your application to fail TBT (ref. TBT procedures section 3.3). For this reason, you should be returning FALSE to EVT_BUSY.

Thanks max and sforbes: I've just fixed my app by returning false on evt_app_busy.. :cool:

Thanks max and sforbes: I've just fixed my app by returning false on evt_app_busy.. :cool:

mohlendo wrote:You should not be blocking other applications from interrupting your application. Doing so will cause your application to fail TBT (ref. TBT procedures section 3.3). For this reason, you should be returning FALSE to EVT_BUSY.
Interesting. We have several apps which have passed NSTL testing that return TRUE for EVT_BUSY on at least 40 different handsets. If we can not return TRUE, then what is the purpose of the event to begin with? Why give the user the option to block another apps from suspending it if you are going to fail it for doing so?

mohlendo wrote:You should not be blocking other applications from interrupting your application. Doing so will cause your application to fail TBT (ref. TBT procedures section 3.3). For this reason, you should be returning FALSE to EVT_BUSY.
Interesting. We have several apps which have passed NSTL testing that return TRUE for EVT_BUSY on at least 40 different handsets. If we can not return TRUE, then what is the purpose of the event to begin with? Why give the user the option to block another apps from suspending it if you are going to fail it for doing so?

The following excerpt is from Brew Programming Concepts document, included in Brew SDK 3.1.3. I beleive the same, or similar paragraph is included in all previous versions of Brew SDK too.
-------------
How to prevent a screen saver from running
To make an application prevent a separate screen saver application from interrupting it, the non-screen saver application (for example, Hello World) must return TRUE to the EVT_BUSY event. This prevents the screen saver application from running as long as Hello World is running, even after the specified amount of nonactive time on the device has elapsed.
--------------
It has been encouraged for years to use EVT_BUSY to prevent screensaver from suspending the active application until they come up with the Brew based SMS notifier on the Razor. NSTL should not fail application for this issue, or at least should waiver the retesting fees for the apps that failed TBT only because of this issue.

The following excerpt is from Brew Programming Concepts document, included in Brew SDK 3.1.3. I beleive the same, or similar paragraph is included in all previous versions of Brew SDK too.
-------------
How to prevent a screen saver from running
To make an application prevent a separate screen saver application from interrupting it, the non-screen saver application (for example, Hello World) must return TRUE to the EVT_BUSY event. This prevents the screen saver application from running as long as Hello World is running, even after the specified amount of nonactive time on the device has elapsed.
--------------
It has been encouraged for years to use EVT_BUSY to prevent screensaver from suspending the active application until they come up with the Brew based SMS notifier on the Razor. NSTL should not fail application for this issue, or at least should waiver the retesting fees for the apps that failed TBT only because of this issue.

Ok, someone please get there story straight. Please see this thread regarding AVT_BUSY.
http://brewforums.qualcomm.com/showthread.php?t=10311&page=2&pp=15

Ok, someone please get there story straight. Please see this thread regarding AVT_BUSY.
http://brewforums.qualcomm.com/showthread.php?t=10311&page=2&pp=15

mohlendo wrote:You should not be blocking other applications from interrupting your application. Doing so will cause your application to fail TBT (ref. TBT procedures section 3.3). For this reason, you should be returning FALSE to EVT_BUSY.
Please see this link in the forum
http://brewforums.qualcomm.com/showthread.php?t=10311&page=2&pp=15
So which is it? Do we do it, or do we not?

mohlendo wrote:You should not be blocking other applications from interrupting your application. Doing so will cause your application to fail TBT (ref. TBT procedures section 3.3). For this reason, you should be returning FALSE to EVT_BUSY.
Please see this link in the forum
http://brewforums.qualcomm.com/showthread.php?t=10311&page=2&pp=15
So which is it? Do we do it, or do we not?

I wouldn't say it's been encouraged.
Your application should not be handling EVT_BUSY. Consider for example the following scenario:
User has a scheduling application designed to alert before an upcoming appointment. There is an urgent meeting planned for 1 pm.
At 12:30 the user fires up your game and starts playing, totally losing track of time.
When 1:00 rolls around, the scheduling app tries to start itself to alert the user that he's missing the meeting. Your game returns TRUE to EVT_BUSY and the scheduling application is unable to start, causing the user to miss his meeting. As a result, he gets fired from his job, his wife leaves him for a teenage poolboy, and he moves into a cardboard box underneath a bridge. Do you want this responsibility on your shoulders? :eek:

I wouldn't say it's been encouraged.
Your application should not be handling EVT_BUSY. Consider for example the following scenario:
User has a scheduling application designed to alert before an upcoming appointment. There is an urgent meeting planned for 1 pm.
At 12:30 the user fires up your game and starts playing, totally losing track of time.
When 1:00 rolls around, the scheduling app tries to start itself to alert the user that he's missing the meeting. Your game returns TRUE to EVT_BUSY and the scheduling application is unable to start, causing the user to miss his meeting. As a result, he gets fired from his job, his wife leaves him for a teenage poolboy, and he moves into a cardboard box underneath a bridge. Do you want this responsibility on your shoulders? :eek:

By the way, I've filed a change request to have BREW's behavior with regard to the EVT_BUSY event changed in a future release. Currently handling the EVT_BUSY event in the foreground application will prevent other applications from becoming top-visible. Only screensaver applications should be prevented from launching.
In the meantime, your application should not be handling EVT_BUSY.

By the way, I've filed a change request to have BREW's behavior with regard to the EVT_BUSY event changed in a future release. Currently handling the EVT_BUSY event in the foreground application will prevent other applications from becoming top-visible. Only screensaver applications should be prevented from launching.
In the meantime, your application should not be handling EVT_BUSY.

mohlendo wrote:I wouldn't say it's been encouraged.
Your application should not be handling EVT_BUSY. Consider for example the following scenario:
User has a scheduling application designed to alert before an upcoming appointment. There is an urgent meeting planned for 1 pm.
At 12:30 the user fires up your game and starts playing, totally losing track of time.
When 1:00 rolls around, the scheduling app tries to start itself to alert the user that he's missing the meeting. Your game returns TRUE to EVT_BUSY and the scheduling application is unable to start, causing the user to miss his meeting. As a result, he gets fired from his job, his wife leaves him for a teenage poolboy, and he moves into a cardboard box underneath a bridge. Do you want this responsibility on your shoulders? :eek:
For some number of years now (at least 3)
there has been a ridiculous circle where NSTL fails apps for not 'suspending'
when there is no suspend sent to the app. The developer then posts a
question here on the forum, and is referred to the 'known issues' where
this is documented as known and correct behavior. (In general this
problem presents itself with regard to SMS messages on certain handsets).
Then the developer is referred back to NSTL support.
It is no minor issue to get something like this corrected. Often it takes
weeks and even sometimes months to get a problem corrected with NSTL,
as they try to get in contact with Qualcomm or your problem slowly gets
escalated up the food chain. This seems especially true with the
infamous, mysterious OTA problems.
And often a carrier will not launch an application until all the phones
have passed. Sometimes an app will miss its launch period due to this
causing months of missed revenue while everything is rescheduled,
and possibly causing the cancellation of a time sensitive app
(like a branded movie game). And then guess who is living in
a cardboard box?
So the point is that there is a disconnect in communication, between
NSTL and Qualcomm, that desperately needs to be corrected. There
needs to be a single, reliable, up to date, searchable database for each
handset. Then NSTL testers need to check the database before failing an
app for an issue.
And perhaps this will never get corrected. But to never point it out
would be equally incorrect. So there you are.

mohlendo wrote:I wouldn't say it's been encouraged.
Your application should not be handling EVT_BUSY. Consider for example the following scenario:
User has a scheduling application designed to alert before an upcoming appointment. There is an urgent meeting planned for 1 pm.
At 12:30 the user fires up your game and starts playing, totally losing track of time.
When 1:00 rolls around, the scheduling app tries to start itself to alert the user that he's missing the meeting. Your game returns TRUE to EVT_BUSY and the scheduling application is unable to start, causing the user to miss his meeting. As a result, he gets fired from his job, his wife leaves him for a teenage poolboy, and he moves into a cardboard box underneath a bridge. Do you want this responsibility on your shoulders? :eek:
For some number of years now (at least 3)
there has been a ridiculous circle where NSTL fails apps for not 'suspending'
when there is no suspend sent to the app. The developer then posts a
question here on the forum, and is referred to the 'known issues' where
this is documented as known and correct behavior. (In general this
problem presents itself with regard to SMS messages on certain handsets).
Then the developer is referred back to NSTL support.
It is no minor issue to get something like this corrected. Often it takes
weeks and even sometimes months to get a problem corrected with NSTL,
as they try to get in contact with Qualcomm or your problem slowly gets
escalated up the food chain. This seems especially true with the
infamous, mysterious OTA problems.
And often a carrier will not launch an application until all the phones
have passed. Sometimes an app will miss its launch period due to this
causing months of missed revenue while everything is rescheduled,
and possibly causing the cancellation of a time sensitive app
(like a branded movie game). And then guess who is living in
a cardboard box?
So the point is that there is a disconnect in communication, between
NSTL and Qualcomm, that desperately needs to be corrected. There
needs to be a single, reliable, up to date, searchable database for each
handset. Then NSTL testers need to check the database before failing an
app for an issue.
And perhaps this will never get corrected. But to never point it out
would be equally incorrect. So there you are.

jmiller2 wrote:So the point is that there is a disconnect in communication, between
NSTL and Qualcomm, that desperately needs to be corrected. There
needs to be a single, reliable, up to date, searchable database for each
handset. Then NSTL testers need to check the database before failing an
app for an issue.
And perhaps this will never get corrected. But to never point it out
would be equally incorrect. So there you are.
Well said.

jmiller2 wrote:So the point is that there is a disconnect in communication, between
NSTL and Qualcomm, that desperately needs to be corrected. There
needs to be a single, reliable, up to date, searchable database for each
handset. Then NSTL testers need to check the database before failing an
app for an issue.
And perhaps this will never get corrected. But to never point it out
would be equally incorrect. So there you are.
Well said.

mohlendo wrote:By the way, I've filed a change request to have BREW's behavior with regard to the EVT_BUSY event changed in a future release. Currently handling the EVT_BUSY event in the foreground application will prevent other applications from becoming top-visible. Only screensaver applications should be prevented from launching.
In the meantime, your application should not be handling EVT_BUSY.
Does this mean we get an EVT_SCREENSAVER event? :-P

mohlendo wrote:By the way, I've filed a change request to have BREW's behavior with regard to the EVT_BUSY event changed in a future release. Currently handling the EVT_BUSY event in the foreground application will prevent other applications from becoming top-visible. Only screensaver applications should be prevented from launching.
In the meantime, your application should not be handling EVT_BUSY.
Does this mean we get an EVT_SCREENSAVER event? :-P

mohlendo wrote:
When 1:00 rolls around, the scheduling app tries to start itself to alert the user that he's missing the meeting. Your game returns TRUE to EVT_BUSY and the scheduling application is unable to start, causing the user to miss his meeting. As a result, he gets fired from his job, his wife leaves him for a teenage poolboy, and he moves into a cardboard box underneath a bridge. Do you want this responsibility on your shoulders? :eek:
Actually, my wife would say I was stupid to be playing a game which distracted me from something that might be more important, and say that I deserve to suffer the consequences.

mohlendo wrote:
When 1:00 rolls around, the scheduling app tries to start itself to alert the user that he's missing the meeting. Your game returns TRUE to EVT_BUSY and the scheduling application is unable to start, causing the user to miss his meeting. As a result, he gets fired from his job, his wife leaves him for a teenage poolboy, and he moves into a cardboard box underneath a bridge. Do you want this responsibility on your shoulders? :eek:
Actually, my wife would say I was stupid to be playing a game which distracted me from something that might be more important, and say that I deserve to suffer the consequences.

sforbes42 wrote:Does this mean we get an EVT_SCREENSAVER event? :-P
No, instead handling EVT_BUSY will only prevent screensaver applications from starting (rather than all applications).
The communications with NSTL have consistently been troublesome. There is a problem with any organization that has a fairly high churn rate -- maintaining a consistent base of knowledge is difficult to say the least. We have worked to emphasize the importance of consulting known issues lists before sending out failure reports, and there have been some improvements.

sforbes42 wrote:Does this mean we get an EVT_SCREENSAVER event? :-P
No, instead handling EVT_BUSY will only prevent screensaver applications from starting (rather than all applications).
The communications with NSTL have consistently been troublesome. There is a problem with any organization that has a fairly high churn rate -- maintaining a consistent base of knowledge is difficult to say the least. We have worked to emphasize the importance of consulting known issues lists before sending out failure reports, and there have been some improvements.

Quote:
maintaining a consistent base of knowledge is difficult to say the least.
Hey. may I suggest?! :)
Would it be that hard to have a single page in the extranet with three combo boxes:
Carrier
Manufacturer
Model
...and then, click, boom, a list of all known issues? :rolleyes: The current pages are way too deep linked.
Once we have this, the next step would be a nice workflow to add new issues.
1. Post code snippet with detailed information
2. Someone at qualcomm / oem validate | reject the issue
Obviously, NSTL would be required to check this page, and waive any bugs reported.

Quote:
maintaining a consistent base of knowledge is difficult to say the least.
Hey. may I suggest?! :)
Would it be that hard to have a single page in the extranet with three combo boxes:
Carrier
Manufacturer
Model
...and then, click, boom, a list of all known issues? :rolleyes: The current pages are way too deep linked.
Once we have this, the next step would be a nice workflow to add new issues.
1. Post code snippet with detailed information
2. Someone at qualcomm / oem validate | reject the issue
Obviously, NSTL would be required to check this page, and waive any bugs reported.

bulach wrote:Hey. may I suggest?! :)
Would it be that hard to have a single page in the extranet with three combo boxes:
Carrier
Manufacturer
Model
...and then, click, boom, a list of all known issues? :rolleyes: The current pages are way too deep linked.
You might be surprised how hard it would be. :mad:
Something like that has been in progress for more than a year now.

bulach wrote:Hey. may I suggest?! :)
Would it be that hard to have a single page in the extranet with three combo boxes:
Carrier
Manufacturer
Model
...and then, click, boom, a list of all known issues? :rolleyes: The current pages are way too deep linked.
You might be surprised how hard it would be. :mad:
Something like that has been in progress for more than a year now.

Quote:
You might be surprised how hard it would be.
Something like that has been in progress for more than a year now.
Yeah, I can imagine: should be really hard to plan the storage capacity in a bug database for these lovely handsets... :p

Quote:
You might be surprised how hard it would be.
Something like that has been in progress for more than a year now.
Yeah, I can imagine: should be really hard to plan the storage capacity in a bug database for these lovely handsets... :p

i am facing same problem with my app that on sms no beep is heard also in my app there is no sound of the ringer , r u got the solution for this. if yes please reply .
billkendrick wrote:An app of ours has failed NSTL testing on the Motorola RAZR because "[when] handset receives an SMS message while the application is running, the application does not suspend. The user is able to view the SMS only after the application has been exited."
We don't have a RAZR on-hand right now, but will soon. In the meantime, I thought I'd ask around here.
Motorolas have a bad tendency to not actually suspend an app when calls or SMSes come in. Instead, the app keeps running in the background while an OEM pop-up covers it up, asking "Answer, or Ignore?" Only when the user actually answers the call, does the app receive EVT_APP_SUSPEND.
So, we work around that bug by checking with ITAPI for incoming calls, and by registering to handle an event when incoming SMSes come in. This solved the OEM stupidity on the Motorolas we had on hand (e.g., the V710).
I'm just wondering, has anyone got experience with this with the RAZR? Is there anything we can do to get around it? Our app uses network, so it could be an issue with the network being active, or (more likely) lingering. I've seen crazier things on other phones. :^/
Thanks,
-bill!

i am facing same problem with my app that on sms no beep is heard also in my app there is no sound of the ringer , r u got the solution for this. if yes please reply .
billkendrick wrote:An app of ours has failed NSTL testing on the Motorola RAZR because "[when] handset receives an SMS message while the application is running, the application does not suspend. The user is able to view the SMS only after the application has been exited."
We don't have a RAZR on-hand right now, but will soon. In the meantime, I thought I'd ask around here.
Motorolas have a bad tendency to not actually suspend an app when calls or SMSes come in. Instead, the app keeps running in the background while an OEM pop-up covers it up, asking "Answer, or Ignore?" Only when the user actually answers the call, does the app receive EVT_APP_SUSPEND.
So, we work around that bug by checking with ITAPI for incoming calls, and by registering to handle an event when incoming SMSes come in. This solved the OEM stupidity on the Motorolas we had on hand (e.g., the V710).
I'm just wondering, has anyone got experience with this with the RAZR? Is there anything we can do to get around it? Our app uses network, so it could be an issue with the network being active, or (more likely) lingering. I've seen crazier things on other phones. :^/
Thanks,
-bill!

Max,
We just had an app fail for the exact same reason, returning TRUE to EVT_BUSY to prevent a screensaver from taking over. I would like to know if developers that had apps fail because of returning TRUE to EVT_BUSY, will get a credit from NSTL? It would only be fair.

Max,
We just had an app fail for the exact same reason, returning TRUE to EVT_BUSY to prevent a screensaver from taking over. I would like to know if developers that had apps fail because of returning TRUE to EVT_BUSY, will get a credit from NSTL? It would only be fair.

I can't make that call. You should get in touch with your developer relations contact and inform them of the situation; there's a slim chance that you would be able to arrange something.

I can't make that call. You should get in touch with your developer relations contact and inform them of the situation; there's a slim chance that you would be able to arrange something.

Ok, from reading this thread, I understand that the Motorola RAZR V3c does not issue an EVT_SUSPEND or an EVT_RESUME like most BREW handsets. This is due to most of the handsets system being implemented on the BREW platform, so all that happens during a suspend/resume is the appropriate app on the handset interrupts my BREW app to handle the call/SMS/whatever.
My question is, what happens after the other app relinquishes control and my app gets to run again? Where do I reenter my app?
I ask because after receiving a suspend/resume event currently, when control is returned the app stops refreshing the screen and I'm not sure why.
Just FYI: I'm returning FALSE when I receive an EVT_BUSY.
Thanks.

Ok, from reading this thread, I understand that the Motorola RAZR V3c does not issue an EVT_SUSPEND or an EVT_RESUME like most BREW handsets. This is due to most of the handsets system being implemented on the BREW platform, so all that happens during a suspend/resume is the appropriate app on the handset interrupts my BREW app to handle the call/SMS/whatever.
My question is, what happens after the other app relinquishes control and my app gets to run again? Where do I reenter my app?
I ask because after receiving a suspend/resume event currently, when control is returned the app stops refreshing the screen and I'm not sure why.
Just FYI: I'm returning FALSE when I receive an EVT_BUSY.
Thanks.

This should not be happening. Once your application has been resumed, it should have complete control over the display. Can you provide any additional information?

This should not be happening. Once your application has been resumed, it should have complete control over the display. Can you provide any additional information?

We've joined the happy bunch of people getting NSTL Razr fails for doing something that's totally acceptable (for example to stop the screensaver kicking in during your app, which is why I added it to my code over a year and many NSTL passes ago)
The energy I'd usually expend on ranting about the situation is probably better spent adding yet another phone-specific-hack to my app engine and finding more cash for NSTL.
FL.

We've joined the happy bunch of people getting NSTL Razr fails for doing something that's totally acceptable (for example to stop the screensaver kicking in during your app, which is why I added it to my code over a year and many NSTL passes ago)
The energy I'd usually expend on ranting about the situation is probably better spent adding yet another phone-specific-hack to my app engine and finding more cash for NSTL.
FL.

Same issue on the Motorola VE. :mad:

Same issue on the Motorola VE. :mad:

We have tried all the possible ways to solve the sms issue i.e Interrrupt on sending sms on the simulator.
This is the code that we are using.
1. This is our main event handler
boolean CFrameWork::HandleEvent(IApplet *_piAa,
AEEEvent EventCode_un16AEEEa,
uint16 Param_un16a,
uint32 Param_un32a)
{
CFrameWork *pcFW = (CFrameWork *)_piAa;
AEERect rc;
switch(EventCode_un16AEEEa)
{
case EVT_APP_START:
return TRUE;
case EVT_BUSY:
return TRUE;
case EVT_APP_NO_SLEEP:
return TRUE;
case EVT_FLIP:
ISHELL_CancelTimer(pcFW->_pcPIm_->_piSm_, NULL, (void *)pcFW);
ISHELL_CloseApplet(pcFW->_pcPIm_->_piSm_, FALSE);
return TRUE;
case EVT_APP_STOP:
ISHELL_CancelTimer(pcFW->m_pIShell, NULL, pcFW);
ISHELL_CloseApplet(pcFW->m_pIShell, FALSE);
return TRUE;
case EVT_APP_SUSPEND:
ISHELL_CancelTimer(pcFW->_pcPIm_->_piSm_, NULL, (void *)pcFW);
return TRUE;
case EVT_APP_RESUME:
ISHELL_SetTimer(pcFW->m_pIShell, pcFW->TimerVal_n8m_, (PFNNOTIFY)(TimerCB), pcFW);
return TRUE;
}
// Handle Key Event . If not handled then it returns false
return pcFW->MainEventHandler(EventCode_un16AEEEa, Param_un16a, Param_un32a);
//return FALSE;

We are getting the EVT_APP_MESSAGE event but we are not getting EVT_APP_SUSPEND on simulator.
Do we need to follow some procedure so as to receive EVT_APP_SUSPEND when we send sms to our applet????
Thanks in advance

We have tried all the possible ways to solve the sms issue i.e Interrrupt on sending sms on the simulator.
This is the code that we are using.
1. This is our main event handler
boolean CFrameWork::HandleEvent(IApplet *_piAa,
AEEEvent EventCode_un16AEEEa,
uint16 Param_un16a,
uint32 Param_un32a)
{
CFrameWork *pcFW = (CFrameWork *)_piAa;
AEERect rc;
switch(EventCode_un16AEEEa)
{
case EVT_APP_START:
return TRUE;
case EVT_BUSY:
return TRUE;
case EVT_APP_NO_SLEEP:
return TRUE;
case EVT_FLIP:
ISHELL_CancelTimer(pcFW->_pcPIm_->_piSm_, NULL, (void *)pcFW);
ISHELL_CloseApplet(pcFW->_pcPIm_->_piSm_, FALSE);
return TRUE;
case EVT_APP_STOP:
ISHELL_CancelTimer(pcFW->m_pIShell, NULL, pcFW);
ISHELL_CloseApplet(pcFW->m_pIShell, FALSE);
return TRUE;
case EVT_APP_SUSPEND:
ISHELL_CancelTimer(pcFW->_pcPIm_->_piSm_, NULL, (void *)pcFW);
return TRUE;
case EVT_APP_RESUME:
ISHELL_SetTimer(pcFW->m_pIShell, pcFW->TimerVal_n8m_, (PFNNOTIFY)(TimerCB), pcFW);
return TRUE;
}
// Handle Key Event . If not handled then it returns false
return pcFW->MainEventHandler(EventCode_un16AEEEa, Param_un16a, Param_un32a);
//return FALSE;

We are getting the EVT_APP_MESSAGE event but we are not getting EVT_APP_SUSPEND on simulator.
Do we need to follow some procedure so as to receive EVT_APP_SUSPEND when we send sms to our applet????
Thanks in advance

Hi all,
I am writing an application which is constantly receiving data and has the INetMGR and ISocket interfaces open pretty much all the time.
On a few other phones the application deals with SMS's just fine (LG, Motorola K1M) but in the case of the V3c when i get an sms, and reply to the sms, and try to go back to my application - the phone resets... :mad:
i tried closing the network when i get EVT_APP_SUSPEND and reopening it when i come back with EVT_APP_RESUME but this is still causing a reset
even using ISHELL_SetTimer is causing a reset when i come back from EVT_APP_SUSPEND
after i cancelled the code i was trying to run at EVT_APP_SUSPEND and llooking in the logs i see the following
09/04/07 12:27:47.120092 EVT_APP_RESUME *AppEntryPoi
09/04/07 12:27:48.142452 call timer *AppEntryPoi
09/04/07 12:27:49.170992 App Started... *AEEShell.c
09/04/07 12:27:49.171725 WakeResume (BREW App Activated) *AEEShell.c
09/04/07 12:27:49.172732 App_New (CREATED 1008000) *AEEShell.c
09/04/07 12:27:49.178408 #*g*C=101402c:3 *AEEShell.c 6496 3
09/04/07 12:27:49.179812 #*g*C=101402d:3 *AEEShell.c 6496 3
09/04/07 12:27:49.181155 #*g*C=101402e:3 *AEEShell.c 6496 3
09/04/07 12:27:49.192630 #*g*C=100200d:3 *AEEShell.c 6496 3
09/04/07 12:27:49.208346 App_Close (1008000) *AEEShell.c
09/04/07 12:27:49.213046 App_Cleanup(1008000) *AEEShell.c
09/04/07 12:27:49.217868 App_Free(1008000) *AEEShell.c 8918 3
it looks like when the application comes back from resume - it is closing itself, cleaning up and freeing the memory... is this why anything using ISHELL is resetting the phone?
or does this new/close/cleanup/free stuff refer to the BREW based application which is handling the SMS's
does anybody out there have a few words of wisdom on how to write an application which will survive SMSs on the V3C !?!?!?
:confused:

Hi all,
I am writing an application which is constantly receiving data and has the INetMGR and ISocket interfaces open pretty much all the time.
On a few other phones the application deals with SMS's just fine (LG, Motorola K1M) but in the case of the V3c when i get an sms, and reply to the sms, and try to go back to my application - the phone resets... :mad:
i tried closing the network when i get EVT_APP_SUSPEND and reopening it when i come back with EVT_APP_RESUME but this is still causing a reset
even using ISHELL_SetTimer is causing a reset when i come back from EVT_APP_SUSPEND
after i cancelled the code i was trying to run at EVT_APP_SUSPEND and llooking in the logs i see the following
09/04/07 12:27:47.120092 EVT_APP_RESUME *AppEntryPoi
09/04/07 12:27:48.142452 call timer *AppEntryPoi
09/04/07 12:27:49.170992 App Started... *AEEShell.c
09/04/07 12:27:49.171725 WakeResume (BREW App Activated) *AEEShell.c
09/04/07 12:27:49.172732 App_New (CREATED 1008000) *AEEShell.c
09/04/07 12:27:49.178408 #*g*C=101402c:3 *AEEShell.c 6496 3
09/04/07 12:27:49.179812 #*g*C=101402d:3 *AEEShell.c 6496 3
09/04/07 12:27:49.181155 #*g*C=101402e:3 *AEEShell.c 6496 3
09/04/07 12:27:49.192630 #*g*C=100200d:3 *AEEShell.c 6496 3
09/04/07 12:27:49.208346 App_Close (1008000) *AEEShell.c
09/04/07 12:27:49.213046 App_Cleanup(1008000) *AEEShell.c
09/04/07 12:27:49.217868 App_Free(1008000) *AEEShell.c 8918 3
it looks like when the application comes back from resume - it is closing itself, cleaning up and freeing the memory... is this why anything using ISHELL is resetting the phone?
or does this new/close/cleanup/free stuff refer to the BREW based application which is handling the SMS's
does anybody out there have a few words of wisdom on how to write an application which will survive SMSs on the V3C !?!?!?
:confused: