Qestion about unhandledError

if i set up an unhandledError and a lowmemory listener and run into a lowmemory issue do both listeners fire or just one? if one which one

The “unhandledError” and “memoryWarning” events are completely unrelated.  So, the answer is you’ll continue to get both.

Low memory warnings happen when your app is using almost all RAM on the device.  This typically happens when you load too many large images and audio clips.  It works well on iOS, but is almost completely useless on Android because Android delivers this warning too late.  I find that Android delivers the low memory warning after you run out of OpenGL texture memory.

The unhandled error events typically happen when you have a Lua runtime error in your script or if your script triggers a Java exception (typically a missing Android permission).  These are great for debugging purposes since it’ll give you a stack trace.  Just be warned that if an unhandled error occurs, your app is most likely in a screwed-over unknown state.  Most native developers would just record the unhandled error’s message and stack trace and then let the app crash… so when the end-user restarts the app, it’ll be in a working state again.

Case in point, on Android, if an unhandled exception occurs in Java on the main UI thread, then it is almost always completely unrecoverable.  This is because Google’s side of the code is in a bad state.  So, it is up to us (Corona Labs) to add error handling to ensure unhandled exception do not happen… except in certain circumstances where we think they should be delivered to the Corona developer, such as permissions exceptions.  What we do in this case is turn Java exceptions into Lua exceptions and give the Corona developer the chance to handle it.  An example of this is calling network.request() in Lua without setting the Android INTERNET permission.  We turn the Internet permission exception into a Lua error which you can catch in a Lua pcall().  For plugin developers this is handy because they may want to make network communications optional and handle it gracefully.

In any case, I probably went beyond the answer that you were looking for, but I hope the above helps you out.

Thx Joshua
That’s all I’m doing is recording it
And it’s always better to have more info

The “unhandledError” and “memoryWarning” events are completely unrelated.  So, the answer is you’ll continue to get both.

Low memory warnings happen when your app is using almost all RAM on the device.  This typically happens when you load too many large images and audio clips.  It works well on iOS, but is almost completely useless on Android because Android delivers this warning too late.  I find that Android delivers the low memory warning after you run out of OpenGL texture memory.

The unhandled error events typically happen when you have a Lua runtime error in your script or if your script triggers a Java exception (typically a missing Android permission).  These are great for debugging purposes since it’ll give you a stack trace.  Just be warned that if an unhandled error occurs, your app is most likely in a screwed-over unknown state.  Most native developers would just record the unhandled error’s message and stack trace and then let the app crash… so when the end-user restarts the app, it’ll be in a working state again.

Case in point, on Android, if an unhandled exception occurs in Java on the main UI thread, then it is almost always completely unrecoverable.  This is because Google’s side of the code is in a bad state.  So, it is up to us (Corona Labs) to add error handling to ensure unhandled exception do not happen… except in certain circumstances where we think they should be delivered to the Corona developer, such as permissions exceptions.  What we do in this case is turn Java exceptions into Lua exceptions and give the Corona developer the chance to handle it.  An example of this is calling network.request() in Lua without setting the Android INTERNET permission.  We turn the Internet permission exception into a Lua error which you can catch in a Lua pcall().  For plugin developers this is handy because they may want to make network communications optional and handle it gracefully.

In any case, I probably went beyond the answer that you were looking for, but I hope the above helps you out.

Thx Joshua
That’s all I’m doing is recording it
And it’s always better to have more info