phone para gratis desde descargar aplicaciones actualizar wcf architecture windows-mobile mobile

wcf - para - windows phone descargar



Desarrollo de Windows Mobile: ¿por dónde empezar? (16)

" 24 horas de desarrollo de aplicaciones móviles de Windows " del blog del equipo de Windows Mobile tiene algunos buenos recursos

De acuerdo, en breve comenzaré a seguir el camino del desarrollo móvil de Windows. No sé nada sobre el tema en realidad y estoy buscando personas con experiencia que me informen de cualquier problema que puedan conocer.

En este momento ni siquiera tengo una breve descripción de lo que se requiere, pero la suposición es que la aplicación será muy poco más que un montón de formularios CRUD para actualizar los datos. El único otro conocimiento que tengo es que la aplicación necesitará admitir almacenamiento sin conexión cuando no haya señal disponible. Esto, a su vez, obviamente requerirá algún tipo de sincronización cuando la señal regrese.

Mi idea inicial es que la aplicación será principalmente una interfaz para interactuar con una capa de servicio web. ¿Asumo que WCF será una tecnología apropiada para construir estos servicios? También pensé que SQL Server CE sería una buena ruta para reducir los problemas de almacenamiento sin conexión.

Cualquier conocimiento que considere útil en este dominio sería apreciado. Consejos, enlaces, libros, cualquier cosa apreciada.

EDITAR: Se ha notado que hay dos maneras de ir con la sincronización fuera de línea. Para utilizar alguna forma de puesta en cola de mensajes o para usar herramientas de sincronización de SQL. ¿Alguien podría ofrecer una buena comparación e introducción a estos?

EDIT 2: Después de un poco más de excavación me da la impresión de que básicamente hay 3 enfoques diferentes que puedo usar aquí:

  1. Emmbeded Database para consultar en contra de la sincronización en línea, cuando pueda
  2. MSMQ junto con .NET remoto
  3. WCF con enlaces de ExchangeWebServiceMailTransport utilizando Exchange Server.

Ahora, se han planteado algunos buenos puntos en el primer número, y creo que entiendo en algún nivel los problemas que enfrentaré. Pero me gustaría obtener un poco más de información sobre las implementaciones de MSMQ y el uso de nuevas vinculaciones de WCF.

"Sincronización de documentos": ¿eso significa bidireccional? ¿O acumulativo solo de escritura? Puedo pensar en arquitecturas móviles que principalmente recolectarían y enviarían transacciones para un documento compartido; si ese es su requisito, entonces deberíamos discutir sobre fuera de línea, es una conversación larga (e interesante).

Agregaré una pregunta adicional a esta publicación, ya que ha sido lo suficientemente activa y espero que sea útil para otros y para mí. Bien, entonces, después de jugar, ahora me doy cuenta de que las bibliotecas de clase estándar no se pueden incluir en las aplicaciones de Windows Mobile.

Ahora, el consejo abrumador aquí parece ser el uso de una base de datos incrustada, aunque ahora tengo casos de uso y parece que necesitaré tener sincronización de documentos y datos relacionales. Con esto en mente, la interacción de la capa de servicio parece inevitable. Entonces mi pregunta es ¿cómo podría compartir objetos de dominio comunes e interfaces entre las capas?

