high level display screens in j2me factory

For the last several years, OCI has published a series of articles describing the basic features of the Java 2 Micro Edition (J2ME) including the Connnected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP). At the time, J2ME and CLDC/MIDP were, for all practical purposes, synonymous. Although many new features of J2ME were in the Java Community Process (JCP) pipeline, including a much-desired and now never-to-be PDA Profile, they were slow to materialize.

At last, J2ME is maturing at the same rate as the rest of Java. The JCP, which defines the new features that will become part of the Java platform, now features 62 specifications relating to features for J2ME. Of these, two of the most important are the Wireless Messaging API (WMA) and the Mobile Media API (MMAPI). WMA was discussed in a previous SETT article. In this article, we focus on the Mobile Media API and provide examples for audio and video playback.

MMAPI provides a generic mechanism to play back and record time-based media such as audio and video. An arbitrary number of formats can be supported, limited only by the capabilities of the device. The API is designed in such a way as to be extensible to new formats as they become available while at the same time supporting devices with limited abilities.

Many of the ideas for MMAPI are taken from the Java Media Framework (JMF) but MMAPI is not a subset of JMF. Whereas JMF targets full-featured Java 2 Standard Edition (J2SE) systems, MMAPI is aimed at the much more limited CLDC environment. MMAPI can support others configurations including the Connected Device Configuration (CDC) but the goal is to enable a rich audio and video experience on mobile devices. Therefore, memory efficiency and performance are two key design goals of the MMAPI expert group.

In other words, MMAPI allows us to develop software for mobile phones, pagers, and PDAs that can play and record both audio and video. In addition, cameras are supported so that a photograph can be captured and used within a custom application. In reality, MMAPI-enabled devices are still new on the market and since the API is targeted at limited devices, not all functionality is required. For example, it appears to be quite common now for mobile phones to support still-image capture but not full motion video.

A data source can be anything that provides media data, including files, resources in the classpath, or a network connection that provides streaming data. The specific formats that are supported are determined by the device that you use. MMAPI specifies Java properties that list which formats are available. The properties are audio.encodings and video.encodings. Each contains a space-separated list of supported formats.

Although MMAPI contains an abstract DataSource class, you do not create it directly. Instead, you must specify a valid URL that points to the data. See Table 1 for examples of valid data source URLs.

In addition to a data source, MMAPI provides access to one or more appropriate players. These players provide general functionality like starting and stopping playback, and can indicate the duration of the recording.

MMAPI is also capable of recording audio and video as well as capturing images from a camera. Example URLs for audio and video playback and capture are listed in Table 1.

The Mobile Media API provides a limited set of classes and interfaces. In fact, only 4 classes are defined along with 18 interfaces. As is becoming common with Java APIs, the specific implementations of the interfaces are provided by the device manufacturer. Table 2 provides a brief description of each class and Table 3 describes each interface. The more important classes and interfaces are in bold.

Marker interface for a class that provides specific functionality to manipulate the medium. For example, a VolumeControl can be used to raise or lower the volume on audio or video playback.

When the members of the MIDP 2.0 expert group (JSR 118) decided to include audio support, they made sure that it was provided as a subset of the Mobile Media API. To do otherwise would fracture the Java platform, requiring similarly-featured software to be written differently depending on the platform it was to be run on.

The audio support in MIDP 2.0 includes most of the basic audio functionality discussed in this article. In fact, the audio examples in this article will run under MIDP 2.0. There is no support for video. Tables 2 and 3 indicate which MMAPI classes are supported in MIDP 2.0.

In addition to playing prerecorded sounds, MMAPI-enabled devices can also generate tones dynamically. This means that we can now write applications that generate sound. For example, it would be relatively straight-forward to create a music composer application.

Tone generation can be accomplished in one of two ways. For simple situations, the Manager.playTone(int note, int duration, int volume) method is used. For more fine-grained control or to play a sequence of tones, a ToneControl must be created from a Player.

