|
The Wireless Application Protocol (WAP) is an open specification that addresses wireless network characteristics by adapting several data-handling approaches already in use by Web protocols, and introducing new ones, where appropriate, to the special requirements of handheld wireless devices. The reuse of existing Web technologies eases the development of WAP applications, and make it similar to developing HTML-based Web applications since it is browser-based. Another approach to developing wireless applications is to use the Java 2 Micro Edition (J2ME) Mobile Information Device Profile (MIDP). MIDP is also an open specification that adapts existing technologies such as Java and the Web. Developing MIDP-based applications (also known as MIDlets) is similar, but not identical, to developing Java Applets in the sense they share a similar programming model. In either approach, Java plays an important role. In WAP, Java servlets and JavaServer Pages (JSPs) can be used to generate dynamic WAP content on the fly (not to mention that most WAP development tools are actually written in Java!), and in MIDlets, Java is the programming language for developing them. WAP and MIDP are not competing technologies, however. They are in fact complementary technologies as you will see here. If you are new to WAP, please see WAP for Java Developers, and if you are new to MIDP please see Getting Started with MIDP. This article presents a brief overview of the WAP and MIDP programming models, then it:
The examples throughout this article were developed using Ericsson's WapIDE and Sun's J2ME Wireless Toolkit. Programming Models The programming model of both, WAP and MIDP are in many ways similar to existing programming models such as the Web and Java. The WAP Programming Model The WAP programming model is similar to the Web programming model with matching extensions for accommodating the characteristics of the wireless environment. Figure 1 illustrates the WAP programming model.
As you can see, the WAP programming model is based heavily on the Web programming model. While WAP was not designed to use HTML, in some cases the data services or content located on the Web server is HTML-based. Some WAP gateways are capable of converting HTML pages into a format that can be displayed on wireless devices. But because HTML wasn't really designed for small screens, the WAP protocol defines its own markup language, the Wireless Markup Language (WML), which adheres to the XML standard and is designed to enable powerful applications within the constraints of handheld devices. In most cases, the actual application or other content located on the Web server will be native WAP created with WML or generated dynamically using Java servlets or JSPs. WAP 2.0 is moving towards XHTML, which is a reformulation of HTML 4.0 as an XML application. In HTML, there are no functions to check the validity of user input or to generate messages and dialog boxes locally. To overcome this limitation, JavaScript was developed. Similarly, to overcome the same restrictions in WML, a new scripting language known as WMLScript has been developed. The basic unit of a WAP application in WML is the card that specifies a single interaction between the user and the user agent. Sample 1 shows the simplest WML document with a single card. Sample 1: Hello.wml
When viewed on a WAP-enabled phone, Sample 1 is rendered and displayed as shown in Figure 2.
The MIDP Programming Model The MIDP programming model is a mix of the Java programming model and the Web programming model. MIDlets are developed using Java and compiled the same way you compile any Java application. Similar to applets, however, where an applet is described in an HTML file, a MIDlet or a group of MIDlets (known as a MIDlet Suite) is described in a Java Descriptor (JAD) file. while applets run in a Web browser, MIDlets run in a MIDlet management software (which is preinstalled on MIDP devices) that provides an operating environment for KVM and MIDlets where they run. Unlike applets, however, MIDlets do not get destroyed when they finish running. They remain installed on the device until they are explicitly removed.
In MIDlets, the basic unit of interaction is the screen, which encapsulates and organizes graphics objects and coordinates user input through the device. The WML example shown earlier in Sample 1 can be rewritten as a MIDlet as shown in Sample 2. Sample 2: HelloMIDlet.java
Even to the untrained eye, Sample 1 looks much simpler than Sample 2. It is the same idea with HTML-based applications and applets. Applets however, bring dynamic applications to the Web and it is the same thing with MIDlets. But remember, we are not trying to compare WAP applications with MIDlets here; as we mentioned earlier these are not competing technologies but complementing ones. When running on a Java-enabled phone, such as the Motorola/Nextel i85s, Sample 2 is displayed as shown in Figure 3.
Rewriting WAP Applications as MIDlets We now look at rewriting WAP applications as MIDlets. The idea however, is not to compare which one is easier but rather to show you the effort involved. We discuss how to rewrite decks, lists, input fields, buttons, and WML with WMLScript. Decks Multiple cards are grouped together in decks. A deck is the topmost element of a WML document. When the user agent receives a deck, it activates only the first card in the deck. Sample 3 shows a hypothetical guide for the city of Vancouver that consists for a deck composed of three cards. Sample 3: CityGuide.wml
When viewed on a WAP-enabled device, Sample 3 is rendered as shown in Figure 4a. Once the city card is loaded, you can navigate through it using the soft key on your device. Figure 4b shows what happens when the
Just as a WAP application may consist of multiple cards in a deck, a MIDlet usually consists of several screens, but only one screen at a time can be visible. The WAP application in Sample 3 can be written as a MIDlet as shown in Sample 4. Sample 4: CityMIDlet.java
When running on a MIDP-enabled phone, Sample 4 is displayed as shown in Figure 5.
Navigation in WAP and MIDP
As you can see from Sample 3, navigation in the Vancouver city example is done using the Lists A list in a WAP application can either be of a single choice or multiple choice type. Single Choice Lists In a single choice list, only one option can be selected. Sample 5 shows the WML code for a single choice list. Sample 5: Pizza.wml
When rendered on a WAP-enabled phone, it looks as shown in Figure 6.
MIDP supports single choice lists as well. The Pizza example shown in Sample 5 can be written as a MIDlet as shown in Sample 6. Sample 6: PizzaMIDlet.java
When it runs on a MIDP-enabled device, this example is displayed as shown in Figure 7.
Multiple Choice Lists In a multiple choice list, multiple items can be selected all at once. For example, Sample 7 shows a WML example of a multiple list for selection toppings for a Pizza. Sample 7: Toppings.wml
When it runs on a WAP-enabled device, it will be rendered and displayed as shown in Figure 8.
The WML Toppings example can be written as a MIDlet. As you can see, all that needs to be done to change from a single choice list to a multiple choice list is to use Sample 8: ToppingsMIDlet.java
When the
Input Fields Applications may need to input from users. Now we will see an example of a WAP application that requires the user to enter their name and phone number. This is done in Sample 9. Sample 9: Delivery.wml
This example uses another form of navigation -- buttons. When the Submit button is selected, the #db card (which is not shown in this example) will be loaded. When this applications runs on a WAP-enabled browser, it is displayed as shown in Figure 10a. When the user clicks on the menu, the Submit button shows up and the user can select it as shown in Figure 10b.
This example can be written as a MIDlet as shown in Sample 10. Sample 10: DeliveryMIDlet.java
As you can see, MIDP is more explicit in what kind of input is required. For example If you run this MIDlet on a MIDP-enabled device, it will be displayed as shown in Figure 11. In comparison with the WML example, note that in the case of MIDlets the commands are shown on the same screen and therefore there are no hidden paths. This makes MIDlets visible and more user friendly.
Validating Input with WMLScript So far we have seen how to rewrite WML applications as MIDlets. The question that may come to mind is what about WMLScript? If a WML page uses a WMLScript page, can this be rewritten as a MIDlet. The answer is yes. The example we will now look at is a login application that asks the user to enter a password. If the user enters the right password, the application displays a new screen. If the user enteres an incorrect password, a dialog box is displayed asking the user to try again. The WML code for this application is shown in Sample 11, and the WMLScript code (which is responsible for checking and verifying the input) is shown in Sample 12. Sample 11: login.wml
The WMLScript code is shown in Sample 12. Sample 12: login.wmls
When you run this application on a WAP-enabled device, you see something similar to Figure 12a. If the user provides an incorrect password, you see something similar to Figure 12b.
This login application can be written as a MIDlet as shown in Sample 13. Sample 13: LoginMIDlet.java
If you run this application, you will see something similar to Figure 13a (user provided correct password) and Figure 13b (user provided incorrect password).
As you might be able to figure out, as applications get more sophisticated there won't be really much difference in the amount of code to be written.
WAP and MIDP: what can they learn from each other? WAP and MIDP solve similar problems but each can learn a couple of things from the other. There are special features that are available in WAP but not in MIDP and vice versa. Here, I summarize the important features:
Integrating WAP and J2ME MIDP As mentioned earlier, WAP and MIDP shouldn't be viewed as competing technologies but rather as complementing ones. If you have any experience working with MIDlets, and more importantly downloading MIDlets on real physical devices (such as the Motorola/Nextel i85s cellular phone) then you might be aware that MIDlets are not currently being provisioned over the air. In order to facilitate over the air provisioning, there is a need for some kind of an environment on the handset that allows the user to enter a URL for a MIDlet Suite, for example. This environment could very well be a WAP browser. Therefore, similar to Java Applets that are integrated in HTML, MIDlets can be integrated into a WML page. The WML page can then be called from a WAP browser and the embedded MIDlet gets installed on the device. In order to enable this a WAP browser (with support for over the air provisioning) is needed on the device. Another alternative approach for over the air provisioning is the use of Short Message Service (SMS) as have been done by Siemens where the installation of MIDlets is accomplished by sending a corresponding SMS. If the SMS contains a URL to a Java Descriptor (JAD) file specifying a MIDlet Suite then the recipient can install the application simply by confirming the SMS. Conclusion This article discusses the programming model of WAP and MIDP and shows how WAP applications can be rewritten as MIDlets. The examples shown throughout the article illustrate that any WAP application can be rewritten as a MIDlet or a MIDlet Suite. MIDP provides a rich set of APIs for constructing MIDlets and provides an excellent navigational and interaction model. MIDlets combine excellent online and offline capabilities that are useful for the wireless environment, which suffers from low bandwidth and network disconnection. Integrating WAP and MIDP opens up possibilities for new wireless applications and over the air distribution models. For more information
Back To Top | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.
|
| ||||||||||||