Sony Ericcson lanza un nuevo SDK Create XPERIA™ X1 Panels para Windows Mobile® 6.1

El 3 de septiembre (de 2008 para los anales de la historia) Sony Ericsson ha lanzado la BETA de su SDK para Windows Mobile, este SDK está pensado para que los desarrolladores podamos crear nuestros propios paneles XPERIA para nuestras aplicaciones.


 



SDK Sony Ericsson
 

 

  Estos paneles pueden ser escritos en nativo (c++) o en HTML y por lo que incluyen en su documentación se trata de una extensión basada en el Windows Mobile Today API de Microsoft. En la descarga de esta BETA podemos encontrar lo siguiente:

  • Emulador XPERIA X1

  • Plantillas para Visual Studio

  • Guía de desarrollo

  • Referencia del API

  • Tutoriales

  • Ejemplos de código
 Podemos encontrar este SDK en la web de Sony Ericsson o directamente en este enlace: Sony Ericsson Beta SDK for Windows Mobile® 6.1 (v1.0.3) (9.1 MB) 

Cabe destacar que lo primero que debemos hacer tras instalar el SDK es leernos detenidamente la Guía de configuración del emulador, ya que nos requerirá seguir algunos pasos antes de poder probar alguno de los ejemplos.
 
El principal problema que nos encontramos es que el emulador aparece de un tamaño descomunal (al menos con una resolución de 1280 X 768 de nuestro monitor) el emulador no entra en la pantalla. Y claro viendo la configuración del emulador nos encontramos con que el emulador está configurado para mostrarse con una pantalla de 480 x 800… Eso y que en esta versión beta no han implementado aún el mapeo de los hard buttons.


 

Pero para que podamos disfrutar un poquito de este emulador desde Mobile Nug he incluido una versión reducida del Skin del XPERIA, con los hard buttons ya enlazados, para utilizarla (pero ojo, ya sabeís que si quereis desarrollar para ese dispositivo debemos hacerlo a una resolución de 400 x 800).

 

Podeís descargaros el skin en el siguiente enlace:

 


 


Por otro lado tenemos que la guía de desarrollo lo único que hace es redirigirnos a las guías de los tutoriales, aunque la referencia del API está bastante bien.
 
Respecto al desarrollo de los paneles el único modo que tenemos para desplegarlos es si creamos nuestro panel con HTML (si no tenemos la suerte de tener un XPERIA) es creando el archivo de instalación y desplegándolo, lo que lo hace un poco tedioso, aunque es cuestión de acostumbrarse.
 
En conclusión se trata de una iniciativa muy bien acogida (que últimamente solo se oye hablar del i-phone de Apple).

Más información en:
www.developer.sonyericsson.com 
https://developer.sonyericsson.com/site/global/docstools/windowsmobile/p_windowsmobile.jsp

José Antonio Gallego


Mobile .NET Users Group


 

Como utilizar la camara de la PDA desde un tasklet


En determinado tipo de aplicaciones es necesario realizar capturas desde la cámara de nuestro dispositivo, y si pudiésemos remitir de una forma automatizada dichas fotos a nuestro ERP, fotos de entrega de mercancía, de las piezas a cambiar en nuestra aplicación de mantenimiento.

 

Creo que a estas alturas todos ya sabemos como utilizar la camara desde Windows Mobile, pero aquí lo que vamos a hacer es integrar dicha funcionalidad dentro de una aplicación de Dynamics Mobile.

 

 

Tasklet Camara

 

Aquí os dejo el artículo completo y la correspondiente solución, espero que os sea útil.

 


Como utilizar la camara de tu PDA en un Tasklet [ PDF 9 Páginas 424 KB (434.176 bytes)]

 

Solución de ejemplo [20,0 KB (20.480 bytes)]

 

!!Un saludo¡¡

José Antonio Gallego

Mobile .NET Users Group

Decalogo del factor humano en el desarrollo de software móvil

En estos últimos años me he dedicado precisamente a esto, a llevar funcionalidades del ERP a dispositivos móviles, y no me he llevado un batacazo… más bien han sido varios, en los cuales uno siempre intenta no volver a caer.


A la hora de acometer un proyecto de software móvil no te puedes centrar en lo meramente técnico, en que lenguaje utilizar, en que sistema operativo vas a basar tu desarrollo, en este tipo de proyectos tendemos a olvidarnos del factor humano, (si, esos seres bípedos que resultan ser los usuarios finales), por otro lado tenemos que tener encuentra que dispositivo se adecua más a su modo de trabajo y sobre todo a su entorno, en este post espero resumir lo más posible todos estos pequeños factores en lo que he querido llamar Decálogo de desarrollo móvil.


1º Un usuario no es un Geek 😉


