Skip to main content

helloWorld midlet crashing

18 replies [Last post]
mdmazzotti
Offline
Joined: 2008-05-09
Points: 0

Hi,
I'm testing the Midlet I'm writing making use of LWUIT with several WTK emulator (what is the difference between an emulator and a simulator btw?) and all is fine.
Now I just tried this trivial Midlet on my actual Motorola V3x and it crashes as soon as I lunch it.

Is calling UIManager.getInstance().setThemeProps mandatory?

Here's the code, am I missing something?

import javax.microedition.midlet.MIDlet;
import com.sun.lwuit.Form;
import com.sun.lwuit.Display;

public class TestMIDlet extends MIDlet {

private boolean midletPaused = false;

public TestMIDlet() {
}

private void initialize() {
Display.init(this);

Form main = new Form("hello world!");

main.setLayout(new BorderLayout());
main.setScrollable(false);
main.show();
}

public void resumeMIDlet() {
if (current != null) {
current.show();
}
}

public void exitMIDlet() {
destroyApp(true);
notifyDestroyed();
}

public void startApp() {
if (midletPaused) {
resumeMIDlet();
} else {
initialize();
startMIDlet();
}
midletPaused = false;
}

public void pauseApp() {
midletPaused = true;
}
}

Thanks in advance!
Matteo

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Qunhuan Mei

Hi Shai,

Sorry I did not respond you promptly last week since I was tied with other things.

Thanks for the tip for how to check what obfuscator has done, which is new and useful to me!

Although as a developer we would like to see the LWUIT stuff in its best and commercial ready form ASAP, I suppose at the moment, we should help to find out any fundamental issues and be patient waiting for you guys to sort issues out.

Many thanks,

Qunhuan

(I noticed there seems to be a "back door" entry for file reading when "#" key is clicked while an app is running - can be removed?)

-----Original Message-----
From: lwuit-users@mobileandembedded.org [mailto:lwuit-users@mobileandembedded.org]
Sent: 07 June 2008 16:24
To: users@lwuit.dev.java.net
Subject: Re: LWUIT code size

Hi Qunhuan,
I responded to this by email but for some reason I don't see the response here...

Regardless I ran some checks about size since yesterday and there are good and bad news:

The good news is what I could tell you in advance, we don't use JSR 75 or 184 in the core of LWUIT and so all the code that makes use of these features will disappear after obfuscation if you don't use features such as logging or 3D.

The bad news is that due to some changes I made in the code recently the core got a bit chubbier than it should be and a hello world MIDlet weighs more than it should. I am analyzing this with the obfuscators help and I pinpointed several different areas of optimization.

I will try to implement these changes and reduce the overall size for the next version.

FYI to check what gets packaged into your application under netbeans do the following:
1. Open the project properties.
2. Go to obfuscating option under "Build".
3. Set the obfuscation level slider to High (level 9).
4. In the Additional obfuscator settings box paste:
-printmapping c:\outputfolder\log.txt
5. Clean and build the project.
6. Open c:\outputfolder\log.txt in a text editor and go over the classes that are packaged in.
7. To see how much a class costs after obfuscation use 7zip (or winzip etc...) and look at the compressed size for the mapped file (using the log.txt file to see the class name after obfuscation). Add about 200 bytes per class for zip overhead.

Keep in mind that LWUIT will shrink somewhat in the next drop ;-)

Thanks,
Shai.

> Hi there,
>
> Good to know that the LWUIT’s code size, after
> compression, is now 123k!
>
> I have noticed to make LWUIT based J2ME app work, the
> minimum API support, apart from MIDP 2.0 and CLDC
> 1.1, is File and PIM API, and Mobile 3D API. I was
> just wondering if there is still further potential to
> make the code size smaller, since these 2 APIs are
> usually not used in the app, or maybe the obfuscator
> has already figured this out and no code from these
> two APIs are actually included in the final app so
> 123k is final.
>
> Any thoughts?
>
> Many thanks,
>
> Qunhuan
[Message sent by forum member 'vprise' (vprise)]

http://forums.java.net/jive/thread.jspa?messageID=278947

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

Matteo Mazzotti

I haven't slept for 2 nights trying to find a solution to this puzzle, so I
thought it was your time to take some of the burden on your hands (you're
still the creator here, aren't you ;)
And I must say it seems like you finally made it! Implementing runnable thus
delegating the form creation to a second thread called serially seems to
have solved the issue. Now the form is shown and no exception is thrown.
I guess now you'll have to investigate in your code the origin of what seems
to be, as you said, a race condition...

Thanks again, and consider me at your disposal for another debugging session
;)

Matteo

