ISHELL_Prompt handing EVT_APP_RESUME

[jcoyer]

Certification requires that we return the user to the point at which the app left off when interrupted by inbound phone call, SMS, low battery, etc. From an app perspective, this means we handle the EVT_APP_RESUME event. My question is:

if the app has called ISHELL_Prompt(), and the shell is displaying the prompt when EVT_APP_RESUME arrives, what is the workaround to "refresh" the Prompt? The BREW shell doesn't seem to handle the event, and this leaves the display completely blank after the event arrives. There is no "method" on the Prompt to call, since it's not a control.

Clearly, the Shell is handling events, since it is handling key events as the user chooses among buttons. And, it sends an event to the app when the user has chosen a button. However, the shell doesn't seem to do anything to refresh the display when the RESUME event arrives. I've tried calling ISHELL_Prompt() again in response to the EVT_APP_RESUME event, but it's unstable.

I suppose I could respond to the EVT_APP_RESUME by faking the prompt into thinking the user had pressed the select key, and then call ISHELL_Prompt again, but this seems heavy handed.

Any workarounds out there?

[jcoyer]

I discovered this workaround, for any out there using ISHELL_Prompt:

when you receive EVT_APP_RESUME after the interrupting event (inbound SMS, phone call, whatever) call ISHELL_Prompt() again to "refresh" the prompt display. If you cache an AEEPromptInfo structure for reuse later, just be careful: some of the members of the structure are no longer valid. Initially, I tried reusing this as-is, and this is where the instability started to creep in.

One other caveat: be sure to de-activate any controls on your display before throwing up the Prompt(); if active, they can bleed through in some cases.