Por mucho que nos empeñemos un usuario final de, por ejemplo, una aplicación de gestión de un matadero, no es precisamente un maquinitas, esto es importante a la hora de diseñar el interfaz de usuario, los nombres a utilizar y el TAMAÑO de los botones, en el caso de que el dispositivo a utilizar carezca de hardbuttons (ver el segundo mandamiento). Por lo tanto por mucho que nos empeñemos si creamos una aplicación difícil de manejar (con más de tres saltos de menú es sencillo que se pierdan) lo más probable es que el proyecto se alargue eternamente en el tiempo ya que los propios usuarios lo van a rechazar.


2º Dime que herramienta tienes y te diré como programarla.


Supongo que esto es mundialmente conocido pero es importante elegir el dispositivo antes de empezar a plantearse tirar una sola línea de código. Si vamos a trabajar en un entorno industrial es lógico (sentido común o como queráis llamarlo) que orientemos a nuestro cliente a elegir un dispositivo de este tipo, por ejemplo de Motorola/Symbol, Psion, Intermec, Datalogic… Es importante tener un conocimiento previo de estos equipos, suelen contar con sus propios SDKs de desarrollo (los cuales es muy importante a la hora de reducir tiempo de desarrollo y el famoso ciclo de reinventar la rueda)


MC70


El dispositivo depende del entorno (no quiero imaginarme una flamante Diamond como herramienta de trabajo en una cámara frigorífica), de la finalidad del programa (tampoco visualizo a un elegante comercial ataviado con un equipo industrial de medio kilo) así que ante la duda lo mejor es ponerse en contacto con los comerciales de alguna de las casas y en la mayoría de los casos tan solo es necesario aplicar como he dicho el sentido común.


También es importante destacar las características técnicas del dispositivo, si esta escaso de recursos deberíamos olvidarnos de programar con Compact Framework y optar por algo más «compacto» como c++


3º Dejar que los usuarios (FINALES) se acerquen a mi


Esta muy bien escuchar las ideas de los administrativos, gerentes, jefes de producción y del personal técnico de la empresa…. ¿Pero quién va a utilizar la aplicación? quien va a tener que estar día a día trabajando con lo que nosotros pobres artistas del software creemos, está claro, aquí aplicamos la solución al primer punto de este decálogo, es importante reunirse con al menos alguno de los usuarios finales del programa, lo más lógico no siempre es acudir al mas «avispado» sino al que mejor se lleve con los compañeros… (si lo se… suena un poco manipulador, pero no es lo que pensáis) la idea de formar, enseñar y co-diseñar (sí, he dicho co-diseñar) al que más trato tenga, es que esa persona os ahorrará horas de trabajo tras la puesta en marcha.


La idea es involucrar al usuario final en el diseño de la aplicación, este después podrá explicar el mismo a sus compañeros el uso de la misma, y por supuesto explicarte a ti de donde cojea la aplicación… Pero CUIDADO, que no se convierta en una carta a los reyes magos!!!


4º Un anillo para dominarlos a todos… Simplificando las comunicaciones


El tema de las comunicaciones siempre es peliagudo, aunque en los últimos tiempos esto ha mejorado considerablemente, así que solo cabe decir aquí que es importante (siempre que sea posible) utilizar un UNICO sistema de comunicación, no hablo de si utilizar WIFI, GPRS, UMTS ect. Sino del sistema, WebServices, Replicación SQL, MSMQ, o transferencia de archivos de texto… insisto en que solo siempre que sea posible, ya que es de cajón de que cuantos más métodos incluyamos más complicado será escalar nuestra aplicación, mantenerla y detectar los posibles errores, que en la parte de comunicaciones suelen aparecer con más frecuencia de la que nos gustaría. Lo ideal es establecer simpre que nos sea posible un unico canal y establacer las interpretaciones en las entradas y las salidas de datos.


Nuestros usuarios agradecerán no tener que realizar complicadas configuraciones.


5º  Planifica bien tu proyecto


Si alargamos demasiado el desarrollo de nuestra aplicación corremos el riesgo de que para cuando la terminemos ya estemos utilizando tecnología obsoleta…. (si, algunos ya sabréis que no es tan raro) un desarrollo de una aplicación móvil comercial no deberíais alagarla más de 3-4 meses (por supuesto esto depende del proyecto a acometer y es solo una media, del tiempo real, que mi equipo y yo hemos dedicado, por supuesto en estos meses no se incluye el tiempo de segundas fases y ampliaciones, sino al tiempo de tener lista la primera release puesta en el cliente) 


La reducción de los tiempos en este tipo de proyecto evitan el cansancio del equipo de desarrollo, y evitan «la dispersión mental» y el perder del norte el objetivo.


Nuestros clientes no se desesperaran al ver que pasan las semanas y siguen sin tener nada, si el proyecto es muy largo desde que hablamos con ellos a la presentación del mismo no recordarán nada de lo que te contaron.


6º Se hace camino al andar… pero si ya lo han andado otros pa’ que