Here is a simple MIDlet that generates a single tone. Notice that the MIDlet destroys itself after playing the tone so that it can be invoked multiple times.

A tone sequence must be defined following the format specified in the MMAPI. Unfortunately, once a player is realized, the tone sequence cannot be changed. In the example below, we play the same tones 5 times, each time at a slightly lower volume. Click here to see the full source code.

First we must create the tone sequence. Since the sequence has the volume embedded in it, we must recreate the sequence with the new volume each time we play it. Before creating the sequence, however, we"ll define some useful constants corresponding to some of the notes on the scale.

To play the sequence, we must do a little more work than to play a simple tone. Instead, a tone player is used to create a ToneControl. The tone sequence must then be defined in this control before the Player enters the prefetched or started state. That is, the player cannot acquired all of its resources before the tone sequence is defined.

The PlayerListener interface requires a playerUpdate method to be defined. In this example, the method uses the END_OF_MEDIA event to trigger the creation of another player with a tone sequence set with a lower volume. It would have been nice to be able to reuse the same Playerwith the different sequences. However, the lifecycle of a Player does not permit this. Once a Player has entered the prefetched or started state, it cannot transition back to a state earlier than prefetched. In other words, a Player can only be used to play one data source. It can replay the same source but it cannot be reused with a different source.

It is relatively straight-forward to play video using similar techniques as for audio. The following code snippet shows how to display full-screen video. (To view the code for the entire application, click here.) Figure 1 shows a full screen display in the J2ME Wireless Toolkit. We must provide a Canvas for the video to be drawn in. Since Canvas is abstract, we define a concrete subclass which does not do anything. The application constructs a player by specifying a valid URL. It then adds a PlayerListener to the player. This listener will be informed of state changes in the player including when the video clip has reached the end of the media.

Before proceeding with the time consuming task of realizing the player, the application first displays a busy screen to the user. Once the player has been realized, meaning that the necessary resources have been allocated and fetched, the application asks the player for a video control that is appropriate for the platform on which it is running. We specify that the video is to be displayed in full-screen mode on the Canvas using VideoControl.initDisplayMode().

In addition to full-screen video, we can display video on a portion of the screen as part of a more feature-rich user interface. Figure 1 shows an embedded video display in the J2ME Wireless Toolkit. The example below is only slightly different from the full-screen example. Here, the VideoControl.initDisplayMode() method creates an Item which can be placed on a Form for display. The Item class is a GUI component defined in the javax.microedition.lcdui MIDP GUI package. Because this example runs only in a MIDP environment, the second parameter to VideoControl.initDisplayMode() can be null. In an AWT environment, the returned display would be a java.awt.Component. In a mixed environment where both AWT and lcdui are supported, the second parameter must specify either "java.awt.Component"; or "javax.microedition.lcdui.Item".

Now that you have whetted your appetite with this article, you will no doubt want to start programming with the Mobile Media API. One easy way to do this is to use the Sun J2ME Wireless Toolkit 2.1. This latest version has support for many J2ME optional packages including MMAPI as well as support for MIDP 2.0. The toolkit is configurable so that J2ME applications can be tested in a MIDP 1.0 or MIDP 2.0 environment, with or without MMAPI.

To run the examples used in this article, download the source code. Unzip the source code to C:\WTK21\apps (where WTK21 is the installation directory for the wireless toolkit). Place the Rabbit2004.mpg and bark.wav files onto your local web server. If your web server is running on a different machine, you will have to modify the example code to point to it. Start the wireless toolkit KToolbar and open either the MMAPIAudioDemo or MMAPIVideoDemo project. Then build and run the demos.

The Mobile Media API provides software developers with tremendous opportunities to enhance applications with sound and video never before available on small devices. This opens the door to creating a much richer experience for the end user, whether it be for gaming, business, productivity or other, more specialized applications.

As always, when dealing with J2ME across many different devices with different form factors from multiple vendors, it is always important to test your application on the targeted deployment device. Since much of MMAPI is optional and media formats may or may not be supported, it becomes especially important to test under real deployment conditions.

