Using LWUIT with J2memap
One of J2memap user wanted to use the application with the LWUIT framework from Sun. So, after some research, it appears that only one modification was needed: a callback to notify the host that the screen needed to be repainted.
This has been done by adding a new callback in the mapDisplayListener:
asBeenRepaint();
So here is the code of the”MapElem” that can be easily added in a LWUIT environment
class MapElement extends Component implements MapDisplayListener {
private final MapDisplay map;
private com.sun.lwuit.Image buffer;
private javax.microedition.lcdui.Graphics bufferGraphics;
private boolean painted;
public MapElement() {
this.map = new MapDisplay();
}
public MapElement(final MapDisplay map) {
this.map = map;
}
public void paint(final com.sun.lwuit.Graphics g) {
if (!painted) {
map.sizeChanged(getWidth(), getHeight());
buffer = com.sun.lwuit.Image.createImage(getWidth(), getHeight());
bufferGraphics = new ImageWrapper(buffer).getGraphics();
map.addListener(this);
}
map.paint(bufferGraphics);
g.drawImage(buffer, 0, 0);
painted = true;
}
// Pass LWUIT Component events to the map
// -------------------- Start ----------------------------//
public void pointerDragged(int x, int y) {
map.pointerDragged(x, y);
}
public void pointerPressed(int x, int y) {
map.pointerPressed(x, y);
}
public void keyPressed(final int keyCode) {
map.keyPressed(keyCode);
}
public void keyReleased(final int keyCode) { }
public void keyRepeated(final int keyCode) {
map.keyRepeated(keyCode);
}
public boolean mapKeyPressed(MapDisplay arg0, int arg1) {
return true;
}
public void onMoveEnd(MapDisplay arg0) { }
public boolean oneLocationSelected(MapDisplay arg0, Marker arg1) {
return true;
}
public void hasBeenRepaint(boolean completed) {
repaint();
}
}
You also need the ImageWrapper class , available here:
package com.sun.lwuit;
public class ImageWrapper {
private final Image image;
public ImageWrapper(final Image lwuitBuffer) {
this.image = lwuitBuffer;
}
public javax.microedition.lcdui.Graphics getGraphics() {
return ( javax.microedition.lcdui.Graphics) image.getGraphics().getGraphics();
}
}
Update: the lwuit getGraphics don’t return anymore an LCDUI graphics, but an Object that need to be casted to an LCDUI Graphics
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=28523995-41f3-4a45-af8f-70d837f82632)
« WhereAmI: new Blackberry application for OpenCellID | Home | OpenCellID Client for Windows Mobile: OpenCellClient »
Comments
Hi,
this approach won’t compile using the current LWUIT drop/SVN. A “quick” solution would be to cast down the getGraphics call to javax.microedition.lcdui.Graphics but that wouldn’t be a good idea due to two reasons:
a. Relying on undocumented API (package protected).
b. This will break on other versions of LWUIT e.g. BlackBerry, Android, CDC etc.
I suggest you try reworking the MapElement Item into a component to leverage the full advantages of LWUIT. You can then use features such as motions to slide through the Map as is shown off in our LWUIT-Makeover demo.
Hello Shai,
This is bad news. Istarted to try to do a “native “LWUIT component, but the main issue was the support of Graphics: most of the calls are different, which require another layer of abstraction.
One of the things that I want to investigate is to check if I can subclass the LWUIT graphics in order to manage the extra parameter (alignement)
What is your views on this?
We removed the alignment component since it is problematic in terms of portability and doesn’t provide much help for the most part.
Graphics can’t be subclassed in LWUIT since they are implemented on top of the portability layer which could pose a problem.
I’m not too fond of the idea of creating another abstraction layer on top of LWUIT since it would be abstracting an abstraction layer… Generally I would assume that most of your code is related to REST networking and very little of the code should be dedicated to drawing, I would just write a separate component for LWUIT which would allow you to leverage it properly (e.g. styles).
Shai, a big part of the code is dedicated to “drawing”, maps, marker, traks, informations, etc…. I’ve started by this, but we there are A LOT of drawing calls in such library.
I really need to maintain a portability with standard Midp Graphics. Even if I don’t use specific alignements, this remains a parameter of most of the graphics functions, especially text functions, and most of them don’t care of LWUIT: they just need a surface to draw.
So what are my choices:
- putting a lot of #ifdef using netbeans to swith beteen LWUIT specific version and Midp standard version
- creating a specific version of LWUIT with the alignement parameters?
- puting the drawString functions in a well defined place and use function calls instead of metjods calls on an object…
None of these are good solutions in my views. The best comprise, in my view, would be to add the alignement parameter as a way to support an easy migration of graphic library like j2memap in various environment. Even if the only supported alignement is Graphics.LEFT|Graphics.TOP….
Adding an alignment argument won’t solve your problem since the package and behavior would be completely different. It would not simplify the job of people who move code from AWT/Swing where such a method doesn’t make sense.
Your 3rd option of concentrating all call to graphics from a single place seems to be the lesser evil. Don’t forget that LWUIT runs on RIM native API, CDC etc. which means that you generally shouldn’t even import MIDP specific API’s if you want to truly make use of LWUIT (e.g. on an HDTV).
Understand the argument for people moving from AWT/Swing, but what about people moving from lcdui to lwuit?
The big issue is that these are the only functions that make really hard to use the same code base for lwuit/lcdui graphical low level engine.
It’s really sad in my view that you did not support enough programmers who’ve put a lot of effort on legacy midp applications and that wants to provide LWUIT support at a reasonnable cost….
On the opposite, understand the benefit of porviding “Graphics” comptability: all the existing components/library (and there are plenty off) can be reused directly most of the time: vector graphics rendrer, 3D engines, game engines, etc….
People moving from LCDUI to LWUIT would still have the same problem, you would still need to use #ifdef since the import statements would be completely different. Drawing a string with top/left which is the simplest method might work as expected but everything else would not… E.g. images which are very different from MIDP or using different anchors.
Since LWUIT gets packaged with the application providing support for legacy costs in size and performance, one of the advantages of being completely external is that we can break compatibility and decisions that were probably a mistake to begin with.
The whole anchor’s concept is one of the biggest confusing points about MIDP, we are trying to create something that’s simpler and more correct so I don’t see it as our role to provide compatibility.
Assuming what you want is portability you can always create a utility class to replace graphics and route all graphics calls through that class, yes its another layer of indirection but it will allow you a single code base.
Sorry Shai and Thomas - the approach you propose seems not to work. Although the application compiles without errors, I can not make LWUIT display the map component. I clearly do the cast, but it doesnt work. Has anyone else tried this ? If yes, I would love to see the code in which the map coponent actually displays and behaves like it should do within a LWUIT form.
Hmmmmz, could you add imports etc cause this is kinda not working with the lcdui versus lwuit graphics here. Thx
C:UsersstudentDocumentsNetBeansProjectsMAPPINGZZZZsrcmapzzzImageWrapper.java:21: getGraphics() is not public in com.sun.lwuit.Graphics; cannot be accessed from outside package
return (javax.microedition.lcdui.Graphics) image.getGraphics().getGraphics();
Hello,
I think there is a problem when using the WTK emulator, lwuit and j2memaps. The arrow keys seem to work, but the zoom keys (numpad 1, numpad 3) do not refresh the display. The display is refreshed although when one of the arrow keys gets pressed. What is the problem?
Leave a Comment