By clicking on these command the applications will perform a pre-defined action. The form has several sub-classes which include gauge, textfield, datefield, customitem, stringitem, imageitem and choicegroup class. A new form object can be created as follows. The list class works similar to the choicegroup class. A new list object can be created as follows. The difference between textbox and textfield class is that textfield does not limit the amount of characters that can be entered in the textfield.
A new textfield object can be created as follows. There are two types of gauges in J2ME viz; interactive and non-interactive. The interactive gauge continously shows the progress. A new gauge object can be created as follows. A new datefield object can be created as follows. Initialization of objects needed while the application is active should be done. The application may call setCurrent for the first screen if that has not already been done. Note that startApp can be called several times if pauseApp has been called in between.
This means that one-time initialization should not take place here but instead should occur within the MIDlet's constructor. Also, if it is desirable to start with another screen when the application is re-activated, the new screen should be set with setCurrent. The behavior of method calls on user interface objects after destroyApp has returned is undefined. The user interface objects that are shown on the display device are contained within a Displayable object.
At any time the application may have at most one Displayable object that it intends to be shown on the display device and through which user interaction occurs. This Displayable is referred to as the current Displayable. The Display class has a setCurrent method for setting the current Displayable and a getCurrent method for retrieving the current Displayable. The application has control over its current Displayable and may call setCurrent at any time. Typically, the application will change the current Displayable in response to some user action.
This is not always the case, however. Another thread may change the current Displayable in response to some other stimulus. The current Displayable will also be changed when the timer for an Alert elapses. The application's current Displayable may not physically be drawn on the screen, nor will user events such as keystrokes that occur necessarily be directed to the current Displayable.
This may occur because of the presence of other MIDlet applications running simultaneously on the same device. An application is said to be in the foreground if its current Displayable is actually visible on the display device and if user input device events will be delivered to it. If the application is not in the foreground, it lacks access to both the display and input devices, and it is said to be in the background.
The policy for allocation of these devices to different MIDlet applications is outside the scope of this specification and is under the control of an external agent referred to as the application management software. As mentioned above, the application still has a notion of its current Displayable even if it is in the background.
The current Displayable is significant, even for background applications, because the current Displayable is always the one that will be shown the next time the application is brought into the foreground. The application can determine whether a Displayable is actually visible on the display by calling isShown. In the case of Canvas , the showNotify and hideNotify methods are called when the Canvas is made visible and is hidden, respectively.
Each MIDlet application has its own current Displayable. It is possible for getCurrent to return null. This may occur at startup time, before the MIDlet application has called setCurrent on its first screen. The getCurrent method will never return a reference to a Displayable object that was not passed in a prior call to setCurrent call by this MIDlet.
Typically, the current screen of the foreground MIDlet will be visible on the display. However, under certain circumstances, the system may create a screen that temporarily obscures the application's current screen.
These screens are referred to as system screens. This may occur if the system needs to show a menu of commands or if the system requires the user to edit text on a separate screen instead of within a text field inside a Form.
Even though the system screen obscures the application's screen, the notion of the current screen does not change. In particular, while a system screen is visible, a call to getCurrent will return the application's current screen, not the system screen. The value returned by isShown is false while the current Displayable is obscured by a system screen. If system screen obscures a canvas, its hideNotify method is called.
When the system screen is removed, restoring the canvas, its showNotify method and then its paint method are called. You can also respond to user input by overriding methods that are called as a result of key presses or pointer movements.
The low-level API does not provide any individual components to handle text input, display lists, offer choices, and so on, although it does include the ability to use Command s, which Canvas inherits from Displayable. The low-level API is well suited for writing graphical games or displaying data in chart form and is described in detail in Chapter 5. Screen is the basic class from which the top-level windows of the high-level API are derived. Like Canvas , Screen is an abstract class, but, unlike Canvas , developers are not expected to subclass it in order to implement a MIDlet user interface.
Screen adds to Displayable the ability to include an optional title string and an optional ticker, which displays a continuously scrolling text message. The most commonly used concrete subclass of Screen is Form , which allows you to build a user interface by adding standard components referred to as Item s to it, much like you add Component s to a Container in the AWT. Unlike the low-level API, the high-level API does not allow the developer to draw directly to the screen or to handle events from the keyboard or the pointer.
A typical example of this might be using the high-level API to create a form that allows the user to specify the location of some data, then switching to a Canvas on which the data is presented as a chart. You cannot, of course, use the high- and low-level APIs on the same screen.
Skip to main content. J2ME in a Nutshell by. Start your free trial. Chapter 4. MIDlet User Interfaces. User Interface Overview. The Display and Displayable Classes. This means the maximum number of characters that can be entered into the text field might be lower than the value passed to the constructor. Creating Instance of TextField Class23 These are immutable images and mutable images. An immutable image is loaded from a file or other resource and cannot be modified once the mage is displayed.
Icons associated with MIDlets are immutable images. Amutable image is drawn on the screen using methods available in the Graphics class. Once drawn, your MIDlet can redraw any ortion of the image. Creating an Instance of ImageItem class 25 Creation of an Instance of an Implicit List Class 27 The first parameter is the title of the text box.
The second parameter is text used to populate the instance. The third parameter is the maximum number of characters that can be entered into the instance. Keep in mind that this parameter is a request and may not be fulfilled by the device. The device determines the maximum number of characters for an instance of the TextBox class. The last parameter is the constraint used to limit the types of characters that can be placed within the instance. Creating an Instance of TextBox Class31 An instance of the Ticker class can be associated with any class derived from the Screen class and be shared among screens.
An instance of a Ticker object is created by passing the constructor of the Ticker class a string containing the text that is to be scrolled across the screen. You cannot control the location on the screen where scrolling occurs. Likewise, there is no control over the speed of the scrolling. The device that runs the MIDlet controls both location and speed. You can replace the text currently scrolling across the screen by calling the setString method. The setString method requires one parameter, which is a string containing the replacement text.
Creating an Instance of Ticker Class33 Thank You Total views 3, On Slideshare 0. From embeds 0. Number of embeds
0コメント