Getting to Know the J2ME Emulator
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Unlike traditional Java applets and applications, which can be executed using a Web browser or Java interpreter during the development phase, MIDlets must be executed using a special emulator that emulates a physical mobile device. A J2ME emulator is an important tool that ships with both the standard J2ME Wireless Toolkit and with other similar toolkits that are made available by device vendors such as Motorola. Although it is certainly possible to test a MIDlet directly on a mobile device, an emulator streamlines the process and enables you to work entirely on a desktop computer throughout the development process. It is still important to test a MIDlet on a physical device as it nears completion, but the emulator plays a critical role in testing a MIDlet prior to that point.
This lesson introduces you to the J2ME emulator that ships with the J2ME Wireless Toolkit, as well as the emulator that ships with the Motorola SDK for J2ME. Both emulators serve the exact same function, but running each of them is a little different. You also learn today how to launch an emulator from within a visual development environment. These are the major topics you cover in today's lesson:
Understanding the strengths and weaknesses of the J2ME emulator
Becoming acquainted with the types of devices targeted by the emulator
Running the emulator from the command line
Running the emulator using a visual development environment
J2ME Emulator Essentials
Today you start to see first-hand why J2ME is such an interesting technology. The J2ME emulator is the tool that enables you to run MIDlets on a desktop PC and simulate how the MIDlet will run on a physical device. Before getting into the specifics of how to run MIDlets within the emulator, I'd like to quickly go over some of the benefits of a J2ME emulator, along with a few of its limitations. Following are three primary benefits of using a J2ME emulator:
You can delay testing on a physical device until the final stage of MIDlet development.
You can test a MIDlet on a variety of different target devices, including custom devices.
You can track specific aspects of a MIDlet's execution such as class loading, method calls, and garbage collection.
The first benefit is pretty obvious and was mentioned in the previous lesson. It reflects the fact that the emulator serves as a great stand-in for a physical device during the early and middle stages of MIDlet development; you'll still want to run a MIDlet through its paces on a physical device late in the development process.
The second benefit alludes to the fact that the emulator operates with respect to a device profile. You learned about device profiles in Day 1, "Java 2 Micro Edition: The Big Picture," but to quickly recap, a device profile models the properties of a physical device. The emulator is very flexible in that it enables you to test a MIDlet on multiple device profiles, which effectively tests the MIDlet on multiple devices. You can even define custom devices (through custom profiles) and test MIDlets on them; you learn how to do this on Day 6, "Creating Custom Device Profiles."
The last benefit listed has to do with the emulator's capability to provide diagnostic information about a MIDlet as it is executing. You learn more about the specific kinds of diagnostic information made available by the emulator a little later in this lesson.
Before you begin to think that the J2ME emulator is the most amazing development tool ever envisioned, I need to temper your excitement by highlighting a few of its limitations. None of these limitations are killers, but it is important to understand where the emulator falls short of a physical device in terms of testing MIDlets. Then you can focus on these aspects of a MIDlet when you do test it on a physical device. Following are the aspects of a MIDlet that cannot be controlled or tested by the emulator:
Execution speed
Available memory
Application manager
Physical mobile devices vary widely in their hardware, which means that processor speed is most definitely a variable that cannot be nailed down by a MIDlet developer unless you target a very specific device and ignore others. Even though you can't necessarily make assumptions about the speed of the processor in a device, it would be nice to be able to test a MIDlet at a variety of different speeds to see how it responds. Unfortunately, the J2ME emulator doesn't currently factor device speed into the emulation process. So you'll have to resort to testing a MIDlet on physical devices when it comes to assessing the speed of execution across different processors.
The processor speed will likely vary considerably across different mobile devices, and the memory available to a MIDlet will quite likely vary as well. Because available memory can dramatically impact the execution of a MIDlet, it is important to test a MIDlet within the memory constraints of each target device. Unfortunately, the J2ME emulator doesn't currently enable you to vary the memory available to a MIDlet, so it doesn't help much in terms of assessing the impact of available memory on a MIDlet. Chalk up memory as another aspect of your MIDlet that you'll need to test directly on a physical device, along with the speed of execution.
The last limitation of the J2ME emulator is less critical than the first two, and has to do with the application manager that is used on mobile devices to manage MIDlets. The application manager on a device is responsible for allowing you to install, remove, and execute individual MIDlets. Currently no support is available for application management in the emulator, which means that you can't completely test the management of MIDlets on a device using the emulator. However, this is a task that is easy enough to test on a physical device when your MIDlet is ready for deployment.
Beyond these easily identifiable weaknesses in the J2ME emulator, you also must consider the fact that any emulator is merely approximating a physical device. This means that an emulator will inevitably yield slightly different results from a real device, which is why you can't rely 100% on emulators for all J2ME software testing. So, although emulators serve a great role in enabling you to accomplish a great deal of developmental testing on a PC, you must always plan on spending ample time testing on a physical device.
Now that I've reversed myself and convinced you that a J2ME emulator isn't all that great, let me reiterate that it is still an extremely valuable tool outside of the few limitations I just mentioned. With that in mind, let's move on and address the relationship between the emulator and physical devices.