Specifications

5-21
Cisco Unified IP Phone Services Application Development Notes
OL-22505-01
Chapter 5 Internal URI Features
Application Management URIs
Note The other component of the Application Management API is the Application Management Event
Handler, see the “Application Event Handlers” section on page 3-31 for details.
When an Application URI request is made, it has a specific application associated with it (not just the
application context) and that action can only be taken on that specific application. The Application
specified in the appId parameter (of the displayable XML object) must be active at the time the action
is requested, or an error will be returned.
This prevents open, but not active, applications which are buried on the application “stack” from closing
the entire application context which would also close the active application, potentially disrupting the
user’s interaction with the application. This also means that if an application closes or becomes
non-active (for example, if user navigates out of an application, or a new application is pushed to the
context) any pending Application URI requests are immediately cancelled.
Note The 6900 series IP phones cannot add phone service under application due to hardkey mapping.
URI Format
App:action:priority:idleTimer:applicationId
Where
action = action to be taken with the application. Values include:
• RequestFocus—Makes a request to the application manager to bring the application context
(window) containing this application into focus (maximize). This is a request, not a demand, as
higher priority applications may prevent the application from actually gaining focus. Applications
must use onAppFocusGained event handlers (see the
“Application Event Handlers” section on
page 3-31) to know when focus is actually gained.
– If the requested application is Open, but not currently Active, this request will not succeed (error
response).
– If the application already has focus, the request has no effect.
• ReleaseFocus—Makes a request to the application manager to relinquish focus to another
application context (essentially, a “move-to-back” request). Applications must use onAppFocusLost
event handlers to know when focus is actually lost (see the
“Application Event Handlers” section on
page 3-31).
– If the application does not have focus, the request has no effect.
– If there are no other applications open (available to receive focus) then this application will
retain focus.
• Minimize—Makes a request to the application manager to minimize the application context
containing this application. This request always results in the application (eventually) being
minimized. If the application has focus when this URI executes, the onAppFocusLost event handler
will be invoked first, then the onAppMinimize handler (see the
“Application Event Handlers”
section on page 3-31).
– If the requested application is Open, but not currently Active, this request will not succeed (error
response).
– If the application is already minimized, the request has no effect.
• Close—Makes a request to the application manager to close the application context containing this
application.