如何使用 FileChannels TransferFrom() 方法监视进度(JProgressBar)?

发布于 2024-08-21 01:15:13 字数 1000 浏览 13 评论 0原文

我需要有关 JProgressBar 组件的一些帮助。我的程序使用 java.nio FileChannels 将文件从一个地方复制到另一个地方。实际的复制方法是transferFrom()

我现在有两个问题。

  1. 如何监控FileChannels的传输进度?我发现的所有教程都使用传统的 java.io InputStreams 并在循环输入流时增加进度 int。

  2. 我的复制方法(FileChannel 方法)封装在一个单独的方法中,该方法由其他方法调用,这些方法迭代源文件夹和目标文件夹,然后为每个文件调用 FileChannel 方法。

如何实现完整复制机制的 ProgressBar?

好吧,我应该早点阅读常见问题解答,所以我想我必须编辑我的初始帖子而不是评论答案,对吧?

好吧,这就是我到目前为止所做的。 正如 jambjo 所建议的(顺便谢谢),transferFrom() 方法现在已循环。 BTW:是否有更好的块大小,或者它是否取决于我的进度条的粒度,就像 EJP 所说的那样?

这是我的代码片段:

while (position < size) {
 position += destination.transferFrom(source, position, chunkSize);
 current =  (position/size)*100;
 System.out.println(current);
}

不幸的是,“当前”值在循环内保持为 0,我不知道为什么。 我错过了什么吗?

再次感谢jambjo!我非常感谢您的意见! 现在单个文件的进度监控已经可以工作了,让我们解决第二个问题。


我想,不,我必须不仅监视单个文件的进度,而且监视一堆文件的进度。 我的主要复制方法遍历各个目录并通过调用实际的传输方法复制适当的文件。 因此复制方法不传输文件,它们只是为实际传输方法选择文件。

I need a little help with the JProgressBar component. My program copies files from one place to another using java.nio FileChannels. The actual copy method is transferFrom().

I've got two questions now.

  1. How to I monitor the transfer progress of FileChannels? All tutorials I've found use the conventional java.io InputStreams and increase the progress int while looping through the inputstream.

  2. My copy methods (the FileChannel methods) are encapsulated in a separate method that is invoked by other methods that iterate though source and destination folders and then invoke the FileChannel methods for each file.

How do I implement a ProgressBar for the complete copy mechanism?

Well I should have read the FAQ a little earlier, so I guess I have to edit my initial post instead of commenting the answers, right?

Ok this is what I've done so far.
Just as jambjo suggested (thanks by the way), the transferFrom() method is now looped.
BTW: Is there a preferable chunk size, or does it depend on the granularity of my progress bar just as EJP said?

Here is my code snippet:

while (position < size) {
 position += destination.transferFrom(source, position, chunkSize);
 current =  (position/size)*100;
 System.out.println(current);
}

Unfortunately the 'current' value stays 0 within the loop and I've got no idea why.
Am I missing something?

Thanks again jambjo! I really appreciate your input!
Now that the progress monitoring of a single file works, let's address my second problem.


I'd like, no I have to, monitor progress of not only a single file, but rather a bunch of files.
My main copy methods iterates through various directories and copies appropriate files by invoking the actual transfer method.
So the copy methods don't transfer files, they are just selecting files for the actual transfer method.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

幸福不弃 2024-08-28 01:15:13

我意识到我在这里复活了一个非常旧的线程,但我今天在谷歌搜索中发现了它,所以...

如果你想监控进度,最好像 EJP 建议让系统处理块大小,以便它可以优化转移。监视的方法是为 ReadableByteChannel 编写一个包装类,每当调用它的 read 方法时,您都可以使用它来传递进度消息。这是一个例子:

package download.progress.example;

import java.io.FileOutputStream;
import java.io.IOException;
import java.net.HttpURLConnection;
import java.net.URL;
import java.nio.ByteBuffer;
import java.nio.channels.Channels;
import java.nio.channels.ReadableByteChannel;

public class DownloadProgressExample {
    public static void main( String[] args ) {
        new Downloader( "/tmp/foo.mp3", "http://example.com/bar.mp3" );
    }

    private interface RBCWrapperDelegate {
        // The RBCWrapperDelegate receives rbcProgressCallback() messages
        // from the read loop.  It is passed the progress as a percentage
        // if known, or -1.0 to indicate indeterminate progress.
        // 
        // This callback hangs the read loop so a smart implementation will
        // spend the least amount of time possible here before returning.
        // 
        // One possible implementation is to push the progress message
        // atomically onto a queue managed by a secondary thread then
        // wake that thread up.  The queue manager thread then updates
        // the user interface progress bar.  This lets the read loop
        // continue as fast as possible.
        public void rbcProgressCallback( RBCWrapper rbc, double progress );
    }

    private static final class Downloader implements RBCWrapperDelegate {
        public Downloader( String localPath, String remoteURL ) {
            FileOutputStream        fos;
            ReadableByteChannel     rbc;
            URL                     url;

            try {
                url = new URL( remoteURL );
                rbc = new RBCWrapper( Channels.newChannel( url.openStream() ), contentLength( url ), this );
                fos = new FileOutputStream( localPath );
                fos.getChannel().transferFrom( rbc, 0, Long.MAX_VALUE );
            } catch ( Exception e ) {
                System.err.println( "Uh oh: " + e.getMessage() );
            }
        }

        public void rbcProgressCallback( RBCWrapper rbc, double progress ) {
            System.out.println( String.format( "download progress %d bytes received, %.02f%%", rbc.getReadSoFar(), progress ) );
        }

