Лучшая практика для autoupdates

Для настольных приложений лучше всего использовать автоматические обновления? В настоящее время мы загружаем все файлы, а затем копируем и регистрируем (если com dll) в соответствующие каталоги.

Я просмотрел метод обновления Google Chrome. Кажется, что он сначала загружает заархивированный файл в каталог, а затем распаковывает все файлы. Кроме того, у них есть приложение настройки, которое, как представляется, используется для обновления. Кроме того, они создают каталог, отображаемый для обновления версии, например, 1.0.154.43, но они хранят каталог старой версии.

Ответ 1

Недавнее сообщение в блоге от команды Chromium - отличное руководство:

http://blog.chromium.org/2009/01/google-chrome-installation-and-updates.html

В принципе, то же самое происходит при использовании MS ClickOnce, и до сих пор у меня нет проблем с использованием приложений с таким методом обновления, поэтому я предполагаю, что это классифицируется как "Лучшая практика"... но это только я.

  • Сохраняйте каждую версию в своей собственной уникальной папке.
  • Используйте "Launcher" для запуска самой обновленной версии и...
  • Проверяйте наличие новых версий в фоновом режиме после запуска приложения.
  • Загрузите новую найденную версию и создайте новую папку для этой версии.

Google Chrome немного отличается, поскольку они используют сервис Google Update для обновления, но общий опыт/цикл практически одинаковы.

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

Ответ 2

Несколько советов:

  • Независимо от того, как вы решите это сделать, не создавайте новую услугу или процесс для проверки обновлений, а затем оставляйте их постоянно. Вы знаете, как это делают Adobe и Sun (для Java). Независимо от того, что вы делаете, я могу гарантировать, что это не так важно, чтобы его нужно обновлять каждый раз, когда пользователь запускает компьютер. Обновления должны быть интегрированы со стандартным процессом обновления, общим для ОС или при запуске приложения. Обновления не должны постоянно красть системные ресурсы или замедлять процесс загрузки по умолчанию.

  • Если вы поддерживаете отдельные каталоги для каждой версии, вам нужно добавить код для его сохранения. Дисковое пространство не предназначено для обновления. Я помню одно приложение Citrix, в котором одновременно было 5 разных версий. Пользователь не должен видеть более двух копий (максимум одной резервной копии, подтвержденной как работоспособной) вашего приложения в своей файловой системе, если только они явно не разместили их там. Ярлыки для вашего приложения могут устаревать, когда расположение папки изменяется так, поэтому будьте осторожны.

  • Если вы обновляете после запуска программы, я бы рекомендовал уведомить пользователя не навязчивым способом. Если обновление не приводит к существенному изменению функциональности, загрузите обновление в фоновом режиме, переключитесь на новую версию при следующем запуске приложения и сообщите пользователю о значительных изменениях (не используйте модальное диалоговое окно или не крадите фокус). Не заставляйте пользователя нажимать кнопку, чтобы согласиться установить обновления перед запуском приложения или заставить их перезагрузиться, чтобы использовать обновленную версию. Разрешить пользователям настраивать автоматические обновления, а затем делать это, не влияя на их производительность. Firefox довольно плохо об этом, что печально, поскольку это такое интегральное приложение для многих пользователей.

  • Не прикасайтесь к системному лотку. Это должно быть зарезервировано для полезных (для пользователя) приложений. Я также рекомендовал бы запретить уведомления о воздушном шаре. Используйте что-то вроде инфобары, обычно наблюдаемой в браузерах. Приложения Microsoft особенно плохо относятся к использованию системного трея и уведомлений о шарах, чтобы тратить время пользователя на несущественные уведомления. Если пользователь включил автоматические обновления, им действительно не нужно знать, что все работает так, как они ожидали. Скажите им, когда есть что-то новое или полезное, и не заставляйте знания переминаться. Оставьте журнал изменений под пунктом меню "Справка", чтобы они могли самостоятельно проверять исправления ошибок.

  • Будьте осторожны с обновлениями с использованием системы MSI, если вы развертываете файл конфигурации по умолчанию. Вы не хотите перезаписывать любые пользовательские файлы в своем обновлении. В том же ключе, если формат файлов конфигурации или пользовательских файлов изменяется, вы должны предоставить механизм автоматического резервного копирования и обновления этих файлов. Или начните создавать настройки по умолчанию внутри приложения, а не развертывать их.

  • Знать пропускную способность. Большие файлы требуют времени и, возможно, пропускной способности от ваших пользователей. Особенно, если вы ежедневно обновляете.

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

Ответ 3

Использовать существующую инфраструктуру

В MacOS X: используйте фреймворк Sparkle, http://sparkle.andymatuschak.org

В Linux: создавайте пакеты и устанавливайте репозитории для дистрибутивов, которые вы будете поддерживать