1

I've been working on an android app and test it on the emulator. Parts of this app require some processing time, such as login, could take up to 10 seconds. If the app is processing the login, and I clicked anywhere on the emulator screen, it will cause the app to crash -> a force close/wait window will pop up and even I choose to wait, this login process will never complete.

I wonder did anybody else encounter this situation? What could I do to avoid user clicking during processing and crash the program? Or on a real phone it is not a problem?

Thanks!

EDIT: This is indeed a UI thread problem and I'm using Mono for Android to write this app, I sort my issues out using methods introduced Here!

EDIT: this is the LOGCAT messages

1-11 00:38:49.165 W/WindowManager(   59): Key dispatching timed out sending to BadumnaAndroidApi1.BadumnaAndroidApi1/badumnaandroidapi1.Activity1
01-11 00:38:49.165 W/WindowManager(   59): Previous dispatch state: {{KeyEvent{action=1 code=66 repeat=0 meta=0 scancode=28 mFlags=8} to Window{44ed87d0 BadumnaAndroidApi1.BadumnaAndroidApi1/badumnaandroidapi1.Activity1 paused=false} @ 1326241690617 lw=Window{44ed87d0 BadumnaAndroidApi1.BadumnaAndroidApi1/badumnaandroidapi1.Activity1 paused=false} lb=android.os.BinderProxy@4508a900 fin=false gfw=true ed=true tts=0 wf=false fp=false mcf=Window{44ed87d0 BadumnaAndroidApi1.BadumnaAndroidApi1/badumnaandroidapi1.Activity1 paused=false}}}
01-11 00:38:49.175 W/WindowManager(   59): Current dispatch state: {{null to Window{44ed87d0 BadumnaAndroidApi1.BadumnaAndroidApi1/badumnaandroidapi1.Activity1 paused=false} @ 1326242329174 lw=Window{44ed87d0 BadumnaAndroidApi1.BadumnaAndroidApi1/badumnaandroidapi1.Activity1 paused=false} lb=android.os.BinderProxy@4508a900 fin=false gfw=true ed=true tts=0 wf=false fp=false mcf=Window{44ed87d0 BadumnaAndroidApi1.BadumnaAndroidApi1/badumnaandroidapi1.Activity1 paused=false}}}
01-11 00:38:49.276 I/Process (   59): Sending signal. PID: 316 SIG: 3
01-11 00:38:49.276 I/dalvikvm(  316): threadid=3: reacting to signal 3
01-11 00:38:49.485 I/dalvikvm(  316): Wrote stack traces to '/data/anr/traces.txt'
01-11 00:38:49.485 I/Process (   59): Sending signal. PID: 59 SIG: 3
01-11 00:38:49.485 I/dalvikvm(   59): threadid=3: reacting to signal 3
01-11 00:38:49.595 I/dalvikvm(   59): Wrote stack traces to '/data/anr/traces.txt'
01-11 00:38:49.616 I/Process (   59): Sending signal. PID: 114 SIG: 3
01-11 00:38:49.616 I/dalvikvm(  114): threadid=3: reacting to signal 3
01-11 00:38:49.625 I/dalvikvm(  114): Wrote stack traces to '/data/anr/traces.txt'
01-11 00:38:49.636 I/Process (   59): Sending signal. PID: 107 SIG: 3
01-11 00:38:49.645 I/dalvikvm(  107): threadid=3: reacting to signal 3
01-11 00:38:49.655 I/dalvikvm(  107): Wrote stack traces to '/data/anr/traces.txt'
01-11 00:38:49.673 I/Process (   59): Sending signal. PID: 254 SIG: 3
01-11 00:38:49.865 I/dalvikvm(  254): threadid=3: reacting to signal 3
01-11 00:38:49.875 I/Process (   59): Sending signal. PID: 246 SIG: 3
01-11 00:38:49.906 I/dalvikvm(  246): threadid=3: reacting to signal 3
01-11 00:38:50.085 I/Process (   59): Sending signal. PID: 177 SIG: 3
01-11 00:38:50.115 I/dalvikvm(  177): threadid=3: reacting to signal 3
01-11 00:38:50.285 I/Process (   59): Sending signal. PID: 221 SIG: 3
01-11 00:38:50.345 I/dalvikvm(  221): threadid=3: reacting to signal 3
01-11 00:38:50.495 I/Process (   59): Sending signal. PID: 169 SIG: 3
01-11 00:38:50.575 I/dalvikvm(  169): threadid=3: reacting to signal 3
01-11 00:38:50.695 I/Process (   59): Sending signal. PID: 185 SIG: 3
01-11 00:38:50.735 I/dalvikvm(  185): threadid=3: reacting to signal 3
01-11 00:38:50.905 I/Process (   59): Sending signal. PID: 111 SIG: 3
01-11 00:38:50.905 I/dalvikvm(  111): threadid=3: reacting to signal 3
01-11 00:38:51.065 I/dalvikvm(  111): Wrote stack traces to '/data/anr/traces.txt'
01-11 00:38:51.065 I/Process (   59): Sending signal. PID: 205 SIG: 3
01-11 00:38:51.185 I/dalvikvm(  205): threadid=3: reacting to signal 3
01-11 00:38:51.275 I/Process (   59): Sending signal. PID: 194 SIG: 3
01-11 00:38:51.405 I/dalvikvm(  194): threadid=3: reacting to signal 3
01-11 00:38:51.485 I/Process (   59): Sending signal. PID: 155 SIG: 3
01-11 00:38:51.605 I/dalvikvm(  155): threadid=3: reacting to signal 3
01-11 00:38:51.685 I/Process (   59): Sending signal. PID: 149 SIG: 3
01-11 00:38:51.875 I/dalvikvm(  149): threadid=3: reacting to signal 3
01-11 00:38:51.885 I/Process (   59): Sending signal. PID: 115 SIG: 3
01-11 00:38:51.916 I/dalvikvm(  115): threadid=3: reacting to signal 3
Improve this question
4
  • Is there any information on LogCat on the possible reason for such a crash? Commented Jan 11, 2012 at 0:02
  • 2
    Are you sure it's a crash? Maybe you're just doing proceesing in the UI thread and your app hangs (thus, the window with the option to force close appears). Commented Jan 11, 2012 at 0:23
  • thanks for that @user1234567, I'm rather new to android, so you mean I cannot do the processing in the UI thread otherwise this situation will occur? Commented Jan 11, 2012 at 0:38
  • @harism The LogCat information is updated.. It does look like a thread problem as user1234567 described.. I'll change the processing thread and see how it go Commented Jan 11, 2012 at 0:44

