Толи оно никому не надо, толи все тривиально и только я непонятливый, однако ж найти хорошее описание JNLP и как с ним работать на родном языке сложно. Значит придется делать самому.
Стандартный заголовок XML файла
<?xml version="1.0" encoding="utf-8"?>
дальше идет тэг <jnlp>, все остальное находится внутри него. Вот его структура, дальше рассмотрим все элементы подробнее
<jnlp>
<information>...</information>
<security>...</security>
<update>...</update>
<resources>...</resources>
<application-desc>...</application-desc> или <applet-desc>...</applet-desc>
или <component-desc>...</component-desc> или <installer-desc>...</installer-desc>
</jnlp>
Элемент jnlp может иметь следующие аттрибуты:
- spec="6.0+" (1.0+,1.5.0 и т.п.) версия спецификации JNLP. + означает - и выше. Самое правильное решение поставить 6.0 или 6.0+ (или уточнить какая версия наиболее распространена на данный момент).
- codebase="" базовый URL, от которого будут плясать все относительные ссылки в этом файле.
- href="" URL этой самой страницы. Следует указать если вы задаете codebase для общей части относительных ссылок на jar-файлы, а jnlp лежит в другом месте.
- version номер версии вашей программы. Если обновился - пользователю автоматически загрузится новая версия. Иначе хоть за обновляйтесь - он об этом не узнает.
Простой вариант - jnlp-файл лежит там куда указывает codebase, все jar'ы - там же, если их мало, или ниже, раскиданные по каталогам если их много. Тогда href можно не задавать вообще или указать "". Если у вас много jnlp, они раскиданы по разным местам и ссылаются на кучу библиотек, которые лежат в одном месте - тогда придется явно указывать и codebase и href.
<information>
их может быть несколько для разных os, платформ, локалей и т.д.
Замечу сразу - это не имеет ни малейшего отношения к загрузке разных нативные библиотек в соответствии с ОС пользователя. Чисто рюшечки и шашечки. Например разные ссылки на домашнюю страницу для разных языков (англоязычных - на американский сервер, русских - на свой) и т.д.
<information>
... а здесь для всех ОС
</information>
<information os="linux">
... указываем что-то специфически линуксовое
</information>
атрибуты:
os, arch, platform, locale - думаю разъяснений не надо. Но если вы их используете, то точные значения придется поискать и у меня есть сомнения что оно будет работать одинаково. Например, все ли линуксы будут сообщать о себе как os="linux", или придется писать отдельные блоки information для centoos, redhat, ubuntu и т.п.?
Рассмотрим information подробнее:
<information>
<title>Название вашей программы</title>
<vendor>Название фирмы или имя разработчика</vendor>
<homepage href=""/> указание на домашнюю страницу
<description kind=""> Описание. kind может принимать значения "one-line", "short", и "tooltip". Описание должно содержать только чистый текст. Никаких html тэгов.</description>
<icon/> может иметь атрибуты width,height - ну это понятно. kind="splash" - если вы хотите окно заставку, вроде того что выводит эклипсе при запуске. Естественно должен быть указан href. Во время загрузки будет показываться иконка 64х64, на рабочем столе 32х32, другие размеры автоматически смасштабируются. Произвольных размеров видимо может быть только заставка.
<offline-allowed/> указываем этот тэг если хотим чтобы приложение работало в оффлайне. Кроме того он влияет на то, как приложение проверяет обновления. Если не задан, то сначала проверяется наличие обновлений, если надо обновляется и только потом запускается - это гарантирует что всегда запущена свежая версия. Если задан, то приложение запускается, и только потом неспешно проверяет, нет ли более свежих версий. В результате запуск быстрее, но не факт, что запущена последняя версия. Необходимо отметить, что если приложение уже запустилось, а вы на сервере поменяли версию, то у вас таки может возникнуть ситуация, что работает несоответствующая версия. Если это важно - передавайте номер версии при общении клиента с сервером и контролируйте соответствие.
<desktop/> нужна ли иконка на рабочем столе
<menu/> нужно ли добавлять себя в меню. Атрибут submenu="" указывает в какое именно.
- extensions="mydata" Т.е. при запуске файла "чтоугодно.mydata" будет запускаться ваша прога
- mime-type="application-x/mydata-file" . Если сервер передаст такой mime-type, то опять же запустится ваша прога.
<related-content href="" title=""> может содержать ссылки на дополнительную информацию (readme-файл, страницу помощи, страницу регистрации и т.п). Соответственно href задает ссылку, title - название. Может содержать элементы icon и description. Но я ума не приложу - где пользователь все это увидит.
</information>
C information покончили. Следующий элемент security.
<security>
<all-permissions/>
</security>
Если вы его не задаете - приложение работает в песочнице. Если задаете - выше указано как. Может быть есть еще варианты, но смысла в них ковыряться нет. Либо все, либо ничего. Если всё, то все JARы должны быть подписаны, причем одним ключом. Т.е. если вы пользуете стороние библиотеки, то подписываете и их тоже. Так кажется, но есть нюансы. Ранее все jar'ы можно было тянуть только из одного места, теперь вы вроде как можете указывать и публичные репозитории для сторонних библиотек. Но подписать вы их естественно в таком случае не сумеете.
Во всяком случае я бы не рекомендовал использовать такой вариант. В один прекрасный день этот сервис может прекратится. Иногда они вас даже предупредят заранее, но часто ли вы читаете новости всевозможных сервисов, которыми пользуетесь? И ваше приложение внезапно перестанет работать. Оно вам надо?
<update check="" policy=""/>
check указывает когда и как проверять обновления. может принимать значения
- background приложение запускается, проверка стартует параллельно
- timeout (по умолчанию) проверка выполняется перед тем как запустить приложение. Если соединения с инетом нет, или сервер загружен, упал и не отвечает то о истечении некоторого таймаута приложение запустится.
- always проверка всегда выполняется перед тем как запустить приложение. Если соединения нет - ваша программа будет жутко пользователя раздражать. На мой взгляд лучше ее запустить и сообщить об отсутствии связи (если она вам нужна). Так что мой выбор - background
policy указывает что делать с обновлением
- always (по умолчанию) - загружать без всяких вопросов
- promt-update - спросить пользователя, хочет ли он обновить или запустить установленную версию
- prompt-run - спросить пользователя, хочет ли он обновить и запустить, или отказаться от запуска программы.
Что выйдет если задать background+prompt-run - не ясно. Т.е. программа уже запустилась, и тут выясняется что запускать ее было нельзя, м-да... По идее такая комбинация использоваться не должна.
Следующий, очень важный и полезный элемент resources.
<resources os="" arch="" locale="">
<jar href="myjar.jar"/> задает ссылку на библиотеку, которая требуется приложению.
<nativelib href="lib/windows/corelib.jar"/> задает ссылку на нативные библиотеки. Все ваши *.dll, lib*.so и т.п. файлы должны быть запакованы в jar (видимо потому что jar можно, и нужно, подписать). и должны быть в корне этого jar, без всяких вложенных папок.
<j2se version="1.6+"/>указывает какая версия Java нам нужна. Я задаю больше или равно той, на которой разрабатываю. С одной стороны - не надо заставлять пользователя загружать устаревшую версию, если у него более новая. С другой стороны меньше шансов, что программа использует какую-то новую фичу, в то время как у пользователя стоит старье.
</resources>
Атрибуты os, arch, locale позволяют например подгрузить разные нативные библиотеки в соответствии с ОС пользователя и языковые данные.
jar и nativelib могут иметь атрибут download. Значения
- lazy - приложение может запускаться не дожидаясь их загрузки
- eager - должны загружаться перед загрузкой приложения
- progress - тоже самое что eager + может использоваться для указания прогресса загрузки. Чтобы это только значило?
дополнительные атрибуты для j2se:
- href="http://java.sun.com/products/autodl/j2se" - указывает где можно взять джаву
- initial-heap-size="64m"
- max-heap-size="128m"
- java-vm-args="" доп. ключики с которыми нужно запускать JVM для ввашего приложения
если вы не знаете зачем все это, то не задавайте.
элемент j2se может содержать еще элементы property
<property name="key" value="value"/>
если ваша программа использует System.getProperty и System.setProperties то вы знаете что это и зачем, если нет - не заморачивайтесь. Почитать о них (на англицком) можно тут: Properties That Affect the Behavior of Rich Internet Applications
<application-desc main-class="Main">
<argument>arg1</argument>
<argument>arg2</argument>
</application-desc>
атрибут main-class должен задавать полное имя класса(включая имя пакета), который содержит метод main.
Если у нас апплет, то вместо application-desc задается applet-desc.
<applet-desc documentBase="http://..."
name="имя вашей программы" main-class="класс апплета"
width="527" height="428">
<param name="key1" value="value1"/>
<param name="key2" value="value2"/>
</applet-desc>
Еще у нас может быть компонент и инсталлятор, <component-desc> и <installer-desc> соответственно. Их описывать не стану, когда вам понадобится их использовать, JNLP файлы уже не будут вызывать у вас священный ужас и в этом вы сможете разобраться самостоятельно.
Комментариев нет:
Отправить комментарий