Skip to main content

Application terminates on return from device's native text input screen

10 replies [Last post]
borisg
Offline
Joined: 2010-05-27

I'm using LWUIT with a J2ME application on Samsung F480 device (touch device).
When I press on textfields in my application, the device's native text input screen is opened for text entry (T9 mode). This screen has two commands: OK and Cancel. When I press any of the commands, regardless of whether any text was entered or not, the application is terminated.
The odd thing about it is that I've noticed that the selected command is always 'Cancel', even when I press on the OK softkey.
The same code runs with no problems on other touch devices (other Samsung models and other companies as well).
This has to be some LWUIT related issue because when I invoke the same native text field from a J2ME application that does not use LWUIT, the application works fine and does not terminate.

Has anyone encountered this problem before?
Any leads on how to resolve this issue will be highly appreciated.

Thank you.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vprise
Offline
Joined: 2003-11-07

That's incorrect.

Text area native input works fine for me on F480. Try running the UIDemo's dialog demo where we have a text area on the device.

Mixa

Well, I may be wrong, and actually high chances are that I am wrong.
This is probably because I do not understand some related parts of
LWUIT code, so I'm asking fro comments.

Let's have a look at GameCanvasImplementation.java:

[code]
public void run() {
while (!done) {
synchronized (getDisplayLock()) {
try {
getDisplayLock().wait(50);
} catch (InterruptedException ex) {
ex.printStackTrace();
}
}
}
}

public void setDone(boolean done) {
this.done = done;
synchronized (getDisplayLock()) {
getDisplayLock().notify();
}
}
[/code]