> Hi Matteo,
> you officially managed to stump me :-)
>
> I'm baffled by this issue...
>
> The fact that the form appears indicates that Display.init(),
> worked correctly and that form.show() worked correctly (at
> least partially).
> The startApp() method occurs on the MIDP thread where the
> code showing the form occurs on the LWUIT thread, this
> shouldn't pose a problem in general and this works on devices
> but I'm thinking maybe the latest version introduced a form
> of race condition...
>
> Try the following, implement runnable in your MIDlet and use
> the following code. This will execute the show() in the LWUIT
> EDT thus removing the potential race condition. Something
> like this makes sense with some of the performance changes I
> made in the latest drop:
> protected void startApp() {
> try {
> Display.init(this);
> Display.getInstance().callSerially(this);
> catch(Throwable ignore) {
> javax.microediton.lcdui.Form f = new
> javax.microediton.lcdui.Form("Start");
> f.append("", t.getMessage());
> javax.microediton.lcdui.Display.getInstance(this).setCurrent(f);
> }
> }
>
> public void run() {
> try {
> Form f = new Form("Hello");
> f.show();
> } catch(Throwable ignore) {
> javax.microediton.lcdui.Form f = new
> javax.microediton.lcdui.Form("Run");
> f.append("", t.getMessage());
> javax.microediton.lcdui.Display.getInstance(this).setCurrent(f);
> }
> }
>
>
> Thanks,
> Shai.
>
> > Thanks Shai, at least now I got the error:
> > NullPointerException ! Does it
> > ake sense to you??
> > Please note that this code
> > protected void startApp() {
> > try {
> > Display.init(this);
> > Form f = new Form("Hello");
> > f.show();
> > catch(Throwable ignore) {}
> >
> >
> > works on my phone: the exception is ignored and the form is shown.
> > So, I wonder where/when the exception is actually raised if
> the form
> > is shown anyway?
> [Message sent by forum member 'vprise' (vprise)]
>
> http://forums.java.net/jive/thread.jspa?messageID=278770
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>

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

vprise
Offline
Joined: 2003-11-07
Points: 0

> Thanks again, and consider me at your disposal for
> another debugging session
> ;)

;-)
Thanks, I'll try to reproduce this exception in the simulator and solve it for the next release.

Shai.

Qunhuan Mei

Hi there,

Good to know that the LWUIT’s code size, after compression, is now 123k!

I have noticed to make LWUIT based J2ME app work, the minimum API support, apart from MIDP 2.0 and CLDC 1.1, is File and PIM API, and Mobile 3D API. I was just wondering if there is still further potential to make the code size smaller, since these 2 APIs are usually not used in the app, or maybe the obfuscator has already figured this out and no code from these two APIs are actually included in the final app so 123k is final.

Any thoughts?

Many thanks,

Qunhuan

vprise
Offline
Joined: 2003-11-07
Points: 0

Hi Qunhuan,
I responded to this by email but for some reason I don't see the response here...

Regardless I ran some checks about size since yesterday and there are good and bad news:

The good news is what I could tell you in advance, we don't use JSR 75 or 184 in the core of LWUIT and so all the code that makes use of these features will disappear after obfuscation if you don't use features such as logging or 3D.

The bad news is that due to some changes I made in the code recently the core got a bit chubbier than it should be and a hello world MIDlet weighs more than it should. I am analyzing this with the obfuscators help and I pinpointed several different areas of optimization.

I will try to implement these changes and reduce the overall size for the next version.

FYI to check what gets packaged into your application under netbeans do the following:
1. Open the project properties.
2. Go to obfuscating option under "Build".
3. Set the obfuscation level slider to High (level 9).
4. In the Additional obfuscator settings box paste:
-printmapping c:\outputfolder\log.txt
5. Clean and build the project.
6. Open c:\outputfolder\log.txt in a text editor and go over the classes that are packaged in.
7. To see how much a class costs after obfuscation use 7zip (or winzip etc...) and look at the compressed size for the mapped file (using the log.txt file to see the class name after obfuscation). Add about 200 bytes per class for zip overhead.

Keep in mind that LWUIT will shrink somewhat in the next drop ;-)

Thanks,
Shai.

> Hi there,
>
> Good to know that the LWUIT’s code size, after
> compression, is now 123k!
>
> I have noticed to make LWUIT based J2ME app work, the
> minimum API support, apart from MIDP 2.0 and CLDC
> 1.1, is File and PIM API, and Mobile 3D API. I was
> just wondering if there is still further potential to
> make the code size smaller, since these 2 APIs are
> usually not used in the app, or maybe the obfuscator
> has already figured this out and no code from these
> two APIs are actually included in the final app so
> 123k is final.
>
> Any thoughts?
>
> Many thanks,
>
> Qunhuan

Matteo Mazzotti

Hi again,
Despite what I hoped, I'm working even today...

I think I've not fully understood how the EDT works, *if* the following is
caused by my lack of knowledge and not a bug:

[some initialization code on StartApp]
Form mainForm = new Form();
mainForm.show();

MyDialog.showLog();
System.out.println("never been here");

MyDialog is just a helper class (it doesn't actually derive from Dialog
btw):

