Writing Mobile Code Essential Software Engineering for Building Mobile Applications [Electronic resources] نسخه متنی

Installation of Runtimes and Other Required Components

If you have a specific device configuration in mind for your mobile application, you can optimize your installation for that device. On the other hand, if your mobile application is intended to run on the largest possible set of devices, you need to consider what the least common denominator device has on it and make allowances for dealing with components that some devices may be missing. This problem can be broken down into two different parts: (1) Target devices missing the runtime required by your application, and (2) target devices missing components that your application uses.

Dynamic Deployment of Runtimes to Mobile Devices

The ability to dynamically install the core runtime libraries required by your mobile application is important if you are targeting multiple generations of devices. For example, whereas the .NET Compact Framework v1.1 is supported on Pocket PC 2000, 2002, 2003, and later devices, no Pocket PC 2000 devices have it pre-installed in ROM, and most 2002 devices do not have it pre-installed either. It is only with the 2003 generation of Pocket PC devices that the .NET Compact Framework became a standard part of the platform. If your application is built to run on top of the .NET Compact Framework v1.1 and you want to run on the largest range of hardware, some devices will need to have this runtime dynamically installed in order for your application to run. This leaves you three options:

Only run on devices that have the needed runtime installed.
This is, of course, the simplest but least flexible option.

Package the needed runtime with the application installation.
This is the most full-service option but is also the most cumbersome because it requires potentially unneeded runtime components to be carried around with the application's setup program and requires potentially complex installation logic because different types of hardware may require different builds of the runtime. If most of your target devices already have the needed runtime version installed, it is a lot of effort for little gain.

Require users of devices without the needed runtime to manually install it.
Ideally your installation logic should be able to detect the presence or absence of needed runtime components. If only a minority of your target devices will require dynamic installation of components, it is probably sufficient to inform those device's users of the prerequisite and direct them to further installation instructions.

Note

Only some device classes support dynamic installation of runtimes and components.

As described previously, some devices are open and allow installation of software, and some devices allow only restricted software installations that may not include the ability to dynamically install a runtime. Additionally, only some device classes are capable of dynamic installation of runtimes for technical reasons. For example, the Microsoft Smartphone and Pocket PC treat file system memory differently, making it reasonable to support installing the .NET Compact Framework in a Pocket PC's RAM file system if needed but making this option infeasible for Microsoft Smartphones, which require the runtime to be ROM installed (although applications can be stored in the Smartphone's file system). For this reason, it is important to understand your target device's specification and extensibility capabilities.

Versioning of runtimes becomes an important consideration as well. Regardless of runtime technology used (for example, .NET Compact Framework, J2ME, J2SE, native code), updated runtime releases will occasionally occur and versioning will require consideration.

Many runtimes are backward compatible; for example, version 1.3 of a runtime may be capable of running code written targeting versions 1.1 and 1.2. If backward version compatibility is not supported, you have two options:

Probably the simplest solution is to produce a version of your application for each version of the runtime you want to support; this requires extra development and testing on your part but makes for the best end user experience.

The second option is to attempt to install the needed runtime version as described above.

Dynamic Installation of Needed Application Components

Components are any additional on-device technologies that your application is leveraging that are not part of the core runtime or operating system. For example, a popular component for mobile enterprise applications is a device-local database engine. Third-party graphing controls that your mobile application can use are another example. Along with the components themselves may come additional files. For example, an application that uses a mobile database engine may also have a prepopulated database file containing the data for the application to use at runtime.