This series targets mobile developers more accustomed to J2ME than BREW or even BREW developers interested in lighter and more efficient code production. Largely inspired by the Java GUI model, the present BREW_J2ME framework deals with what’s known in J2ME as a “high-level interface.” It is far from being an exact J2ME match—reasons will be discussed in the article—but exhibits a similar domain abstraction.

We will begin by quickly discussing the gap between BREW and J2ME and how we can narrow the distance, by providing insight into the design process. A thorough presentation of the framework follows.

Since the beginning, Qualcomm tried to position BREW as language neutral, with C/C++ as the best choice—other options being always available for application development [1]. From a technical standpoint, the theory is perfectly plausible—a new language can be always implemented as a static extension, wrapping native BREW functionality. As an added bonus, being an extension, it can immediately reap all the benefits of BREW Distribution System (BDS). This is on the bright side. But what’s left in the shadows?

Such an implementation will be inherently slower (all the OS calls are mediated by BREW) and bulkier than the same implementation directly on top of the OS. Now, speaking of J2ME: BREW offers much more functionality than standard MIDP (even 2.0)—meaning that probably a non-standard API will be offered to fill the gap.

But, of course, choosing one language over another is mostly a business decision and there is no point in comparing their merits. What’s more attractive is to offer Java developers a more familiar way of writing BREW applications using C++. Obviously, this endeavor implies knowing the limits and differences between J2ME and BREW from the point of view of development.

Some differences stem from the Java vs. C++ architectural debate—for example, memory manipulation, multiple inheritance, type safeness, generics, and so forth. There is another category derived mostly from BREW limitations—prominent examples are lack of support for static variables, level of support for C++, cooperative multitasking, developer not insulated from watchdog activity, and the like. Of course, Java on top of BREW means that somehow Java has to absorb all these differences. A third group of dissimilarities is due to a basic design decision such as event model, components, and so forth. And of course, as mentioned before, J2ME is a platform-independent set of specifications with no counterpart for some BREW functionality.

Our declared goal is to ease the creation of “high-level interface” code and associated logic, making life easier for Java developers. This means that, theoretically at least, we could be able to write code like this:

As we could see in the overview, there are various forces influencing the design. Here are some examples in no particular order: no built-in garbage collector; no static variables = no singletons in the sense of [2]; no root Object but safe type generics, and so forth. Considering all these factors, it becomes clear that code as above cannot be written freely in BREW. Reasons might be:

One of the most important decisions is related to memory management and objects lifetime. If there is no delete, who’s responsible for the destruction of our widgets? There are obvious answers, such as stack-based objects and smart pointers for a scope-defined life span or reference counting (that happens to coincide with BREW solution). One solution, used in previous articles, is to register objects and bind their lifetime to the life of the registrar. This implies an additional layer (the registry) and has the advantage of keeping track of all the resources in one place. There is another subtler advantage. too. A C++ application created directly on top of BREW is not a first-rank C++ object but merely a POD structure. That’s why real C++ manipulation explicitly requires such an insulation layer. We will call our registry DisplayableRegistry.

For convenience, every application inherits from an IMidlet abstract class, responsible for declaring and implementing dummy application-level event callbacks (this subject will be discussed later), as well as providing access to the unique instance of DisplayableRegistry. This solves another issue—Singleton implementation. Please note that the mechanism supplied by IMidlet and dynamic polymorphism is not necessary, per se—static polymorphism can do the trick, too. Making every component aware of the application is somehow equivalent with giving them a context.

And, finally, making the registration process as well as the GUID-based BREW initialization process transparent requires an additional construct—a factory. Our first line of code is now:

The next concern is event handling. Apparently, there are important differences between BREW and Java: a unique ID, event loop mechanism versus an implicit, observer-based one. I say “apparently” because one can move freely from one mechanism to the other. Even more: J2ME, for example, shares one of the weaknesses of BREW—the command listener implementation is a close relative of the BREW event loop—usually a hard-to-maintain, huge “switch.” On top of this, listeners are weak-typed constructs, exposing a Displayable interface that has to be cast by the user. Our framework offers a safer approach with type safe, J2SE style listeners. For example, the ListImpl class defines a listener:

