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

Developer

Forums

Forums:

Hi all:
do anyone knows that: what will the brew system do when it receive "exit" command. what i want know is that: if brew will cancel any timer and cancel any callback just before it exit the app? and also i want to know what will brew do just before exiting? thx.:confused:

no u have to call the ISHELL_CancelTimer(), to cancel any timer....
when brew app. exits the pFREEAppData function pointed in AEEApplet_New() will be called and and if u have a EVT_STOP event in the app. handler.
but i found some times the the handler is not called.

no u have to call the ISHELL_CancelTimer(), to cancel any timer....
when brew app. exits the pFREEAppData function pointed in AEEApplet_New() will be called and and if u have a EVT_STOP event in the app. handler.
but i found some times the the handler is not called.

Whenever your application exits, BREW will call your free app function and this will be the last function of your app executed by BREW. Make sure you cancel all your callbacks including network/timer etc.
ruben

Whenever your application exits, BREW will call your free app function and this will be the last function of your app executed by BREW. Make sure you cancel all your callbacks including network/timer etc.
ruben

does brew post any message just before exiting?
and also CALLBACK_Cancel(callback) may not successful when exit , does it cause harm? or how can i cancel the callback successfully? thx.

does brew post any message just before exiting?
and also CALLBACK_Cancel(callback) may not successful when exit , does it cause harm? or how can i cancel the callback successfully? thx.

I tested when the app exit, it goes to EVT_APP_STOP first, then goes to ...FreeAppData(...), does it do anything else?

I tested when the app exit, it goes to EVT_APP_STOP first, then goes to ...FreeAppData(...), does it do anything else?

AS per the API Ref doc,
Upon termination of the currently active applet, the shell scans the timer list. If the terminated applet was deleted as a result of it's termination (ie. it's reference count went to 0), and an associated timer was found with the data pointer pointing to the
IApplet, the timer is deleted.
So If u have not cancelled any timer, shell will do the cleanup.

AS per the API Ref doc,
Upon termination of the currently active applet, the shell scans the timer list. If the terminated applet was deleted as a result of it's termination (ie. it's reference count went to 0), and an associated timer was found with the data pointer pointing to the
IApplet, the timer is deleted.
So If u have not cancelled any timer, shell will do the cleanup.

"So If u have not cancelled any timer, shell will do the cleanup." so shell can cancel the timers but how about AEECallback, can shell cancel it ?

"So If u have not cancelled any timer, shell will do the cleanup." so shell can cancel the timers but how about AEECallback, can shell cancel it ?

it is safe to clean up the timer call backs on the evt_STOP option.......

it is safe to clean up the timer call backs on the evt_STOP option.......

you know CALLBACK_Cancel(callback) may do not cancel the callback if callback.pfnCancel == 0, so how can i cancel the callback anyway?

you know CALLBACK_Cancel(callback) may do not cancel the callback if callback.pfnCancel == 0, so how can i cancel the callback anyway?

for time callback ........
if (ISHELL_GetTimerExpiration (pme->a.m_pIShell, (PFNNOTIFY) _CallBack, (void*)pme) > 0)
ISHELL_CancelTimer( pme->a.m_pIShell,(PFNNOTIFY) _CallBack, pme);
for CALLBACK_Cancel()... if callback is already happened then there is no need to cancel it since it has already happened....
sdg

for time callback ........
if (ISHELL_GetTimerExpiration (pme->a.m_pIShell, (PFNNOTIFY) _CallBack, (void*)pme) > 0)
ISHELL_CancelTimer( pme->a.m_pIShell,(PFNNOTIFY) _CallBack, pme);
for CALLBACK_Cancel()... if callback is already happened then there is no need to cancel it since it has already happened....
sdg

Quote:Originally posted by sdg
for CALLBACK_Cancel()... if callback is already happened then there is no need to cancel it since it has already happened....
sdg
hi sdg, the callback i faced is not happened yet but i need cancel it before exiting the application i think, so how can i implement this?

Quote:Originally posted by sdg
for CALLBACK_Cancel()... if callback is already happened then there is no need to cancel it since it has already happened....
sdg
hi sdg, the callback i faced is not happened yet but i need cancel it before exiting the application i think, so how can i implement this?

when callback function is invoked the AEE sets pfnCancel to NULL ... if it is not happed yet then you should be able to cancel it by CALLBACK_Cancel().... and if it is in middle of callback you may have to wait till end of processing that event....
sdg

when callback function is invoked the AEE sets pfnCancel to NULL ... if it is not happed yet then you should be able to cancel it by CALLBACK_Cancel().... and if it is in middle of callback you may have to wait till end of processing that event....
sdg

Quote:Originally posted by sdg
if it is not happed yet then you should be able to cancel it by CALLBACK_Cancel().... and if it is in middle of callback you may have to wait till end of processing that event....
sdg
I test cancel callback cancel strategy, the conclusion is: initial a callback, then ... can not be canceled.... can be canceled ... (the callback function invoked) can not be canceled...
so callback can be canceled in a short interval just before the callback function invoked. this short interval can not be controled smartly ... that cause my question.

