high level display screens in j2me free sample

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 Java 2 Micro Edition (J2ME) gives Java developers the opportunity to leverage their skills onto a wide variety of mobile devices. Of course, mobile devices are diverse in their capabilities and horsepower, but J2ME abstracts away these differences by defining configurations and profiles, which, when taken together, provide a complete platform and API for application development on a particular family of mobile devices.

The Connected Limited Device Configuration (CLDC) and Mobile Information Device Profile (MIDP) combine to support the majority of low-cost mobile devices in use today, such as PDAs, wireless phones, and two-way pagers. In this article, you’ll get your feet wet with J2ME by building a small sample application.

The process of actually building, installing, and running an MIDP application is significantly different from that used for a standard Java application. So to do justice to the topic, I’ll dedicate a future article to it. For now, you’ll have to be content to examine the structure of a sample application. I’ve placed the code for a typical “Hello World!” application, called HelloJ2ME, in Figure A.

Not too impressive, I know, but good examples rarely are. As you can see, HelloJ2ME extends the base MIDP application MIDlet class and imports two package namespaces, javax.microedition.midlet and javax.microedition.lcdui. The former includes the application’s base MIDlet class, while the latter provides a set of Swing-like GUI elements for use in the application.

The MIDlet class provides three abstract methods that are used by the device’s application manager to communicate with the apps it runs. The startApp method is called immediately after the constructor and anytime an application is made active, not just when the application is initially launched. An application may transition between active and inactive states multiple times during a single run, so you should avoid placing single-use initialization code here, such as code to initialize the UI, since it will likely be executed a number of times. Use the constructor for this purpose instead.

The destroyApp method is called by the manager to indicate that an application is about to be shut down. Unlike startApp, this method will be called only once during an application’s lifetime, so it’s safe to place cleanup code here. In fact, because the MIDP doesn’t include finalize functionality for objects, you’ll have to perform cleanup here. At the same time, though, a typical mobile device is much less stable than your typical standard platform and will be routinely powered off or reset by the user. So you can’t really count on destroyApp being executed either.

The remaining abstract method, pauseApp, is a little weird at first blush. It’s meant to provide notification that the app is about to be paused because the user has switched to a different application or is using a function of the device that will prevent the app from continuing to run. Because most mobile devices lack the horsepower to be truly multitasking, this will probably happen to your app a lot. You should also be a good citizen and free any resources you can inside this method. When the application is resumed, the startApp method will be called by the application manager.

Of course, communication has to be a two-way street to be effective, and MIDP applications are no exception. MIDlet provides a set of final methods you can use to communicate with the application manager:

· NotifyDestroyed tells the manager that your app wants to be shut down. Calling this method will not result in your destroyApp method being executed, so you’ll have to call it manually.

· GetAppProperty retrieves configuration information about an app from a manifest or an application descriptor file, something I’ll discuss further in a future article. For now, it’ll suffice to think of this method as accessing a private initialization file.

As I mentioned before, the javax.microedition.lcdui package contains the UI elements used with MIDP applications. Most of the UI elements you’ll find here have analogous Swing counterparts, although the names are different, and the underlying event system works in essentially the same way for both APIs. You’ll still be registering event listener objects with controls, as I do in HelloJ2ME’s constructor. In this case, for simplicity, HelloJ2ME implements the commandListener interface itself and serves as the listener object for the sole Command object it contains. However, other techniques for creating event listener classes, anonymous inner classes, and dedicated classes will work just as well.

There are basically three families of GUI components defined in the lcdui package, which I group based on their base classes: Screen components, Item components, and what I’ll call Miscellaneous Displayable components.

Screen components descend from the abstract class Screen and provide the traditional window-like GUI widgets. The Form object used in HelloJ2ME is a Screen descendant that can contain and display GUI controls. Other Screen components include Alert, a dialog box; List, which displays groups of choices; and TextBox, a multiline text-entry screen.

Item components are the traditional controls, like the “Hello World!” TextField in the sample app, that all descend from the Item abstract class, which provides a uniform API for labeling, event handling, and displaying controls. ChoiceGroup, DateField, Gauge, ImageItem, and StringItem are other Item components.

Miscellaneous Displayable components all either descend from the higher-level abstract Displayable class or are in some way related to it. This group includes components like Command, a command button; Ticker, which displays scrolling text; Graphics, for displaying graphics; and Choice, an interface for manipulating predefined selections, which don’t really fit in another category.

