D'abord quelques définitions pour garder les choses claires.
Utilisateur: une personne en direct, à l'aide du logiciel
Client: une entreprise qui paie pour une version personnalisée de notre logiciel pour ses utilisateurs.
Nous avons actuellement quelques applications qui nécessiteront des modifications importantes dans l'interface utilisateur basée sur le client que l'utilisateur appartient. Nous avons actuellement une construction distincte pour chaque client, mais autant que le nombre de clients augmente, il devient plus mal à gérer toutes ces versions distinctes.
Mon objectif est de basculer sur un seul client générique pouvant être personnalisé de manière dynamique sur la base de qui se connecte. Puisque notre logiciel nécessite une connexion Internet de toute façon (utilise de manière approfondie desservices), je envisageais simplement d'utiliser un contrôle WebBrowser et lui permettant d'interagir (via ObjectForCripting) avec le matériel requis sur l'ordinateur.
Ensuite, l'ensemble de l'interface utilisateur est écrit en HTML / JavaScript et stocké sur le serveur effectuant une 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 parler à nos périphériques matériels et peut être dit de le faire via JavaScript.
Je vois beaucoup d'avantages à cette approche et pas trop d'inconvénients. Qu'est-ce que je rate? Pourquoi devrais-je ne pas aller dans cette direction?
6 Réponses :
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.
Cela ressemble à une excellente solution, en fait. Une chose vient à l'esprit, bien que:
Pourquoi ne pas simplement passer à une application Web complète? Y a-t-il certaines choses que vous ne pouvez faire que du client à l'extérieur d'un navigateur? Parce que sinon, vous obtiendrez probablement vos scénarios de déploiement fortement simplifiés en faisant simplement une application Web.
Il a du matériel personnalisé qu'il veut interagir avec.
Ahh, j'ai raté cette partie. Ma faute. Pourtant, cela ressemble à une solution décente.
Cela dépend du type d'application, mais je ne vois pas pourquoi cela ne pouvait pas fonctionner. Inconvénients possibles: vous devez travailler dans HTML et JavaScript, le composant WebBrowser dépend de la version Internet Explorer installée (pas toujours la même), l'interface utilisateur n'est pas vraiment originale et ressentira probablement une application Web (ne pas avoir à être un inconvénient). Si j'ai raison, je pense que l'interface utilisateur de Microsoft Money était entièrement basée sur un contrôle WebBrowser.
Avoir l'interface être HTML et JavaScript et CSS peuvent également être un avantage énorme. Certaines choses sont beaucoup plus faciles, par exemple en combinant un bouton d'image et un lien d'URL en un; En C # / Winforms, cela pourrait être inutilement difficile; En HTML, il s'agit simplement d'éliminer les balises intérieures .
Il existe des applications commerciales qui utilisent cette approche avec succès. Voici quelques considérations à garder à l'esprit. Ceux-ci ne devraient pas vous empêcher de tenter l'approche de toute façon. Une question clé à poser, cependant, est de savoir si l'application pourrait être une application Web natale.
Le contrôle du navigateur Web "mange des onglets". Vous pouvez utiliser la touche d'onglets pour déplacer la mise au point d'entrée dans la commande du navigateur à partir de l'application d'hébergement, mais vous ne pouvez pas vous en sortir (sauf si vous ne code pour cela explicitement)
Les applications HTML / JavaScript sont uniques à filetage. Si vous avez besoin d'un traitement des antécédents, vous devrez peut-être déléguer cette tâche à l'application d'hébergement.
Si les conditions d'erreur se produisent dans le contrôle du navigateur Web, elles sont traitées comme des erreurs de script et sont contenues à l'intérieur du contrôle. Le confinement est une bonne chose. Mais vous ne réaliserez peut-être même pas qu'une condition d'erreur s'est produite lors de la construction / du débogage.
S'il n'y a pas de connectivité réseau, les utilisateurs peuvent voir la page d'échec du navigateur. Vous ne pouvez pas préempter cela et montrer votre propre message.
Selon votre application et la manière dont elle est implémentée, la navigation peut sembler plus efficace que celle commune dans les applications de bureau. Recharge de la page en particulier. Une utilisation minutieuse de l'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'UI seul ne sera pas capable de cacher ce fait. La réactivité et l'échec occasionnel divulgueront ce fait. Cela peut ou non être un problème pour vous.
Votre application devra prendre en charge plusieurs versions de navigateur. Le contrôle du navigateur Web .NET est un wrapper autour de la mise en œuvre de l'explorateur Internet sur la machine de l'utilisateur. Ce serait ie6, 7, 8, etc. Selon ce qui est installé là-bas.
Soutenir plusieurs versions IE ne devrait pas être un problème. Nous ne ferons rien de très délicat avec le HTML / CSS. La plupart des pages seraient extrêmement simples et font un peu plus d'affichage un formulaire. Une seule correction à votre message, nous pouvons détecter s'il n'y a pas de connexion réseau et nous ne pouvons pas afficher le contrôle WebBrowser ou nous pouvons transmettre une chaîne / fichier local contenant l'erreur HTML.
Timothée, génial! Heureux d'entendre que votre HTML / CSS fonctionne bien avec les versions correspondantes de IE. Notez que les conditions de défaillance du navigateur qui entraînent des pages d'erreur pourraient être plus subtiles. La connectivité peut être intermittente, le serveur peut être en panne, l'application peut être sur le serveur, le serveur peut renvoyer des erreurs HTTP 500, le serveur peut être chronométré de manière sporadique en raison de la charge, etc. à nouveau, ne devrait pas vous empêcher, etc. juste appeler la question
Je ne recommanderais pas d'utiliser le contrôle WebBrowser si vous devez implémenter une fonctionnalité complexe. Les inconvénients sont:
Son comportement dépend de la version IE installée et des paramètres IE, mais n'est pas identique à "réel". J'ai vu certains cas, lorsque la fonctionnalité JS a travaillé dans un autonome, c'est-à-dire, mais ne fonctionnait pas dans un contrôle WebBrowser sans une raison évidente (et donc sans aucune chance de le réparer).
Il est difficile de personnaliser l'interface utilisateur (Menu d'alter contextuel, faites 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'envioploi de la manière dont vous avez besoin.
Vous pouvez envisager d'utiliser une solution entièrement basée sur le Web, travailler dans un navigateur autonome - au moins vous êtes beaucoup moins susceptible de trouver un bogue peu commun. Un 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 configurait en quelque sorte en fonction de l'utilisateur. Si vous avez toujours besoin d'intégrer un navigateur, vous pouvez utiliser Gecko (moteur de Mozilla) ou WebKit (moteur de Chrome) - Je n'ai aucune expérience pratique avec eux, mais ils ont probablement plus de consistance entre les versions intégrées et autonomes .
Je devrai examiner à nouveau dans les plug-ins ActiveX et Browser, mais j'ai un sentiment d'exposition d'accès au matériel via les plugins / ActiveX Controls va être plus de problèmes que la solution de navigateur personnalisée. Ce serait beaucoup, beaucoup plus simple si Silverlight appuyait l'accès matériel.
Je pense que le contrôle WebBrowser par défaut sur une bibliothèque IE6, peu importe ce que l'utilisateur utilise normalement.
WPF ne vous donnerait pas les avantages de la cinglage facilement pour différents utilisateurs tout en conservant les riches avantages de l'interface utilisateur?