Quote:Originally posted by sdg
if it is not happed yet then you should be able to cancel it by CALLBACK_Cancel().... and if it is in middle of callback you may have to wait till end of processing that event....
sdg
I test cancel callback cancel strategy, the conclusion is: initial a callback, then ... can not be canceled.... can be canceled ... (the callback function invoked) can not be canceled...
so callback can be canceled in a short interval just before the callback function invoked. this short interval can not be controled smartly ... that cause my question.

any other clues?

any other clues?

so the conclusion is that: when app is about to exit it will do follows by sequence
1). cancel any timers and callbacks
2). do with EVT_APP_STOP handler.
3). do appdatafree

so the conclusion is that: when app is about to exit it will do follows by sequence
1). cancel any timers and callbacks
2). do with EVT_APP_STOP handler.
3). do appdatafree

hello xacheng,
it is other way arround....
1) do with EVT_APP_STOP handler.
2) do appdatafree
3) cancel any timers and callbacks

hello xacheng,
it is other way arround....
1) do with EVT_APP_STOP handler.
2) do appdatafree
3) cancel any timers and callbacks

hi, skumar_rao, thx. if anyone has other idea pls give ur reply. thx

hi, skumar_rao, thx. if anyone has other idea pls give ur reply. thx

One should not rely on BREW to clean up timers and callbacks when your app is asked to exit. A well behaved BREW app should cancel its timers and callbacks and release any allocated memory/objects.

One should not rely on BREW to clean up timers and callbacks when your app is asked to exit. A well behaved BREW app should cancel its timers and callbacks and release any allocated memory/objects.

When I get GPS info by using IPosdet and using int IPOSDET_GetGPSInfo
(
IPosDet *pIPosDet,
AEEGPSReq req,
AEEGPSAccuracy accuracy,
AEEGPSInfo *pGPSInfo,
AEECallback *pcb,
) ;
The tested conclusion is that : after we call CALLBACK_Cancel(pcb), it may not cancel callback really: if we release the IPosdet instance pIPosdet, OK, the callback can be insure canceled; else the callback may break out later. In my test app it display:¡±GPS stoped but the callback return.¡± Maybe the app can force cancel the callback, what i need to know is that: does the force canceling may cause some problem?

When I get GPS info by using IPosdet and using int IPOSDET_GetGPSInfo
(
IPosDet *pIPosDet,
AEEGPSReq req,
AEEGPSAccuracy accuracy,
AEEGPSInfo *pGPSInfo,
AEECallback *pcb,
) ;
The tested conclusion is that : after we call CALLBACK_Cancel(pcb), it may not cancel callback really: if we release the IPosdet instance pIPosdet, OK, the callback can be insure canceled; else the callback may break out later. In my test app it display:¡±GPS stoped but the callback return.¡± Maybe the app can force cancel the callback, what i need to know is that: does the force canceling may cause some problem?

hello Abhi,
--------------------------------------------------------------------------
One should not rely on BREW to clean up timers and callbacks when your app is asked to exit. A well behaved BREW app should cancel its timers and callbacks and release any allocated memory/objects.
--------------------------------------------------------------------------
is not it safe to cancel the timer call backs ur self then leaving it to be cleared by the system. is there any problem if i clear the BREW callbacks and timers my self on exit,....

hello Abhi,
--------------------------------------------------------------------------
One should not rely on BREW to clean up timers and callbacks when your app is asked to exit. A well behaved BREW app should cancel its timers and callbacks and release any allocated memory/objects.
--------------------------------------------------------------------------
is not it safe to cancel the timer call backs ur self then leaving it to be cleared by the system. is there any problem if i clear the BREW callbacks and timers my self on exit,....

hi
it is safe to cancel time call-back and BREW callbacks at the time of exiting app. when app is terminated by user or at the time of exiting app.
sdg

hi
it is safe to cancel time call-back and BREW callbacks at the time of exiting app. when app is terminated by user or at the time of exiting app.
sdg

Quote:
is not it safe to cancel the timer call backs ur self then leaving it to be cleared by the system. is there any problem if i clear the BREW callbacks and timers my self on exit,....
In my post I say that the app should release its callback explicitly rather than rely on the system to cleanup for you.

Quote:
is not it safe to cancel the timer call backs ur self then leaving it to be cleared by the system. is there any problem if i clear the BREW callbacks and timers my self on exit,....
In my post I say that the app should release its callback explicitly rather than rely on the system to cleanup for you.

On A610 the ISHELL_CancelTImer does not get executed at all. Even if I am making a mistake in doing the CancelTimer, the shell surely does not cancel the pending timers. As a result the game become extremely slow after a suspend event when I Cancel timers....and it actually does not get cancelled....
And thereafter even popping out the battery keeps the game slow.
thanks

On A610 the ISHELL_CancelTImer does not get executed at all. Even if I am making a mistake in doing the CancelTimer, the shell surely does not cancel the pending timers. As a result the game become extremely slow after a suspend event when I Cancel timers....and it actually does not get cancelled....
And thereafter even popping out the battery keeps the game slow.
thanks