1 Answer 1

Reset to default
4

Ok the chances are you might be causing the UI thread to hang due to this heavy processing -but I could be way off without seeing any code -hint-. What you might is put the heavy stuff into a background thread seperate to the GUI thread, which you are currently running in.

Luckily Android has the AsyncTask class to help you here. Lets say (as there is not enough detail in the question) you are logging in to your app by making a web request to a server. When the user presses login you want to show some sort of processing message while doing all the legwork in your background thread.

Take a look at this article in particular the AsyncTask example http://www.vogella.de/articles/AndroidPerformance/article.html

You can see that doInBackground() is where all the heavy lifting is done and that postExecute() runs in the UI thread once again, which is where you will want to update the UI based on the result of what just happened. For example the user logged in sucessfully or an error occured while logging in.

I could go on for quite some time however this is well documented. Another good post by Google themselves can be found here http://android-developers.blogspot.com/2009/05/painless-threading.html

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Thank you and I think you are making a very good point, because I am doing quite some heavy processing and I'm converting a windows .NET application to android, there used to be a BackgroundWorker used to process this in the background so I think this could be the problem. Thank you for all the information! I'll try it out!
Thank you, this is a great answer and it is exactly where my problem lies. However I'm using Mono for Android to write the app (which you couldn't have known since I never mentioned), using AsyncTask in my case can be a bit complicated. I've sorted out my issue using methods introduced in Click Here, just for those who also use mono and had same problem. Thank you very much!! Cheers!!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.