Несколько раз пользователи Aml Pages просили меня выпустить портабельную версию программы. Про Aml Maple и вовсе уж говорить не приходится – результаты голосования более чем красноречивы. Но с “Маплей” как раз все было проще – она изначально всю жизнь была именно портабельной, банальный ZIP-архив со всеми нужными файлами (версия с инсталлятором появилась с пару месяцев назад, да и то больше из-за буржуев).
Совсем другое дело с Aml Pages. Мало того, что она 100 лет в обед поставляется с программой установки, так у нее еще и есть определенная организация файлов: плагины в папке Plugins, синтаксическая подсветка рядом с exe-шником и.т.д. Совсем худо в том, что при первом запуске Aml Pages должна совершенно по разному инициализировать некоторые настройки в стандартной версии, и в портабельной. К примеру: отключить автосохранение на флешку, резервные копии, да и выставить сохранение настроек в ini-файл, а вовсе не в реестр Windows.
Можно сколько угодно писать инструкцию, как перенастроить софт для портабельной версии – но пользователи все равно ее не прочтут (нарушат, ошибутся – нужное подчеркнуть). По уму портабельная версия должна сама верно проинициализироваться. Ну свойственно людям ошибаться – и тут ничего не поделаешь. Но вот минимизировать риск ошибки можно, и должно.
Расскажу-ка как я выкрутился с проблемой портабельности в Aml Pages. Тут вот какое дело: в Aml Pages есть прозрачный движок для чтения и записи пользовательских настроек. Ему абсолютно по барабану куда и откуда читать и писать настройки – что в ини-файл, что в реестр Windows. Конечно, у каждого способа есть свои плюсы, и свои минусы. Выбор того или иного варианта производился в конкретной строке кода – затем вся запись и чтение настроек уже были независимы для любой ветки кода.
В общем, это самый обычный традиционный полиморфизм: есть абстрактный класс движка чтения\записи настроек, и есть два класса-наследника – соответственно для реестра, и для ини-файла. В конкретной строке инстанцируется нужный класс, а дальше уже понесся обобщенный код чтения\записи конкретных настроек. В общем, ничего мудренного.
Но разговор не о том. Было нужно, чтобы в портабельной версии при первом запуске Aml Pages несколько иначе инициализировала определенные настройки по умолчанию. Проще говоря, нужно чтобы софтина знала, в каком режиме она запускается первый раз (второй раз не суть – позже все сохраненные настройки будут считываться). Выкрутился я простым, но весьма эффективным способом. Итак, рецепт такой:
- Набиваем ZIP-архив всеми необходимыми файлами, ну и если нужно распихиваем их по нужным субдиректориям в архиве.
- Добавляем bat-файл с каким-нить “говорящим” названием RUN_PORTABLE.bat. Да еще и специально его именуем в верхнем регистре, дабы пользователю ну просто в глаза бросался.
- В батнике пишем банальнейшую инструкцию запуска такого вида:
бинарник.exe /run_portable - Ну и напоследок не забываем вложить в ZIP-архив вразумительный ReadMe, в котором указываем, что для портабельной версии нужно пущать программу именно через bat-файл.
Уловили в чем фишка? Все крайне просто. Кто обычно пользуются портабельными версиями? Угу – продвинутые пользователи! Полагаю, в подавляющем большинстве им известно, что такое bat-файл, ну и поясняющий ReadMe лишний раз напомнит. Опять же такие пользователи, как правило не ленятся пошариться по ZIP-архиву, посмотреть что к чему, почитать ReadMe.
Пользователь стартует bat-файл и exe-шник получает ключ командной строки. Все что остается, это вписать в код проверку на этот ключ командной строки, и коли он есть – немного изменить поведение софтины. В моем случае это была всего лишь иная инициализация 2-3 особых настроек для работы портабельной версии.
Согласитесь, по соотношению цена-качество подход впечатляет – 2-3 строки кода, батник и портабельная версия готова. Хотя, есть и ограничения этого подхода – “так-то оно да, а так-то нет” (©). У меня нет COM-объектов, который кровь из носа надо регистрировать. Да и абсолютно пофигистичный код чтения\записи настроек – что в реестр, что в ини-файл – есть уже ну очень давно, да и вылизан до идеала.
Но вот простота этого подхода меня просто очаровала. Напоследок ZIP-файл портабельной версии, ясен пень, тоже не ручками собирается: ваяем еще один батник, жмем на него, шуршит диск и все необходимые файлы уже собраны в готовый ZIP-архив портабельной версии.
Cсылка по теме: обсуждение портабельности на RSDN.ru.
PS: вместо дисклаймера – авторство идеи ключа командной строки не мое, подсмотрено где-то в сети. Но все гениальное - просто!
Можно исходить из мысли, что портативная версия - версия на флешке. Значит выкладываем отдельный установщик, который сам запишет программу на выбранную флешку (что-то типа создания загрузочных дискет/флешек для обновления биосов). Далее, программа определяет - первый запуск с флешки (берем тип носителя через api), значит версия портабельная со всеми вытекающими
ОтветитьУдалитьЗагадочно, но всё равно могут быть ошибки.
ОтветитьУдалитьВариант:
1) Всегда настройки сохранять в ini
2) В инсталляшке предлагать выбор - partable или нет, и потом в самой проге переключатель туда/сюда
3) Сделать отдельно 2 инсталяшки чтоб уж точно не перепутали :)
2Albert:
ОтветитьУдалитьА зачем портативной версии установка? Для чего? Очень часто пользователи ожидают - что распаковал, запустил и поехали. А установка всегда вызывает ощущение, что она (установка) возможно делает что-то еще!?!
В Aml Pages у меня так и есть: что первый запуск автоматически определяет носитель, и если он съемный, то ставятся настройки для портабельной версии.
Но частенько пользователи сначала вытаскивают портабельную версию на хард, там пускают и если оно то самое, просто хотят скопировать версию на флешку потом (вот тут и нужен ключ командной строки - чтобы несмотря на первый запуск с харда все равно выставили портабельные настройки)
2thevaleks:
ОтветитьУдалитьПочему ошибки?
1) Всегда в ини-файл не очень то предпочтительно. Если настроек много, то они быстрее будут писаться в реестр, а не в ини-файл. Более того, если пользователь пользуется исключительно с харда, то настройки в реестре позволяют использовать одни и те же настройки для одновременно используемых нескольких версий, установленных в разные папки.
2) Инсталляшка как правило ставится на хард. Поэтому имхо вполне достаточно просто настроек по умолчанию, которые автоматически выставит прога при первом запуске.
Выбор ини vs реестр: в Aml Pages кстати так и есть - в пользовательском интерфейсе есть выбор, куда сохранять настройки и в ини, или в реестр.
Кстати и импорт\экспорт настроек как раз и завязан на ту же самую запись настроек из реестра в ини (с той разницей, что пользователь сам указывает в какой именно ини-файл писать).
3) 2 отдельных инсталлятора: в принципе нормально, но хотелось бы сделать портабельную версию вообще без инсталлера, чтобы портабельность была прямо таки очевидной.
Хотел написать ответ, в результате написал себе целый пост :)
ОтветитьУдалитьhttp://begemotov.net/creator/shareware/evolyutsiya-portabelnosti/
знаеш обидно терять данные или долго и нудно их выковыривать и настраивать я имею в виду падение винды переустановка итд я лично поэтому предпочитаю портабельные версии органайзеров и брузеров и стоят они у меня на другом диске ваше
ОтветитьУдалитьа что что касается амл было бы неплохо чтоб была
возможность сохранять документы в папку спрограммой
А какие собсна проблемы? Сохранять документы пользователя в Aml Pages можно вообще куда-угодно: все обычно - открыли документ, "сохранить как" и все готово.
ОтветитьУдалить