Возвращение GIF-изображения из метода - PullRequest
2 голосов
/ 21 октября 2008

Я создаю приложение в Java, которое будет частью внешнего приложения. Мое приложение содержит область просмотра, которая показывает несколько полигонов и тому подобное. Внешнему приложению необходимо получить изображение области просмотра в формате GIF. Для этого он вызывает метод в интерфейсе (реализованный моим приложением), и мое приложение возвращает изображение. Внешнее приложение должно хранить изображение в базе данных (или что-то связанное с этим, о чем мне не нужно беспокоиться).

Мой вопрос: - Каким должен быть тип изображения контейнера, когда мое приложение отправляет его во внешнее приложение? Я имею в виду, какой должен быть тип возврата метода? В настоящее время мой класс кодировщика gif возвращает массив байтов. Есть ли другой вариант «лучше»?

Ответы [ 4 ]

3 голосов
/ 21 октября 2008

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

Даже если сегодня вы просто вернете полностью заполненный ByteArrayOutputStream, это позволит вам в будущем изменить реализацию, не затрагивая скрытый код.

2 голосов
/ 21 октября 2008

Более интуитивным типом возврата может быть java.awt.Image.

Вот несколько примеров: http://www.google.com/codesearch?q=java+gif+image&hl=en&btnG=Search+Code

0 голосов
/ 06 января 2009

Я бы создал два метода:

  1. Первый метод создает изображение и возвращает java.awt.Image. Здесь вы можете поместить чертежную часть вашего метода.
  2. Второй метод создает gif-представление java.awt.Image по запросу внешнего приложения. Он должен вернуть OutputStream, как уже предлагалось.
0 голосов
/ 21 октября 2008

Если ваше «приложение» фактически вызывает метод Java, оно должно понимать типы возвращаемых данных Java, и вы должны вернуть java.awt.image.

Если вы делаете это через какую-то удаленную процедуру, которая не может понять типы Java, я бы возвратил байтовый массив и позволил принимающему приложению декодировать его.

...