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