What is purpose of run() method? - I was not able to find appropriate
Thread.start() call, and the run() looks strange in general. Let's
assume setDone() and run() are supposed to work in pair via
wait/notify (just I'm not sure here, please confirm) - run() checks
for 'done' flag every 50 ms, outside the sync block - what will happen
if setDone() calls notify exactly before run() sits back on wait()? I
expect we may get an IllegalMonitorStateException somewhere in
commandAction() when user completes input in native edit box, and VM
may stop the app unexpectedly.

Mike

On Sun, May 30, 2010 at 10:12 AM, wrote:
> That's incorrect.
>
> Text area native input works fine for me on F480. Try running the UIDemo's dialog demo where we have a text area on the device.
> [Message sent by forum member 'vprise']
>
> http://forums.java.net/jive/thread.jspa?messageID=471989
>
> ---------------------------------------------------------------------
> 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

Mixa

And a minor comment about run() implementation - it doesn't affects
current use case, since setDisplayLock() is called once on
Display.init().

Still it would be better (generally) to avoid possible collisions
between setDisplayLock and getDisplayLock:
[code]
synchronized (getDisplayLock()) {
[/code]
actually calls getDisplayLock() outside sync body (monitor), so it
would be better to place lock object into a local variable, and
outside the loop, since code can't be optimized automatically.

Mike

On Wed, Jun 2, 2010 at 2:09 PM, Mixa wrote:
> Well, I may be wrong, and actually high chances are that I am wrong.
> This is probably because I do not understand some related parts of
> LWUIT code, so I'm asking fro comments.
>
> Let's have a look at GameCanvasImplementation.java:
>
> [code]
>        public void run() {
>            while (!done) {
>                synchronized (getDisplayLock()) {
>                    try {
>                        getDisplayLock().wait(50);
>                    } catch (InterruptedException ex) {
>                        ex.printStackTrace();
>                    }
>                }
>            }
>        }
>
>        public void setDone(boolean done) {
>            this.done = done;
>            synchronized (getDisplayLock()) {
>                getDisplayLock().notify();
>            }
>        }
> [/code]
>
> What is purpose of run() method? - I was not able to find appropriate
> Thread.start() call, and the run() looks strange in general. Let's
> assume setDone() and run() are supposed to work in pair via
> wait/notify (just I'm not sure here, please confirm) - run() checks
> for 'done' flag every 50 ms, outside the sync block - what will happen
> if setDone() calls notify exactly before run() sits back on wait()? I
> expect we may get an IllegalMonitorStateException somewhere in
> commandAction() when user completes input in native edit box, and VM
> may stop the app unexpectedly.
>
> Mike
>
> On Sun, May 30, 2010 at 10:12 AM,   wrote:
>> That's incorrect.
>>
>> Text area native input works fine for me on F480. Try running the UIDemo's dialog demo where we have a text area on the device.
>> [Message sent by forum member 'vprise']
>>
>> http://forums.java.net/jive/thread.jspa?messageID=471989
>>
>> ---------------------------------------------------------------------
>> 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

See the invokeAndBlock at the end of editString() which is a blocking method. Its in the Canvas class to save space.
If notify is called first then a 50ms sleep might occur and the done flag will be checked (partly why we don't wait forever).
getDisplayLock() is shared with the Display which is why we use a method, common approach from AWT.

Mixa

Hi vprise, thanks for explanations.

It is still not clear for me what prevents calling notify() _exactly_
between lines
[code]
while (!done) {
synchronized (getDisplayLock()) {
[/code]
before entering monitor section, causing IllegalMonitorStateException?
It should happen quite seldom though, but the point is that design
allows it, that's not OK.

the 'stop' flag checking and setting must be inside the sync blocks,
it is a common pattern, AFAIK. 'done' can't be used as a flag that we
are sitting on wait(), and actually we are _not_ on wait() every 50ms
outside monitor section, so notify() calls are not throwing exceptions
just 'by chance'.

I'm a bit pedantic here, since it is a key of the monitor concept.
Please tell me that I'm correct, otherwise my brain needs replacing :)

Mike

On Thu, Jun 3, 2010 at 5:46 PM, wrote:
> See the invokeAndBlock at the end of editString() which is a blocking method. Its in the Canvas class to save space.
> If notify is called first then a 50ms sleep might occur and the done flag will be checked (partly why we don't wait forever).
> getDisplayLock() is shared with the Display which is why we use a method, common approach from AWT.
> [Message sent by forum member 'vprise']
>
> http://forums.java.net/jive/thread.jspa?messageID=472559
>
> ---------------------------------------------------------------------
> 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

Monitor state exception is called when notifying/waiting on an object for which the current thread doesn't own the monitor:
e.g.
[code]
// will throw exception
myObj.wait();

// Won't throw exception
synchronized(myObj) {
myObj.wait();
}
[/code]

As far as I can see there is no such place in LWUIT.

Mixa

Hi vprise, sorry for a late followup - I missed your reply here.

Indeed, you're right and I was wrong, my java knowledge needed
correction in that point, thanks for it.

Regards,
Mike

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

Mixa

I don't think it's the matter, see
"This has to be some LWUIT related issue because when I invoke the
same native text field from a J2ME application that does not use
LWUIT, the application works fine and does not terminate."

I remember LWUIT has some specific synchronized code when showing
native edit box (a lock), it may matter.

Before that, I would check what TextBox options are used - say if it
has NUMERIC constraints or so - nobody knows if samsung people tested
TextBox with something except TEXT_ANY ;). Check size settings as well
- I remember I saw in LWUIT some code about issues with maximum size
of TextBox.

For testing, I would modify LWUIT code to show native TextBox with
default settings only, to see if constraints affects that. If they
don't then I would go with investigations around LWUIT TextBox lock (I
don't remember if I managed to understand that code, nevertheless I
would try to comment it out to see if it makes any difference ))

Mike

On Fri, May 28, 2010 at 1:16 AM, wrote:
> Samsung devices by default are not multi-threaded OS enabled.
>
> When you close your app to open the native editing, the app is terminated.
> [Message sent by forum member 'dmitry_belov']
>
> http://forums.java.net/jive/thread.jspa?messageID=471762
>
> ---------------------------------------------------------------------
> 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

dmitry_belov
Offline
Joined: 2009-03-16

Samsung devices by default are not multi-threaded OS enabled.

When you close your app to open the native editing, the app is terminated. Since your other apps do not terminate, this is kinda weird.

I haven't had an issue with Samsung yet.

spiralni
Offline
Joined: 2009-12-03

So? No LWUIT for samsung or is there any walkaround?