Class MyDialog {
public static void showLog(){
TextArea ta = new TextArea();
LogMessage[] logs = Log.getLogMessages(); -> I'm using
a 3rd party Log class, not yours
StringBuffer sb = null;
for (int i=0; i < logs.length; i++){
System.out.println("this is the last thing I'll say,
then I'll freeze.");
sb.append(log.getLog());
}
System.out.println("never been here");
Dialog.show("Log", ta, Command[] somecommands);
}
}

What happens is that after that mainForm is shown, the call to showLog()
hangs on the for loop forever, so the statement just after it is never
executed (nothing is printed on the System.out).
Notice that if instead of the StringBuffer (which is synchronized) I use a
normal String, no dead lock occurs...

Thanks in advance,
Matteo

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

Shai Almog

Hi Matteo,
I've been spending some time trying to reproduce your race condition
from yesterday on the simulator without success... I'll try it on a
device next week and see whether I can replicate that.

About your problem, this won't work and actually has little to do
with our EDT.

There are really two threads of importance in a LWUIT MIDP
application: the EDT and the MIDP lifecycle thread.

We normally hide the MIDlet thread during runtime but startApp etc...
are part of the MIDP API and they expose that thread.
When you "hold" the lifecycle thread then MIDP won't paint, our EDT
is working correctly and trying to draw/install itself but since
MIDP's worker thread is paused we can't really do anything...

Why the logging code gets stuck is beyond me, but a Dialog.show() in
the startApp() method wouldn't work either ;-)

I suggest doing the following:

public void startApp() {
Display.init(this);
new Thread(this).start();
}

public void run() {
// paste rest of the code from startApp()
}

Thanks,
Shai.

> Hi again,
> Despite what I hoped, I'm working even today...
>
> I think I've not fully understood how the EDT works, *if* the
> following is
> caused by my lack of knowledge and not a bug:
>
> [some initialization code on StartApp]
> Form mainForm = new Form();
> mainForm.show();
>
> MyDialog.showLog();
> System.out.println("never been here");
>
>
> MyDialog is just a helper class (it doesn't actually derive from
> Dialog
> btw):
>
> Class MyDialog {
> public static void showLog(){
> TextArea ta = new TextArea();
> LogMessage[] logs = Log.getLogMessages(); -> I'm using
> a 3rd party Log class, not yours
> StringBuffer sb = null;
> for (int i=0; i < logs.length; i++){
> System.out.println("this is the last thing I'll say,
> then I'll freeze.");
> sb.append(log.getLog());
> }
> System.out.println("never been here");
> Dialog.show("Log", ta, Command[] somecommands);
> }
> }
>
>
> What happens is that after that mainForm is shown, the call to
> showLog()
> hangs on the for loop forever, so the statement just after it is never
> executed (nothing is printed on the System.out).
> Notice that if instead of the StringBuffer (which is synchronized)
> I use a
> normal String, no dead lock occurs...
>
>
> Thanks in advance,
> Matteo
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

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

Matteo Mazzotti

Hi Shai, everybody,
I'm playing with TextField now.

As a picture is worth a thousand words, please see attached files.
I created a container with BoxLayout(BoxLayout.Y_AXIS)), then a TextField
and set its setPreferredW(200) and a Label("username"). Finally I added both
to the container.
The TextField is painted respecting the preferredW ("before" picture), but
right after editing it by filling in my name and moving away, it is shrinked
to the Label size. Also notice what happens to the text (the full text is
still there, but the visibile portion is just the last 3 letters. If you
focus the textField again and click the left arrow key, you can see it all
again).
A last side note: with a textfield as small as the one in the "after"
picture, the editing mode indication (eg "Abc") hides the text inputted by
the user, which is somewhat annoying.

No way to have your textfield behave more like the original lcdui TextField
?

Thanks,
Matteo

[after.jpg]
[before.jpg]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net

Matteo Mazzotti

While waiting for an answer (hopefully), I just want to share with you a
"dirty trick" I found to solve the issue.

I added a ActionListener to the textField. Once the action event is fired, I
set the preferredW again and the shrink effect is gone.

> Hi Shai, everybody,
> I'm playing with TextField now.
>
> As a picture is worth a thousand words, please see attached files.
> I created a container with BoxLayout(BoxLayout.Y_AXIS)), then
> a TextField and set its setPreferredW(200) and a
> Label("username"). Finally I added both to the container.
> The TextField is painted respecting the preferredW ("before"
> picture), but right after editing it by filling in my name
> and moving away, it is shrinked to the Label size. Also
> notice what happens to the text (the full text is still
> there, but the visibile portion is just the last 3 letters.
> If you focus the textField again and click the left arrow
> key, you can see it all again).
> A last side note: with a textfield as small as the one in the "after"
> picture, the editing mode indication (eg "Abc") hides the
> text inputted by the user, which is somewhat annoying.
>
> No way to have your textfield behave more like the original
> lcdui TextField ?
>
>
> Thanks,
> Matteo
>
>
>
>
>

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

Shai Almog

Hi Matteo,
There are several different issues involved with the behavior you are
seeing.

First off there appears to be a bug in the TextField/TextArea size
calculation logic, I fixed at least a part of it.

setPreferredWidth() should either be deprectated or fixed as it
doesn't work as you would expect, if you invoke setPreferredSize() it
would do what you expect...
But in the long term this is a bad solution since it forces you to
decide on pixel based sizes!

A more "proper" solution would be the following:
1. We will fix the bug where you can determine the size of the text
field/area with rows/columns and it won't shrink bellow that size
(this will go into the next drop).
2. Use a different layout manager (this will work today).

The BoxLayout just sizes everything to their preferred size rather
than stretch elements, this can work nicely for some cases but not so
much for others.
If you want a label next to a text field and you want the text field
to grab the width of the row just place both in a BorderLayout
container as such:

Container c = new Container(new BorderLayout());
c.addComponent(BorderLayout.WEST, myLabel);
c.addComponent(BorderLayout.CENTER, myTextField);

Place this container in a Y axis box layout or in a grid to arrange
the layout.

The horizontal scrolling you are seeing with only 3 letters showing
might be a bug in the text field, I'm assuming you can scroll
backwards to show the rest of the characters.
Input mode ("Abc", "123" etc...) shouldn't be drawn when the text
field is too small, if it appears there might be something wrong with
my calculations.

