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.

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….

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).

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….

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).

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?

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.