Skip to main content

Blackberry implementation

78 replies [Last post]
thorsten_s
Offline
Joined: 2008-08-15

To whom it may concern,

I have been working on a Blackberry implementation that could be used as an alternative to the default MIDP GameCanvas implementation. I know that the default implementation does work fine on a Blackberry. Unfortunately it does not give an option to make use of the Blackberry keys such as the Menu key and the Back(Escape) key. To address this you would have to use of the Blackberry UI classes which in turn requires to write a Blackberry CLDC application instead of a MIDlet. While this requires you to build more than one jar, this does have a few advantages, too. Anyway, it's good to have the choice.

The sources are provided AS IS, they are not complete and are not completely working, yet! You are invited to help out here. I am new to the Blackberry API and probably a few things could/should have been approached differently. The header of each file contains some implementation and usage notes. Note that Blackberry OS >= 4.2 is required for the BBScreenImplementation class and OS>= 4.7 for the BBScreenImplementationTouch class.

Things that still need work:
* touch gestures
* system font stuff
* play media
* lifecycle
* making use of filters for input sensitivity configuration?
* screen rotation/resizing
* character input for textfield (not textarea) completely untested
* problem when clicking the menu button twice, seems to be LWUIT related.
* probably a lot more

find sources at https://lwuit.dev.java.net/source/browse/lwuit-incubator/trunk/thorsten_s/

Edit: changed source location.

Another Edit: there is the new official implementation available that you could try out at:
https://lwuit.dev.java.net/source/browse/lwuit/trunk/BlackBerry/
http://lwuit.blogspot.com/2009/08/new-stuff-in-lwuit.html

Message was edited by: thorsten_s

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
thorsten_s
Offline
Joined: 2008-08-15

Right now I have no Idea what could be happening here. I see no reason why this case should behave different than the same app using the MIDP implementation. I guess you should post some working example code to reproduce the issue.

Making use of the back button works by just setting a command as the back command on a form. Use the Form.setBackCommand(Command backCommand) method. Then listen for the command and show whatever form you like. That's it. It should behave like any other back button on other Java ME devices.

PS: Thank's for the feedback everyone, I really appreciate it!

technolgia
Offline
Joined: 2009-03-09

Hi ,

In my application i use the forms setBackCommand() method to map the escape key of blackberry using Thorstons port. In the same way is it possible to map the dialogue's Cancel command to the escape key and dialogue's Ok command to fireclicked?
Can someone help me out with this.

Thanking you,
Regards,
S.A.Norton Stanley

technolgia
Offline
Joined: 2009-03-09

Hi,

I got it working by setting the same for the dialog. :-)

[b]Regards,
S.A.Norton Stanley[/b]

achie3xis
Offline
Joined: 2008-08-26

Hi Thorsten.

In u'r last revision(26),i can't make full obfuscation.obfuscation just in level 8..
Thanx.

Regards,

[b]Asri Dwitiya[/b]

cknappe
Offline
Joined: 2008-08-28

Hi Thorsten,

I build some TestCode for the Form Problem. Hope this can give you some help.

http://projects.innascor.com/gaia/dev/Test.java

I've seen the BBDeviceImplementationDirect in the repos - whats this about?

Regards,
Christian

thorsten_s
Offline
Joined: 2008-08-15

Hi Christian,

the class you mentioned has been created to test drawing on the screen directly without using an image as a buffer. It's not working too well but I figured it might be interesting to people hacking on the implementation. My advice: Don't use it.

The menu issue is caused by the padding of the soft buttons. You could adjust the style on your forms manually (including the menu dialog!):
[code]
Form form = new Form(){
protected Command showMenuDialog(Dialog menu) {
menu.getSoftButtonStyle().setPadding(0, 0, 0, 0);
return super.showMenuDialog(menu);
}

};
form.getSoftButtonStyle().setPadding(0, 0, 0, 0);
[/code]

Currently I do not see a way to globally set that style other than modifying the Form.MenuBar class.

cknappe
Offline
Joined: 2008-08-28

Hello Thorsten,

thanks a lot - this works fine. Now I have a nother problem - but I think this is a LWUIT related thing. I did some kind of a wizard for setting some configuration parameters.

The code which closes the actual dialog and shows the next step is as follows...

private void start(final IGWizView view){

if(this.actView != null){
this.actView.dispose();
}

if(view != null){
// save step id to config
this.getMainController().getGModel().getGConfiguration().setLastWizStep(view.getID());
this.actView = view;
this.actView.showPacked(BorderLayout.CENTER, true);
}
}

This works fine in a older version of LWUIT (rev. 244 for example). But know I want to use a newer revision for your incubator. The link shows a screen of the behavior. It seems that the actual dialog could not be disposed. But on some steps it works - I really don't know whats the problem here.

http://projects.innascor.com/gaia/dev/

Any ideas?

Regards, Christian

drdth
Offline
Joined: 2003-06-16

> I am thinking about switching to an other
> client for my eclipse - could you give me an advice.

Try subversive instead ?

cknappe
Offline
Joined: 2008-08-28

Switched to subversive now. All my other repositories work fine. But I think the client wasn't the problem.

I just tried to check out https://lwuit.dev.java.net/source/browse/lwuit-incubator/trunk/thorsten_s/ instead of https://lwuit-incubator.dev.java.net/svn/lwuit-incubator/trunk ...

So know everything is fine.

Thanks a lot.

technolgia
Offline
Joined: 2009-03-09

Hi Thorston,

I am trying to run an application on BB but am not successful. Can u please guide me with the steps to go about doing this. How do i make use of ur sources.

Thanks,
Regards,
Norton

thorsten_s
Offline
Joined: 2008-08-15

Hello Norton,
there are instructions in a README_BB.txt file within the sources at https://lwuit.dev.java.net/source/browse/lwuit-incubator/trunk/thorsten_...

Other than that I am afraid you have to check the blackberry developer guide and other docs at http://na.blackberry.com/eng/developers/resources/ as well as the LWUIT developer guide at https://lwuit.dev.java.net/servlets/ProjectDocumentList

Regards,
Thorsten.

monicager
Offline
Joined: 2006-03-14

Hi thorsten,

First of all thanks very much for the bb implementation. I'm developing a BlackBerry app with LWUIT and I really need this. :)

I configure the latest lwuit and thorsten sources from svn with rim_api in Eclipse. I can build it an run in blackberry devices, I'm testing with bb 4.3 and 4.6 simulators.

