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 o cualquier otra cosa parecida (con 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, 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 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: [email protected] [mailto:[email protected]] 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
