Почему SwingWorker#setProgress ограничен [0, 100]?

Есть ли веская причина, по которой они ограничили прогресс до [0,100]?

В той мере, в какой этот вопрос имеет конструктивный ответ, понятие прогресса, вероятно, лучше всего известно тому, что моделируется в фоновом потоке. Масштабирование ограничивает количество отображаемых деталей.

В то же время SwingWorker < em>предназначен для подкласса. Ничто не мешает добавить метод setProgress(int progress, in min, int max) и поддержку изменения сопутствующего свойства, но трудно увидеть какое-либо преимущество — получатель просто должен масштабировать его для отображения.

Обсуждать дизайн API довольно занимательно, но склонны к догадкам :-)

Несколько случайных мыслей в конце недели:

• базовая модель процесса SwingWorker состоит в том, чтобы позволить что-то делать в фоновом режиме и поддерживать отправку как промежуточных, так и конечных результатов обратно в EDT.

• он предназначен для создания подклассов (как уже подчеркивал @trashgod), в то же время он пытается свести к минимуму усилия, необходимые для этого: состояние и ход выполнения являются полностью определенными и реализованными удобными свойствами, предназначенными для использования как- является.

• при этом правила API-документа, в которых четко указано, что допустимые значения процесса связанного свойства находятся в диапазоне от 0 до 100, инклюзивно. Никакой двусмысленности, ничего нельзя изменить в пользовательских реализациях. Отображение прогресса в процентах является наиболее распространенным вариантом использования, поддержка которого нестандартно является разумным решением.

• для сообщения промежуточных результатов в координатах, отличных от процентов, предполагаемый путь - реализовать процесс (..). Это зависит от пользовательской реализации, что именно она делает, может запускать пользовательское определенное свойство или напрямую заполнять модель представления или... что угодно

• наконец, учебный пример — это просто пример. Плюс он сам по себе противоречив: в описании упоминается метод task.getLenghtOfTask, который не реализован в кастомном свингворкере. Мое (дикое) предположение состоит в том, что текст примера все еще основан на более старой версии, которая могла поддерживать произвольные значения.

Чтобы ответить на вопрос (мои 0,02 евроцента :-) - в дизайне нет ничего плохого, это хорошо сбалансированная базовая реализация, которая готово обрабатывает распространенные варианты использования и в то же время достаточно гибка, чтобы упростить более сложные требования. реализовать.

обновить, как только будет доступна одна часть информации

вы не можете полностью контролировать детализацию отчетов: все, что вы можете сделать, это определить единицу наименьшего фрагмента, а затем ожидать получения одной или нескольких из этих наименьших монет.

1) SwingWorker#setProgress ---> Я принимаю это как процентное значение, в основном существует диапазон от 0 до 100, согласен, что алгебра знает отрицательные % или 1M в %, но таким же образом вы можете вычислить четвертое/пятое измерение, немного сложнее может быть с уравнением Дрейка, но возможно

2) JProgressBar ---> не имеет этого ограничения/запрета, т.к. можно написать красивый код, где можно переключаться (JComboBox) между значениями в %, Mb, оставлять.... для прогресса

Это зависит от вашего варианта использования, но вы также можете использовать метод публикации для публикации хода выполнения и обновления индикатора выполнения в методе публикации. См. мой ответ на другой вопрос SO для примера