I have a problem with TextField when I use T9 input way. When I select T9 a new dialog is showed, I type something and a ClassCastException is throw.

I'm using MIDlets not UiApplication, maybe the problem is related to this.
Can I use MIDlets or do you recommend me to use UiApplication?

Sorry about my english.

Regards,

Mónica

monicager
Offline
Joined: 2006-03-14

I found the problem, was my mistake. The ClassCastException was thrown in equals method of com.sun.lwuitCommand, that the first line of this is

public boolean equals(Object obj) {
if(((Command)obj).command == null) {

I think this is method wrong, because it'll fail in case of have the same listener of different kinds of controls, this was changed in the last revision.

Regards,

winvinay
Offline
Joined: 2009-06-09

Hi Thorsten,

Nice work!! its really helpful for me.

I am porting an existing J2ME LWUIT application to blackberry. I was able to port the application using BBScreenImplementation class.

I have to configure back button so that it loads some other screen on click of it. But problem with that is when back button is clicked twice the screen is hanging. If i click back button only once it works. Can you please give a code example on configuring back button in BBScreenImplementation to navigate to some new screen or some previous screen.

Regards,
Vinay H V

technolgia
Offline
Joined: 2009-03-09

Hi Thorston,

Real good job. Am sure i couldn have done anything with blackberry without ur classes..

Regards,
Norton

sojourner_jdk
Offline
Joined: 2008-12-17

Hi Thorsten,
I am trying to build lwuit-incubator project meant for BlackBerry. I am getting the following error:

[b]Error preverifying class java.beans.PropertyChangeEvent
java/lang/NoClassDefFoundError: java/util/EventObject[/b]

I am using Netbeans 6.5 and have already included net_rim_api.jar.

Any info to fix this problem would be highly appreciated.

Thanks,
-jdk

thorsten_s
Offline
Joined: 2008-08-15

Check your path settings. You are trying to preverify the class PropertyChangeEvent that references Event object which is not available. This has nothing to do with LWUIT or the Blackberry implementation.
Regards,
Thorsten.

smartfish
Offline
Joined: 2008-09-05

hi thorsten_s ,

I am also getting the same error.."Error preverifying class java.beans.PropertyChangeEvent
java/lang/NoClassDefFoundError: java/util/EventObject" What path settings do i have to make in order to run my application (TestMidlet.java). I am using Netbeans 6.1 .
thanks and regards,
SmartFish

achie3xis
Offline
Joined: 2008-08-26

Hi..

i'll try u'r 19 revision.,but it show the same result.,when i click the icon.,my app can't show my splashform..i show splashform in the begin..
But.,no error show..

Regards,

[b]Asri Dwitiya[/b]

thorsten_s
Offline
Joined: 2008-08-15

Hello Asri,
I fail to see any bug in the changes of revision 18. Please make sure the location strings to your images start with a '/'.
Regards,
Thorsten.

achie3xis
Offline
Joined: 2008-08-26

Hi..

yups sorry.,i forget add a "/" in my path..
that's because in under 17 u'r revision is must without "/".
But.,how with my textfield...???if i use RIM java programming it's not have any problem..

Regards,

[b]Asri Dwitiya[/b]

achie3xis
Offline
Joined: 2008-08-26

Hi Thorsten..

i use u'r revision 17 with no problem..but when i use no 18 my app hang..

Regards,

[b]Asri Dwitiya[/b]

Message was edited by: achie3xis

thorsten_s
Offline
Joined: 2008-08-15

Hello Asri,
the text field behavior you described seems to be unrelated to the blackberry implementation. I think that is an issue of the LWUIT textfield implementation. Maybe Shai or Chen will pick this up.

Could you give some more details on the hanging situation? I understand that is different from the text field issue?

Regards,
Thorsten.

achie3xis
Offline
Joined: 2008-08-26

Hi thorsten..

when i click my icon app in bb simulator.,directly my app hang..
but when i use u'r revision 17 and under.,my app works well..
i use jde 4.5.0 and bb 8310 device.

Regards,

[b]Asri Dwitiya[/b]

Message was edited by: achie3xis

dickkwong
Offline
Joined: 2009-01-06

Great Job, thorsten_s!

I have tried on blackberry bold (4.6.0) and it works fine on my application. Two question if you can help and one minor bug I wonder.

question:
is it possible to make the menu popup on left side of screen?
is it possible to make the menu has the same graphical style as native blackberry application?

minor bug:
I found that the left and right key are swapped.

interesting thing is, if I swap the value of left and right key code, the problem still exist and no effect on the left-right swap problem at all.
private static final int BB_IMPL_KEY_LEFT = -23457; //org value -23456;
private static final int BB_IMPL_KEY_RIGHT = -23456; //org value -23457;

So, in BBScrenImplementation.java, I change the follow function code to fix this.
-----------
public int getGameAction(int keyCode) {
switch (keyCode) {
case BB_IMPL_KEY_DOWN:
return Display.GAME_DOWN;
case BB_IMPL_KEY_UP:
return Display.GAME_UP;
[b] case BB_IMPL_KEY_LEFT:
return Display.GAME_RIGHT;
case BB_IMPL_KEY_RIGHT:
return Display.GAME_LEFT;[/b]
case BB_IMPL_KEY_FIRE:
return Display.GAME_FIRE;
default:
return 0;
}
}

public int getKeyCode(int gameAction) {
switch (gameAction) {
case Display.GAME_DOWN:
return BB_IMPL_KEY_DOWN;
case Display.GAME_UP:
return BB_IMPL_KEY_UP;
[b] case Display.GAME_RIGHT:
return BB_IMPL_KEY_LEFT;
case Display.GAME_LEFT:
return BB_IMPL_KEY_RIGHT;[/b]
case Display.GAME_FIRE:
return BB_IMPL_KEY_FIRE;
default:
return 0;
}
}
-------------
anyidea?

thanks a lot.

thorsten_s
Offline
Joined: 2008-08-15

Thank you for your input, I just checked in a fix for the messed up key events. But I did apply the change to the navigationMovement() method as that's the place where left and right were confused.

To your two questions regarding the menu: Yes ans yes.

One approach would be to override these two methods:
Form.showMenuDialog(Dialog menu)
Form.createCommandList(Vector commands)
I don't know how close you can get by using the style editor.

If you manage to create a nice result, let us know ;-)

Thank's for the bugreport,
Thorsten.

dickkwong
Offline
Joined: 2009-01-06

Yes, the problem is found in navigationMovement().

For the left-menu, right-back setting, I found that the most easy way is
UIManager.getInstance().getLookAndFeel().setReverseSoftButtons(true);

For the style of popup Menu, your suggestion need to override the methods in Form. I am not sure how difficult if using native blackberry popup Menu together with your LWUIT implementation. In other words, override these two methods and use blackberry popup menu API inside these override. What's your opinion? (sorry I am lazy to study it as I am green on blackberry API)

Cheers
dickkwong

thorsten_s
Offline
Joined: 2008-08-15

Yes, I do believe you could use a native blackberry menu within the Form.showMenuDialog(Dialog menu) method. You might not even have to touch the com.sun.lwuit.impl.bb classes. You would just push another screen on top. It's not a very portable solution. I would not do it, but it might just be what you are looking for.

dickkwong
Offline
Joined: 2009-01-06

Hi Thorsten_s,

For the menu, if I click it twice, the menu will popup selection of [select, cancel] after your 1st popup menu. Is it possible to take it away?

For the blackberry, if you click menu button twice, the menu will popup, and then disappear.

any idea?

Cheers
dickkwong

thorsten_s
Offline
Joined: 2008-08-15

Hello,
I think you have to update your LWUIT version (not the blackberry implementation). The second (unwanted) menu on top of the first is a bug that has been fixed sometime in the past.

Interesting thing about the menu closing behavior. I did not think about it at all. It would be very nice to get LWUIT to behave the same way. But it (probably) had to be changed within LWUIT. That would affect other platforms that have a single menu button, too.
I wonder if there are other devices out there with a single menu/soft button that behave different. Does anyone know one?

dickkwong
Offline
Joined: 2009-01-06

hiya,

the lwuit I am using is the latest 20081222 already. (any updated?)

may be I am not making it clear.

for sun implementation, say, if you have [back, go] command added, you will have
[back go]
on the bottom menu bar.

and If you have [back, go, map, stop, home], you will have
[back menu]
if you click menu, you will have
1. a popup menu of [back, go, map, stop, home]
2. [cancel select] on the bottom menu bar.

now, turns what I see when it is implemented in BB (of course, no bottom menu bar anymore)

If you have [back, go, map, stop, home] and click menu button, popup menu of
[back, go, map, stop, home] will shown.

and let's say within the popup menu, [go] is highlighted, if you click menu botton again (second menu button click),
a popup menu [select cancel] is shown.

that's what I don't want to have, and what expected is no more popup menu on the screen as 2nd menu botton clicked. (same as BB menu button behaviour)

any clue?

thorsten_s
Offline
Joined: 2008-08-15

Yes, we speak about the same thing but I should have mentioned the SVN sources I guess :-)
The bug has been fixed after the binary release. Updating will fix your first problem. But the menu will not be closed on the second press of the menu button. You would have to press the back button.

