Лучшие практики для Сам Обновляющий Настольное приложение в сетевой среде
Я перерыл Google и ТАК для возможных ответов на этот вопрос, но могу только найти маленькие биты информации рассеянными вокруг места, большинство которых, кажется, личное мнение.
Я знаю, что этот вопрос можно было считать субъективным, но я не ищу личное мнение, скорее факты с причинами (например, прошлый опыт) или даже единственная ссылка на блог/Wiki, который описывает лучшие практики для этого (это - то, что я предпочел бы быть честным). То, что я не ищу, - то, как сделать эту работу, я знаю, как создать сам обновляющий настольное приложение.
Я хочу знать о лучших практиках для создания сам обновляющий настольное приложение. Вид лучших практик, на предмет которых мне особенно любопытно:
- Вы вызываете обновление, если клиентское программное обеспечение устарело, но не собирающийся повреждаться при попытке общаться с другой версией программного обеспечения или самой базы данных? Раз так, как Вы показываете это изменение повреждения?
- Как часто необходимо проверить на обновления? Еженедельно/ежедневно/каждый час и точно почему?
- Обновление должно быть видимо пользователю или работать негласно с точки зрения UI?
- Необходимо ли даже уведомить пользователя, что существует обновление, доступное, если это не основное обновление? (например, фиксация единственной кнопки в удаленной части приложения, которого только один пользователь на самом деле требует),
- Необходимо ли попытаться исправить приложение, или Вы повторно загружаете целое приложение с нуля стиль Macintosh?
- Необходимо ли позволить пользователям обновлять от центрального расположения или только позволять обновлять через указанное приложение? (для закрытых бизнес-приложений).
Конечно, существуют некоторые записанные правила/предложения об этом материале? Одной из самых раздражающих вещей о большом количестве приложений является обновление, поскольку трудно найти хороший баланс между "устаревшим" и "в пользовательской поверхности".
Если это помогает полагать, что это записано в .net C# для единственного клиента, работая на машинах с постоянной доступной возможностью соединения к серверу обновления, все эти машины говорят друг с другом через приложение, и все также говорят с центральным сервером базы данных.
4 ответа
Трудно дать общий ответ. Это зависит от контекста: критичность обновления, тип приложения, пользовательские настройки, количество пользователей, ширина сети и т. Д. Вот некоторые из вариантов / компромиссов.
Вы принудительно выполняете обновление, если программное обеспечение клиентов устарело, но не ломается при попытке установить связь с другой версией программного обеспечения или самой базой данных? Если да, то как вы обозначите это критическое изменение?
Как разработчик, вы заинтересованы в том, чтобы все приложения были как можно более актуальными. Это снижает ваши затраты на техническое обслуживание. Таким образом, если пользователь не возражает, вам следует выполнить обновление.
Как часто вы должны проверять наличие обновлений? Еженедельно / ежедневно / ежечасно и почему?
Если обновления прозрачны для пользователя, немедленный перезапуск приложения не требуется, тогда я изменения функциональности / пользовательского интерфейса (пользователь будет озадачен, увидев, что внешний вид изменился без предыдущего предупреждения)
Следует ли вам даже уведомить пользователя о наличии доступного обновления, если это не серьезное обновление? (например, фиксация одной кнопки в удаленной части приложения, которая на самом деле требуется только одному пользователю)
те же аргументы, что и в предыдущем вопросе
Если вы попытаетесь исправить приложение или повторно загрузите все приложение из царапать в стиле Macintosh?
если размер приложения небольшой, загрузите его с нуля. Это предотвратит всевозможные странные ошибки, созданные из-за несоответствия между различными патчами («ад DLL»). Однако это может потребовать длительного времени загрузки или привести к большим потерям в вашей сети.
Следует ли разрешать пользователям выполнять обновление из центра или разрешать обновление только через указанное приложение? (для закрытых бизнес-приложений).
Я думаю, что
Из практического опыта не забудьте добавить функциональность для обновления движка обновлений. Это означает, что выполнение обновления обычно представляет собой двухэтапный подход.
- Проверить, есть ли обновления для механизма обновления
- Проверить, есть ли обновления для реального приложения
Вы выполняете принудительное обновление, если клиенты программное обеспечение устарело, но не собирается ломаться при попытке общения с другой версией программного обеспечения или сама база данных? Если да, то как ты означает это критическое изменение?
Обычной практикой является наличие метода «ProtocolVersion», который указывает самую низкую / самую старую разрешенную версию.
«ProtocolVersion» может быть предоставлен клиентом или сервером в зависимости от вашего уровня доверия. между клиентом и сервером. При низком уровне доверия, вероятно, лучше, чтобы клиент предоставил «ProtocolVersion», а затем запретил доступ на стороне сервера до тех пор, пока клиент не будет обновлен. В сценарии с «высоким уровнем доверия» будет легче, если сервер предоставит «ProtocolVersion», который он принимает, а затем всю логику для адаптации к этому, включая обновление клиентского приложения, будет реализовано только в клиенте. Преимущество в том, что код проверки / обработки версии должен находиться только в одном месте.
- Никогда не пытайтесь принудительно выполнить обновление, если этого не требуют ваши юристы. Покажите пользователю уведомление об обновлении, которое он может принять или проигнорировать. Старайтесь не спамить одну и ту же версию слишком часто, если она ее отвергла. Помогите ей принять решение, включите ссылку на примечания к выпуску или краткое описание изменений.
- Еженедельно было бы хорошим интервалом проверки обновлений по умолчанию, но пусть пользователь выбирает его, включая полное отключение проверки обновлений через Интернет. Не проверяйте слишком часто, потому что, возможно, она пользуется дорогим тарифным планом мобильной передачи данных или ей просто не нравится идея, что приложение звонит домой.
- The update check part should be completely silent. If an update was found, display a notification for the user. During download and installation, show a progress bar.
- To keep this simple, notify the user about any newer version. If you do not want to annoy them with frequent updates including just a few minor bug fixes, do not release every minor version at the download location watched by the update checker
- Maintaining patches for all previously released versions is too much work. If the download size becomes a problem, figure out some other way than patches to make it smaller (7-zip compressed self-extracting exe, splitting the application to multiple MSI packages that have independent versions etc)
Two more things:
- Вы выполняете принудительное обновление, если клиентское программное обеспечение устарело, но оно не будет прерываться при попытке связи с другой версией программного обеспечения или сама база данных? Если да, то как вы обозначите это критическое изменение?
Спросите пользователя.
- Как часто вы должны проверять наличие обновлений? Еженедельно / ежедневно / ежечасно и почему?
Спросите пользователя.
- Должно ли обновление быть видимым для пользователя или запускаться за кулисами с точки зрения пользовательского интерфейса?
Спросите пользователя.
- Следует ли вам даже уведомить пользователя о наличии доступного обновления, если оно не является крупное обновление? (например, фиксация одной кнопки в удаленной части приложения, которая на самом деле требуется только одному пользователю)
Спросите пользователя (заметьте здесь тенденцию?).
- Следует ли вам пытаться исправить приложение или повторно загрузить все приложение с нуля в стиле Macintosh?
Как правило, патч, если приложение имеет какой-либо значительный размер.
Что касается ответов «спросить пользователя», это не означает, что всегда запрашивать их каждый раз время. Вместо этого дайте им опцию , чтобы указать, что им следует запрашивать, а что следует делать просто незаметно (и при первом возникновении данной вещи спросите их, что делать в будущем, и запомните это). Это не должно быть очень сложно, и вы получите большую поддержку от большей части вашей пользовательской базы, так как очень трудно установить фиксированные настройки, соответствующие желаниям всех, кто использует ваше приложение. В случае сомнений, больше вариантов лучше, чем меньше, особенно когда это вариант, который довольно легко кодировать.