Tutorials | With the rapid development of mobile communications, the new word mobile is slowly becoming a hotspot for developers to focus on. A recent survey conducted online found that 24.34% of respondents were involved in embedded/mobile device application development, a figure that may be slightly higher than the actual ratio, but it also shows that embedded/mobile device application development is a tempting fresh cheese. J2ME (Java 2 Micro Edition) is the king of the embedded/mobile application platform, which is 二、三位 by Linux and wince. Nokia and other manufacturers push the Symbian platform is not yet satisfied with the level of developers, considering the survey items merged embedded devices (such as PDA) and mobile devices (such as smartphones), Symbian, WinCE series on the mobile platform will be the main two sides of the competition. If the manufacturers can do more standard implementation, then the J2ME features will play more vividly, continue to retain the king status. This chapter will be based on the J2ME architecture and the MIDlet application model.
What is J2ME
It is very important to learn J2ME before knowing what is J2ME. J2ME is the Sun Company's development platform for embedded, consumer electronics products, with J2SE and Java EE together to form the three important branches of technology. J2ME is actually a collection of specifications that are made by the JCP organization to make the relevant Java specification Request (JSR) and published, which are implemented by the factory chambers according to the specifications, but must pass the TCK test to ensure compatibility. For example, the MIDP2.0 specification is made in JSR118. Developers who might have contacted J2ME would think that J2ME is a series of specifications inaccurate. Because we use a lot of things like CLDC (Connected Limited Devices Configuration) and MIDP (Mobile information Profile) in development. In fact, this is not contradictory, because these are made in the relevant norms. If you do not have a good understanding of the problem, it does not matter, please continue to look at, we began to understand the architecture of the J2ME platform.
J2ME Platform Architecture
The J2ME platform is composed of configuration (Configuration) and Summary tables (profile). A configuration is a collection of minimal class libraries that are available to the maximum range of devices, and include Java virtual machines in the configuration. A summary table is a collection of development packages that are provided for a range of devices. An important concept in J2ME is the optional package (Optional Package), which is a class library for a specific device, such as Bluetooth enabled, and JSR82 (Bluetooth API) in this feature J2ME provides Bluetooth support.
Currently, there are two main configurations in the J2ME, connected Limited Devices Configuration (CLDC) and connected Devices Configuration (CDC) respectively. They are differentiated according to the hardware performance of the device, such as the processor, memory capacity, and so on. Since this standard was specified in 2001, the processing power and memory capacity of mobile terminals are developing rapidly, and it may be inaccurate to judge by this standard. So we just list the criteria for the reader's reference. This tutorial will mainly explain the content of the J2ME platform based on CLDC. With the development of technology and hardware equipment, J2ME development Network will gradually introduce the J2ME platform based on CDC.
The CDC hardware parameters:
2m above memory.
• Network connectivity, usually a wireless network.
• Need to implement the full functionality of the Java Virtual Machine specification.
• 32-bit or 64-bit processors.
Hardware parameters for CLDC:
512 KB The following memory
• Limited energy supply (usually using batteries)
• Limited or non-persistent network connections
• A simple user interface
• 16-bit or 32-bit processors
From the above standards we can see that CLDC mainly for those resources are very limited equipment such as mobile phone, PDA, duplex pager. The CDC is mainly about home appliances, such as set-top boxes and car navigation systems. The summary table is based on configuration, for example, Mobile Information Devices profile (MIDP) is an important summary of the upper CLDC. Unlike the longitudinal characteristics of the configuration, the summary table is horizontal. The following diagram is a block diagram of the J2ME architecture:
J2ME System Structure diagram
the lifecycle of the MIDlet application
Understanding the architecture of J2ME is not as easy as it seems, and we feel that reading more information is not helpful, and that our direct move towards J2ME development may help you understand the important concept of J2ME platform architecture. A new application model MIDlet is defined in MIDP, which is managed by the application Management Software (AMS). AMS is responsible for installation, download, operation, and deletion of MIDlet. While being administered by AMS, MIDlet can communicate with application management software to notify application management software of their own state changes, usually through method notifydestroyed () and notifypaused ()
The MIDlet has three states, namely pause, active and destroyed. When you start a midlet, the application management software first creates a MIDlet instance and puts him in the pause state, midlet into the active state when the Startapp () method is invoked, which is the state of the operation. Invoking the Destroyapp (Boolean unconditional) or Pauseapp () method in the active state can cause MIDlet to enter the destroyed or pause state. It is worth mentioning the Destroyapp (Boolean unconditional) method, in fact, when the Destroyapp () method is invoked, AMS notifies MIDlet to enter the destroyed state. The MIDlet in the destroyed state must free all resources and save the data. If unconditional is false, MIDlet can throw the midletstatechangeexception and remain in the current state upon notification, and if set to true, the destroyed state must be entered immediately. The following figure illustrates the MIDlet state change:
MIDlet State diagram
The following is an example to verify the lifecycle of the MIDlet application:
Import javax.microedition.midlet.*;
Import javax.microedition.lcdui.*;
public class HelloWorld extends midlet{
private display display;
Constructors
Public HelloWorld () {
display = Display.getdisplay (this);
System.out.println ("constructor");
}
public void startApp () {
System.out.println ("startApp is called.");
Form f = new form ("Hellotest");
Display.setcurrent (f);
}
public void Pauseapp () {
System.out.println ("Pauseapp is called.");
}
public void Destroyapp (Boolean unconditional) {
System.out.println ("Destroyapp is called.");
}
}
After compiling the program, the console will output sequentially:
Constructor startApp is called.
When we exit the program, the console will output:
Destroyapp is called.
For detailed lifecycle issues, readers can view other tutorials or later versions of this guide.
Finally, briefly describe the development process of the J2ME project as the end of this chapter. The development process is generally in the following order: Write source program, compile as class file, check, package and publish the application. There are other articles on the detailed development process and how to develop J2ME applications using the integrated development environment.