Aprovecha las funcionalidades del SO, dedica algún tiempo (se puede vivir durmiendo 5 horas) a estudiar las funcionalidades que te ofrecen los SDK del sistema operativo a utilizar. En alguna ocasión me he encontrado con desarrollos muy originales…. sobre algo que ya estaba resuelto en una nueva versión del Compact Framework, o desarrollos de Windows Mobile 5 muy currados pero que luego corrían sobre Windows Mobile 6 y con funcionalidades ya resueltas en su SDK


7º Estar atento a las novedades y desarrollos de terceros.


Más de lo mismo que el punto 6… pero es que muchas veces está muy bien desarrollar tus propios componentes pero dependiendo del alcance del proyecto a veces es interesante ver que componentes ya existen y adquirirlos. El trabajo de los demás también debe ser valorado. Un claro ejemplo es OpenNetCF (aunque ya ha perdido un poco de su espiritú de código abierto que tanto exito les dió)


8º Crea manuales SENCILLOS


Si puedes hacer que el manual entre en un folio mejor que mejor, y esto incluyendo capturas de pantalla, el equipo de soporte te lo agradecerá, y será más fácil que los usuarios finales «al menos» le echen un ojo.


Si no es posible reducirlo tanto, siempre está bien crear una hoja de guía rápida en la primera página de tal modo que puedan utilizarla de chuleta.


9º Valora a tu equipo


Insistiendo en el valor humano, si los desarrolladores no comprenden la aplicación difícilmente podrán darse cuenta de los «agujeros» con los que pueda contar la misma, es importante dedicar un tiempo a explicar el modo de trabajo actual de los usuarios finales, de este modo siempre nos podremos ahorrar el trabajo extra de corregir después errores (que suelen suponer replantear toda la aplicación…)


10º Aquí sois vosotros los que decidís este punto del factor humano en el desarrollo de un proyecto


¿Sugerencias?….


Un saludo a todos y perdonar por esta pequeña chapa, a veces me pongo a escribir y pierdo un poco el norte. 


José Antonio Gallego


Mobile .NET Users Group

Un mini Geek en mi familia

Hoy continua, para mí, el que sin lugar a dudas es el proyecto mas importante al que nos podemos enfrentar en este mundo, y es tener un hijo, esta noche y con muchas prisas ha nacido mi primer hijo Alejandro, con tres kilos y medio y sin dejar de mover las manitas de un lado a otro, espero que sea para que le vaya bien un teclado entre las manos  (perdonar que voy a por el babero que se me cae la baba aún).


Se que no es muy adecuado poner aquí este post pero agggg, estoy tan contentoooooo que quiero que todo el mundo se entrere!!! (Seguro que lo comprendereis 😉 )


Un abrazo comunidad!!!


PD: Me voy a comprar pañales :S a ver si de tanto inventar, a alguno de IT se le ocurre una maquinita que haga esa parte!!! jejeje

Microsoft se mueve, VI-FI ¿Un nuevo protocolo de red para vehículos?

La universidad de Massachusetts, Microsoft y la Universidad de Washington están trabajando en un nuevo sistema que permitiría resolver el problema del uso de redes Wi-Fi en nuestros vehículos.


Si, ya sé que a primera vista esto tecnológicamente no sería complicado, lo complicado es que “funcione de verdad”, es decir, el dotar a un vehículo como un autobús para que suministre conexión Wifi a los viajeros no tiene ninguna complicación, la complicación es que el autobús pueda conectarse a una red Wifi externa, como las actuales redes WI-FI urbanas que están comenzando a aparecer y esta ofrezca un servicio sin interrupciones.


ViFi

El sistema lo que pretende es mejorar el sistema de Handoff para evitar los cortes que se producen entre el cambio de una estación base a otra.


Lo que se pretende NO es dar otro motivo de distracción al conductor, sino de dar una posibilidad real y económica para que los pasajeros o los sistemas del vehículo, como el GPS, el ordenador de abordo puedan utilizar una conexión de red que no se caiga a cada paso, lo que permitiría incluso la posibilidad de utilizar sistemas de telefonía VoIP desde el coche.


Por ello se está trabajando en un nuevo protocolo al que han denominado Vi-Fi que pretende mejorar los métodos den handoff actuales.


En el siguiente enlace del blog de Balasubramanian podréis leer más sobre el tema, realmente muy interesante.


Aunque no se trata de algo totalmente novedoso, ya hay empresas que han realizado estudios de I+D sobre este tema, si que parece una muestra de las tendencias de las comunicaciones y de la informatización de los vehículos, como ya se está viendo por parte de la adaptación de Windows Automotive como por ejemplo con el sistema Blue And Me de Microsoft que se integro en Fiat (y por favor jejeje, olvidémonos del chiste del coche y el pantallazo azul).


José Antonio Gallego


Mobile .NET Users Group