The whole graphical shebang is managed by a Display object, of which each application has access to a single, private instance. This instance is retrievable via the static Display.getDisplay method, and it’s customary to hold a single reference to this instance in a member variable, as HelloJ2ME does in its constructor. In addition to methods for setting the focus to a particular screen element (setCurrent) and retrieving the element with the focus (getCurrent), Display also exposes a handful of methods useful for obtaining information about the display capabilities of the device, notably whether color is displayed (isColor) and how many colors are supported (numColors).

I’ll leave you now with a short list of things to keep in mind when developing Java applications for a mobile platform. First, you’ll be dealing with an abbreviated class library: no reflection, JNI, or, as I mentioned, finalization support. Second, you’ll be dealing with rather draconian memory restrictions, as most devices running the MIDP profile will have less than 100 K of dynamic memory available. As a result, you’ll need to keep a wary eye on the memory use of any algorithms you employ. Finally, keep in mind that any network connectivity will be limited in bandwidth and probably sporadic.

Stay up to date on the latest in technology with Daily Tech Insider. We bring you news on industry-leading companies, products, and people, as well as highlighted articles, downloads, and top resources. You’ll receive primers on hot tech topics that will help you stay ahead of the game.

Launch wireless toolkit via "Start" button ⇒ Programs ⇒ Sun Java Wireless Toolkit 2.5.2 ⇒ new Project... ⇒ In "Project Name", enter "Hello". In MIDlet Class Name, enter "HelloMIDlet" ⇒ Create Project ⇒ OK ⇒ Take note of the source file directory, e.g., "c:\WTK2.5.2\apps\Hello\src".

Write the following source code, using a programming text editor, and saved as "HelloMIDlet.java" in the source file directory noted in the previous step.

