Provides functionality to trigger event notifications through Consequence i. Provides fundamental functionality for constructing the user interface of a RIM Device application. Provides a library of prebuilt interface components and controls for constructing usable UI applications. Provides a library of prebuilt interface component mangers for constructing usable UI applications. Step 2: Install Run the downloaded installer. 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. In the startApp 4 , we create the mainForm of javax. 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. Display of this midlet, and set the mainForm as the current display. This class, as the command listener, needs to implement the javax. CommandListener interface 2. This interface declares an abstract method commandAction. We override this method 7 to invoke notifyDestroy in response to the "Exit" command, which will inform the runtime that this midlet has entered the destroy state.
Step 3: Write a "Hello-world" Program refer to the getting starting document and the source code above. CDC is beyond the scope of this writing. CLDC 1.
MIDP 2. The latest MIDP 2. EXIT, 0 ; mainForm. READ ; if conn. Game API will be discussed in the next section. Priority: a smaller number indicates higher priority. Code Example : Guessing a number import java. Random; import javax. You can retrieve the off-screen graphics handler via method GameCanvas::getGraphics and transfer the contents to the on-screen buffer via GameCanvas::flushGraphics.
Code Example : A key-controlled moving avatar built upon GameCanvas import javax. TOP Graphics. You can retrieve the off-screen Graphics handle via method GameCanvas::getGraphics. In normal not full-screen mode, the appearance of the Canvas should be similar to that of Screen classes, so that visual continuity is retained when the application switches between low-level Canvas objects and high-level Screen objects.
Repainting is done automatically for all Screens , but not for Canvas ; therefore, developers utilizing the low-level API must ; understand its repainting scheme. In the low-level API, repainting of Canvas is done asynchronously so that several repaint requests may be implemented within a single call as an optimization. This means that the application requests the repainting by calling the method repaint of class Canvas.
The actual drawing is done in the method paint -- which is provided by the subclass Canvas -- and does not necessarily happen synchronously to repaint. It may happen later, and several repaint requests may cause one single call to paint. The application can flush the repaint requests by calling serviceRepaints. The last call causes the repaint thread to be scheduled.
The repaint thread finds the two requests from the event queue and repaints the region that is a union of the repaint area:. In this imaginary part of an implementation, the call canvas. The primary drawing operation is pixel replacement, which is used for geometric rendering operations such as lines and rectangles. With offscreen images, support for full transparency is required, and support for partial transparency alpha blending is optional.
A bit color model is provided with 8 bits each for the red, green, and blue components of a color. Not all devices support bit color, so they will map colors requested by the application into colors available on the device. Facilities are provided in the Display class for obtaining device characteristics, such as whether color is available and how many distinct gray levels are available. This enables applications to adapt their behavior to a device without compromising device independence.
Graphics may be rendered either directly to the display or to an off-screen image buffer. The destination of rendered graphics depends on the origin of the graphics object.
A graphics object for rendering to the display is passed to the Canvas object's paint method. This is the only way to obtain a graphics object whose destination is the display.
Furthermore, applications may draw by using this graphics object only for the duration of the paint method. A graphics object for rendering to an off-screen image buffer may be obtained by calling the getGraphics method on the desired image. These graphics objects may be held indefinitely by the application, and requests may be issued on these graphics objects at any time.
The Graphics class has a current color that is set with the setColor method. All geometric rendering, including lines, rectangles, and arcs, uses the current color. The pixel representing the current color replaces the destination pixel in these operations. There is no background color. Painting of any background be performed explicitly by the application using the setColor and rendering calls. Support for full transparency is required, and support for partial transparency alpha blending is optional.
Images created in such a fashion are immutable in that the application is precluded from making any changes to the pixel data contained within the image. Rendering is defined in such a way that the destination of any rendering operation always consists entirely of fully opaque pixels.
The origin 0,0 of the available drawing area and images is in the upper-left corner of the display. The numeric values of the x-coordinates monotonically increase from left to right, and the numeric values of the y-coordinates monotonically increase from top to bottom. Applications may assume that horizontal and vertical distances in the coordinate system represent equal distances on the actual device display. If the shape of the pixels of the device is significantly different from square, the implementation of the UI will do the required coordinate transformation.
A facility is provided for translating the origin of the coordinate system. All coordinates are specified as integers. The coordinate system represents locations between pixels, not the pixels themselves.
Therefore, the first pixel in the upper left corner of the display lies in the square bounded by coordinates 0,0 , 1,0 , 0,1 , 1,1. An application may inquire about the available drawing area by calling the following methods of Canvas :. An application may request one of the font attributes specified below. However, the underlying implementation may use a subset of what is specified. So it is up to the implementation to return a font that most closely resembles the requested font.
Each font in the system is implemented individually. A programmer will call the static getFont method instead of instantiating new Font objects. This paradigm eliminates the garbage creation normally associated with the use of fonts.
The Font class provides calls that access font metrics. The following attributes may be used to request a font from the Font class :.
The methods may be called from callbacks, TimerTasks , or other threads created by the application. Also, the implementation generally does not hold any locks on objects visible to the application. This means that the applications' threads can synchronize with themselves and with the event callbacks by locking any object according to a synchronization policy defined by the application.
One exception to this rule occurs with the Canvas. This method calls and awaits completion of the paint method. Strictly speaking, serviceRepaints might not call paint directly, but instead it might cause another thread to call paint. In either case, serviceRepaints blocks until paint has returned. This is a significant point because of the following case. Suppose the caller of serviceRepaints holds a lock that is also needed by the paint method.
But if your program is running on its own thread, this might happen at any point in your game's algorithm. If you're not careful about using synchronized blocks, this could potentially cause errors if one thread is updating data about the game's current state and the other is using that data to perform calculations. The program is simpler and easier to follow if you get the keystroke information when you want it by calling the GameCanvas method getKeyStates.
An additional advantage of the getKeyStates method is that it can tell you if multiple keys are being pressed simultaneously. The keyCode that's passed to the keyPressed int keyCode method can tell you only about a single key and therefore will be called multiple times even if the user presses two keys at the same time. Here are the latest Insider stories. More Insider Sign Out. Sign In Register. Sign Out Sign In Register. Latest Insider. Check out the latest Insider stories here.
More from the IDG Network. Java databases get small. Hands on: Build a Storm analytics solution. How to describe Java code with annotations. What is OSGi?
0コメント