Java has a more elegant getSelected() mechanism instead of unique labels to be passed to IMENUCTL_AddItem. This can be easily implemented by using the ubiquitous DisplayableRegistry, this time generating unique numbers to be used internally as IDs. Please note the use of a policy to faster retrieve the IDs in some particular cases.

A striking difference between BREW and Java is error handling, when RTTI based exception handling is not available or might be considered too expensive to be used in BREW. Emulating a try/catch mechanism using setjmp/longjmp is not directly applicable due to problems in destructing auto objects, but other techniques are available (see [4], [5]). As a convenience, we provided an ErrorHandler as a policy—a way to gracefully provide error tracking information.

Our simple application will deal with two lists, each one having four items—{“1″,”2″,”3″,”4”} and {“A”,”B”,”C”,”D”}. Pressing “1,” for example, takes us to the correspondent “A,” pressing “C” switches to “3,” and so on. This logic is embedded in the event handlers: my14ListUsage and myADListUsage.

This first attempt didn’t cover important subjects such as multi-control screens, handling events other than EVT_COMMAND, and controlling the registered resources. The next installment will discuss all these topics as well as mechanisms to extend the framework.

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users" wishes when a user submits their information through our Contact Us form.

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

If a user"s personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user"s personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user"s account.

Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson"s commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice

To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

