You can use native code to extract all the information the native system
has. Unlike a JIT situation Codename One is consistent in runtime.
--
You received this message because you are subscribed to the Google Groups
"CodenameOne Discussions" group.
To unsubscribe from this group and stop recei
I agree that running under a debugger on the device is not a complete
solution. In particular,
I wish for a permanent monitor on the deployed app to catch rare cases.
The problem in codename1 is that even if you identify a likely problem at
runtime,
there is no way to extract information about
We use logging extensively for cases like this. We'd like to introduce
on-device-debugging in the future but due to the nature of problems like
this it might not reproduce in a debugger so logging is pretty much the
only tool.
This search finds threadalizers
https://www.google.com/search?q=jav
On Thursday, August 18, 2016 at 11:02:31 PM UTC-7, Shai Almog wrote:
>
> That's legacy code that doesn't work. Killing threads is problematic
> across devices, if a thread is stuck you have a problem.
>
Of course, this is about diagnosing the problem. If I have a rare lockup
seen only on the l
That's legacy code that doesn't work. Killing threads is problematic across
devices, if a thread is stuck you have a problem.
Notice that JavaSE has threadalizers that should work with Codename One. I
haven't used one in years but it should work in theory.
--
You received this message because
