Control WebBrowser como interfaz de usuario

Question

Primero algunas definiciones para mantener las cosas claras.

usuario: una persona viva, utilizando el software

Cliente: Una empresa que está pagando por una versión personalizada de nuestro software para sus usuarios.

Actualmente tenemos algunas aplicaciones que requerirán cambios significativos en la interfaz de usuario según el cliente al que pertenece el usuario. Actualmente tenemos una compilación separada para cada cliente, pero a medida que aumenta el número de clientes, cada vez es más complicado gestionar todos esos lanzamientos por separado.

Mi objetivo es cambiar a un único cliente genérico que se puede personalizar dinámicamente en función de quién inicia sesión. Dado que nuestro software requiere una conexión a Internet de todos modos (utiliza servicios web extensamente) estaba contemplando usar un control WebBrowser en .NET y permitiéndole interactuar (a través de ObjectForScripting) con el hardware requerido en la computadora.

Luego toda la interfaz de usuario está escrita en HTML/JavaScript y almacenada en el servidor, lo que hace que la distribución y el mantenimiento de las nuevas interfaces de usuario sean triviales. El cliente genérico es poco más que un navegador web personalizado que sabe cómo hablar con nuestros dispositivos de hardware y se le puede decir que lo haga a través de JavaScript.

Estoy viendo muchas ventajas en este enfoque y no demasiadas desventajas. ¿Qué me estoy perdiendo? ¿Por qué NO debo ir en esta dirección?

Answer 1

Existen algunas aplicaciones comerciales que utilizan este enfoque con éxito. Las siguientes son algunas consideraciones a tener en cuenta. Esto no debería impedir que intentes el acercamiento de todos modos. Sin embargo, una pregunta clave que debe hacerse es si la aplicación podría ser una aplicación web nativa.

• El control del navegador web "come pestañas". Puede usar la tecla de tabulación para mover el foco de entrada al control del navegador desde la aplicación de alojamiento, pero no puede salir de ella (a menos que codifique explícitamente)

• Las aplicaciones HTML/Javascript tienen un solo hilo. Si necesita algún procesamiento en segundo plano, es posible que deba delegar esa tarea en la aplicación de alojamiento.

• Si se producen condiciones de error dentro del control del navegador web, se tratan como errores de script y se encuentran dentro del control. La contención es algo bueno. Pero es posible que ni siquiera se dé cuenta de que se ha producido una condición de error al compilar/depurar.

• Si no hay conectividad de red, los usuarios pueden ver la página de fallas del navegador. No puede adelantarse a eso y mostrar su propio mensaje.

• Dependiendo de su aplicación y de cómo se implemente, la navegación puede parecer más lenta de lo habitual en las aplicaciones de escritorio. La página se recarga en particular. El uso cuidadoso de AJAX asíncrono puede ayudar a aliviar parte o la totalidad de eso.

• Sus usuarios sabrán que están trabajando con una página web. El diseño de la interfaz de usuario por sí solo no podrá ocultar ese hecho. La receptividad y el fracaso ocasional revelarán ese hecho. Esto puede o no ser un problema para usted.

• Su aplicación tendrá que ser compatible con varias versiones de navegador. El control del navegador web .NET es un envoltorio alrededor de la implementación de Internet Explorer en la máquina del usuario. Eso sería IE6, 7, 8, etc. dependiendo de lo que está instalado allí.

Answer 2

Si no está perdiendo funciones significativas de interfaz de usuario al cambiar a la interfaz web, no veo por qué esta no es una gran solución.

Answer 3

Parece una gran solución, en realidad. Sin embargo, una cosa viene a la mente:

¿Por qué no cambiar a una aplicación web completa? ¿Hay ciertas cosas que solo puedes hacer desde el lado del cliente fuera de un navegador? Porque si no es así, probablemente simplificará mucho los escenarios de implementación simplemente haciendo que todo sea una aplicación web.

Answer 4

Depende del tipo de aplicación, pero no veo por qué no podría funcionar. Posibles desventajas: tiene que trabajar en HTML y JavaScript, el componente WebBrowser depende de la versión de Internet Explorer instalada (no siempre es la misma), la interfaz de usuario no es realmente nativa y probablemente se sienta como una aplicación web (no tiene por qué ser una desventaja). Si estoy en lo cierto, creo que la interfaz de usuario de Microsoft Money se basó por completo en un control WebBrowser.

Answer 5

No recomendaría usar el control WebBrowser, si necesita implementar cualquier funcionalidad compleja. Las desventajas son:

• Su comportamiento depende de la versión de IE instalado, y la configuración de Internet Explorer, pero no es idéntica a la 'real' de IE. Vi algunos casos, cuando la funcionalidad de JS funcionaba en un IE independiente, pero no funcionaba en un control WebBrowser sin una razón obvia (y por lo tanto sin posibilidad de solucionarlo).

• Es difícil personalizar la IU (modifique el menú contextual, realice algunos manejadores de eventos complejos), ya que el control no expone mucho de sí mismo. Por lo tanto, podría ser irrazonablemente difícil hacerlo interactuar con el medio ambiente de la manera que lo necesita.

Se podría considerar el uso de una solución completamente basada en web, trabajando en un navegador independiente - al menos es mucho menos probable que encuentre un fallo raro allí. Se podría usar un applet o un control ActiveX para interactuar con el hardware.

Otra opción es desarrollar un thin client como una aplicación de Windows, que de alguna manera se configuraría en función del usuario. Si aún necesita insertar un navegador, podría usar Gecko (el motor de Mozilla) o WebKit (el motor de Chrome). No tengo experiencia práctica con ellos, pero probablemente tengan más consistencia entre las versiones integradas y las independientes. .

Answer 6

¿No le daría WPF las ventajas de despellejar fácilmente a diferentes usuarios mientras conserva los ricos beneficios de UI?