0

It is really strange and I don't know what to think here.

I have a little timer program that creates a thread with certain operations. One of these operations is creating one more thread to do the actual count down.

The problem is that it doesn't work as expected when I simply run the program (timer freezes at 05:00). However, when I try to do things in debug mode and set breakpoints in the suspicious lines the execution passes through! And it counts down below 5 minutes as expected, but with a little warning message:

I/PomoACt﹕ 04 : 56
I/Choreographer﹕ Skipped 57 frames!  The application may be doing too much work on its main
I/PomoACt﹕ 04 : 55
I/Choreographer﹕ Skipped 58 frames!  The application may be doing too much work on its main thread.

Well the message from choreographer is probably due to slowness of emulator, but why is there a difference in the execution flow of regular vs debug mode?

EDIT: Posting code as requested.

This is a thread which instance I run inside of the main UI thread:

@Override
        public void run() {

            pomodoroLeft = numPomodoro;
            while(pomodoroLeft > 0) {
                pomodoroLeft--;
                runTime = TWENTY_MINUTES; //runTime is needed for timerUpdate
                timerUpdate();                         //This method just updates 
                                                       //textWiew with the current value of 
                                                       //runTime
                runnable = new Clock(); 
                timerRun = true; 
                runnable.run(); 
                waitForClock();
                Log.i("while", "execution in while");


                runTime = FIVE_MINUTES;
                Log.i("while", "execution in while 2");
                runnable = new Clock();
                timerRuns = true;
                Log.i("while", "execution in while 3");
                timerUpdate();
                runnable.run();                          //This is form where the execution
                                                         //misbehaves
                waitForClock();



public class Clock implements Runnable 
    {

        public void run() {
            if (!timerRuns) {
                return;
            }
                Log.i("PomoACt", timeShown.getText().toString());   //To log currently 
                                                                    //displayed value
                runTime -= ONE_SECOND;
                timerUpdate();

                mHandler.postDelayed(this, 1000);                   //Wait a second
                if(timeShown.getText().toString().contentEquals("00 : 00")) {
                    stopClock();
                    synchronized (runnable) {
                        runnable.notify();                          //Notify the waiting
                                                                    //thread that it should
                                                                    //go on with execution
                        Log.i("Not", "notified from runnabe");
                    }
                    //here goes the alarm.
                }


        }
    }

public void stopClock() {
        timerRuns = false;
        mHandler.removeCallbacks(runnable);
    }


 public void waitForClock() {
        synchronized(runnable){
            try{
                runnable.wait();                     //Wait for the current runnable to 
                                                     //compliete
            } catch(InterruptedException e){}
        }
    }

And so TWENTY_MINUTES loop gets executed as expected, but FIVE_MINUTE loop doesn't. It only executes ones, thus showing 4:59 on emulator. It executes fine during debugging session.

user3081519
  • 2,659
  • 5
  • 25
  • 35
  • @ChuongPham Here you go. – user3081519 Apr 06 '14 at 04:53
  • When you have a lot of processing on the main UI thread, this _"The application may be doing too much work on its main thread."_ is to be expected. The reason for the difference is that in debugging mode, your codes stop at a certain point, so the timer method may not hang the UI thread yet. If you ran it normally, it would. My suggestion is to move your timer execution to a [AsyncTask](http://developer.android.com/reference/android/os/AsyncTask.html) to prevent the UI from freezing, not to mention your loop will work properly! – ChuongPham Apr 06 '14 at 05:09
  • @ChuongPham UI is not getting frozen. I can still press the buttons. It is that textView is not getting updated. AsyncTask is not suggested for the use when the process it ought to run exceeds 10 seconds. Java thread is suggested in such case. That is why I went with that. – user3081519 Apr 06 '14 at 05:14
  • Where did you read about this _"AsyncTask is not suggested for the use when the process it ought to run exceeds 10 seconds"_? Certainly not officially from [here](http://developer.android.com/guide/components/processes-and-threads.html). – ChuongPham Apr 06 '14 at 05:24
  • @ChuongPham, The link you specified contains no information about comparative advantage of AsyncTask vs Thread. It merely describes how to use AsyncTask. [This](http://stackoverflow.com/questions/12797550/android-asynctask-for-long-running-operations) post explains in more detail why AsyncTask is a bad idea for long running operations. – user3081519 Apr 06 '14 at 05:44
  • I never said it contains _"comparative advantage of AsyncTask vs Thread"_. I merely provided the link so you can read about processes and threads so you can decide what you want to do after reading it. – ChuongPham Apr 06 '14 at 05:59
  • @ChuongPham Thanks, much appreciated. Didn't mean it it in a bad way. – user3081519 Apr 06 '14 at 06:06
  • @ user3081519: Neither did I. We are here to help each other. ;) – ChuongPham Apr 06 '14 at 06:15

0 Answers0