Re: STK DisplayText changes proposal

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]

Hi Guillaume,

On 11/23/2010 09:33 AM, Lucas, GuillaumeX wrote:
> Hi,
> 
> According to the 3GPP specifications there is some missing points in the SATK DisplayText implementation and I want to propose some API changes here.
> 
> 1. clear message after delay / wait for user to clear flag
> 
> This flag corresponds to the bit 8 of the command qualifier (see ETSI TS 102 223) and indicates how the message should be cleared by the UI.
> In the STK agent documentation it's indicated that this flag is handled using different timeout value for the Agent DisplayText method call. But that doesn't seem the case in the code: there is no check of the flag.

Andrew has to answer this one, it seems like there's a disconnect
between the implementation and the docs.  Probably just a bug.

> 
> For me it's to the UI to handle the way how the message must be cleared and not to ofono. With the current Agent DisplayText method API this is not possible as there is no indication if the message must be cleared after a delay or after a user action. So I want to propose the following change for the STK Agent:
> 
> Change    void DisplayText(string text, byte icon_id, boolean urgent)
> By        void DisplayText(string text, byte icon_id, boolean urgent, boolean clear_after_delay)
> 
> Where clear_after_delay boolean must be set to '1' for the clear message after delay case and to '0' for the wait for user to clear case.

Actually I really don't want to make this distinction.  The UI should
always give the user the option to clear the message.  So just
increasing the timeout when wait_for_user flag is set seems enough to me.

> 
> 2. Busy screen
> 
> The other missing point in the DisplayText implementation is the case of the busy screen.
> According to the sequence 1.2 of the ETSI TS 102 384 we must return a terminal response with the error "screen busy" when the ME is not in the idle screen and if the text message is not urgent. In the current implementation there is no way to return this type of error in the terminal response.
> 
> I propose to add a new error code ScreenBusy in the same way of what it's done for GoBack and EndSession event.

I can be convinced that this is a good idea.  However, in 99% of the
cases the STK session is started by the user, so the screen should never
be 'busy'.

Andrew, what do you think?

Regards,
-Denis