Customizing the Supplied UI

Other versions of this page are also available for the following:

• Windows Embedded CE 6.0 R3

8/27/2008

The User Interface (UI) provided by the sample, VoIP Phone Suite, is tested for usability and functionality and is provided in source code sample form. The four main applications that make up the components of the VoIP Phone Suite share responsibility for the UI presented. Each component is responsible for its own individual UI to support its functionality and PhCommon is used to provide support to the components for common controls and UI functionality. For more information about PhCommon, see Using the PhCommon Core Component.

You can take advantage of this in different ways.

• At a simple level, you can leave the UI as-is. Or you might keep the overall appearance and operation of the UI the same and replace just a few items.
  For example, you might replace the Windows graphic in the upper right corner of the UI with a graphic that represents your company or a third party such as a partner or customer.
  You might also add a screen here or a button there to provide additional functionality, but leave most of the UI the same.
• You can also completely replace the UI with one that provides whatever functionality you want in whatever way you choose.
  For example, you could replace the current Win32 custom control UI with one that is based on HTML or another UI technology.
• The controls in the VoIP Phone Suite are custom Win32 controls. This customization is performed by PhCommon in conjunction with the use of resource (.rc) files. Altering the way PhCommon handles the controls, including the drawing of the controls, or directly modifying the various resource files, will alter the user interface for the entire VoIP Phone Suite sample application set.

UI Changes can be Non-Trivial

Example situation: Using Other Applications with the VoIP Phone Suite

The suite is a set of four sample applications that use six VoIP Core components, not discounting other OS components used as well. These specialized dialog windows are design to be in portrait 240 by 320 pixel mode and to take over the entire screen of the device, giving a seamless, unified and elegant appearance.

Other applications obtained from Catalog selections are not necessarily the same and would likely have a more typical Windows UI appearance, including the Windows System Tray.

Adding other OS components or applications is easy, you just select the Catalog items you desire in Platform Builder and build the resulting OS. However, matching UI appearances is not easy and not generally recommended since you would have to interfere with the messaging and drawing routines of the applications, which could lead to extra time testing and debugging issues. Still, using the applications is an option if you wish to add quick functionality to your design. You just might want to alter the UI of the phone suite rather than hassle with trying to customize the other applications to match. The VoIP Phone Suite comes as sample code and is designed to be modified to suit your purposes.

Suppose you do wish to add the system tray to your design, in that case, you will need to modify each custom screen of the VoIP Phone Suite so that it no longer takes over the entire screen, but allows space for the system tray to be present as well. You would need to move the four buttons along the base of each screen upwards so that they would not be blocked by the tray.

You can do a hard-coded version of this by directly modifying the resource files containing the dialog templates. A more elegant way is to dynamically redraw each window based on any new circumstances - like the addition of the tray in a particular location. However, this would take much more work to do and is not a trivial change to make. You would have to alter the drawing and sizing areas of the entire suite. Most of the actual drawing is contained with the PhCommon dynamic link library, but you would still need to alter the painting, sizing and moving commands contained within each application of the suite as well.

In the long run, if you expect to be using multiple applications and want them all to act seamlessly and effortlessly together, modifying the code of the suite is the best way. Since doing this also would allow you to bypass using the system tray as a mechanism for switching between applications. You would likely use the IP Home Screen application. Currently, IP Home Screen is the starting place for launching the other applications of the suite and monitors them. Augmenting this application to include any other applications you wish to launch and at the dimensions you want, from Catalog choices to your own custom applications, would be the most seamless way to handle multiple shell applications.

If you are using the default drawing abilities of the suite, then you would still need to create your own custom resources as well as your own custom windows, placing new menus and buttons as suits your needs. However, as said previously, you might want to invest time and effort into creating and using your own UI display system as well.

You also might want to not only change the UI, or augment the applications launched, but change the functionality beneath. For example, you might want to add presence or IM calls using the RTC Client API into the IP Dialer application rather than using the Messenger application. IP Dialer is the only application of the suite that uses the RTC Client API and handles all call control, so adding functionality to it would not necessarily impact the other applications. You would likely want to modify the database usage as well if you wanted to store IM or presence information. This leads you to the IP Contacts application, but again, each application handles a specific set of tasks, making it easier to modify or augment features.

You might even just mimic the IP Dialer code and write your own small internet messaging (IM) or presence application that calls RTC directly and stores the results. It is entirely up to you.

Example situation: Changing the Screen Orientation from Portrait to Landscape

Again, as with the previous example, this involves modifying the resource files and possibly considering making the changes dynamically as well.

You could have dialog templates for both cases (portrait and landscape) with all the custom controls laid out properly and created or modified if necessary for the different screen layouts. This is if you plan to allow rotation on the fly. If the screen is not intended to rotate, then the fastest route is simply to design your layouts as you want them and only in the orientation you need.

This could also be applied to having different international layouts and languages.

To make the changes dynamically, again, you will have to be able to draw your controls and windows on demand, possibly using bitmaps in different orientations or using images that will work well in either orientation. Or you could simply draw your controls without resorting to bitmaps.

Like the previous example, this is not a trivial undertaking, but may pay off in the long term if you anticipate such regular changes to your screens.

Again, using the sample code's current mechanisms or devising your own, is entirely in your control.

The Underlying Non-UI Functionality

Regardless of the route you choose, you can continue to call the same functions that the VoIP Phone Suite calls.

This insulates your UI from underlying changes in general phone functionality, SIP signaling, and media transport, and enables you to change these pieces without requiring that you change the corresponding component UI.

It also means you can continue to use the general phone functionality provided by the other components, like call log and caller information.

For more information about good UI design practices, please see User Interface Design Guidelines.

For more information about multilingual language support and other localization and internationalization issues, please see Multilingual User Interface (MUI) and International.

For more information about using the integrated development environment (IDE) of Platform Builder, source code control and general Platform Builder questions, please see Platform Builder User's Guide, Platform Builder IDE and Source Code Control.

For more information about customizing or using the VoIP Phone Suite sample code, see Customizing the VoIP Phone Suite.

See Also

Tasks

How to Develop a VoIP Phone

Other Resources

Common VoIP Phone Customization Tasks
Real-time Communications (RTC) Client API