среда, 10 февраля 2010 г.

Portable-версия – легко и непринужденно

Портабельная версия - быстро и просто Несколько раз пользователи Aml Pages просили меня выпустить портабельную версию программы. Про Aml Maple и вовсе уж говорить не приходится – результаты голосования более чем красноречивы. Но с “Маплей” как раз все было проще – она изначально всю жизнь была именно портабельной, банальный ZIP-архив со всеми нужными файлами (версия с инсталлятором появилась с пару месяцев назад, да и то больше из-за буржуев).

Совсем другое дело с Aml Pages. Мало того, что она 100 лет в обед поставляется с программой установки, так у нее еще и есть определенная организация файлов: плагины в папке Plugins, синтаксическая подсветка рядом с exe-шником и.т.д. Совсем худо в том, что при первом запуске Aml Pages должна совершенно по разному инициализировать некоторые настройки в стандартной версии, и в портабельной. К примеру: отключить автосохранение на флешку, резервные копии, да и выставить сохранение настроек в ini-файл, а вовсе не в реестр Windows.

Можно сколько угодно писать инструкцию, как перенастроить софт для портабельной версии – но пользователи все равно ее не прочтут (нарушат, ошибутся – нужное подчеркнуть). По уму портабельная версия должна сама верно проинициализироваться. Ну свойственно людям ошибаться – и тут ничего не поделаешь. Но вот минимизировать риск ошибки можно, и должно.

Расскажу-ка как я выкрутился с проблемой портабельности в Aml Pages. Тут вот какое дело: в Aml Pages есть прозрачный движок для чтения и записи пользовательских настроек. Ему абсолютно по барабану куда и откуда читать и писать настройки – что в ини-файл, что в реестр Windows. Конечно, у каждого способа есть свои плюсы, и свои минусы. Выбор того или иного варианта производился в конкретной строке кода – затем вся запись и чтение настроек уже были независимы для любой ветки кода.

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

Но разговор не о том. Было нужно, чтобы в портабельной версии при первом запуске Aml Pages несколько иначе инициализировала определенные настройки по умолчанию. Проще говоря, нужно чтобы софтина знала, в каком режиме она запускается первый раз (второй раз не суть – позже все сохраненные настройки будут считываться). Выкрутился я простым, но весьма эффективным способом. Итак, рецепт такой:

  1. Набиваем ZIP-архив всеми необходимыми файлами, ну и если нужно распихиваем их по нужным субдиректориям в архиве.
  2. Добавляем bat-файл с каким-нить “говорящим” названием RUN_PORTABLE.bat. Да еще и специально его именуем в верхнем регистре, дабы пользователю ну просто в глаза бросался.
  3. В батнике пишем банальнейшую инструкцию запуска такого вида:
    бинарник.exe /run_portable
  4. Ну и напоследок не забываем вложить в ZIP-архив вразумительный ReadMe, в котором указываем, что для портабельной версии нужно пущать программу именно через bat-файл.

Уловили в чем фишка? Все крайне просто. Кто обычно пользуются портабельными версиями? Угу –  продвинутые пользователи! Полагаю, в подавляющем большинстве им известно, что такое bat-файл, ну и поясняющий ReadMe лишний раз напомнит. Опять же такие пользователи, как правило не ленятся пошариться по ZIP-архиву, посмотреть что к чему, почитать ReadMe.

Пользователь стартует bat-файл и exe-шник получает ключ командной строки. Все что остается, это вписать в код проверку на этот ключ командной строки, и коли он есть – немного изменить поведение софтины. В моем случае это была всего лишь иная инициализация 2-3 особых настроек для работы портабельной версии.

Согласитесь, по соотношению цена-качество подход впечатляет – 2-3 строки кода, батник и портабельная версия готова. Хотя, есть и ограничения этого подхода – “так-то оно да, а так-то нет” (©). У меня нет COM-объектов, который кровь из носа надо регистрировать. Да и абсолютно пофигистичный код чтения\записи настроек – что в реестр, что в ини-файл – есть уже ну очень давно, да и вылизан до идеала.

Но вот простота этого подхода меня просто очаровала. Напоследок ZIP-файл портабельной версии, ясен пень, тоже не ручками собирается: ваяем еще один батник, жмем на него, шуршит диск и все необходимые файлы уже собраны в готовый ZIP-архив портабельной версии.

Cсылка по теме: обсуждение портабельности на RSDN.ru.

PS: вместо дисклаймера – авторство идеи ключа командной строки не мое, подсмотрено где-то в сети. Но все гениальное - просто!

7 комментариев:

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

    ОтветитьУдалить
  2. Загадочно, но всё равно могут быть ошибки.
    Вариант:
    1) Всегда настройки сохранять в ini
    2) В инсталляшке предлагать выбор - partable или нет, и потом в самой проге переключатель туда/сюда
    3) Сделать отдельно 2 инсталяшки чтоб уж точно не перепутали :)

    ОтветитьУдалить
  3. 2Albert:
    А зачем портативной версии установка? Для чего? Очень часто пользователи ожидают - что распаковал, запустил и поехали. А установка всегда вызывает ощущение, что она (установка) возможно делает что-то еще!?!

    В Aml Pages у меня так и есть: что первый запуск автоматически определяет носитель, и если он съемный, то ставятся настройки для портабельной версии.
    Но частенько пользователи сначала вытаскивают портабельную версию на хард, там пускают и если оно то самое, просто хотят скопировать версию на флешку потом (вот тут и нужен ключ командной строки - чтобы несмотря на первый запуск с харда все равно выставили портабельные настройки)

    ОтветитьУдалить
  4. 2thevaleks:
    Почему ошибки?
    1) Всегда в ини-файл не очень то предпочтительно. Если настроек много, то они быстрее будут писаться в реестр, а не в ини-файл. Более того, если пользователь пользуется исключительно с харда, то настройки в реестре позволяют использовать одни и те же настройки для одновременно используемых нескольких версий, установленных в разные папки.


    2) Инсталляшка как правило ставится на хард. Поэтому имхо вполне достаточно просто настроек по умолчанию, которые автоматически выставит прога при первом запуске.

    Выбор ини vs реестр: в Aml Pages кстати так и есть - в пользовательском интерфейсе есть выбор, куда сохранять настройки и в ини, или в реестр.
    Кстати и импорт\экспорт настроек как раз и завязан на ту же самую запись настроек из реестра в ини (с той разницей, что пользователь сам указывает в какой именно ини-файл писать).

    3) 2 отдельных инсталлятора: в принципе нормально, но хотелось бы сделать портабельную версию вообще без инсталлера, чтобы портабельность была прямо таки очевидной.

    ОтветитьУдалить
  5. Хотел написать ответ, в результате написал себе целый пост :)
    http://begemotov.net/creator/shareware/evolyutsiya-portabelnosti/

    ОтветитьУдалить
  6. знаеш обидно терять данные или долго и нудно их выковыривать и настраивать я имею в виду падение винды переустановка итд я лично поэтому предпочитаю портабельные версии органайзеров и брузеров и стоят они у меня на другом диске ваше
    а что что касается амл было бы неплохо чтоб была
    возможность сохранять документы в папку спрограммой

    ОтветитьУдалить
  7. А какие собсна проблемы? Сохранять документы пользователя в Aml Pages можно вообще куда-угодно: все обычно - открыли документ, "сохранить как" и все готово.

    ОтветитьУдалить