Aquí algunas palabras de mi experiencia hasta ahora (alrededor de 9 meses) del desarrollo de .net Windows Mobile.

  1. Bueno, ocasionalmente estás conectado. (O más probablemente ocasionalmente desconectado). Debe elegir si va a utilizar la mensajería con colas (es decir, WCF / SOAP / XML o algo similar) o la sincronización de la base de datos. Elijo la ruta de sincronización SQL, así que no puedo comentar sobre la mensajería. ¡La ruta de sincronización SQL no está libre de problemas!

  2. Si bajas la ruta de sincronización con SQL Compact como yo, básicamente tienes dos opciones. SQL Server fusiona la replicación o los servicios más nuevos de ADO.NET Synchronization. Si elige lo primero, debe tener mucho cuidado con el diseño de su base de datos para asegurarse de que pueda dividirse fácilmente entre los suscriptores de dispositivos móviles y el editor. Realmente necesita pensar en conflictos, y dividir tablas que normalmente no se dividirían en un diseño de BD normalizado es una forma de hacerlo. Debe tener en cuenta situaciones en las que un dispositivo se desconecta durante un tiempo y el DB editor (es decir, el DB principal) y / o un suscriptor altera los mismos datos. ¿Qué sucede cuando el dispositivo vuelve a estar en línea? Puede significar resolver conflictos incluso si ha dividido bien las cosas. Aquí es donde me quemé. Pero SQL Merge Replication puede funcionar bien y reduce la cantidad de código que tiene que escribir.

  3. Tira tu propio DAL. No intente usar datareaders, etc. directamente desde el código de UI y tampoco use conjuntos de datos tipeados. Puede haber DAL de terceros que funcionen con Windows Mobile (es decir, sé que LLBLGEN sí, podría valer la pena) pero Linq-to-SQL no es compatible y de todos modos necesita algo ligero. Lo más probable es que el DAL no sea demasiado grande, así que arrástralo tú mismo.

  4. Si está utilizando .net probablemente terminará queriendo algunas características de plataforma no implementadas. Recomiendo usar este marco de bajo costo para darle lo que le falta (especialmente en lo relacionado con la conectividad y la administración de energía) - http://www.opennetcf.com/Products/SmartDeviceFramework/tabid/65/Default.aspx

  5. Los dispositivos con Windows Mobile se apagan parcialmente para ahorrar energía cuando no están en uso. Si está haciendo un diseño tipo encuesta, tendrá que activarlos cada x minutos. Una clase normal de temporizador .net no hará esto. Tendrá que utilizar una función de plataforma que se puede utilizar desde OpenNetCF (arriba). La clase de temporizador se llama LargeIntervalTimer y está en el ensamblado / espacio de nombres OpenNetCF.WindowsCE (creo).

¡Buena suerte!

No debe sentirse intimidado por el desarrollo de Windows Mobile. No es muy diferente del desarrollo de escritorio. Recomiendo encarecidamente que use .NET Compact Framework para desarrollo y no C ++ / MFC.

Algunos enlaces útiles:

  • Sección móvil en Code Project. Encontrarías muchos artículos, se necesita un poco de excavación para encontrar el adecuado.
  • Smart Device Framework de OpenNetCF ofrece valiosas extensiones para el marco compacto.
  • Cuando instale Mobile SDK, encontrará debajo de los enlaces de la carpeta de la comunidad para los blogs del marco de Windows Mobile y CF. Estos también son recursos valiosos.

En cuanto a su aplicación, tiene razón acerca de WCF y SQL Server CE. Estas son las formas adecuadas para manejar la comunicación y el almacenamiento.

Algunos consejos para personas que provienen de un mundo de escritorio:

  • Necesita tener algún tipo de administración de energía. El dispositivo puede pasar automáticamente al estado de suspensión. Además, no debería consumir energía cuando no sea necesario.
  • La conectividad de red es un problema difícil. Puede registrar notificaciones para cuando una red específica (Wi-Fi, GPRS) esté disponible o no disponible. También puede establecer los medios de comunicación preferidos.
  • Haz que la IU sea lo más simple posible. El usuario usa su pulgar y / o un bolígrafo y probablemente esté en movimiento.
  • Pruebe en un dispositivo real lo antes posible.

Owen puede compartir código desde Compact Framework -> Desktop, es solo Desktop -> Compact Framework que tiene problemas de compatibilidad si utiliza ciertos objetos que no son compatibles con CF.

Mientras que una lib de escritorio no funciona en CF, una libra CF FUNCIONARÁ en el escritorio, ¡también puede ejecutar CF.exes en el escritorio!

Simplemente cree una biblioteca CF como el proyecto que define sus objetos / interfaces básicos, etc.

Para desarrollar aplicaciones móviles de Windows , debe tener las herramientas básicas como Silverlight, Visual Studio, Windows Phone Emulator y sqlite como su almacenamiento de base de datos.

Para el bit de replicación de la base de datos, recomiendo Sybase Ultralite . En términos de flexibilidad y rendimiento, golpea los calcetines de SQL CE

Si puede, trate de comenzar desde los casos de uso del usuario y vuelva al código, en lugar de viceversa. Es realmente fácil dedicar más tiempo a trabajar en las herramientas que a trabajar en el problema comercial. Y pensar a través de los requisitos de los usuarios lo ayudará a considerar estrategias alternativas, porque muchos de los patrones que usted conoce de .NET normal no se aplican.