The application is not very complex. It shows one side of the dice ( it"s selected randomly ), and each time the user presses the fire button or the "5" key, it just generates a new random integer between 1 and 6, and shows the appropiate side of the dice.

Why does DiceController implements an interface?. Because that interface is the reference that the MIDlet will have of this class. But we"ll see it later.

Every J2ME application must be built around a class that extends MIDlet. That class ( at least in this example ) will have the responsibility to manage all the high-level button handlers ( it will handle the main application buttons, those asigned to the phone"s soft buttons ). But in this example, I want to track also some of the phone"s keys ( fire and "5" ), so I will need also to write a class to manage them. And that class must be a Canvas.

This class extends MIDlet ( that"s mandatory ), and like every midlet, it inherits three methods ( startApp, pauseApp, destroyApp ). I"ve also created three commands ( exitCommand, aboutCommand, backCommand ), that will be asigned to the soft buttons.

When this class is instantiated, it creates an instance of DiceCanvas ( we"ll take a look at this class later, but it extends Canvas ). It also registers itself as a listener of the commands that are passed to DiceCanvas.

The method commandAction handles the high-level interaction. When the user selects "about", it creates and instance of HelpScreen, and sets it as the current display.

Do you remember the interface implemented by DiceController?. Now, the reference to DiceController is typed IDiceActions, so DiceCanvas only knows that there"s a method called rollDice that returns a number, but it doesn"t know the class that implements it.

The paint method is inherited from Canvas, and is executed every time we want to refresh the display. So there, we draw the text and icons we want to show. The display is cleared with every refresh, which is not very efficient, but that will be changed in the next version. we just paint a different icon with every refresh, depending on the result of rollDice( ).

append("You can roll the dice using the fire button or the "5" key\n\nDeveloped by Cesar Tardaguila\nIcons by Celia Carracedo\n\nhttp://www.design-nation.net/en");

There are some things that have to be improved. First of all, the whole application is a bit heavy ( about 18 Kb ), due to the icons used to represent the Dice. So, in the next version, I"ll try to draw those icons using the drawing API. I"ll also try to add some animation, just to make it as similar to flash as possible, so I"ll have to introduce some Thread management. And the way the display is refreshed should be improved too.

The current state of the wireless world is downright exciting. Already, technologies have been implemented that allow users to enjoy a freedom of mobility never before thought possible. Building on that excitement is a whole new set of technologies that promise to cut the tether forever. To address this, we put two of our experts together to talk candidly about the respective technologies, debate the pros and cons, and give some insight about what we can expect in the future.

Ana: WAP (Wireless Application Protocol) was designed to allow wireless devices, and their limited screens and connection speeds, to access Internet and intranet applications. Phone.com, Ericsson, Nokia, and Motorola founded the Wireless Application Protocol Forum in June 1997, an organization that has grown to include hundreds of members. The goal was to offer a license-free standard to the entire wireless industry so that anyone would be able to develop WAP-based services.

And they have met that goal. WAP is an evolving standard but has already built a significant degree of industry support, making it the standard of choice for delivering and presenting wireless Internet services to the market of handheld devices.

WAP standardizes access not only for mobile phones but also for PDAs (personal digital assistants) and pagers. It works with all major wireless networks -- including CDMA (Code Division Multiple Access), GSM (Global System for Mobile communications), TDMA (Time Division Multiple Access), and CDPD (cellular digital packet data) -- over circuit-switched, packet, or Simple Messaging Service and can be built on any operating system, such as Windows CE, Palm OS, EPOC, and JavaOS.

WAP-based sites typically present the information in one or two lines of data: company name and phone number; flight numbers and times; currency and exchange rate, etc. This is the information that WAP is good at handling, and it is quick and easy for individuals to access. But WAP is not for everyone. Due to its bare-bones nature, WAP benefits individuals with a high demand for mobility the most.

Tim: On those same lines, Java 2 Micro Edition (J2ME) was developed specifically to address the vast consumer space of small devices, ranging from smart cards to pagers. This space, with its limited memory and display constraints, has proved to be an ideal environment for Java.

But before we venture too far into what J2ME is and the benefits it provides, it might make sense to state up front what it is not, and that is a replacement for WAP. Those who follow this space will quickly agree that, instead of looking at it as a WAP competitor, J2ME should be looked at as a complementary technology used to further expand the usefulness of wireless access and applications.

As you mentioned, WAP is a browser technology that allows users to browse WAP-enabled Web sites. Unfortunately, although useful in what it does, it does have a few shortcomings, including security and the fact that it requires constant airtime for stand-alone or offline operations.

When coupled with J2ME, however, users will now be provided with a full-featured Java-based application environment from which to enhance their experience. What makes it especially appealing is the fact that implementation is as easy as having your users download the application via their standard WAP browser.

Furthermore, by employing this type of technology, users will no longer be restricted to the limited monochromatic interfaces seen on WAP devices today, but rather we will enjoy full-color, animated graphics and applications that are much easier to navigate. Once the Java application has been stored on the handset, it can then exchange data with back-end information systems using the existing WAP infrastructure.

With that said, users will also be happy to know that applications developed with J2ME are upwardly scalable to work with Java 2 Standard Edition (J2SE) and the venerable Java 2 Enterprise Edition (J2EE) with little rework required.

The devices will cover a wide base of end-user needs, and phone manufactures will continue to improve and develop newer and more sophisticated devices that will continue to support and enhance services and the user"s experience. Because WAP is supported by all major phone manufacturers, it is very likely to become very successful.

I believe that J2ME will also triumph, Tim, as phone-manufacturing market leaders such as Nokia, Motorola, and LG Telecom also support it. Java is also an established program, and J2ME will appeal to developers, which may lead to better wireless applications. Some individuals may not take J2ME seriously right away, however, because Java has been traditionally better-suited as a desktop-and server-based language and therefore appeals to mainstream developers more than it does to embedded-system builders.

Tim: I could not agree with you more, Ana, except for the statement that J2ME is not being taken seriously. In fact, if you consider the upcoming 3G (third generation) standard, most vendors are already considering the use and inclusion of the technology. Moreover, once more individuals realize the huge potential that Java can bring not only to their tethered applications but also to those that are wireless, I expect to see an even bigger adoption of the technology.

The only real problem I see with WAP, or more specifically WML (Wireless Markup Language), in the future is that, just like any specialized language or technology, few qualified individuals are or will be available. Here is where Java really stands proud: As long as individuals continue using it, and I would suspect this to be true for some time to come, a constant source of talent will be available.

Ana: WAP has been designed to leverage the established Internet infrastructure by taking advantage of investments already made in programming, applications, development tools, and Web servers.

WAP is also closely aligned with existing data networking standards and Internet technologies, including IP and XML, while focusing on the unique requirements of wireless access.

WAP enthusiasts expect that a number of wireless Web sites will program their content directly in HTML/XML in an attempt to eliminate the translation process and proxy server technologies required to support WAP. In fact, most developers of small-footprint microbrowsers will likely offer hybrid WML/HTML products so that others will be able to display either WAP"s WML or traditional Internet HTML content. There are four WAP toolkits available for software developers to use in the development of WAP-based services, with Dynamical Systems Research, Ericsson, Nokia, and Phone.com supplying them.

Tim: Although I agree with you that many tools exist for transforming content into WML, including one you didn"t mention, IBM"s Transcoding Publisher, an even larger number exist for creating J2ME applications. Whether your pleasure is Metrowerks" Code Warrior for Java or Sun"s J2ME Wireless Toolkit, chances are high you"ll find a tool capable of enabling developers to create feature-rich content and applications based on J2ME.

Ana: 3G is the generic term used for the next generation of mobile communications systems. 3G systems will provide enhanced services to voice, text, and data but will be known for their high speeds and multimedia data services.

As 3G becomes more widely available in the United States, home banking, ecommerce, and online trading applications will be modified for the mobile environment and videoconferencing. The wireless terminal will be the personal gateway to the world of voice, data, video, mobile Internet, and interactive multimedia communications.

Tim: I agree that once 3G has reached a saturation point more users will find the wireless experience appealing. From a J2ME standpoint, adoption is already taking place, as J2ME has been chosen as the industry standard for wireless devices by the Third Generation Partnership Project, a group responsible for defining the specification for the next-generation handset application environment.

Ana: WAP currently uses the Wireless Transport Layer Security (WTLS) specification, which some believe has notable holes. WTLS was specifically designed to conduct secure transactions over a low-bandwidth environment without requiring PC-level processing power or memory in the handset. For this to work, the WAP gateway acts as a translator between WTLS encryption and the Web"s standard, more robust SSL (Secure Sockets Layer) security protocol. The problem occurs when the data is handed over from WTLS to SSL, a process in which the data is decrypted and then re-encrypted, meaning that for a split second the data is not secure. Even though the data translation occurs within a secure data center, it"s still valuable for that split second. New versions of the WAP specification are expected to address this issue, but they will probably take awhile before they get resolved.

Tim: This is where J2ME, or more specifically Java, really shines, thanks to the fact that all Java applications, regardless of implementation, are restricted by a simple principle that untrusted code be placed in a sandbox, where it can play safely without doing any damage to the real world. When an applet or other piece of untrusted code is running in the sandbox, there are a number of restrictions on what it can do. The most obvious is that it has no access whatsoever to the local file system or system resources. Should you decide to allow access, a simple certificate is all that"s required.

J2ME has other benefits as well because it can support other Internet protocols. An example Sun gives is that you might download an Internet Message Access Protocol-based mail application and communicate directly with your back-end mail server, not only speeding the rate of data exchange but also doing so without using WAP.

For the developer in all of us who still is concerned with security, the toolkits mentioned above can also aid in building applications that make use of RMI (remote method invocation) between the handheld and a Java 2-compliant back end, further removing doubt.

With the simplicity of WAP, tthe strength of Java, and the promise of greater amounts of bandwidth approaching, users will find transforming content from plain to pristine something of a joy.

Ana: I couldn"t agree more with Tim. The combination of WAP, Java, and the increase of bandwidth is going to make it possible to access the Internet and keep in touch with your world, literally with your fingertips.