boopalanm
Offline
Joined: 2008-12-24

Thanks thorsten,

this works for me also.
but i find a problem while using this..
when i use Image Label in this code i am getting Nullpointer exception
when i command the code

[b]com.sun.lwuit.impl.ImplementationFactory.setInstance(
new com.sun.lwuit.impl.bb.BBScreenImplementation.BBImplementationFactory());[/b]

its working fine
can you please find the reason where i did the mistake..

the following code i used to display the image label

[b]Image img = Image.createImage("/images/logo.png");
Label imgl = new Label(img);
form.addComponent(imgl);[/b]

thanks,
boopalanm

boopalanm
Offline
Joined: 2008-12-24

sorry i find the reason

the problem with the image path

thanks,
boopalan

thorsten_s
Offline
Joined: 2008-08-15

Hi,
I applied a change anyway. Seems the Blackberry method Bitmap.getBitmapResource(String) expects a different type of input than its J2ME counterpart.
This probably breaks your workaround , so make sure you start the path with a '/' again ;-)
Regards,
Thorsten.

achie3xis
Offline
Joined: 2008-08-26

Hi Thorsten...

maybe i found the bug..
if i have 2 textfield :
1.one textfield i setConstraint(TextField.ANY);
2.another textfield i setConstraint(TextField.PASSWORD);

the strange is if my focus move from textfield number one to number two and i back again to one.,i must press any key if i want to delete character in textfield number one.
Forgive me if i wrong.thanks

Regards,

[b]Asri Dwitiya[/b]

thorsten_s
Offline
Joined: 2008-08-15

The sources have been moved to the LWUIT incubator at https://lwuit.dev.java.net/source/browse/lwuit-incubator/trunk/

Note that you no longer have to pass the UiApplication instance to the init method. The init method now accepts a MIDlet, a UiApplication or null.

So the whole thing could work with a midlet as its base class:

[code]
ImplementationFactory.setInstance(
new BBScreenImplementation.BBImplementationFactory());
Display.init(null); // or Display.init(myMidlet); or Display.init(myUiApplication);
// now do GUI stuff.
[/code]

don't forget that the code is more or less experimental, so expect to run into problems.

Arnau Vàzquez

[att1.html]

Shai Almog

Hi.
timeframe has nothing to do with me so no.

Personally I would recommend the following for helping now:
1. Start playing with Thorsten's solution, I can't look at it myself
but I understand he did something very similar. Lessons learned by
you guys playing with his port can probably be applied to our port.

2. If you want to contribute to help BB development sign the SCA and
email it to lwuit (at) sun (dot) com to join the LWUIT incubator.
Once stuff is added to the LWUIT incubator I can look at it and try
to help without fear of "tainting".

