Java 2 Platform, Micro Edition (J2ME) is the Java platform for consumer and embedded devices such as mobile phones, PDAs, TV set-top boxes, in-vehicle telematics systems, and a broad range of embedded devices. Like the Java 2 Platform, Enterprise Edition (J2EE), Java 2 Platform, Standard Edition (J2SE), and smart card (Java Card) counterparts, the J2ME platform is a set of standard Java APIs defined through the Java Community Process program by expert groups that include leading device manufacturers, software vendors, and service providers. With J2ME, applications are written once for a wide range of devices, downloaded dynamically, and can leverage each device's native capabilities.
As globalization trends reach most aspects of software development, it impacts the embedded device community. If you want to reach the widest market possible, you'd better globalize your application appropriately so that it can be localized. Developing such applications in J2ME is different from ordinary J2SE applications in many facets. In this article, we explore the detailed content throughout the software development life cycle.
The development and distribution cycle of J2ME applications involves three roles: application developers, service providers, and end users. Developers create the software and provide the installation image to the service providers. The worldwide service providers deploy the application and deliver it to their local users. Then, the local users are the end users that use this software. Figure 1
Figure 1. J2ME application development and distribution
When developing J2ME applications for worldwide users, it's important to keep the following requirements in mind:
- The application provides a different UI according to the user's locale.
- The service providers are able to decide which locales and languages the application supports.
- The service providers are able to extend the application to support more languages.
- The end users are able to use different devices to access the application, for example, Pocket PC, cell phone, Palm, and so on. Additionally, the UI should be well formed regardless of the device type and display resolutions.
- The application is able to support different code sets for different operating systems. For example, it should support GB2312 for the Chinese version of Palm OS and Unicode for WinCE .Net.
The requirements for this globalization system are typical of those found in many embedded device application environments, especially for the application providers focused on the international market. They supply J2ME applications to many service providers from different countries. These local service providers then supply the download service to their local users. The service providers have their target customers, so they decide which locales or languages the application should support. For example, when a software provider in the United States develops a J2ME application, the application typically only supports English. However, when the application is sold to the Chinese market, it must support Simplified Chinese, Traditional Chinese, and possibly Japanese as well. Therefore, the service provider should incorporate Chinese and Japanese support for the J2ME application. The J2ME application should, in turn, allow the service providers to add the support for new languages without accessing the source code directly. On the contrary, the service provider only needs to add the localization packs for Chinese and Japanese and repackage the application using some simple scripts. Thus, when the local users download the repackaged application from the service provider, they get a friendly UI.
Developing a J2SE application that meets the requirements mentioned above is relatively easy because the J2SE platform provides support for internationalization and globalization. But for performance consideration and size limitation, the Java Runtime Environment (JRE) does not fully provide the J2ME applications with these functions, especially in CLDC/MIDP. Additionally, you can develop J2SE or J2EE applications that support several locales by binding corresponding resource files. This cannot be done, however, for J2ME applications because of the memory and disk size limitation of handheld devices. The size of the J2ME application should be minimized for performance considerations without having an impact on the application's usability. Therefore, the application should offer a mechanism for loading resource files dynamically that is not included in the JRE.
Keeping these requirements in mind helps you make your product more adaptable to the international market.
Based on the initial business requirements, the following key design objectives should be included in the solution:
- The architecture is capable of supporting all languages. Design an architecture that supports all languages.
- Remove the need for application developers to decide which encoding the application will support. Developers should only have to focus on business logic.
- Pay more attention to the UI differences in devices so that the developers won't have to. The width and length of a device screen impacts the UI design.
- Enable the service providers to extend the language support. This operation is completed during the deployment phase.
- Allow local users to select their preferred languages as provided by the application. The UI component should change immediately when the users switch the locale, without having to reset or reboot the device.
During the design phase, we address these objectives by:
- Defining a reasonable architecture or framework that complies with these objectives for the application. The architecture mainly consists of three parts: business logic, back-end resource, and UI rendering.
- Defining the methodology of managing the back-end resource, which includes the process of translation, invocation, and maintenance.
- Taking the multilingual support and device span into account during the UI design.
Generally speaking, the architecture decides whether the application supports globalization well. A good architecture should be flexible, extensible, and portable. In Figure 2, J2ME is the run time environment for the application and the foundation for the architecture. The concrete business logic of the application is often reusable, persistent, and portable to a variety of platforms. The idea of separating business logic from presentation is very popular in system design. In this architecture UI, rendering represents things visible in the user interface (for example, windows, table views, and buttons). Such elements can be associated with multilingual information, and they also change when the application is migrated from one type of device to another. Back-end resource refers to localization packs and device profiles, which are invoked by business logic and UI rendering as parts of the application.
Figure 2. The architecture for globalization applications
The benefit of this architecture is obvious. First, developers are allowed to focus on the business logic, without having to know what kind of UI rendering is used. Second, the architecture enables applications to have multiple views. Those views are based on the same business logic, but vary according to the language and device options. What's more, it is easy to maintain the code and understand the application behavior. Changes in one module have less influence on other modules. It enhances the maintainability, extensibility, and testability of the application.
Think about the following scenario: At the beginning, your application only supports one language and one device. When globalization requirements are raised, you find that to support one more language only one additional localization pack and UI rendering is needed. Although a real case might be more than this, this architecture provides you with a feasible solution to meet such requirements.
The localization pack is the most common kind of back-end resource. It is a set of language- and culture-dependent data. Device profiles describe the information of devices, which might contain the device type, screen size, and the supported encoding. the back-end resource is retrieved dynamically by applications at run time. This requires a unified framework to manage this resource. There is no specific requirement on the format of the localization pack; you can choose the most suitable one for your application, for example, XML.
How to store these localization packs is also up to you; either a database or a file system can be used. There should be a developer in charge of maintaining the repository and localization packs in it. If using a file system as the repository, the developer is required to define a detailed file structure for the storage of localization packs. When localization packs and device profiles are distributed for some device, they are retrieved from the repository and encoded in the device-supported encoding.
The process for translating localization packs is also very important. Developers are able to write and read the localization pack only in their own languages. However, if the application needs to support multiple languages, there must be an effective way to translate these localization packs. For example, developers can write the localization packs in English, which is understood by a majority of people in the world. Then, these localization packs can be sent to the local translation service center, where they are translated into the local language and sent back. In the design phase, the translation process should also be clearly defined.
If UI design is part of your design plan, you should pay extra attention to it. In general, J2ME applications run on various mobile devices such as PDAs, Palms, cell phones, and so on. These devices have a common ground with their limited screen size. Their designers are usually required to give a small, compact layout, which fits the screen of the devices well. In these situations, the text that is presented to users is a big problem, because the length of a sentence might change when it is translated into a different language.
In order to get an idea of how this will affect the application, you should localize the application in the languages that are known to be the longest in world. Languages such as Finnish and German are ideal for these kinds of tests, as shown in Figure 3.
Figure 3. Java String length comparison
Suppose the device screen allows only 15 characters per line. When local users select the German language, the UI component might fail to present an appropriate message. The most common situation is when only part of the text is shown, while others exceed the screen boundary.
The best solution is to identify the maximum number of characters allowed in any UI item. According to this guideline, we divide long sentences into short ones. Use of abbreviated translations is also sometimes necessary. The translators need to ensure that their translations do not lead to an expanded sentence that cannot be handled by the application. What's more, developers can also avoid these errors by using the right components. Some components, such as javax.microedition.lcdui.TextBox, automatically display long sentences in multiple lines when the sentence length exceeds the maximum length.
Before beginning this section, look at the J2ME API as compared to the J2SE API, as shown in Figure 4.
Figure 4. J2SE/J2ME globalization and localization API comparison
If your applications are based on CDC and the personal/foundation profile, things are not too difficult for you during implementation phase because most internalization- and localization-related API are still available. However, what if those applications are based on CLDC/MIDP? You have to face the tough reality about how to make these globalization-related classes available to your application. Here's some advice on a good implementation:
- Follow the design model. Develop the application to allow the single executable produced by the source compilation to handle the cultural needs of all supported locales.
- Use the appropriate encoding for the application, according to the device supporting the encoding.
- Implement a complete module that manages the location, loading, and accessing of localization packs.
- Implement the locale model to support the major categories of locale-dependent computing.
Implementing a single executable architecture
Complying with a good design typically leads to a successful project. A design plan is not expected to stay the same throughout, though. It is recommended that you refine the design plan during the implementation phase because any requirement changes might affect some of the design plan. Also, feedback from both developers and testers helps to improve the design plan.
One important feature of this architecture is the single executable. The built-in application provides total support for all languages. This is key to ensuring that a globalized application can be designed, built, and maintained efficiently and correctly. In order to reach this goal, localization packs and locale model are required.
Using appropriate encoding is our second suggestion. As you know, Java technology inherently supports Unicode. The easiest solution is to use Unicode as the default encoding. But, actually, the OS of a mobile device usually supports various encoding schemes. For example, Palm might support code page ISO-8859-1, while mobile phones in China support code page GBK. Therefore, when developers are programming for different devices, they should take these factors into account. Device profiles are used to store this encoding information for the application, and the application retrieves this information during the run time.
The localization packs should also be encoded according to the system encoding. To avoid code point loss, we suggest converting each localization pack by using an JDK executable file called native2ascii. This tool converts every non-ASCII character to the Unicode escape character. Applications are able to load these localization packs without any failure. But whether they are displayed to local users correctly depends on the supported encoding of the device.
The third consideration deals with invoking localization packs, and J2SE provides an easy interface for them. Resource bundle classes in the java.util package are a type of implementation. If the application is based on CLDC/MIDP, however, developers must enable Resource Bundle and Locale, which are not part of the CLDC/MIDP API. The Resource Bundle and Locale can be implemented by MIDP core classes, and, of course, you can also utilize the third-part API.
Implementation of Resource Bundle and Locale is actually not a difficult job. In fact, in the simplest case, you can even use java.lang.String to distinguish different locales such as en_US, zh_CN, fr_FR. Developing a lightweight ResourceBundle for MIDP (we call it YourResourceBundle) is kind of challenging. In general, if language packs are stored in property files, it's important to store the proprietary files in the right encoding. These files are packaged in a JAR file with other application classes. YourResourceBundle first reads these proprietary files by the getResourceAsStream(String name) method of java.lang.Class. It then parses the stream to get the right name/value pair, which might take some effort. YourResourceBundle provides a small and simple subset interface of java.lang.ResourceBundle. Because the YourResourceBundle class is based on MIDP core classes, it is available for both CDC/Profile and CLDC/MIDP. Now you can utilize YourResourceBundle to access the localization packs. Most of these operations occur in the UI rendering module of the application.
Implementing generic locale model beans
Locale model is the last item we want to review. It contains assumptions about cultural features, which usually include numbers and mathematics, currency formats, the date, telephone numbers, and so on. The requirements to implement some of them are met during the application development -- we'll call these objects locale model beans. Locale model beans are reusable modules to developers, so it's a common requirement that these objects be reusable to both J2ME and J2SE applications. The J2SE and J2ME APIs are different, though. For example, MIDP forbids the use of any floating-point types. As a result, you might think of constructing locale model beans based on the J2ME API. It is often not feasible to use only the J2ME API, however, because locale model beans are not powerful enough to meet the J2SE applications.
Our solution here is to split the locale model beans into separate classes so that one class contains the J2ME-compliant functionality, and the other class contains the J2SE-only extensions. For example, first you write the J2MENumberFormat class based on the MIDP API. This class only provides one format method, which supports the long type number. While the J2SENumberFormat class extends the J2MENumberFormat, it provides an additional format method for double type numbers. In this way, your customized classes for globalization have two orientations, and each one is suitable for its run time environment. The class diagram is shown in Figure 5.
Figure 5. Class diagram of the local model bean
Testing is an important part of the software development process, and becomes more complicated when globalization applications are involved. Like any non-globalized application, your applications require a unit test, integration verification test, system verification test, and more. In addition to these tests, a translation verification test (TVT) is required. Because your application supports many languages, it's not feasible to verify the translation in one centralized workplace; instead, there are two ways around this issue.
If your application can be run on a device simulator, it is recommended that you have the application examined by testers in different countries. These testers verify the translation based on the test cases. Every time a defect is detected, developers should fix it and rebuild the application. Then, a new version should be sent to the testers. Various tools can assist with this to achieve better efficiency.
If your application can only be run on a particular device, the testing process has to change. It is unrealistic to let each tester have one device on which to deploy and test the application. The common solution is to capture the UI elements that contain the globalization text. This can be done by the developers or owners of the test cases, who will send them, along with the pictures, to the testers. Developers then fix any defects found by the testers, and resend the correct UI element to the testers.
Developers usually build, test, and evaluate an application on a platform similar to the one on which the application is to be deployed and run. Development of wireless Java applications is more challenging than most because they are typically developed on one platform (such as Solaris or Windows), but deployed on a totally different one (such as a cell phone or PDA). Also, they are typically developed in one particular language (such as English), but deployed with many locales (such as a simplified Chinese and English). The deployer should select the devices and the locales that the application supports. According to these factors, the application is repackaged and distributed in different languages. The representative process could be described as Figure 6.
Figure 6. Workflow of the application deployment process
The deployer could edit a deployment description file, and select which of the devices predefined in the development phase are supported in the J2ME application. Thus, the devices' profile files describing the specified screen size or resolution are included in the prepared package. Secondly, the deployer edits the locale list, which might not be defined in the development phase, and adds all of the locale-specific resource files to the packages. Finally, the deployer can repackage all of the binary code, the device profile, and the language packs into several file types in terms of the selected devices (for example, PRC format for Palm).
Now the new package is ready to serve the local users with multiple locales and multiple devices.
This article introduced you to a method for developing globalized J2ME applications. It is applicable to both existing and new projects, and provides a feasible way for all of the traditional applications to evolve into globalized applications.
- Read through the Redbook "e-business Globalization Solution Design Guide: Getting Started", from the collection of IBM Redbooks.
- The Java Web site breaks down the J2ME platform and offers downloads and related event listings too.
- Check out the "Globalization Insider", a part of the Lisa (Local Industry Standards Association) Newsletter for globalization, internationalization, localization, and translation.
- Take part in IBM's forum discussing globalization, including topics such as multilingual search engines.
- If you're working with Domino, you can download the Localized Server Kit to language-enable it from English to any of 10 other languages.