The text field component can't be quite like the native LCDUI text
field since we can't access that functionality of the phone without
leaving the canvas. The LCDUI text field behaves differently on every
single phone so we can't possibly replicate the behavior in a
consistent way.

Thanks,
Shai.

> While waiting for an answer (hopefully), I just want to share with
> you a
> "dirty trick" I found to solve the issue.
>
> I added a ActionListener to the textField. Once the action event is
> fired, I
> set the preferredW again and the shrink effect is gone.
>
>
>> Hi Shai, everybody,
>> I'm playing with TextField now.
>>
>> As a picture is worth a thousand words, please see attached files.
>> I created a container with BoxLayout(BoxLayout.Y_AXIS)), then
>> a TextField and set its setPreferredW(200) and a
>> Label("username"). Finally I added both to the container.
>> The TextField is painted respecting the preferredW ("before"
>> picture), but right after editing it by filling in my name
>> and moving away, it is shrinked to the Label size. Also
>> notice what happens to the text (the full text is still
>> there, but the visibile portion is just the last 3 letters.
>> If you focus the textField again and click the left arrow
>> key, you can see it all again).
>> A last side note: with a textfield as small as the one in the "after"
>> picture, the editing mode indication (eg "Abc") hides the
>> text inputted by the user, which is somewhat annoying.
>>
>> No way to have your textfield behave more like the original
>> lcdui TextField ?
>>
>>
>> Thanks,
>> Matteo
>>
>>
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

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

Matteo Mazzotti

Hi Shai, thanks for your prompt reply as usual.
I think I'll wait for your next code drop as the matryoshka-like containers
combination will excessively clutter my code so I think I'll stick to the
trick I found for the moment (I need to get a prototype of my application
ASAP. Refactoring and optimization will come in a 2nd phase).

> But in the long term this is a bad solution since it forces
> you to decide on pixel based sizes!
I'm working with a web designer for styling the application, and we decided
to target phones with a display of at least 240x320. So some of the UI will
be pixel based (we are mimicking a web fixed layout)

> If you want a label next to a text field and you want the
> text field to grab the width of the row just place both in a
> BorderLayout container as such
In my case, I want the label to be above the textfield. I'll have 2
textfields each with their own label, a checkBox and a "login" button.
Everything must be arranged vertically and centered on the screen. I haven't
tested your solution, but can it be applied to my case as well (I guess
using BorderLayout.NORTH and CENTER will do, but I'm not sure)

Thanks,
Matteo

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

Shai Almog

>> If you want a label next to a text field and you want the
>> text field to grab the width of the row just place both in a
>> BorderLayout container as such
> In my case, I want the label to be above the textfield. I'll have 2
> textfields each with their own label, a checkBox and a "login" button.
> Everything must be arranged vertically and centered on the screen.
> I haven't
> tested your solution, but can it be applied to my case as well (I
> guess
> using BorderLayout.NORTH and CENTER will do, but I'm not sure)

Yes, that will work ;-)

Good luck.

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

Shai Almog

Hi Matteo,
calling setThemeProps is not mandatory although it is recommended for
aesthetic reasons ;-)

Have you tried running on the Motorola emulator, I think the build of
your JAR might not match the code since I noticed a compilation error
(current isn't defined).
If you are using NetBeans verify that you don't have any
"UnsupportedOperationException" throws in the code, NetBeans sticks
them automatically when it implements a method and they work in the
simulator but crash devices.

A simulator runs the environment on the current hardware: e.g. the
WTK is a JVM similar to the one on the phone but its compiled to run
on i86 hardware and invoke Java SE based skin.
An emulator replicates the hardware environment of the chips in the
phone and boots the phone OS on them, it then runs the VM exactly the
same as it runs on the phone (with obvious performance differences).

Simulators tend to be accurate enough for most Java development but
they have some problems e.g. the WTK doesn't store Image objects in
the Java ME heap so loading images costs almost nothing, this is
obviously not the case in a phone environment...

Hope that helps.
Thanks,
Shai.

> Hi,
> I'm testing the Midlet I'm writing making use of LWUIT with several
> WTK emulator (what is the difference between an emulator and a
> simulator btw?) and all is fine.
> Now I just tried this trivial Midlet on my actual Motorola V3x and
> it crashes as soon as I lunch it.
>
> Is calling UIManager.getInstance().setThemeProps mandatory?
>
> Here's the code, am I missing something?
>
> import javax.microedition.midlet.MIDlet;
> import com.sun.lwuit.Form;
> import com.sun.lwuit.Display;
>
> public class TestMIDlet extends MIDlet {
>
> private boolean midletPaused = false;
>
> public TestMIDlet() {
> }
>
> private void initialize() {
> Display.init(this);
>
> Form main = new Form("hello world!");
>
> main.setLayout(new BorderLayout());
> main.setScrollable(false);
> main.show();
> }
>
> public void resumeMIDlet() {
> if (current != null) {
> current.show();
> }
> }
>
> public void exitMIDlet() {
> destroyApp(true);
> notifyDestroyed();
> }
>
> public void startApp() {
> if (midletPaused) {
> resumeMIDlet();
> } else {
> initialize();
> startMIDlet();
> }
> midletPaused = false;
> }
>
>
> public void pauseApp() {
> midletPaused = true;
> }
> }
>
>
> Thanks in advance!
> Matteo
> [Message sent by forum member 'mdmazzotti' (mdmazzotti)]
>
> http://forums.java.net/jive/thread.jspa?messageID=278634
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

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

Matteo Mazzotti

Hi Shai, thanks for the reply.
The compilation error you spotted was just a copy-paste error, there is no
mention to the variable "current" in the code actually.
I tried a super-stripped down version with only the startApp method
implemented:
protected void startApp() {
Display.init(this);
Form f = new Form("test");
f.show();
}

On the Motorola emulator it works just right, on my phone it tries to load
the midlet then it crashes throwing a generic "application error".
Now I just tried adding a try catch to the startApp method. Although I don't
know how to show the error to the phone UI (I guess the Dialog component
needs to have an underlying Form to show itself on, because when I try to
call Dialog.show() as the first command after Display.init I get a
NullPointerException on the emulators), at least now the form is displayed
on my phone. So that means the application was crashing because of the Form
object.
I've seen on the emulator console, for not having set a theme , the message
"using default style - no theme enabled(to enable a theme use - public void
setStyleProps(Hashtable themeProps) method)". Is this an exception? Could
this be what makes the midlet crash?