        private int contentLength( URL url ) {
            HttpURLConnection           connection;
            int                         contentLength = -1;

            try {
                HttpURLConnection.setFollowRedirects( false );

                connection = (HttpURLConnection) url.openConnection();
                connection.setRequestMethod( "HEAD" );

                contentLength = connection.getContentLength();
            } catch ( Exception e ) { }

            return contentLength;
        }
    }

    private static final class RBCWrapper implements ReadableByteChannel {
        private RBCWrapperDelegate              delegate;
        private long                            expectedSize;
        private ReadableByteChannel             rbc;
        private long                            readSoFar;

        RBCWrapper( ReadableByteChannel rbc, long expectedSize, RBCWrapperDelegate delegate ) {
            this.delegate = delegate;
            this.expectedSize = expectedSize;
            this.rbc = rbc;
        }

        public void close() throws IOException { rbc.close(); }
        public long getReadSoFar() { return readSoFar; }
        public boolean isOpen() { return rbc.isOpen(); }

        public int read( ByteBuffer bb ) throws IOException {
            int                     n;
            double                  progress;

            if ( ( n = rbc.read( bb ) ) > 0 ) {
                readSoFar += n;
                progress = expectedSize > 0 ? (double) readSoFar / (double) expectedSize * 100.0 : -1.0;
                delegate.rbcProgressCallback( this, progress );
            }

            return n;
        }
    }
}

I realize I'm resurrecting a very old thread here but I came across it in my googling today, so...

If you want to monitor progress it's better as EJP suggests to let the system deal with the chunk size so it can optimize the transfer. The way to monitor is to write a wrapper class for ReadableByteChannel that you use to pass progress messages whenever its read method is called. Here's an example:

package download.progress.example;

import java.io.FileOutputStream;
import java.io.IOException;
import java.net.HttpURLConnection;
import java.net.URL;
import java.nio.ByteBuffer;
import java.nio.channels.Channels;
import java.nio.channels.ReadableByteChannel;

public class DownloadProgressExample {
    public static void main( String[] args ) {
        new Downloader( "/tmp/foo.mp3", "http://example.com/bar.mp3" );
    }

    private interface RBCWrapperDelegate {
        // The RBCWrapperDelegate receives rbcProgressCallback() messages
        // from the read loop.  It is passed the progress as a percentage
        // if known, or -1.0 to indicate indeterminate progress.
        // 
        // This callback hangs the read loop so a smart implementation will
        // spend the least amount of time possible here before returning.
        // 
        // One possible implementation is to push the progress message
        // atomically onto a queue managed by a secondary thread then
        // wake that thread up.  The queue manager thread then updates
        // the user interface progress bar.  This lets the read loop
        // continue as fast as possible.
        public void rbcProgressCallback( RBCWrapper rbc, double progress );
    }

    private static final class Downloader implements RBCWrapperDelegate {
        public Downloader( String localPath, String remoteURL ) {
            FileOutputStream        fos;
            ReadableByteChannel     rbc;
            URL                     url;

            try {
                url = new URL( remoteURL );
                rbc = new RBCWrapper( Channels.newChannel( url.openStream() ), contentLength( url ), this );
                fos = new FileOutputStream( localPath );
                fos.getChannel().transferFrom( rbc, 0, Long.MAX_VALUE );
            } catch ( Exception e ) {
                System.err.println( "Uh oh: " + e.getMessage() );
            }
        }

        public void rbcProgressCallback( RBCWrapper rbc, double progress ) {
            System.out.println( String.format( "download progress %d bytes received, %.02f%%", rbc.getReadSoFar(), progress ) );
        }

        private int contentLength( URL url ) {
            HttpURLConnection           connection;
            int                         contentLength = -1;

            try {
                HttpURLConnection.setFollowRedirects( false );

                connection = (HttpURLConnection) url.openConnection();
                connection.setRequestMethod( "HEAD" );

                contentLength = connection.getContentLength();
            } catch ( Exception e ) { }

            return contentLength;
        }
    }

    private static final class RBCWrapper implements ReadableByteChannel {
        private RBCWrapperDelegate              delegate;
        private long                            expectedSize;
        private ReadableByteChannel             rbc;
        private long                            readSoFar;

        RBCWrapper( ReadableByteChannel rbc, long expectedSize, RBCWrapperDelegate delegate ) {
            this.delegate = delegate;
            this.expectedSize = expectedSize;
            this.rbc = rbc;
        }

        public void close() throws IOException { rbc.close(); }
        public long getReadSoFar() { return readSoFar; }
        public boolean isOpen() { return rbc.isOpen(); }

        public int read( ByteBuffer bb ) throws IOException {
            int                     n;
            double                  progress;

            if ( ( n = rbc.read( bb ) ) > 0 ) {
                readSoFar += n;
                progress = expectedSize > 0 ? (double) readSoFar / (double) expectedSize * 100.0 : -1.0;
                delegate.rbcProgressCallback( this, progress );
            }

            return n;
        }
    }
}
云裳 2024-08-28 01:15:13

无法监视单个调用 transferFrom 的进度,但由于您可以向其传递偏移量和长度参数,因此您可以围绕它实现自己的循环并更新合适大小的块之间的进度条的数据。

There is no way to monitor the progress of a single invokation of transferFrom, but since you can pass it offset and length parameters, you can implement your own loop around it and update the progress bar between suitable sized chunks of data.

烦人精 2024-08-28 01:15:13

...尽管这完全超出了首先使用transferTo()的意义,即尽可能地将复制交给内核。要么你想这样做,要么你想看到进展。你必须选择。至少您必须选择进度显示所需的粒度。

... although that would be completely beside the point of using transferTo() in the first place, which is to hand the copying off to the kernel as much as possible. Either you want to do that or you want to see progress. You have to choose. At least you have to choose how much granularity you want in the progress display.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文