A midlet (or Java ME program) (#2) extends from the abstract class javax.microedition.midlet.MIDlet. This class declares three abstract methods: startApp(), pauseApp() and destroyApp(). These are call-back methods, that will be invoked by the runtime (or Application Management Software) at the appropriate instance. You need to override these methods to program the running behaviors of your midlet.

startApp() (#4) is called by the runtime when the midlet is starting, or resuming after it is being paused. pauseApp() (#5) is called by the runtime to pause the midlet. destroyApp() (#6) is called the the runtime when the midlet is about to be destroyed and removed from the memory.

In the startApp() (#4), we create the mainForm (of javax.microedition.lcdui.Form) to place the "Hello, world" StringItem UI component. We add a "Exit" command to the mainForm, and set this class as the command listener for handling the commands. We then retrieve the current display (of javax.microedition.lcdui.Display) of this midlet, and set the mainForm as the current display.

This class, as the command listener, needs to implement the javax.microedition.lcdui.CommandListener interface (#2). This interface declares an abstract method commandAction(). We override thismethod (#7) to invoke notifyDestroy() in response to the "Exit" command, which will inform the runtime that this midlet has entered the destroy state.

Compared with Sun Java Wireless Toolkit, NetBeans provides a GUI Builder (called Visual Mobile Designer) in addition to source coding. Follow the steps in "Quick Start Guide" to use the Visual Mobile Designer to write a Hello-world Java ME applications.

Java ME, is easier than the Java SE and Java EE, simply because the APIs is very much smaller (because mobile devices has limited capability). For example, the java.lang in Java ME (CLDC 1.1) has 17 classes and 1 interface, compared with the java.lang of Java SE (JDK 1.6), which has 35 classes and 8 interfaces.

Unlike Java SE, which is a single piece of software identical in all the operating platforms for developing desktop applications, Java ME is designed for mobile devices, which have limited and diverse computational power, memory, screen size, and networking capability. Due to the large variety and diversity of mobile devices, it does not make sense to design a one-size-fits-all solution and request all variety of mobile devices to support this piece of software.

Java ME is, therefore, divided into configurations, profiles, and optional APIs. A mobile device manufacturer is free to choose what to support, depending on the device"s capability.

A configuration specifies a Java Virtual Machine (JVM) and a base set of core APIs for a certain class of devices. There are currently two configurations defined:

CLDC (Connected & Limited Device Configuration): for intermittently networked (connected) and limited capability devices such as mobile phone, smart phone, PDAs. CLDC specifies a JVM and core API packages java.lang, java.io, java.util (which are subset of the Java SE counterparts) and javax.microedition.io (for networking support).

CDC (Connected Device Configuration): for robust networked and more capable devices, such as high-end PDAs, set-top boxes. (CDC is beyond the scope of this writing.)

Configuration (CLDC and CDC), by itself, is incomplete for application development. A profile is defined on top of a configuration to provide specific APIs (such as user interface, persistent storage) to make a complete application environment for developing applications. For example, MIDP (Mobile Information Device Profile) is build on top of CLDC; PDAP (PDA Profile) is build on top of CDC.

Mobile devices may choose to support optional APIs, such as Blue tooth API, Wireless Messaging API (WMA 1.0 or 2.0) and many others, depending on their capability.

Configurations and profiles are confusing. As a starter, you need not worry about how to distinguish them. You simply need to understand the combined APIs provided by the "MIDP for CLDC".

In this writing, we focus on the "MIDP for CLDC". Recall that CLDC is the base, and MIDP builds on top of CLDC to provide a complete application development environment. Currently, there are two versions of CLDC: 1.0 and 1.1 and three versions of MIDP: 1.0, 2.0, 2.1.

CLDC defines the JVM and a base set of core APIs for a class of devices with intermittent connectivity and limited capacity. CLDC specifies core APIs such as java.lang, java.io, java.util:

java.lang: CLDC 1.0 has 15 classes and 1 interface: Object, System, Thread/Runnable, Runtime, Class, String/StringBuffer, Math, wrapper classes (Integer/Byte/Short/Long/Character/Boolean). CLDC 1.1 added the floating-point support and wrapper classes Float/Double.

java.util: CLDC 1.0 has 7 classes and 1 interface: Random, collections (Vector/Hashtable/Stack), Calendar/Date/TimeZone, Enumeration. CLDC 1.1 added Timer/TimerTask.

java.io: CLDC has 11 classes and 2 interfaces: InputStream/OutputStream, DataInputStream/DataOutputStream, ByteArrayInputStream/ByteArrayOutputStream, Reader/Writer, InputStreamReader/OutputStreamWriter, and PrintStream.

CLDC does not provide a complete application development environment, e.g., it lacks the user interface. MIDP is built upon CLDC to provide a complete environment. MIDP specifies these APIs:

MIDP 2.0 added packages javax.microedition.media (multimedia support), javax.microedition.media.control, javax.microedition.lcdui.game (UI for game development), and javax.microedition.pki (public key infrastructure).

The latest MIDP 2.1 specification does not bring new features but instead it focuses to reduce device fragmentation by specifying a consistent set of Java technologies that must present in MIDP 2.1 capable phone.

A MIDP program is written by subclassing javax.microedition.midlet.MIDlet, and hence is called a midlet. A midlet is run and under the control of the Application Management Software (AMS or the runtime). The AMS can manage multiple midlets at the same time, and needs to content with other applications (such as SMS, MMS) for the limited system resources available in the mobile device.

A midlet extends abstract class MIDlet, which declares three abstract methods for managing its life cycle: startApp(), pauseAPP() and destroyApp(), and other non-abstract methods such as notifyPaused() and notifyDestroy().

A midlet could be in one of these states: constructed, paused, active, and destroyed. The life cycle of a midlet begins when the AMS invokes the constructor to create a new instance of the midlet. After it is constructed, the AMS places the midlet in the paused state. It then invokes Midlet::startApp() to start the midlet and place the midlet in the active state. The AMS may shift the midlet into the paused state by invoking Midlet::pauseApp() (e.g., there is a incoming call or MMS message which requires attention and system resources) and resume its operation by calling startApp() again. In the paused state, the midlet is not terminated, but it should release any resource it obtained in startApp(). The pause/active transition give you the ability to manage resources effectively. Typically, you shall use startApp() to allocate resources such as record stores, network connections, UI components, and use pauseApp() to release these resources. The AMS can put the midlet into the destroyed state from either paused or active state, via a call to destroyApp().

A midlet may voluntarily enter the paused state by invoking Midlet::notifyPaused(). Similarly, it could invoke Midlet::notifyDestroyed() to inform the AMS that it can now be considered destroyed.

The Display class provides the foundation for visual interaction with a midlet. There is only one instance of Display, which can be retrieved via static method Display.getDisplay(). You can then use Display::setCurrent() and Display::getCurrent() to get/set the current display for a particular Displayable.

The Displayable is an abstract class of objects that can be placed on the Display. A Displayable may have a title, a ticker, command(s) and an associated command listener. The following methods are provided:

Alert can be used for providing "dialog". There are two types of Alert: one display for a set period of time and does not require user"s interaction; the other interrupt the program until user provides a response. Alert is a Displayable. Hence, it can have title, ticker, command(s) and can register command listener. Alert has the following constructors:

The available AlertTypes are: ALARM, CONFIRMATION, ERROR, INFO, WARNING. You can use methods getTimeout() and setTimeout() to control the timeout (in milliseconds or FOREVER). Alert can be associated with an image or a sound effect.

off-screen graphics buffer for double-buffered rendering. You can retrieve the off-screen graphics handler via method GameCanvas::getGraphics() and transfer the contents to the on-screen buffer via GameCanvas::flushGraphics().

The GameCanvas class provides a off-screen graphics buffer for double-buffered rendering. You can retrieve the off-screen Graphics handle via method GameCanvas::getGraphics(). You can then perform your graphic rendenering on this off-screen buffer, and invoke GameCanvas::flushGraphics() to send the contents to the on-screen buffer.

This bouncing ball is straight-forward. However, I have problem writing multiple balls, because MIDP"s Math class does not provide arc-tangent function.

The Sprite class allow you to render an animated sprite with several image frames stored as one single image for better management of animated frames. Two examples of animated frame images are given below:

The Sprite class is able to extract the frames (given the frame width and height) and number them starting from 0 for the top-left frame, in row-major manner. Read the API documentation of the Sprite class for more illustration.

The Sprite class also provide basic transforms via the method Sprite::setTransform(type). The type includes TRANS_NONE, TRANS_ROT90, TRANS_ROT180, TRANS_ROT270, TRANS_MIRROR, TRANS_MIRROR_ROT90, TRANS_MIRROR_ROT180, TRANS_MIRROR_ROT270. For rotation, you can use setRefPixelPosition(x, y) to set the rotation center (by default, it rotates about (0, 0), which is the top-left corner of the image). Note that: (a) you cannot concatenate multiple transforms, (b) rotation of arbitrary degree in not supported, and (c) the rotational degree is measured clockwise (instead of the usual convection of counter-clockwise).

A sprite can detect collision with another sprite via the method Sprite::collidesWith(). You can set the collision detection at "pixel-level" or "bounding-box-level".

A TiledLayer is a special layer that is divided into grid of cells. Each cells can be filled with a selected tile frame. In this way, you can reuse the tile frames instead of providing a huge image. TiledLayer is often used for background.

To use a TiledLayer, you keep the tile frames in a single image (similar to sprite) and specify the width and height of the tile frame. The frames will be extracted and numbered starting from 1 (unlike sprite frame which starts from 0) for the top-left tile, in row-major manner. You then divide the tile layer into cells (of rows and columns). For each cell, you can assign a tile frame index (from 1 to n). Index 0 indicates that the cell is empty. You can use negative index for animated tile cells. Each negative index is associated with a positive tile frame index, and the associated tile frame can be changed on the fly. For example, the animated tile index -1 can be made alternate between tile frame index 5 and 6. Read the API documentation of TiledLayer for more illustrations.

The LayerManager can be used to manage a collection of Layers, and place them on the screen with a specific z-order. Each Layer is given an index corresponding to its z-order, with value of 0 closer to you, and highest number further away from you. Layers can be added into the LayerManager (via insert() or append()) and removed (via remove()). Recall that Layer is an abstract class, with implementations in Sprite and TiledLayer classes.

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

In a previous article, Java 2 Micro Edition: Java for Small and Embedded Systems, we explored how Java 2 Micro Edition (J2ME) can be used to program Palm devices. A lot has changed on the J2ME landscape since then.

In this article, I will give you an update on the current state of J2ME. We will then explore how J2ME can be used to extend your enterprise applications to wireless devices.

Just as the Applet class contains methods that allow a browser to control the lifecycle of an applet, the MIDlet contains similar methods, which are manipulated by a device-dependent application manager. However, unlike an applet, a MIDlet is not a GUI component.

The MIDlet class defines the methods startApp(), pauseApp(), and destroyApp(), which can be called either by the MIDlet itself or by an application manager on the device.

The application manager is responsible for creating the MIDlet and starting it. It will also pause the MIDlet when necessary, such as when a phone call comes in, and it will destroy the MIDlet if there is an uncaught exception (see Figure 1).

Since the MIDlet class is not a GUI component, the above code has no screen presence. Depending on the device, you may not even see "Hello MIDlet" printed out. On most emulators, standard out is redirected to a console window.

Each time the user invokes the MIDlet, "Hello MIDlet" will be sent to standard out. Since we don"t have to do anything special when the MIDlet is paused or destroyed, these methods are empty.

Typically, pauseApp() and destroyApp() would contain any code needed to free resources that were grabbed by startApp(). It is important to remember that startApp() can be called multiple times during the lifetime of the MIDlet.

If you need to perform a task only when the application is first started, for example showing a splash screen, it will be necessary to set an appropriate flag in the startApp() method.

In J2SE, we have a rich set of visual components that we can place in our application using layout managers. In MIDP, the assumption is that the screen is not large enough to display a lot of components at once.

It is also desirable to display the application in a way that is natural for the device it is running on. Just as AWT applications look different on different computer systems, MIDP applications may look different on different devices.

The high-level API specifies a small set of Screen objects, only one of which can be shown at a time. Because of the limited size of the devices, we leave behind the notion of layout managers. When the object is shown, it takes up all of the screen real estate available to MIDP (note that some of the screen may be reserved for device-specific information, as well).

Note that if a phone call is received while HelloMIDlet is running, the MIDlet is paused. When the user resumes HelloMIDlet, startApp() is called again, and the GUI is recreated from scratch.

The HelloMIDlet class above is built using the high-level GUI components. It also uses a Command to indicate that the user has the option to exit the application.

Commands can be associated with any Screen component except an Alert; unfortunately, adding a Command to an Alert will produce a runtime error, not a compiler error.

The same command can be associated with multiple screens. Depending on the type of command (as defined by constants in the Command class), the command may be mapped to a hardware key or a soft key on the device. For example, an exit command may be mapped to the "hang up" key on a phone.

It is up to the device manufacturers to map the commands appropriately. MIDP gives no direct control to the developer for the placement of the commands. Indirectly, we can affect the placement by manipulating the command"s type and priority.

The Canvas class also provides methods to access pointer and keyboard events. This allows the developer to create interactive games or custom components. However, cross-device compatibility may be compromised.

For example, a game that relies on pointer-based events may not work on a phone. On the other hand, a game that only uses key events will be awkward – but possible – to use on a Palm device.

MIDP provides the ability to persistently store data on a device. The javax.microedition.rms package defines classes to support data persistence across different invocations of the MIDlet and across device power outs.

Only one concrete class, RecordStore, is defined. It has static methods to create and destroy data stores, as well as instance methods to manipulate the contents of a record store. A single record is stored as an array of bytes.

Having persistent data on the device itself allows network-dependent MIDP applications to run, even when the network is inaccessible. For example, an application could store data on the device when no network is available and then send that data to a server at a later time.

The CLDC defines a Connector framework to support networking. The framework is much smaller than the J2SE network-support classes; however, it is very flexible and easy to use.

Creating an HTTP connection on a MIDP device is quite easy. The following code opens an HTTP connection, sends a GET request, and reads some text from the response.

One of the most exciting aspects of J2ME is that it enables us to extend our network infrastructures into the wireless world. Using the networking classes described above, we can write software for wireless devices that interact with a server.

There are several tools available on the market today for J2ME development. Sun has the J2ME Wireless Toolkit, which can run in stand-alone mode or as an integrated piece of Forte for Java. JBuilder 5 includes integration with the Nokia toolkit. Motorola and Nokia offer tools through their developer web sites designed to work with their phones.

In the URL above, "myParam" is the parameter name and "Test+Param" is the parameter value, where the "+" is used to represent a space between the two words.

Now that we have our servlet working, and we"ve tested it with our web browser, we can begin the much more interesting task of creating a MIDP client.

The client consists of the WirelessMIDlet class and the HTTPHelper class. The MIDlet builds the user interface, and HTTPHelper contains utility functions to send HTTP GET and POST requests to a given URL and retrieve the responses as text.

We have explored how J2ME MIDP can break the tether of the wired connection, gaining us access to enterprise functionality in the wireless world. Using the simple and well-understood HTTP protocol, MIDlets can access data anywhere on the Internet.

It is important to remember that, although we have access to all of the information on the Internet, MIDP applications should not be modeled after the familiar web browser paradigm to which we have all become accustomed.

Because of the limited screen size, awkward input mechanisms, low computing power, and slow connection speeds of these wireless devices, the browsing paradigm of the Web does not work. Instead, MIDP applications must be small, targeted applications that solve a single problem quickly and easily with a minimum of user involvement.