He hecho muchos desarrollos de aplicaciones intermitentes exactamente del tipo que está describiendo, y una base de datos integrada funciona bien. Las cosas de MSMQ / WCF solo agregan una sobrecarga conceptual sin agregar mucho valor. De todos modos, necesita un almacén de datos lógico localmente, y la replicación en este nivel es un concepto simple que desea mantener simple, por lo que el seguimiento de auditoría se supervisa y depura fácilmente. MSMQ y WCF tienden a ocultar cosas en lugares desconocidos.

Volví a subir la sugerencia de SqlLite por cierto. MS no tiene su historia de persistencia estabilizada aún para CE.

SqlCE es solo una de las opciones disponibles para el almacenamiento local de datos en un dispositivo con Windows Mobile, y aunque es una excelente base de datos, tiene limitaciones. Por un lado, SqlCE no funcionará (período) bajo cifrado (en otras palabras, si el usuario encripta la ubicación donde se encuentra su archivo SDF, ya no podrá acceder a los datos).

La segunda (y más crítica) debilidad de SqlCE se encuentra en las herramientas RDA / Combinar replicación. SqlCE Merge Replication no es 100% confiable en situaciones donde la conexión de red puede caer durante la replicación (obviamente muy común en dispositivos con Windows Mobile). Si le gusta tratar de explicar datos perdidos o dañados a sus clientes, siga adelante y utilice SqlCE y fusione la replicación.

Oracle Lite es una buena alternativa a SqlCE, aunque tampoco funciona correctamente bajo cifrado. Si el cifrado es un problema potencial, debe encontrar un motor de base de datos que funcione bajo cifrado (no sé de uno) o escriba su propio componente de persistencia utilizando XML o algo así.

Escribir una aplicación WM como interfaz que interactúa principalmente con un servicio web en tiempo real solo funcionará en un entorno siempre conectado. Un mejor enfoque es escribir su aplicación como una interfaz que interactúa principalmente con datos locales (SqlCE, Oracle Lite, XML o lo que sea), y luego crear un componente de sincronización separado que maneje empujar y tirar datos.

Una vez más, la duplicación de combinación SqlCE hace que esto empuje y tire bella y elegantemente, simplemente no funciona todo el tiempo. Si desea un mecanismo de replicación que funcione de manera confiable, tendrá que escribir el suyo. Oracle Lite tiene algo llamado tabla de instantáneas que funciona muy bien para este propósito. Una tabla de instantáneas en Olite rastrea los cambios (como las adiciones, actualizaciones y eliminaciones) y le permite consultar los cambios por separado y actualizar la base de datos central (a través de un servicio web) para que coincida.

Sugeriría Sqlite para el almacenamiento local. Desde el último punto de referencia que ejecuté fue mucho mejor que SqlCe y no tienes que hacer cosas estúpidas como mantener una conexión abierta para mejorar el rendimiento.

Las compensaciones son que el conjunto de herramientas es menos rico y la integración con otros productos MSSql es nula. :(

Tuve que hacer esto una vez. Configuración extraña con Mac para el desarrollo, y todos éramos programadores de Java. Y una breve fecha límite. PowerPC Macs también, por lo que no hay posibilidad de instalar Windows para el desarrollo de Visual Studio, no importa que el dinero para esto nunca hubiera aparecido.

Terminamos escribiendo aplicaciones usando Java, ejecutándose en la máquina virtual IBM J9, con SWT para una interfaz de usuario. Pila de desarrollo completamente libre. Fácil de implementar El código se ejecutaba en cualquier plataforma que deseáramos, no solo en PocketPC / WinMob.

La mayor parte del trabajo estaba en el lado del servidor de todos modos: la base de datos, el servidor del servicio web. La lógica. El motor de informes Sin embargo, el lado del cliente no era totalmente simple: obtendría las plantillas de formulario del servidor (porque cambiaban frecuentemente), los detalles del sitio (implementación en múltiples sitios), generaba una UI a partir de la plantilla del formulario (usando algunos componentes GUI de SWT que son maravilloso para el desarrollo de Pocket PC, como ExpandBar), recopilar datos con una interfaz de apuntar y hacer clic (minimizando la entrada del teclado cuando sea posible), y luego enviarlo de vuelta al servidor.

Para el almacenamiento fuera de línea, utilizamos archivos XML en el dispositivo. Más que suficiente para nuestras necesidades, pero las suyas pueden diferir. Tal vez considere SQLite?