Contrôle WebBrowser en tant qu'interface utilisateur

Question

D'abord quelques définitions pour garder les choses claires.

Utilisateur: Une personne en direct, en utilisant le logiciel

Client: Une entreprise qui paie pour une version personnalisée de notre logiciel pour leurs utilisateurs.

Nous avons actuellement quelques applications qui nécessiteront des changements significatifs dans l'interface utilisateur en fonction du client auquel l'utilisateur appartient. Nous avons actuellement une version distincte pour chaque client, mais à mesure que le nombre de clients augmente, il est de plus en plus difficile de gérer toutes ces versions distinctes. Mon objectif est de passer à un seul client générique qui peut être personnalisé dynamiquement en fonction de qui se connecte. Puisque notre logiciel nécessite une connexion internet (utilise beaucoup les services web), je pensais juste utiliser un contrôle WebBrowser dans .NET et lui permettant d'interagir (via ObjectForScripting) avec le matériel requis sur l'ordinateur.

Ensuite, toute l'interface utilisateur est écrite en HTML/JavaScript et stockée sur le serveur, ce qui rend la distribution et la maintenance des nouvelles interfaces utilisateur triviales. Le client générique est un peu plus qu'un navigateur Web personnalisé qui sait comment parler à nos périphériques matériels et peut être dit de le faire par javascript.

Je vois beaucoup d'avantages à cette approche et pas trop d'inconvénients. Qu'est-ce que je rate? Pourquoi ne devrais-je pas aller dans cette direction?

Answer 1

Il existe certaines applications commerciales qui utilisent cette approche avec succès. Voici quelques considérations à garder à l'esprit. Cela ne devrait pas vous empêcher de tenter l'approche de toute façon. Une question clé à se poser, cependant, est de savoir si l'application pourrait être une application web native à la place.

• Le contrôle du navigateur Web "mange les onglets". Vous pouvez utiliser la touche de tabulation pour déplacer le focus d'entrée dans le contrôle du navigateur à partir de l'application d'hébergement, mais vous ne pouvez pas en sortir (sauf si vous le codez explicitement)

• Les applications HTML/Javascript sont mono-thread. Si vous avez besoin d'un traitement en arrière-plan, vous devrez peut-être déléguer cette tâche à l'application d'hébergement.

• Si des conditions d'erreur se produisent dans le contrôle du navigateur Web, elles sont traitées comme des erreurs de script et sont contenues dans le contrôle. L'endiguement est une bonne chose. Mais vous pourriez même ne pas réaliser qu'une condition d'erreur s'est produite pendant la construction/le débogage.

• S'il n'y a pas de connectivité réseau, les utilisateurs peuvent voir la page d'échec du navigateur. Vous ne devez pas préempter cela et montrer votre propre message. En fonction de votre application et de sa mise en œuvre, la navigation peut sembler plus lente que ce qui est courant dans les applications de bureau. La page recharge en particulier. L'utilisation prudente d'AJAX asynchrone peut aider à atténuer tout ou partie de cela.

• Vos utilisateurs sauront qu'ils travaillent avec une page Web. La conception de l'interface utilisateur seule ne sera pas en mesure de cacher ce fait. La réactivité et l'échec occasionnel révéleront ce fait. Cela peut ou peut ne pas être un problème pour vous.

• Votre application devra supporter plusieurs versions de navigateur. Le contrôle de navigateur Web .NET est un wrapper autour de l'implémentation Internet Explorer sur la machine de l'utilisateur. Ce serait IE6, 7, 8, etc. selon ce qui est installé là-bas.

Answer 2

Si vous ne perdez pas de fonctionnalités d'interface utilisateur importantes en passant à l'interface Web, je ne vois pas pourquoi ce n'est pas une excellente solution.

Answer 3

Cela ressemble vraiment à une excellente solution. Une chose vient cependant à l'esprit:

Pourquoi ne pas simplement passer à une application Web complète? Y a-t-il certaines choses que vous ne pouvez faire que côté client en dehors d'un navigateur? Parce que si ce n'est pas le cas, vous allez probablement simplifier considérablement vos scénarios de déploiement en faisant simplement du tout une application Web.

Answer 4

Cela dépend du type d'application, mais je ne vois pas pourquoi cela ne pourrait pas fonctionner. Inconvénients possibles: vous devez travailler en HTML et JavaScript, le composant WebBrowser dépend de la version d'Internet Explorer installée (pas toujours la même chose), l'interface utilisateur n'est pas vraiment native et se sentira probablement comme une application web (ne doit pas être un désavantage). Si je me trompe, je pense que l'interface utilisateur de Microsoft Money était entièrement basée sur un contrôle WebBrowser.

Answer 5

Je ne recommanderais pas d'utiliser le contrôle WebBrowser si vous devez implémenter des fonctionnalités complexes. Les inconvénients sont les suivants:

• Son comportement dépend de la version d'IE installée et des paramètres IE, mais n'est pas identique à l'IE réel. J'ai vu des cas où la fonctionnalité JS fonctionnait dans un environnement d'exploitation autonome, mais ne fonctionnait pas dans un contrôle WebBrowser sans raison apparente (et donc sans aucune chance de la réparer).

• Il est difficile de personnaliser l'interface utilisateur (modifier le menu contextuel, créer des gestionnaires d'événements complexes), car le contrôle n'expose pas une grande partie de lui-même. Donc, il pourrait être déraisonnablement difficile de le faire interagir avec l'environnement de la manière dont vous avez besoin.

Vous pourriez envisager d'utiliser une solution entièrement basée sur le Web, en travaillant dans un navigateur autonome - au moins vous êtes beaucoup moins susceptibles de trouver un bug rare là-bas. Une applet ou un contrôle ActiveX pourrait être utilisé pour interagir avec le matériel.

Une autre option consiste à développer un client léger en tant qu'application Windows, qui se configurerait d'une manière ou d'une autre en fonction de l'utilisateur. Si vous avez encore besoin d'intégrer un navigateur, vous pouvez utiliser Gecko (le moteur de Mozilla) ou WebKit (le moteur de Chrome) - Je n'ai aucune expérience pratique avec eux, mais ils ont probablement plus de cohérence entre les versions embarquées et autonomes .

Answer 6

WPF ne vous donnerait-il pas les avantages de skinning facile pour différents utilisateurs tout en conservant les avantages de l'interface utilisateur riches?