Android Question Question about "isn't responding wait/cancel" popup

[almontgreen]

In another thread there was a brief comment about using DoEvents to keep this system message box from popping up.

I've discovered that if someone repeatedly presses a key quickly (from a "real" keyboard) which generates an event with a sub that the message will pop up. If you put a DoEvents in that sub, then the application exits as many DoEvents happen very quickly and I'm thinking that causes a problem since it exits.

There seems to be a timing issue with regards to how often you send a DoEvents command. And also, how often a keypress activity happens.

Now, why would somebody repeatedly press a key? Good question. They would if they are frustrated waiting for something to happen or a kid playing around with a "kiosk" type of application.

So, I am wondering if a Java library could be created to keep that message from popping up? Is it possible?

Thanks. B4A is quite AMAZING! Very fast development time to create something! However, reading everything here is a bit like drinking from a fire hose ;^)

 

[Eric H]

You may find this helpful: http://developer.android.com/training/articles/perf-anr.html

specifically this part:

How to Avoid ANRs
Android applications normally run entirely on a single thread by default the "UI thread" or "main thread"). This means anything your application is doing in the UI thread that takes a long time to complete can trigger the ANR dialog because your application is not giving itself a chance to handle the input event or intent broadcasts.

Therefore, any method that runs in the UI thread should do as little work as possible on that thread. In particular, activities should do as little as possible to set up in key life-cycle methods such as onCreate() andonResume(). Potentially long running operations such as network or database operations, or computationally expensive calculations such as resizing bitmaps should be done in a worker thread (or in the case of databases operations, via an asynchronous request).

The bottom line answer to your question isn't finding a way to prevent Android from being able to give the user a way out of a trapped UI thread, but for you as the programmer to prevent the UI thread from being too busy to process user input by performing your heavy lifting in a separate thread.

This library will likely be of interest to you: http://www.b4x.com/android/forum/threads/threading-library.6775/

Eric H

 

[Informatix]

There seems to be a timing issue with regards to how often you send a DoEvents command.

I've never seen that with DoEvents.
Do this in an empty project and you'll see that nothing happens (no memory loss, no exit):

For i = 0 To 10000
     DoEvents
Next

 

[almontgreen]

I've never seen that with DoEvents.
Do this in an empty project and you'll see that nothing happens (no memory loss, no exit):

For i = 0 To 10000
     DoEvents
Next

That's different from putting a DoEvents within an Activity_Keypress sub that gets fired very quickly with repeated key presses somehow. At least, that's what it seems like. I will investigate further, but it seems like there is something about keypress and mouse events that is different.

 

[Informatix]

That's different from putting a DoEvents within an Activity_Keypress sub that gets fired very quickly with repeated key presses somehow. At least, that's what it seems like. I will investigate further, but it seems like there is something about keypress and mouse events that is different.

What's your Android version?

 

[almontgreen]

What's your Android version?

4.2.2

 

[Erel]

Can you post the code in this sub?

 

[almontgreen]

Can you post the code in this sub?

Sorry for delay... Let me put together something that shows the problem clearly and I'll post it here.