> Hi Shai,
>
> do you have any approximate timeframe for the approval / release of
> this port? Would it be possible for us, the community, to help in
> the testing process to help speed up its development? (as we have
> BB devices and you seem to have not).
>
> Thanks in advance,
> Arnau
>
>
> En/na Shai Almog ha escrit:
>>
>> Hi Thorsten,
>> great job! That is the type of stuff we were looking for when open
>> sourcing LWUIT ;-)
>>
>> I already implemented an official LWUIT BlackBerry port on top of
>> the BB API, however we are still waiting for both management
>> approval and testing of this port (its problematic since we don't
>> have a working device).
>>
>> I took a very similar approach to yours with my implementation the
>> things that are implemented in our port are:
>> * Rotation
>> * Touch
>> * Hover/click touch support
>> * Multi-touch support
>> * System fonts
>> * Media - Partial we are experiencing some issues with the BB
>> media implementation.
>> * In place native text editing
>>
>>
>> Menu etc. also works as expected in our port. However, since we
>> don't have a device we can only confirm this on the simulator.
>>
>> Regards,
>> Shai.
>>
>>
>>> To whom it may concern,
>>>
>>> I have been working on a Blackberry implementation that could be
>>> used as an alternative to the default MIDP GameCanvas
>>> implementation. I know that the default implementation does work
>>> fine on a Blackberry. Unfortunately it does not give an option
>>> to make use of the Blackberry keys such as the Menu key and the
>>> Back(Escape) key. To address this you would have to use of the
>>> Blackberry UI classes which in turn requires to write a
>>> Blackberry CLDC application instead of a MIDlet. While this
>>> requires you to build more than one jar, this does have a few
>>> advantages, too. Anyway, it's good to have the choice.
>>>
>>> The sources are provided AS IS, they are not complete and are not
>>> completely working, yet! You are invited to help out here. I am
>>> new to the Blackberry API and probably a few things could/should
>>> have been approached differently. The header of each file
>>> contains some implementation and usage notes. Note that
>>> Blackberry OS >= 4.2 is required for the BBScreenImplementation
>>> class and OS>= 4.7 for the BBScreenImplementationTouch class.
>>>
>>> Things that still need work:
>>> * touch gestures
>>> * system font stuff
>>> * play media
>>> * lifecycle
>>> * making use of filters for input sensitivity configuration?
>>> * screen rotation/resizing
>>> * character input for textfield (not textarea) completely untested
>>> * problem when clicking the menu button twice, seems to be LWUIT
>>> related.
>>> * probably a lot more
>>>
>>>
>>> http://www.pader-sync.com/bbimpl/BBScreenImplementation.java
>>> http://www.pader-sync.com/bbimpl/BBScreenImplementationTouch.java
>>> [Message sent by forum member 'thorsten_s' (thorsten_s)]
>>>
>>> http://forums.java.net/jive/thread.jspa?messageID=321694
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>>
>>
>> Shai Almog
>> http://lwuit.blogspot.com/
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net For
> additional commands, e-mail: users-help@lwuit.dev.java.net

Shai Almog
http://lwuit.blogspot.com/

[att1.html]

Patrick Julien

Hi Shai,

Would it not be possible for us to get a binary drop similar to the
one we received before LWUIT was open sourced?

I'm also wondering if it would be of value to add an entry point class
to LWUIT so that a LWUIT developer doesn't need to rely on the
pre-processor to either include a Midlet derived class or one that is
derived from a RIMlet Application.

