Mapping Hardware to TUI Functionality (Windows CE 5.0)
The TUI is architected so that functionality required by specific hardware can be implemented cleanly in one location rather than being strewn throughout the TUI source code.
By continuing to use this division between hardware-independent and hardware-specific code, you might be able to minimize the amount of integration work to be done if the TUI application source code is updated at some future time.
Note The TUI can be used on target devices that support a widely varying set of hardware buttons. This topic doesn't discuss mapping input hardware to TUI functionality. For more information about integrating input hardware, see TUI Keyboard Hotkeys.
For example, traditional IP phone hardware meant to be used on an office desk has multiple speakers and microphones: a speaker and microphone in the handset and a speaker and microphone for use as a speaker phone.
IP phone hardware often also supports various indicator lights and LEDs. The interaction with this hardware is specific to the hardware itself.
The TUI manages the current state of the IP phone. Out of the box, this state can be one of the following:
- Idle
- Handset
- Speaker phone
The TUI does this management in a hardware-independent manner in the VoipApp.cpp file that resides in %_WINCEROOT%\Public\VoIP\OAK\Phone\TUI\App.
The hardware-independent code in VoIPApp.cpp calls hardware-specific dispatch code in the hardware.cpp file that exists in the same directory.
For example, code in Voipapp.cpp calls the CHardwareSpecificInterface::SetNewAudioMode method to handle switching between different speaker/handset modes. Similar methods handle turning LEDs on and off.
When the TUI detects that, say, the handset has been picked up and the phone is off-hook (using hotkeys) it calls into the hardware-specific code, which then turns specific speakers and microphones on or off.
The provided implementation of these methods in the shipping code is specific to Broadcom BCM91101 hardware. If you use different hardware, reimplement the appropriate methods for your hardware.
When these methods are called by a device running on a CEPC or Emulator, the m_cpHardware member variable, which points to a Broadcom-specific IVoIPPhone implementation, is empty.
(The IVoIPPhone interface is used only to implement methods in the CHardwareSpecificInterface class. You are not required to use this interface when implementing methods for your own hardware.)
The current implementation of the methods in hardware.cpp does nothing when m_cpHardware is empty.
Supporting New Hardware
The existing API supported by hardware.h should be sufficient to support audio state and specific indicator LEDs (for example, one that lights when the phone is in speaker phone mode).
To integrate with new hardware, implement the hardware-specific routines in hardware.cpp. The rest of the TUI application should not need to change.
To support additional hardware — say, an LED that lights when voicemail is available — add and implement new functionality in hardware.h and hardware.cpp, and call this functionality from the appropriate VoIPApp.cpp code.
To add additional audio devices (for example, a Bluetooth handset) modify the interaction between the CVoIPApp and CHardwareSpecificInterface classes, and ensure that the overall hook state (whether the phone is on or off hook) is maintained.
See Also
Customizing the TUI Application
Send Feedback on this topic to the authors