One more thing:
protected void startApp() {
try{
Display.init(this);
Form f = new Form("test");
f.show();
Dialog.show("Dialog", "", "OK", null);
}catch (Exception ignore){}
}

No Dialog is shown! (again, the emulator is ok)
I'm getting really confused :|

I guess that having the source code would help in sheding some light on this
strange behaviour, any plan on when you will release it?

While we're waiting for it, thanks again for your help!
Matteo

-----Messaggio originale-----
Da: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
Inviato: venerdì 6 giugno 2008 6.27
A: users@lwuit.dev.java.net
Oggetto: Re: helloWorld midlet crashing

Hi Matteo,
calling setThemeProps is not mandatory although it is recommended for
aesthetic reasons ;-)

Have you tried running on the Motorola emulator, I think the build of your
JAR might not match the code since I noticed a compilation error (current
isn't defined).
If you are using NetBeans verify that you don't have any
"UnsupportedOperationException" throws in the code, NetBeans sticks them
automatically when it implements a method and they work in the simulator but
crash devices.

A simulator runs the environment on the current hardware: e.g. the WTK is a
JVM similar to the one on the phone but its compiled to run on i86 hardware
and invoke Java SE based skin.
An emulator replicates the hardware environment of the chips in the phone
and boots the phone OS on them, it then runs the VM exactly the same as it
runs on the phone (with obvious performance differences).

Simulators tend to be accurate enough for most Java development but they
have some problems e.g. the WTK doesn't store Image objects in the Java ME
heap so loading images costs almost nothing, this is obviously not the case
in a phone environment...

Hope that helps.
Thanks,
Shai.

> Hi,
> I'm testing the Midlet I'm writing making use of LWUIT with several
> WTK emulator (what is the difference between an emulator and a
> simulator btw?) and all is fine.
> Now I just tried this trivial Midlet on my actual Motorola V3x and it
> crashes as soon as I lunch it.
>
> Is calling UIManager.getInstance().setThemeProps mandatory?
>
> Here's the code, am I missing something?
>
> import javax.microedition.midlet.MIDlet; import com.sun.lwuit.Form;
> import com.sun.lwuit.Display;
>
> public class TestMIDlet extends MIDlet {
>
> private boolean midletPaused = false;
>
> public TestMIDlet() {
> }
>
> private void initialize() {
> Display.init(this);
>
> Form main = new Form("hello world!");
>
> main.setLayout(new BorderLayout());
> main.setScrollable(false);
> main.show();
> }
>
> public void resumeMIDlet() {
> if (current != null) {
> current.show();
> }
> }
>
> public void exitMIDlet() {
> destroyApp(true);
> notifyDestroyed();
> }
>
> public void startApp() {
> if (midletPaused) {
> resumeMIDlet();
> } else {
> initialize();
> startMIDlet();
> }
> midletPaused = false;
> }
>
>
> public void pauseApp() {
> midletPaused = true;
> }
> }
>
>
> Thanks in advance!
> Matteo
> [Message sent by forum member 'mdmazzotti' (mdmazzotti)]
>
> http://forums.java.net/jive/thread.jspa?messageID=278634
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>

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

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

vprise
Offline
Joined: 2003-11-07
Points: 0

Hi Matteo,
you can use code like this to display an error if LWUIT fails on the device:

try {
Display.init(this);
....
} catch(Throwable t) {
javax.microediton.lcdui.Form f = new javax.microediton.lcdui.Form("Error");
f.append("", t.getMessage());
javax.microediton.lcdui.Display.getInstance(this).setCurrent(f);
}

Debugging on devices is hard with and without the source code especially when we fail on the start and can't even get a log going.

Dialog.show() won't work without a form bellow it so thats why you are getting a null pointer exception if you try placing it before showing a form.

The printout you are seeing is not an exception only a warning and shouldn't cause a problem.

You might be crashing because of the size of the MIDlet, did you remove resource files from the project?

As a last resort try obfuscating the project, some older phones have issues with unobfuscated MIDlets.

Thanks,
Shai.

> Hi Shai, thanks for the reply.
> The compilation error you spotted was just a
> copy-paste error, there is no
> mention to the variable "current" in the code
> actually.
> I tried a super-stripped down version with only the
> startApp method
> implemented:
> protected void startApp() {
> Display.init(this);
>
> Form("test");
> f.show();
> he Motorola emulator it works just right, on my phone
> it tries to load
> the midlet then it crashes throwing a generic
> "application error".
> Now I just tried adding a try catch to the startApp
> method. Although I don't
> know how to show the error to the phone UI (I guess
> the Dialog component
> needs to have an underlying Form to show itself on,
> because when I try to
> call Dialog.show() as the first command after
> Display.init I get a
> NullPointerException on the emulators), at least now
> the form is displayed
> on my phone. So that means the application was
> crashing because of the Form
> object.
> I've seen on the emulator console, for not having set
> a theme , the message
> "using default style - no theme enabled(to enable a
> theme use - public void
> setStyleProps(Hashtable themeProps) method)". Is this
> an exception? Could
> this be what makes the midlet crash?
>
> One more thing:
> protected void startApp() {
> try{
> init(this);
> Form f = new Form("test");
> f.show();
> Dialog.show("Dialog", "", "OK", null);
> }catch (Exception ignore){}
> }
> Dialog is shown! (again, the emulator is ok)
> I'm getting really confused :|
>
> I guess that having the source code would help in
> sheding some light on this
> strange behaviour, any plan on when you will release
> it?
>
> While we're waiting for it, thanks again for your
> help!
> Matteo
>
>
>
> -----Messaggio originale-----
> Da: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
> Inviato: venerdì 6 giugno 2008 6.27
> A: users@lwuit.dev.java.net
> Oggetto: Re: helloWorld midlet crashing
>
> Hi Matteo,
> calling setThemeProps is not mandatory although it is
> recommended for
> aesthetic reasons ;-)
>
> Have you tried running on the Motorola emulator, I
> think the build of your
> JAR might not match the code since I noticed a
> compilation error (current
> isn't defined).
> If you are using NetBeans verify that you don't have
> any
> "UnsupportedOperationException" throws in the code,
> NetBeans sticks them
> automatically when it implements a method and they
> work in the simulator but
> crash devices.
>
> A simulator runs the environment on the current
> hardware: e.g. the WTK is a
> JVM similar to the one on the phone but its compiled
> to run on i86 hardware
> and invoke Java SE based skin.
> An emulator replicates the hardware environment of
> the chips in the phone
> and boots the phone OS on them, it then runs the VM
> exactly the same as it
> runs on the phone (with obvious performance
> differences).
>
> Simulators tend to be accurate enough for most Java
> development but they
> have some problems e.g. the WTK doesn't store Image
> objects in the Java ME
> heap so loading images costs almost nothing, this is
> obviously not the case
> in a phone environment...
>
> Hope that helps.
> Thanks,
> Shai.
>
> > Hi,
> > I'm testing the Midlet I'm writing making use of
> LWUIT with several
> > WTK emulator (what is the difference between an
> emulator and a
> > simulator btw?) and all is fine.
> > Now I just tried this trivial Midlet on my actual
> Motorola V3x and it
> > crashes as soon as I lunch it.
> >
> > Is calling UIManager.getInstance().setThemeProps
> mandatory?
>
> > Here's the code, am I missing something?
> >
> > import javax.microedition.midlet.MIDlet; import
> com.sun.lwuit.Form;
> > import com.sun.lwuit.Display;
> >
> > public class TestMIDlet extends MIDlet {
> >
> > private boolean midletPaused = false;
> >
> > public TestMIDlet() {
> > }
> >
> > private void initialize() {
> > Display.init(this);
> >
> > Form main = new Form("hello world!");
> >
> > main.setLayout(new BorderLayout());
> > main.setScrollable(false);
> > main.show();
> > }
> >
> > public void resumeMIDlet() {
> > if (current != null) {
> > current.show();
> > }
> > }
> >
> > public void exitMIDlet() {
> > destroyApp(true);
> > notifyDestroyed();
> > }
> >
> > public void startApp() {
> > if (midletPaused) {
> > resumeMIDlet();
> > } else {
> > initialize();
> > startMIDlet();
> > }
> > midletPaused = false;
> > }
> >
> >
> > public void pauseApp() {
> > midletPaused = true;
> > }
> > }
> >
> >
> > Thanks in advance!
> > Matteo
> > [Message sent by forum member 'mdmazzotti'
> (mdmazzotti)]
> >
> >
> http://forums.java.net/jive/thread.jspa?messageID=2786
> 34
> >
> >
> ------------------------------------------------------
> ---------------
> > To unsubscribe, e-mail:
> users-unsubscribe@lwuit.dev.java.net
> > For additional commands, e-mail:
> users-help@lwuit.dev.java.net
> >
>
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail:
> users-help@lwuit.dev.java.net
>
>
>
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail:
> users-help@lwuit.dev.java.net

Matteo Mazzotti

Thanks Shai, at least now I got the error: NullPointerException ! Does it
make sense to you??
Please note that this code
protected void startApp() {
try {
Display.init(this);
Form f = new Form("Hello");
f.show();
} catch(Throwable ignore) {}
}

works on my phone: the exception is ignored and the form is shown.
So, I wonder where/when the exception is actually raised if the form is
shown anyway?

I also forgot to tell you that you LWUITDemo Midlet works properly on my
phone, and there is no restriction on the midlet size (I tried other
unobfuscated and quite big midlets with no hassle). Moreover, I want to
specify that the code above is the only code that my test Midlet contains,
there's nothing else (then no resources, images or other stuff).

Thanks
Matteo

> Hi Matteo,
> you can use code like this to display an error if LWUIT fails
> on the device:
>
> try {
> Display.init(this);
> ....
> } catch(Throwable t) {
> javax.microediton.lcdui.Form f = new
> javax.microediton.lcdui.Form("Error");
> f.append("", t.getMessage());
> javax.microediton.lcdui.Display.getInstance(this).setCurrent(f);
> }
>
> Debugging on devices is hard with and without the source code
> especially when we fail on the start and can't even get a log going.
>
> Dialog.show() won't work without a form bellow it so thats
> why you are getting a null pointer exception if you try
> placing it before showing a form.
>
> The printout you are seeing is not an exception only a
> warning and shouldn't cause a problem.
>
> You might be crashing because of the size of the MIDlet, did
> you remove resource files from the project?
>
> As a last resort try obfuscating the project, some older
> phones have issues with unobfuscated MIDlets.
>
> Thanks,
> Shai.
>
> > Hi Shai, thanks for the reply.
> > The compilation error you spotted was just a copy-paste
> error, there
> > is no mention to the variable "current" in the code actually.
> > I tried a super-stripped down version with only the startApp method
> > implemented:
> > protected void startApp() {
> > Display.init(this);
> >
> > Form("test");
> > f.show();
> > he Motorola emulator it works just right, on my phone it
> tries to load
> > the midlet then it crashes throwing a generic "application error".
> > Now I just tried adding a try catch to the startApp method.
> Although I
> > don't know how to show the error to the phone UI (I guess
> the Dialog
> > component needs to have an underlying Form to show itself
> on, because
> > when I try to call Dialog.show() as the first command after
> > Display.init I get a NullPointerException on the
> emulators), at least
> > now the form is displayed on my phone. So that means the
> application
> > was crashing because of the Form object.
> > I've seen on the emulator console, for not having set a theme , the
> > message "using default style - no theme enabled(to enable a
> theme use
> > - public void setStyleProps(Hashtable themeProps) method)".
> Is this an
> > exception? Could this be what makes the midlet crash?
> >
> > One more thing:
> > protected void startApp() {
> > try{
> > init(this);
> > Form f = new Form("test");
> > f.show();
> > Dialog.show("Dialog", "", "OK", null);
> > }catch (Exception ignore){}
> > }
> > Dialog is shown! (again, the emulator is ok) I'm getting really
> > confused :|
> >
> > I guess that having the source code would help in sheding
> some light
> > on this strange behaviour, any plan on when you will release it?
> >
> > While we're waiting for it, thanks again for your help!
> > Matteo
> >
> >
> >
> > -----Messaggio originale-----
> > Da: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
> > Inviato: venerdì 6 giugno 2008 6.27
> > A: users@lwuit.dev.java.net
> > Oggetto: Re: helloWorld midlet crashing
> >
> > Hi Matteo,
> > calling setThemeProps is not mandatory although it is
> recommended for
> > aesthetic reasons ;-)
> >
> > Have you tried running on the Motorola emulator, I think
> the build of
> > your JAR might not match the code since I noticed a
> compilation error
> > (current isn't defined).
> > If you are using NetBeans verify that you don't have any
> > "UnsupportedOperationException" throws in the code, NetBeans sticks
> > them automatically when it implements a method and they work in the
> > simulator but crash devices.
> >
> > A simulator runs the environment on the current
> > hardware: e.g. the WTK is a
> > JVM similar to the one on the phone but its compiled to run on i86
> > hardware and invoke Java SE based skin.
> > An emulator replicates the hardware environment of the chips in the
> > phone and boots the phone OS on them, it then runs the VM
> exactly the
> > same as it runs on the phone (with obvious performance differences).
> >
> > Simulators tend to be accurate enough for most Java development but
> > they have some problems e.g. the WTK doesn't store Image objects in
> > the Java ME heap so loading images costs almost nothing, this is
> > obviously not the case in a phone environment...
> >
> > Hope that helps.
> > Thanks,
> > Shai.
> >
> > > Hi,
> > > I'm testing the Midlet I'm writing making use of
> > LWUIT with several
> > > WTK emulator (what is the difference between an
> > emulator and a
> > > simulator btw?) and all is fine.
> > > Now I just tried this trivial Midlet on my actual
> > Motorola V3x and it
> > > crashes as soon as I lunch it.
> > >
> > > Is calling UIManager.getInstance().setThemeProps
> > mandatory?
> >
> > > Here's the code, am I missing something?
> > >
> > > import javax.microedition.midlet.MIDlet; import
> > com.sun.lwuit.Form;
> > > import com.sun.lwuit.Display;
> > >
> > > public class TestMIDlet extends MIDlet {
> > >
> > > private boolean midletPaused = false;
> > >
> > > public TestMIDlet() {
> > > }
> > >
> > > private void initialize() {
> > > Display.init(this);
> > >
> > > Form main = new Form("hello world!");
> > >
> > > main.setLayout(new BorderLayout());
> > > main.setScrollable(false);
> > > main.show();
> > > }
> > >
> > > public void resumeMIDlet() {
> > > if (current != null) {
> > > current.show();
> > > }
> > > }
> > >
> > > public void exitMIDlet() {
> > > destroyApp(true);
> > > notifyDestroyed();
> > > }
> > >
> > > public void startApp() {
> > > if (midletPaused) {
> > > resumeMIDlet();
> > > } else {
> > > initialize();
> > > startMIDlet();
> > > }
> > > midletPaused = false;
> > > }
> > >
> > >
> > > public void pauseApp() {
> > > midletPaused = true;
> > > }
> > > }
> > >
> > >
> > > Thanks in advance!
> > > Matteo
> > > [Message sent by forum member 'mdmazzotti'
> > (mdmazzotti)]
> > >
> > >
> > http://forums.java.net/jive/thread.jspa?messageID=2786
> > 34
> > >
> > >
> > ------------------------------------------------------
> > ---------------
> > > To unsubscribe, e-mail:
> > users-unsubscribe@lwuit.dev.java.net
> > > For additional commands, e-mail:
> > users-help@lwuit.dev.java.net
> > >
> >
> >
> > ------------------------------------------------------
> > ---------------
> > To unsubscribe, e-mail:
> > users-unsubscribe@lwuit.dev.java.net
> > For additional commands, e-mail:
> > users-help@lwuit.dev.java.net
> >
> >
> >
> >
> > ------------------------------------------------------
> > ---------------
> > To unsubscribe, e-mail:
> > users-unsubscribe@lwuit.dev.java.net
> > For additional commands, e-mail:
> > users-help@lwuit.dev.java.net
> [Message sent by forum member 'vprise' (vprise)]
>
> http://forums.java.net/jive/thread.jspa?messageID=278751
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
> For additional commands, e-mail: users-help@lwuit.dev.java.net
>
>

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

vprise
Offline
Joined: 2003-11-07
Points: 0

Hi Matteo,
you officially managed to stump me :-)