On Mon, Dec 15, 2008 at 7:08 AM, Shai Almog wrote:
> Hi Thorsten,
> great job! That is the type of stuff we were looking for when open sourcing
> LWUIT ;-)
> I already implemented an official LWUIT BlackBerry port on top of the BB
> API, however we are still waiting for both management approval and testing
> of this port (its problematic since we don't have a working device).
> I took a very similar approach to yours with my implementation the things
> that are implemented in our port are:
> * Rotation
> * Touch
> * Hover/click touch support
> * Multi-touch support
> * System fonts
> * Media - Partial we are experiencing some issues with the BB media
> implementation.
> * In place native text editing
>
> Menu etc. also works as expected in our port. However, since we don't have a
> device we can only confirm this on the simulator.
> Regards,
> Shai.
>
> To whom it may concern,
> I have been working on a Blackberry implementation that could be used as an
> alternative to the default MIDP GameCanvas implementation. I know that the
> default implementation does work fine on a Blackberry. Unfortunately it
> does not give an option to make use of the Blackberry keys such as the Menu
> key and the Back(Escape) key. To address this you would have to use of the
> Blackberry UI classes which in turn requires to write a Blackberry CLDC
> application instead of a MIDlet. While this requires you to build more than
> one jar, this does have a few advantages, too. Anyway, it's good to have
> the choice.
> The sources are provided AS IS, they are not complete and are not completely
> working, yet! You are invited to help out here. I am new to the Blackberry
> API and probably a few things could/should have been approached
> differently. The header of each file contains some implementation and usage
> notes. Note that Blackberry OS >= 4.2 is required for the
> BBScreenImplementation class and OS>= 4.7 for the
> BBScreenImplementationTouch class.
> Things that still need work:
> * touch gestures
> * system font stuff
> * play media
> * lifecycle
> * making use of filters for input sensitivity configuration?
> * screen rotation/resizing
> * character input for textfield (not textarea) completely untested
> * problem when clicking the menu button twice, seems to be LWUIT related.
> * probably a lot more
>
> http://www.pader-sync.com/bbimpl/BBScreenImplementation.java
> http://www.pader-sync.com/bbimpl/BBScreenImplementationTouch.java
> [Message sent by forum member 'thorsten_s' (thorsten_s)]
> http://forums.java.net/jive/thread.jspa?messageID=321694
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
> Shai Almog
> http://lwuit.blogspot.com/
>

--
http://www.spectrumdt.com
http://codepimps.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net

Shai Almog

Hi Patrick,
I don't think source release or binary release will make any
difference in terms of the effort we need to make to get this
published (I'm really terrible with all of these corporate processes)...

In the case of RIM I just use the unmodified MIDlet of the LWUITDemo
with the new implementation and it works as advertised. I am no
expert in RIM and don't have a BB device so I have no idea if this is
a problem, my understanding is that RIM supports a global UI
application instance which you can get through the static getter
method in UiApplication even if you are a MIDlet. I understand this
is "unofficial" and used by pretty much everyone...

Regarding the generic "lifecycle class" is something Chen and myself
toyed with a bit, less for RIM but more for the Android/CDC port
where this would indeed be useful. There are several problems here:

1. We will need to include a main class which the user will need to
define as a MIDlet/RIMlet etc... this will not be intuitive without
IDE guidance.

2. The class will need someway to detect the application starting
point e.g. our MIDlets startApp will need to invoke the generic
"start" for the application. The problem is that with obfuscation we
won't be able to find the class.
Even if obfuscation were removed this means you will need to
customize the class name in the jad or some other location which
isn't trivial...

3. It will be a subset of the lifecycle API meaning it will suck for
advanced users.

4. This is beyond the current scope of LWUIT - we can venture beyond
GUI but right now we have a ton of work to do so this is behind quite
a few other things...

Since the "lifecycle class" in all platforms is relatively simple,
you can avoid the preprocessor and use features such as the netbeans
build filter which allows you to define files to ignore/accept for a
specific configuration. Then have a MIDlet/main class/xlet/intent
etc. all of which would be compiled only with the appropriate build.

> Hi Shai,
>
> Would it not be possible for us to get a binary drop similar to the
> one we received before LWUIT was open sourced?
>
> I'm also wondering if it would be of value to add an entry point class
> to LWUIT so that a LWUIT developer doesn't need to rely on the
> pre-processor to either include a Midlet derived class or one that is
> derived from a RIMlet Application.
>
> On Mon, Dec 15, 2008 at 7:08 AM, Shai Almog
> wrote:
>> Hi Thorsten,
>> great job! That is the type of stuff we were looking for when open
>> sourcing
>> LWUIT ;-)
>> I already implemented an official LWUIT BlackBerry port on top of
>> the BB
>> API, however we are still waiting for both management approval and
>> testing
>> of this port (its problematic since we don't have a working device).
>> I took a very similar approach to yours with my implementation the
>> things
>> that are implemented in our port are:
>> * Rotation
>> * Touch
>> * Hover/click touch support
>> * Multi-touch support
>> * System fonts
>> * Media - Partial we are experiencing some issues with the BB media
>> implementation.
>> * In place native text editing
>>
>> Menu etc. also works as expected in our port. However, since we
>> don't have a
>> device we can only confirm this on the simulator.
>> Regards,
>> Shai.
>>
>> To whom it may concern,
>> I have been working on a Blackberry implementation that could be
>> used as an
>> alternative to the default MIDP GameCanvas implementation. I know
>> that the
>> default implementation does work fine on a Blackberry.
>> Unfortunately it
>> does not give an option to make use of the Blackberry keys such as
>> the Menu
>> key and the Back(Escape) key. To address this you would have to
>> use of the
>> Blackberry UI classes which in turn requires to write a Blackberry
>> CLDC
>> application instead of a MIDlet. While this requires you to build
>> more than
>> one jar, this does have a few advantages, too. Anyway, it's good
>> to have
>> the choice.
>> The sources are provided AS IS, they are not complete and are not
>> completely
>> working, yet! You are invited to help out here. I am new to the
>> Blackberry
>> API and probably a few things could/should have been approached
>> differently. The header of each file contains some implementation
>> and usage
>> notes. Note that Blackberry OS >= 4.2 is required for the
>> BBScreenImplementation class and OS>= 4.7 for the
>> BBScreenImplementationTouch class.
>> Things that still need work:
>> * touch gestures
>> * system font stuff
>> * play media
>> * lifecycle
>> * making use of filters for input sensitivity configuration?
>> * screen rotation/resizing
>> * character input for textfield (not textarea) completely untested
>> * problem when clicking the menu button twice, seems to be LWUIT
>> related.
>> * probably a lot more
>>
>> http://www.pader-sync.com/bbimpl/BBScreenImplementation.java
>> http://www.pader-sync.com/bbimpl/BBScreenImplementationTouch.java
>> [Message sent by forum member 'thorsten_s' (thorsten_s)]
>> http://forums.java.net/jive/thread.jspa?messageID=321694
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>> Shai Almog
>> http://lwuit.blogspot.com/
>>
>
>
>
> --
> http://www.spectrumdt.com
> http://codepimps.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

Shai Almog
http://lwuit.blogspot.com/

[att1.html]

Patrick Julien

I understand your arguments on the life cycle class, makes sense to me
that it's less of a priority.

You're right about UiApplication being unsupported but being used by
pretty much every one also. However, let me highlight two things here
that you won't notice using emulators that will still show up if
you're using a midlet.

1. The security dialog, even if you have a signed COD file, will still
show up on BB OS if you're using a MIDlet. Worse still, if you happen
to have users on BB 4.1, the application looks blocked because the
security dialog shows up beneath the midlet. I know this is a bug in
the OS but I've already helped a few developers on this list out of
this jam. Unfortunately, BB OS 4.1 is still in widespread use.

That being said, I didn't quite get from your email if the use of a
midlet on BB was mandatory or optional.

2. Performance penalty. Unfortunately, it seems using a midlet, the
application is just slower on this platform. I do not understand why
that is.

Also, I'm wondering how you guys handled SVG on this platform. BB OS
4.7 has SVG support but previous versions do not. Considering the VM
on BB OS is brain dead and tries to load every class on startup, is
the idea here to have more than one binary for BB? One for 4.7+ and
one for < 4.7?

On Tue, Dec 16, 2008 at 9:31 AM, Shai Almog wrote:
> Hi Patrick,
> I don't think source release or binary release will make any difference in
> terms of the effort we need to make to get this published (I'm really
> terrible with all of these corporate processes)...
> In the case of RIM I just use the unmodified MIDlet of the LWUITDemo with
> the new implementation and it works as advertised. I am no expert in RIM and
> don't have a BB device so I have no idea if this is a problem, my
> understanding is that RIM supports a global UI application instance which
> you can get through the static getter method in UiApplication even if you
> are a MIDlet. I understand this is "unofficial" and used by pretty much
> everyone...
> Regarding the generic "lifecycle class" is something Chen and myself toyed
> with a bit, less for RIM but more for the Android/CDC port where this would
> indeed be useful. There are several problems here:
> 1. We will need to include a main class which the user will need to define
> as a MIDlet/RIMlet etc... this will not be intuitive without IDE guidance.
> 2. The class will need someway to detect the application starting point e.g.
> our MIDlets startApp will need to invoke the generic "start" for the
> application. The problem is that with obfuscation we won't be able to find
> the class.
> Even if obfuscation were removed this means you will need to customize the
> class name in the jad or some other location which isn't trivial...
> 3. It will be a subset of the lifecycle API meaning it will suck for
> advanced users.
> 4. This is beyond the current scope of LWUIT - we can venture beyond GUI but
> right now we have a ton of work to do so this is behind quite a few other
> things...
>
> Since the "lifecycle class" in all platforms is relatively simple, you can
> avoid the preprocessor and use features such as the netbeans build filter
> which allows you to define files to ignore/accept for a specific
> configuration. Then have a MIDlet/main class/xlet/intent etc. all of which
> would be compiled only with the appropriate build.
>
>
> Hi Shai,
> Would it not be possible for us to get a binary drop similar to the
> one we received before LWUIT was open sourced?
> I'm also wondering if it would be of value to add an entry point class
> to LWUIT so that a LWUIT developer doesn't need to rely on the
> pre-processor to either include a Midlet derived class or one that is
> derived from a RIMlet Application.
> On Mon, Dec 15, 2008 at 7:08 AM, Shai Almog wrote:
>
> Hi Thorsten,
> great job! That is the type of stuff we were looking for when open sourcing
> LWUIT ;-)
> I already implemented an official LWUIT BlackBerry port on top of the BB
> API, however we are still waiting for both management approval and testing
> of this port (its problematic since we don't have a working device).
> I took a very similar approach to yours with my implementation the things
> that are implemented in our port are:
> * Rotation
> * Touch
> * Hover/click touch support
> * Multi-touch support
> * System fonts
> * Media - Partial we are experiencing some issues with the BB media
> implementation.
> * In place native text editing
> Menu etc. also works as expected in our port. However, since we don't have a
> device we can only confirm this on the simulator.
> Regards,
> Shai.
> To whom it may concern,
> I have been working on a Blackberry implementation that could be used as an
> alternative to the default MIDP GameCanvas implementation. I know that the
> default implementation does work fine on a Blackberry. Unfortunately it
> does not give an option to make use of the Blackberry keys such as the Menu
> key and the Back(Escape) key. To address this you would have to use of the
> Blackberry UI classes which in turn requires to write a Blackberry CLDC
> application instead of a MIDlet. While this requires you to build more than
> one jar, this does have a few advantages, too. Anyway, it's good to have
> the choice.
> The sources are provided AS IS, they are not complete and are not completely
> working, yet! You are invited to help out here. I am new to the Blackberry
> API and probably a few things could/should have been approached
> differently. The header of each file contains some implementation and usage
> notes. Note that Blackberry OS >= 4.2 is required for the
> BBScreenImplementation class and OS>= 4.7 for the
> BBScreenImplementationTouch class.
> Things that still need work:
> * touch gestures
> * system font stuff
> * play media
> * lifecycle
> * making use of filters for input sensitivity configuration?
> * screen rotation/resizing
> * character input for textfield (not textarea) completely untested
> * problem when clicking the menu button twice, seems to be LWUIT related.
> * probably a lot more
> http://www.pader-sync.com/bbimpl/BBScreenImplementation.java
> http://www.pader-sync.com/bbimpl/BBScreenImplementationTouch.java
> [Message sent by forum member 'thorsten_s' (thorsten_s)]
> http://forums.java.net/jive/thread.jspa?messageID=321694
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
> Shai Almog
> http://lwuit.blogspot.com/
>
>
>
> --
> http://www.spectrumdt.com
> http://codepimps.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
> Shai Almog
> http://lwuit.blogspot.com/
>

--
http://www.spectrumdt.com
http://codepimps.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net

Shai Almog

Hi Patrick,
thats very interesting feedback. If this is the case I would
recommend that people use the UiApplication where possible, it should
work out of the box with a UiApplication just as well as with a
MIDlet since our current port has absolutely no dependency on MIDP or
the MIDlet lifecycle.

I assume both issues relate to the security implementation in the BB
device but thats just a guess.

Our solution for SVG/3D etc. was to create "dummy" SVG/M3G/
Transition3D classes that just return false when queried for
supported. This essentially means that you can code as usual as long
as you test "isSupported" for 3D/SVG (as we do in the LWUIT demo) it
will work as you expected.

Using SVG on newer devices would require another build which I'm not
sure about.

My bigger concern is my solution for touch devices, I built a
BlackBerryCanvas class and then subclassed it as BlackBerryTouch
where I added the touch specific methods (that reference non-existing
classes). This will essentially require JDE 4.7 to compile, my hope
is that it will still run on older devices since I don't reference
the BlackBerryTouch class... Worse comes to worse, we will have two
versions for BB.

> I understand your arguments on the life cycle class, makes sense to me
> that it's less of a priority.
>
> You're right about UiApplication being unsupported but being used by
> pretty much every one also. However, let me highlight two things here
> that you won't notice using emulators that will still show up if
> you're using a midlet.
>
> 1. The security dialog, even if you have a signed COD file, will still
> show up on BB OS if you're using a MIDlet. Worse still, if you happen
> to have users on BB 4.1, the application looks blocked because the
> security dialog shows up beneath the midlet. I know this is a bug in
> the OS but I've already helped a few developers on this list out of
> this jam. Unfortunately, BB OS 4.1 is still in widespread use.
>
> That being said, I didn't quite get from your email if the use of a
> midlet on BB was mandatory or optional.
>
>
> 2. Performance penalty. Unfortunately, it seems using a midlet, the
> application is just slower on this platform. I do not understand why
> that is.
>
> Also, I'm wondering how you guys handled SVG on this platform. BB OS
> 4.7 has SVG support but previous versions do not. Considering the VM
> on BB OS is brain dead and tries to load every class on startup, is
> the idea here to have more than one binary for BB? One for 4.7+ and
> one for < 4.7?
>
> On Tue, Dec 16, 2008 at 9:31 AM, Shai Almog
> wrote:
>> Hi Patrick,
>> I don't think source release or binary release will make any
>> difference in
>> terms of the effort we need to make to get this published (I'm really
>> terrible with all of these corporate processes)...
>> In the case of RIM I just use the unmodified MIDlet of the
>> LWUITDemo with
>> the new implementation and it works as advertised. I am no expert
>> in RIM and
>> don't have a BB device so I have no idea if this is a problem, my
>> understanding is that RIM supports a global UI application
>> instance which
>> you can get through the static getter method in UiApplication even
>> if you
>> are a MIDlet. I understand this is "unofficial" and used by pretty
>> much
>> everyone...
>> Regarding the generic "lifecycle class" is something Chen and
>> myself toyed
>> with a bit, less for RIM but more for the Android/CDC port where
>> this would
>> indeed be useful. There are several problems here:
>> 1. We will need to include a main class which the user will need
>> to define
>> as a MIDlet/RIMlet etc... this will not be intuitive without IDE
>> guidance.
>> 2. The class will need someway to detect the application starting
>> point e.g.
>> our MIDlets startApp will need to invoke the generic "start" for the
>> application. The problem is that with obfuscation we won't be able
>> to find
>> the class.
>> Even if obfuscation were removed this means you will need to
>> customize the
>> class name in the jad or some other location which isn't trivial...
>> 3. It will be a subset of the lifecycle API meaning it will suck for
>> advanced users.
>> 4. This is beyond the current scope of LWUIT - we can venture
>> beyond GUI but
>> right now we have a ton of work to do so this is behind quite a
>> few other
>> things...
>>
>> Since the "lifecycle class" in all platforms is relatively simple,
>> you can
>> avoid the preprocessor and use features such as the netbeans build
>> filter
>> which allows you to define files to ignore/accept for a specific
>> configuration. Then have a MIDlet/main class/xlet/intent etc. all
>> of which
>> would be compiled only with the appropriate build.
>>
>>
>> Hi Shai,
>> Would it not be possible for us to get a binary drop similar to the
>> one we received before LWUIT was open sourced?
>> I'm also wondering if it would be of value to add an entry point
>> class
>> to LWUIT so that a LWUIT developer doesn't need to rely on the
>> pre-processor to either include a Midlet derived class or one that is
>> derived from a RIMlet Application.
>> On Mon, Dec 15, 2008 at 7:08 AM, Shai Almog
>> wrote:
>>
>> Hi Thorsten,
>> great job! That is the type of stuff we were looking for when open
>> sourcing
>> LWUIT ;-)
>> I already implemented an official LWUIT BlackBerry port on top of
>> the BB
>> API, however we are still waiting for both management approval and
>> testing
>> of this port (its problematic since we don't have a working device).
>> I took a very similar approach to yours with my implementation the
>> things
>> that are implemented in our port are:
>> * Rotation
>> * Touch
>> * Hover/click touch support
>> * Multi-touch support
>> * System fonts
>> * Media - Partial we are experiencing some issues with the BB media
>> implementation.
>> * In place native text editing
>> Menu etc. also works as expected in our port. However, since we
>> don't have a
>> device we can only confirm this on the simulator.
>> Regards,
>> Shai.
>> To whom it may concern,
>> I have been working on a Blackberry implementation that could be
>> used as an
>> alternative to the default MIDP GameCanvas implementation. I know
>> that the
>> default implementation does work fine on a Blackberry.
>> Unfortunately it
>> does not give an option to make use of the Blackberry keys such as
>> the Menu
>> key and the Back(Escape) key. To address this you would have to
>> use of the
>> Blackberry UI classes which in turn requires to write a Blackberry
>> CLDC
>> application instead of a MIDlet. While this requires you to build
>> more than
>> one jar, this does have a few advantages, too. Anyway, it's good
>> to have
>> the choice.
>> The sources are provided AS IS, they are not complete and are not
>> completely
>> working, yet! You are invited to help out here. I am new to the
>> Blackberry
>> API and probably a few things could/should have been approached
>> differently. The header of each file contains some implementation
>> and usage
>> notes. Note that Blackberry OS >= 4.2 is required for the
>> BBScreenImplementation class and OS>= 4.7 for the
>> BBScreenImplementationTouch class.
>> Things that still need work:
>> * touch gestures
>> * system font stuff
>> * play media
>> * lifecycle
>> * making use of filters for input sensitivity configuration?
>> * screen rotation/resizing
>> * character input for textfield (not textarea) completely untested
>> * problem when clicking the menu button twice, seems to be LWUIT
>> related.
>> * probably a lot more
>> http://www.pader-sync.com/bbimpl/BBScreenImplementation.java
>> http://www.pader-sync.com/bbimpl/BBScreenImplementationTouch.java
>> [Message sent by forum member 'thorsten_s' (thorsten_s)]
>> http://forums.java.net/jive/thread.jspa?messageID=321694
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>> Shai Almog
>> http://lwuit.blogspot.com/
>>
>>
>>
>> --
>> http://www.spectrumdt.com
>> http://codepimps.org
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
>> For additional commands, e-mail: users-help@lwuit.dev.java.net
>>
>> Shai Almog
>> http://lwuit.blogspot.com/
>>
>
>
>
> --
> http://www.spectrumdt.com
> http://codepimps.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

Shai Almog
http://lwuit.blogspot.com/

[att1.html]

Patrick Julien

Yeah, that doesn't work on BB because all the classes are loaded on
start up. Technically, you should be able to try this on the
emulator, that is, try your 4.7 build on an older JDE. Even with the
emulator, you can see that it doesn't work.

I've had this problem before. I had written code that determines if a
WI-FI interface is available on the phone. These new methods and
classes are only available in 4.3+, this would stop the application
from loading on anything < 4.3.

Great news about the dependency on Midlet, or lack thereof should I say.

On Tue, Dec 16, 2008 at 10:26 AM, Shai Almog wrote:
> Hi Patrick,
> thats very interesting feedback. If this is the case I would recommend that
> people use the UiApplication where possible, it should work out of the box
> with a UiApplication just as well as with a MIDlet since our current port
> has absolutely no dependency on MIDP or the MIDlet lifecycle.
> I assume both issues relate to the security implementation in the BB device
> but thats just a guess.
> Our solution for SVG/3D etc. was to create "dummy" SVG/M3G/Transition3D
> classes that just return false when queried for supported. This essentially
> means that you can code as usual as long as you test "isSupported" for
> 3D/SVG (as we do in the LWUIT demo) it will work as you expected.
> Using SVG on newer devices would require another build which I'm not sure
> about.
> My bigger concern is my solution for touch devices, I built a
> BlackBerryCanvas class and then subclassed it as BlackBerryTouch where I
> added the touch specific methods (that reference non-existing classes). This
> will essentially require JDE 4.7 to compile, my hope is that it will still
> run on older devices since I don't reference the BlackBerryTouch class...
> Worse comes to worse, we will have two versions for BB.
>
>
> I understand your arguments on the life cycle class, makes sense to me
> that it's less of a priority.
> You're right about UiApplication being unsupported but being used by
> pretty much every one also. However, let me highlight two things here
> that you won't notice using emulators that will still show up if
> you're using a midlet.
> 1. The security dialog, even if you have a signed COD file, will still
> show up on BB OS if you're using a MIDlet. Worse still, if you happen
> to have users on BB 4.1, the application looks blocked because the
> security dialog shows up beneath the midlet. I know this is a bug in
> the OS but I've already helped a few developers on this list out of
> this jam. Unfortunately, BB OS 4.1 is still in widespread use.
> That being said, I didn't quite get from your email if the use of a
> midlet on BB was mandatory or optional.
>
> 2. Performance penalty. Unfortunately, it seems using a midlet, the
> application is just slower on this platform. I do not understand why
> that is.
> Also, I'm wondering how you guys handled SVG on this platform. BB OS
> 4.7 has SVG support but previous versions do not. Considering the VM
> on BB OS is brain dead and tries to load every class on startup, is
> the idea here to have more than one binary for BB? One for 4.7+ and
> one for < 4.7?
> On Tue, Dec 16, 2008 at 9:31 AM, Shai Almog wrote:
>
> Hi Patrick,
> I don't think source release or binary release will make any difference in
> terms of the effort we need to make to get this published (I'm really
> terrible with all of these corporate processes)...
> In the case of RIM I just use the unmodified MIDlet of the LWUITDemo with
> the new implementation and it works as advertised. I am no expert in RIM and
> don't have a BB device so I have no idea if this is a problem, my
> understanding is that RIM supports a global UI application instance which
> you can get through the static getter method in UiApplication even if you
> are a MIDlet. I understand this is "unofficial" and used by pretty much
> everyone...
> Regarding the generic "lifecycle class" is something Chen and myself toyed
> with a bit, less for RIM but more for the Android/CDC port where this would
> indeed be useful. There are several problems here:
> 1. We will need to include a main class which the user will need to define
> as a MIDlet/RIMlet etc... this will not be intuitive without IDE guidance.
> 2. The class will need someway to detect the application starting point e.g.
> our MIDlets startApp will need to invoke the generic "start" for the
> application. The problem is that with obfuscation we won't be able to find
> the class.
> Even if obfuscation were removed this means you will need to customize the
> class name in the jad or some other location which isn't trivial...
> 3. It will be a subset of the lifecycle API meaning it will suck for
> advanced users.
> 4. This is beyond the current scope of LWUIT - we can venture beyond GUI but
> right now we have a ton of work to do so this is behind quite a few other
> things...
> Since the "lifecycle class" in all platforms is relatively simple, you can
> avoid the preprocessor and use features such as the netbeans build filter
> which allows you to define files to ignore/accept for a specific
> configuration. Then have a MIDlet/main class/xlet/intent etc. all of which
> would be compiled only with the appropriate build.
>
> Hi Shai,
> Would it not be possible for us to get a binary drop similar to the
> one we received before LWUIT was open sourced?
> I'm also wondering if it would be of value to add an entry point class
> to LWUIT so that a LWUIT developer doesn't need to rely on the
> pre-processor to either include a Midlet derived class or one that is
> derived from a RIMlet Application.
> On Mon, Dec 15, 2008 at 7:08 AM, Shai Almog wrote:
> Hi Thorsten,
> great job! That is the type of stuff we were looking for when open sourcing
> LWUIT ;-)
> I already implemented an official LWUIT BlackBerry port on top of the BB
> API, however we are still waiting for both management approval and testing
> of this port (its problematic since we don't have a working device).
> I took a very similar approach to yours with my implementation the things
> that are implemented in our port are:
> * Rotation
> * Touch
> * Hover/click touch support
> * Multi-touch support
> * System fonts
> * Media - Partial we are experiencing some issues with the BB media
> implementation.
> * In place native text editing
> Menu etc. also works as expected in our port. However, since we don't have a
> device we can only confirm this on the simulator.
> Regards,
> Shai.
> To whom it may concern,
> I have been working on a Blackberry implementation that could be used as an
> alternative to the default MIDP GameCanvas implementation. I know that the
> default implementation does work fine on a Blackberry. Unfortunately it
> does not give an option to make use of the Blackberry keys such as the Menu
> key and the Back(Escape) key. To address this you would have to use of the
> Blackberry UI classes which in turn requires to write a Blackberry CLDC
> application instead of a MIDlet. While this requires you to build more than
> one jar, this does have a few advantages, too. Anyway, it's good to have
> the choice.
> The sources are provided AS IS, they are not complete and are not completely
> working, yet! You are invited to help out here. I am new to the Blackberry
> API and probably a few things could/should have been approached
> differently. The header of each file contains some implementation and usage
> notes. Note that Blackberry OS >= 4.2 is required for the
> BBScreenImplementation class and OS>= 4.7 for the
> BBScreenImplementationTouch class.
> Things that still need work:
> * touch gestures
> * system font stuff
> * play media
> * lifecycle
> * making use of filters for input sensitivity configuration?
> * screen rotation/resizing
> * character input for textfield (not textarea) completely untested
> * problem when clicking the menu button twice, seems to be LWUIT related.
> * probably a lot more
> http://www.pader-sync.com/bbimpl/BBScreenImplementation.java
> http://www.pader-sync.com/bbimpl/BBScreenImplementationTouch.java
> [Message sent by forum member 'thorsten_s' (thorsten_s)]
> http://forums.java.net/jive/thread.jspa?messageID=321694
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
> Shai Almog
> http://lwuit.blogspot.com/
>
>
> --
> http://www.spectrumdt.com
> http://codepimps.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
> Shai Almog
> http://lwuit.blogspot.com/
>
>
>
> --
> http://www.spectrumdt.com
> http://codepimps.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
> Shai Almog
> http://lwuit.blogspot.com/
>

--
http://www.spectrumdt.com
http://codepimps.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net

cargon
Offline
Joined: 2009-08-21

Hi Thorsten,
I've been using your implementation of LWUIT for an application for BB Storm: this is working perfectly! Now I'm trying to develop a similar application for the BB Pearl Flip: do you think it would be possible to handle the external display for this device by modifying your implementation in some way?
Thanks.

thorsten_s
Offline
Joined: 2008-08-15

Hi,
I did a quick search on the BB forums but it seems that there are no APIs to address this screen in any way. So my guess is no, not possible. But if you happen to find out it is possible one could think about how to build this into LWUIT.

bardubitzki
Offline
Joined: 2003-11-02

Hi there,

yesterday, I checked out the latest versions of LWUIT and BB incubator and build the respective libraries. I build my ported LWUIT app with the new BB library but when run debug it doesn't show up in the emulator anymore. This is true on both the BB OS 4.6 and BB OS 4.7 version. The output from the emulators indicate that my app has started but it doesn't show up.

Any ideas what could be wrong?

Regards,
Stephan

bardubitzki
Offline
Joined: 2003-11-02

No one has the same problem?

Just tried again with the latest checkouts from today but same thing.

thorsten_s
Offline
Joined: 2008-08-15

The incubator version still works for me. Or did you mean the new port published by Shai?
It would be great if you could post a complete example that reproduces the problem.

bardubitzki
Offline
Joined: 2003-11-02

Hi Thorsten,

I have used the checkout from the incubator.

Unfortunately, I'm pretty much under time pressure and can't provide you with a complete example. But I can ensure you that the BB LWUIT port build from LWUIT revision 644 and incubator revision 38 works with my project. For now I'm just using this port from my backups to come ahead.

First I thought my problem is caused because I still use a resource file build with the old designer, but my generic LWUIT project works with the latest LWUIT checkout.