Tried look thru the posts for these answers with no exact answer. Here're several questions about suspend/resume in BREW apps.

1. when app is running with networking transactions, there's a lingering time of 30 sec (default). If outside voice call comes in, and network connection is not yet torn down because of the lingering time, the voice call will be directed to voice mailbox right away, and app doesn't get the EVT_SUSPEND event. Is this acceptable for TBT, i.e. calling the phone with app running might be routed to voice mail automatically.

2. Is there a way for BREW app to programmably SUSPEND itself, and RESUME later? e.g. one would be playing a BREW game, pause it, and make a phone call, then back to the BREW game again. Is this feasible, how does the BREW system handles RESUME after regular phone activity/usage.

3. What is the guideline/rule for BREW application running on background --- i.e. no UI interaction. particularly does the same SUSPEND/RESUME rule apply?

Thanks.

-Wes

1. Yes, this is acceptable and expected.

2. There is no API whose purpose is to send EVT_APP_SUSPEND to your application. However, a number of factors (ITAPI_MakeVoiceCall, ISHELL_StartApplet on another applet, etc.) will result in your application getting suspended.

A possible method to implement pause functionality is to store state in your app prefs or in a file in your app directory, then call ISHELL_CloseApplet on yourself. When the app is restarted from the BREW Application Manager, the app will know on the basis of recorded information whether to resume with the previously stored state info.

3. Background applications do not reside on the application stack and cannot be suspended or resumed. Background applications cannot write to display and no not receive key press events.

Devi Krishnan
BREW Support

With latest CDMA network CDMA2000 1xEV-DO (later on EV-DV) you can have simulatenous voice and data call. Verizon have EV-DO in San Diego and Washington DC. I was told by verizon representative that by the end of this year almost all the major cities will have EV-DO network.

ruben

thx for the reply.

Devi, would like to know more about #3, background app.
How to put an app to background.. can app choose to put itself to background mode?

Toggle the value of dwParam in the close app event in your event handler, your application will be put into background mode.

See this thread
http://brewforums.qualcomm.com/show...=&threadid=3082

Background Applications


Overview

Applications can be divided into three categories: active, suspended, and background. Active and suspended applications reside within the context of the application stack, which is used by BREW to monitor running applications. The top application in the stack is the active application; it is the only application able to communicate directly with the user through modifying the screen and receiving user events. Suspended applications are somewhere beneath the currently active application on the stack. Since there may be multiple applications running in suspended state, developers should ensure that resource allocations are minimized as much as possible when the application suspends. Applications on the stack transfer back and forth through the use of suspend and resume events.



As of BREW 2.0, background applications have been introduced. Background applications function outside the scope of the application stack; that is, they will not behave conventionally for suspend/resume events. Instead, the background application is persistently running without direct user interaction after it has been initiated.





Starting/Ending

When it comes to initiating background applications, they behave much like normal BREW applications; they can be executed either directly from the BREW interface, or started from another application with ISHELL_StartApplet(). To place itself into the background, an application must modify the dwParam when it handles the EVT_APP_STOP event. The dwParam for this event represents a pointer to a boolean value. If the boolean value is FALSE, the application will be placed in the background after handling the EVT_APP_STOP. This can be accomplished through the statement *((boolean*) dwParam) = FALSE. The background application may return to the foreground by calling ISHELL_StartApplet() on itself, which will make it active.



Terminating a background application poses a greater challenge. As they are unable to receive key events directly, it is necessary for the background application to either terminate itself upon successful completion of a designated task or listen to events generated by a separate façade application. The application may be terminated through three methods:

1. Another application sends an event (with eCode >= EVT_USER) signaling the background application to terminate through ISHELL_SendEvent() or ISHELL_PostEvent()
2. Background application terminates itself with ISHELL_CloseApplet() upon completion of a specific task. Note that according to the API references, calling ISHELL_CloseApplet(pIShell, TRUE) from the active application will close all other executing applications and return to the idle screen; however, when called by the active application this operation will not affect other programs not in the application stack
3. Background application activates itself by calling ISHELL_StartApplet(), at which point it may receive user events




