RTEditor/src/main/java/com/onegravity/rteditor/media/MonitoredActivity.java
public <T> T startForegroundJob(int msgId, ForegroundJob<T> job) {
        // make the progress dialog uncancelable, so that we can guarantee
        // that the thread is done before the activity gets destroyed
        ProgressDialog dialog = ProgressDialog.show(this, null, getString(msgId), true, false);
        Job<T> managedJob = new Job<T>(job, dialog);
        return managedJob.runForegroundJob();
    }
public <T> T startForegroundJob(int msgId, ForegroundJob<T> job) {
        // make the progress dialog uncancelable, so that we can guarantee
        // that the thread is done before the activity gets destroyed
        ProgressDialog dialog = ProgressDialog.show(this, null, getString(msgId), true, false);
        Job<T> managedJob = new Job<T>(job, dialog);
        return managedJob.runForegroundJob();
    }
public < T > T startForegroundJob ( int msgId , ForegroundJob < T > job ) { // make the progress dialog uncancelable, so that we can guarantee // that the thread is done before the activity gets destroyed ProgressDialog dialog = ProgressDialog . show ( this , null , getString ( msgId ) , true , false ) ; Job < T > managedJob = new Job < T > ( job , dialog ) ; return managedJob . runForegroundJob ( ) ; }
Start a foreground job showing a progress bar as long as the job runs.
A foreground job shows a modal dialog that can't be cancelled while the app
does some processing. This should be used for short jobs only that block the ui.
Of course this contradicts many of the Android guidelines but with short jobs
we mean < 1 second and only in rare cases should it me more (e.g. when the garbage
collector kicks in which would normally lead to stuttering).
Using foreground jobs gives a better user experience in these rare cases.
The user has to wait but he/she knows it because there's a progess bar.
Start a foreground job showing a progress bar as long as the job runs . A foreground job shows a modal dialog that can t be cancelled while the app does some processing . This should be used for short jobs only that block the ui . Of course this contradicts many of the Android guidelines but with short jobs we mean < 1 second and only in rare cases should it me more ( e . g . when the garbage collector kicks in which would normally lead to stuttering ) . Using foreground jobs gives a better user experience in these rare cases . The user has to wait but he / she knows it because there s a progess bar .