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

Developer

Forums

Forums:

As I know, in BREW2.1, When App running, it can prevent being interrupted by other Apps(start new App), that is, handle and return TRUE for EVT_APP_NO_CLOSE.

But, in BREW3.1.5, BREW only will send this event to the active applet when the new starting app is screen saver. Then,in BREW 3.1.5, from Apps side, How to prevent being interrupted by new-starting apps.

Thanks a lot

Returning TRUE to EVT_BUSY should indicate to BREW that you don't want to application suspended or closed, though I'm not sure if BREW is allowed to ignore that and suspend/close the application anyway on some phones. You will probably have to test it out on a handset to be sure.
http://brewforums.qualcomm.com/showthread.php?t=10311
You should be aware, though, that this might cause issues on some phones.

Returning TRUE to EVT_BUSY should indicate to BREW that you don't want to application suspended or closed, though I'm not sure if BREW is allowed to ignore that and suspend/close the application anyway on some phones. You will probably have to test it out on a handset to be sure.
http://brewforums.qualcomm.com/showthread.php?t=10311
You should be aware, though, that this might cause issues on some phones.

Returning TRUE to EVT_BUSY in the top visible app should only prevent another app from starting in the case where the new app has the screensaver flag set in the MIF. There was a bug previously where all new apps would be prevented from starting when the EVT_BUSY event was handled by the top-visible app, but this has been corrected in newer BREW releases.

Returning TRUE to EVT_BUSY in the top visible app should only prevent another app from starting in the case where the new app has the screensaver flag set in the MIF. There was a bug previously where all new apps would be prevented from starting when the EVT_BUSY event was handled by the top-visible app, but this has been corrected in newer BREW releases.

Hi, Max, I know this bug has been fixed in BREW3.1.5, Then In BREW3.1.5,How to meet the requirement which i mentioned in this thread.
I know in BREW3.1.5, when start new applet, brew will use ITopvisable to judge whether new app can start as well as call oem_notify with OEMNTF_APP_Start to check whether OEM allow to start. Right??
Then can we Retrieve the itopvisable and do something to meet the requirement in app layer?
Thanks a lot

Hi, Max, I know this bug has been fixed in BREW3.1.5, Then In BREW3.1.5,How to meet the requirement which i mentioned in this thread.
I know in BREW3.1.5, when start new applet, brew will use ITopvisable to judge whether new app can start as well as call oem_notify with OEMNTF_APP_Start to check whether OEM allow to start. Right??
Then can we Retrieve the itopvisable and do something to meet the requirement in app layer?
Thanks a lot

Is this an OEM app? Why can't you prevent additional apps from starting at the OEM layer?
Please open an SR through qishelp.qualcomm.com for any questions that should go to the OEM Engineering team.

Is this an OEM app? Why can't you prevent additional apps from starting at the OEM layer?
Please open an SR through qishelp.qualcomm.com for any questions that should go to the OEM Engineering team.

Hi Max, I know how to prevent app starting in OEM Layer, that is, return un-SUCCESS in OEM_Notify for OEMNTF_APP_START event.
Now, I also want to know whether can do such in App Layer, OR how to use ITopVisableCtl interface to do such.
Thanks a lot

Hi Max, I know how to prevent app starting in OEM Layer, that is, return un-SUCCESS in OEM_Notify for OEMNTF_APP_START event.
Now, I also want to know whether can do such in App Layer, OR how to use ITopVisableCtl interface to do such.
Thanks a lot

max wrote:Returning TRUE to EVT_BUSY in the top visible app should only prevent another app from starting in the case where the new app has the screensaver flag set in the MIF. There was a bug previously where all new apps would be prevented from starting when the EVT_BUSY event was handled by the top-visible app, but this has been corrected in newer BREW releases.
Just to confirm - is this apply to BREW version 3.1.3.17? Seems like on my test device, when I return TRUE in EVT_BUSY, I'm unable to start any other application ...

