UJML allows you to write programs which work in much the same way on many different devices. This is both because UJML does most of the hard work for you and because it provides a rich set of functions and entity argument values to determine device support for language features which your program can use to adapt to the device at run time.

The first step in adapting your program to a device is to determine the device context. See Determining Device Context. This context is the hardware and software capabilities of the device, and using this information you can then modify your run time state to match. The colors.ujml sample is a simple example of a UJML program which adapts to a wide range of device capabilities.

The next step to device independence involves your user interface design: Make certain your visual elements are scalable to a wide range of screen sizes, color support, and image support. See Screen Resolution, Color Support, Image Support. If your application uses audio elements you need to adapt those as well. See Audio Support. In the case of images and audio elements, you may need to provide the same images and sounds in multiple file formats. 

An equally important consideration is the modularity of your application. A highly modular application, with its functionality in different files which are linked or included, is more flexible and thus easier to port to a new device. See Anatomy of a UJML Application, Types of UJML Files. The Lunar Lander Sample and the Visual Elements Sample are examples of applications with support for a wide range of device capabilities. In the case of linked UJML modules an application may even provide several different linkable sub-programs with similar functionality and choose from them at run time based on the device context. 

Note: Each partition increases the memory usage of a UJML application. For this reason you must balance modularity against memory requirements and available memory on the device. Included files also add to memory requirements, although not as much.

Sometimes a device doesn't support a feature, but you can substitute something else at run time. For example, a device may not support drawing ovals on the screen. Depending on the needs of your program, you can replace the oval with a box, a picture, or not use the visual element at all. See Visual Elements. 

Which things may be substituted for others, and how you go about changing them, varies from application to application.

When a device doesn't support a feature which is required to make your program work, you need to display an appropriate error message during startup and then stop the program from continuing. This error message should include contact information and other pertinent data needed to help isolate the problem (for example the device type, your program version and a description of problem encountered). Try to make certain that even software failure is a good experience for the customer.

Even if your UJML application is only going to run on one device you should consider device independence during the design process. Doing this protects your investment by:

1. Easing upgrades for new versions of the device.
2. Making ports to new devices easier, should the market change.
3. Requiring more modularity in your code, thus increasing reuse.

In most cases, you will not have the luxury of designing for one device, but rather will be targeting several different devices. So why not make your application as device independent as possible and allow it to run on nearly everything?

Anatomy of a UJML Application, Types of UJML Files, Visual Elements, lunarlander.ujml, Visual Elements Sample