Jajaja, no era que te demoraste en leerlo, es que estas escribiendo desde ayer la respuesta no ?????
Abrazo JAE 2009/6/25 Carlos A. Pérez <logic...@arnet.com.ar> > Ey sorry por la demora. > > > > Esencialmente, de acuerdo a lo que vos me contestes, te digo > > 1. Si existe conexión directa siempre con la red de datos, ya sea > Wifi o por red celular > > a. Se puede utilizar una aplicación de internet, páginas hechas con > ASP.NET <http://asp.net/> o cualquier otra cosa parecida (con > ASP.NET<http://asp.net/>y Visual Studio 2008 es DEMASIADO FACIL) > > b. Se puede desarrollar un cliente pesado a bordo del dispositivo. Si > es una PocketPC, podes desarrollar algo en .NET Compact Framework. Si es un > Blackberry, bueno, en Java Micro Edition, y así. El tema acá pasa por saber > qué mecanismo de conexión se utiliza para grabar los datos > > i. Si > es WiFi, podes utilizar la conexión directa al SQL Server utilizando la > clase SqlClient() de .NET CF, para ello el dispositivo se comporta como un > cliente más del gestor central, y necesitas usar los puertos 1433, etc. > > ii. Si > es red celular de datos (GPRS, etc.) , entonces lo anterior no es muy > válido, porque equivaldría a exponer el servidor SQL a la internet, con sus > puertos abiertos, no es buena idea. Para ello, te recomendaría utilizar un > web service desde el lado del servidor, que genere los datasets, te los pase > por servicio web, vos los tomás y sin necesidad de transformarlos > (castearlos) los consumís directamente en tu aplicación, porque en ambos > lados tenes ADO.NET <http://ado.net/>, los datasets son clases homogéneas > en escritorio como en móvil, si bien son medio pesadas, en este caso las > ventajas pueden sobrepasar las limitaciones. Para grabarlo, por el mismo > servicio web podrías enviar de vuelta el dataset. > > iii. Pegale > un vistazo a ADO.NET <http://ado.net/> Synchronization services. > > 2. Si NO existe conexión permanente a la internet, te digo > > a. Necesitas desarrollar un cliente pesado a bordo. Como la conexión > es intermitente, no podes utilizar páginas web ni tampoco acceso directo al > SQL Server. La pregunta es entonces que hacés para sincronizar datos > > i. El > cliente pesado deberá poder grabar los datos localmente. Lo puede hacer con > un gestor de bases de datos embebido como el SQL Server CE para .NET CF, o > bien gestionar la grabación en archivos de texto, XMLs, etc. > Particularmente, es muy atractiva la idea de trabajar con datasets en > memoria y después grabarlos con sus métodos WriteXML() y leerlos con > ReadXML(), porque nos evita muchos problemas a la hora de persistir > localmente, aunque las clases datasets son un poco pesadas. En algun momento > del ciclo de operación deberá tener contacto con el repositorio central de > datos. Si utilizas Web services para sincronizar, del otro lado puede haber > MySQL, SQL server express, etc. > > ii. El > uso de SQL Server CE para persistencia local tiene la ventaja que permite > sincronizar directamente con SQL Server Enterprise en la modalidad merge- > replication o bien push-pull (RDA, remota data Access). Sin embargo, esto > implica colocar un servidor IIS , y un gestor SQL Server Enterprise que > admita ser origen de publicación, esto tiene costo, aunque la configuración > es rapidísima (20 minutos). Mirá en mi blog > http://www.logica10mobile.blogspot.com que hay tutoriales paso a paso de > cada cosa que te digo respecto de esta sincronización. En el caso de > utilizar SQL Server CE a bordo de cada dispositivo, (es gratuito, lo que es > pago es el gestor central SQL Enterprise), podes utilizar la clase mucho más > liviana SQLResultSet, que es esencialmente una ventana deslizante sobre la > tabla física, es como un cursor de doble barrido del lado del servidor, sólo > que el servidor (SQL Server CE) está embebido en el cliente: como ningun > sistema operativo móvil puro tiene el concepto de servicios, no se puede > hablar de servicios de datos. Lo que existe es un motorcito de bases de > datos SQL Server CE que es una DLL de .NET que se sube dentro del dominio de > la aplicación .NET corriendo en el dispositivo, por eso se llama “gestor de > base de datos en proceso”, es como si fuese un componente COM que se suma al > espacio de memoria del proceso llamador. No existe ningún equivalente a esto > en el mundo móvil de la competencia, al estar en proceso la comunicación es > sumamente rápida, y en 1.3 MB entra un gestor completo de RDMBS , con > soporte para T-SQL, y un pequeño optimizador de acceso. > > > > En resumen, si tenes conectividad 100% del ciclo operativo, podes grabar > directamente contra el repositorio central. Sino , tenes que crearte una > forma de persistencia local de datos, y en una ventana del tiempo de > operación, deberás tener conexión y visibilidad de la fuente central de > datos. En ambos casos, el uso de web services puede funcionar, aunque se > reporta cierta lentitud en instanciar el proxy y las clases de > encapsulamiento del lado del móvil (el startup time es una maldición para > todos los sistemas operativos móviles). > > > > Respecto de la productividad, no hay con qué darle a Visual Studio 2008 en > lo que respecta a movilidad. Hoy por hoy podes desarrollar completamente la > aplicación utilizando el emulador, incluyendo la conexión a las bases de > datos SQL CE, la sincronización contra SQL Server Enterprise, etc. Como los > chicos de mobile y .NET CF respetaron la metáfora de desarrollo de .NET, > tiene mucho en común con el desarrollo de aplicaciones winforms para > escritorio. > > > > Si pensás en el iPhone, te diría que sería bueno para utilizar el modo > conectado 100%, pero aquí podrías obtener el mismo resultado con un Nokia > 5800 o algo así, o incluso una PDA que no sea teléfono, como la serie 100 de > HP que anda joyamente. En definitiva, cualquier PDA o móvil con un browser > decente puede consumir páginas web para cargar datos, pero exige conexión > 100%. > > Por otro lado, si vas a utilizar cliente pesado, cuidado con el IPhone. Por > ejemplo, su sistema operativo es un Mac OS/X Leopard venido a menos, es > decir , portado a móvil (recortado y recompilado), mientras que Windows > Mobile y Symbian son sistemas operativos creados desde cero, para movilidad > exclusivamente. Desde este punto de vista, deberías desarrollar en Java > Micro Edition para el iPhone, el Blackberry, etc. y según otros colegas de > otras partes del mundo, la curva de productividad es mucho menor que con > VS+.NET. > > > > Espero haber sido de utilidad > > > > Carlos A. Pérez > > Microsoft MVP Devices App Development > > > > > > *De:* GUFA@mug.org.ar [mailto:g...@mug.org.ar] *En nombre de *SERGIO > FABIAN IBARRA > *Enviado el:* miércoles, 24 de junio de 2009 12:17 > *Para:* GUFA List Member > *Asunto:* [GUFA] [OT] palms - wifi > > > > Hola gente, me encargaron un proyecto: > > Un pub quiere que se carguen los pedidos a traves de palms (o similar) en > linea y obiamente inalámbricamente. > Alguien me pude tirar una idea, es decir hay muchos modelos de palms o > colectoras de datos que usan distintos SO. > Nunca he desarrollado nada para este tipo de aparatos. > > Saludos! > Gracias. > ------------------------------ > > Tus elecciones hablan por vos. ¡Conocé quién sos > realmente!<http://www.descubrewindowslive.com/> > > __________ Información de ESET NOD32 Antivirus, versión de la base de > firmas de virus 4184 (20090624) __________ > > ESET NOD32 Antivirus ha comprobado este mensaje. > > http://www.eset.com > > > __________ Información de ESET NOD32 Antivirus, versión de la base de > firmas de virus 4188 (20090625) __________ > > ESET NOD32 Antivirus ha comprobado este mensaje. > > http://www.eset.com >