max wrote:Returning TRUE to EVT_BUSY in the top visible app should only prevent another app from starting in the case where the new app has the screensaver flag set in the MIF. There was a bug previously where all new apps would be prevented from starting when the EVT_BUSY event was handled by the top-visible app, but this has been corrected in newer BREW releases.
Just to confirm - is this apply to BREW version 3.1.3.17? Seems like on my test device, when I return TRUE in EVT_BUSY, I'm unable to start any other application ...

sdmitry wrote:Just to confirm - is this apply to BREW version 3.1.3.17? Seems like on my test device, when I return TRUE in EVT_BUSY, I'm unable to start any other application ...
Hi sdmitry,
I see that it has been a while since you posted the question, but maybe you or someone else is still interested in the answer....
I just talked to one of the guys at Qualcomm, and he said the fix came in BREW 3.1.5 ...so that would explain why you are still seeing it on 3.1.3.17
FYI, now that the bug is fixed, the OEMs can make good use of this event to find out if a downloaded app is "busy" or not. I see it as asking the question "Is your app busy serving the user, such that their eyes would be currently focused on the screen?" This is very much needed in the case where the user has not pressed a key for a while. The OEM can see that the user has stopped pressing keys for a while, but only the app knows that it is scrolling a long text for instructions or a "Star Wars"-type introduction ...or maybe showing a video, or giving turn-by-turn directions. It would be pretty annoying if OEMs launched a screensaver, or a software keyguard, or dimmed the backlight ...right in the middle of it. I would hope in these cases, that an app would return TRUE for EVT_BUSY. However, if the user has been staring at a menu list for 30 seconds without hitting a key, then it should be desirable to launch the screensaver or software keyguard or dim the backlight, since the user has probably stopped looking at the phone anyway. So I would hope that an app would return FALSE for EVT_BUSY in that case. It seems to me that a music playing app should also return false to EVT_BUSY, since it should still work fine if suspended under a screensaver, or under a software keyguard, or a dimmed backlight. Obviously, the app can "kick" the backlight repeatedly, but it is up to the OEM to turn it off at some point, and now that the EVT_BUSY bug is fixed, OEMs that want to "play nice" with the downloaded apps can provide a better user experience.
Jon

sdmitry wrote:Just to confirm - is this apply to BREW version 3.1.3.17? Seems like on my test device, when I return TRUE in EVT_BUSY, I'm unable to start any other application ...
Hi sdmitry,
I see that it has been a while since you posted the question, but maybe you or someone else is still interested in the answer....
I just talked to one of the guys at Qualcomm, and he said the fix came in BREW 3.1.5 ...so that would explain why you are still seeing it on 3.1.3.17
FYI, now that the bug is fixed, the OEMs can make good use of this event to find out if a downloaded app is "busy" or not. I see it as asking the question "Is your app busy serving the user, such that their eyes would be currently focused on the screen?" This is very much needed in the case where the user has not pressed a key for a while. The OEM can see that the user has stopped pressing keys for a while, but only the app knows that it is scrolling a long text for instructions or a "Star Wars"-type introduction ...or maybe showing a video, or giving turn-by-turn directions. It would be pretty annoying if OEMs launched a screensaver, or a software keyguard, or dimmed the backlight ...right in the middle of it. I would hope in these cases, that an app would return TRUE for EVT_BUSY. However, if the user has been staring at a menu list for 30 seconds without hitting a key, then it should be desirable to launch the screensaver or software keyguard or dim the backlight, since the user has probably stopped looking at the phone anyway. So I would hope that an app would return FALSE for EVT_BUSY in that case. It seems to me that a music playing app should also return false to EVT_BUSY, since it should still work fine if suspended under a screensaver, or under a software keyguard, or a dimmed backlight. Obviously, the app can "kick" the backlight repeatedly, but it is up to the OEM to turn it off at some point, and now that the EVT_BUSY bug is fixed, OEMs that want to "play nice" with the downloaded apps can provide a better user experience.
Jon