I'm baffled by this issue...

The fact that the form appears indicates that Display.init(), worked correctly and that form.show() worked correctly (at least partially).
The startApp() method occurs on the MIDP thread where the code showing the form occurs on the LWUIT thread, this shouldn't pose a problem in general and this works on devices but I'm thinking maybe the latest version introduced a form of race condition...

Try the following, implement runnable in your MIDlet and use the following code. This will execute the show() in the LWUIT EDT thus removing the potential race condition. Something like this makes sense with some of the performance changes I made in the latest drop:
protected void startApp() {
try {
Display.init(this);
Display.getInstance().callSerially(this);
catch(Throwable ignore) {
javax.microediton.lcdui.Form f = new javax.microediton.lcdui.Form("Start");
f.append("", t.getMessage());
javax.microediton.lcdui.Display.getInstance(this).setCurrent(f);
}
}

public void run() {
try {
Form f = new Form("Hello");
f.show();
} catch(Throwable ignore) {
javax.microediton.lcdui.Form f = new javax.microediton.lcdui.Form("Run");
f.append("", t.getMessage());
javax.microediton.lcdui.Display.getInstance(this).setCurrent(f);
}
}

Thanks,
Shai.

> Thanks Shai, at least now I got the error:
> NullPointerException ! Does it
> ake sense to you??
> Please note that this code
> protected void startApp() {
> try {
> Display.init(this);
> Form f = new Form("Hello");
> f.show();
> catch(Throwable ignore) {}
>
>
> works on my phone: the exception is ignored and the
> form is shown.
> So, I wonder where/when the exception is actually
> raised if the form is
> shown anyway?

Qunhuan Mei

To identify which statement/part relates to this "null", you can set up a (global) int variable, starting from 0, and increase it after passing every statement, then print it in your catch output block -- then you may be able to figure out what specific statement/part went null in the code.

-----Original Message-----
From: lwuit-users@mobileandembedded.org [mailto:lwuit-users@mobileandembedded.org]
Sent: 06 June 2008 13:56
To: users@lwuit.dev.java.net
Subject: Re: R: R: helloWorld midlet crashing

Hi Matteo,
you officially managed to stump me :-)

I'm baffled by this issue...

The fact that the form appears indicates that Display.init(), worked correctly and that form.show() worked correctly (at least partially).
The startApp() method occurs on the MIDP thread where the code showing the form occurs on the LWUIT thread, this shouldn't pose a problem in general and this works on devices but I'm thinking maybe the latest version introduced a form of race condition...

Try the following, implement runnable in your MIDlet and use the following code. This will execute the show() in the LWUIT EDT thus removing the potential race condition. Something like this makes sense with some of the performance changes I made in the latest drop:
protected void startApp() {
try {
Display.init(this);
Display.getInstance().callSerially(this);
catch(Throwable ignore) {
javax.microediton.lcdui.Form f = new javax.microediton.lcdui.Form("Start");
f.append("", t.getMessage());
javax.microediton.lcdui.Display.getInstance(this).setCurrent(f);
}
}

public void run() {
try {
Form f = new Form("Hello");
f.show();
} catch(Throwable ignore) {
javax.microediton.lcdui.Form f = new javax.microediton.lcdui.Form("Run");
f.append("", t.getMessage());
javax.microediton.lcdui.Display.getInstance(this).setCurrent(f);
}
}

Thanks,
Shai.

> Thanks Shai, at least now I got the error:
> NullPointerException ! Does it
> ake sense to you??
> Please note that this code
> protected void startApp() {
> try {
> Display.init(this);
> Form f = new Form("Hello");
> f.show();
> catch(Throwable ignore) {}
>
>
> works on my phone: the exception is ignored and the
> form is shown.
> So, I wonder where/when the exception is actually
> raised if the form is
> shown anyway?
[Message sent by forum member 'vprise' (vprise)]

http://forums.java.net/jive/thread.jspa?messageID=278770

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