Suspend/Resume

Since background applications reside outside of the application stack model, they are not concerned with suspend and resume events. The only time a background application must handle suspend and resume events is when it has been made active, either by its own volition or as the result of an event sent by another application.





Event Handling

While running in the background, applications are not capable of receiving key events. However, many background applications will use event handling to communicate with a façade application that allows the user to control the background application’s behavior. In this case, the façade will signal the background application by sending events with the ISHELL_SendEvent() or ISHELL_PostEvent() methods, which the background application will receive and process as appropriate.





Limitations

The primary constraint to bear in mind while designing background applications is that, unless they make themselves active, background applications have no means of modifying the display or otherwise interacting directly with the user. Beyond this, developers should carefully consider that the application will be running in an environment with limited resources. This is particularly important for background applications, as there may be multiple background applications running at once. Additionally, handsets running background applications will experience increased power drain due to the inability to enter standby mode; consequently, prolonged background execution should be avoided for its deleterious effects on handset battery lifetime. Some OEMs may limit the capabilities available to a background application; for instance, while running in the background, applications may be unable to open sockets or play ringers.







This application can be sent to the background and reactivated through the EVT_USER event, which would be sent by another application using the ISHELL_SendEvent() or ISHELL_PostEvent(). In this implementation, the EVT_USER event merely toggles the application between foreground and background modes; more complex behavior could be implemented through inspecting the dwParam value passed by the application dispatching the event. If this application were invoked directly from the BREW Applications Manager, the initialization value of m_bGoBg would determine whether it would immediately send itself to the background.

__________________
Max
BREW Apps Engineering

Hi MAX,

thanks for the detail spec.

We tried the following and have some finding:

- putting app into background by dwParam set to false.
the background app still able to control UI -- can paint screen

- putting app into foreground (active) by
regularly launching app thru BREW panel -- thus getting a EVT_APP_START event from BREW system. in handling EVT_APP_START, call ISHELL_StartApplet.

It seems working fine. but want to confirm. the question is:
. is the above putting foreground the right approach (without facade applet), or will it start 2nd instance of the same app in foreground?
. is UI controllable in background app normal.. i.e. OEM decide this behavior?

-Wes

Calling ISHELL_StartApplet() is not necessary unless the application is already in the background and you want to bring it to the foreground. Background applications should not be able to control the UI.

__________________
Max
BREW Apps Engineering

I'm waking up my app on reception of the brew directed SMS. In which mode is it starting - for/background - by default? I'm having a problem with sending reply SMS - immediately after i return control to brew it frees applet and callback never happens. Can background applet receive callbacks?

Anybody?

In response to your BREW directed SMS, BREW calls your APPInit function and then provides you EVT_APP_MESSAGE. When you return from that function, applicatoin will be shut down.

In the EVT_APP_MESSAGE handler, If you need to start your application in background mode, call ISHELL_CloseApplet, and then in EVT_APP_STOP do the following
*((boolean*)dwParam) = FALSE; and then start with your application initialization (no display or keyevent access in background mode)

If you need to start your app in foreground mode, from EVT_APP_MESSAGE handler, call ISHELL_STARTAPPLET

In this last case (bringning the app to foreground after sms wake up was received), does this mean that AppInit will be called twice (once right before EVT_APP_MESSAGE, and another time caused by StartApplet())?

ps I'm having troubles using BrewLogger to find that out, because of async DBGPRINTFs, on the other hand, synching them doesn't seems to help...

No, it will be called only once, unless you call this function from EVT_APP_STRAT event.

Hi,

I want to develop one application which should get invoked whenever an incoming call is received. Also, I want that - either modify the contents of incoming call screen(where the callerID is displayed) or display my own UI. Is it possible on BREW?

Should I have to write a listener kind of application for listening incoming calls?

Any suggestions/source codes would be of great help.

Regards,
==dn==

You can register for NMASK_TAPI_STATUS to receive notifications when the TAPI status has changed. Registration can be done through the IShell interface or the MIF file. You can’t, however, change the native UI call screen.