February 2012 - Artículos
Introducción
Microsoft ha lanzado en este mes de Febrero que ahora finaliza una actualización de Microsoft Windows Phone SDK (aún en versión preliminar, CTP).
Concretamente, lo que se denomina como Windows Phone SDK 7.1.1 CTP que corresponde con la versión denominada como Windows Phone Tango.
El porqué de esta actualización
El motivo principal del "porqué" de esta actualización, se debe fundamentalmente a que varios fabricantes llevaban varios meses desarrollando teléfonos móviles dotados de Windows Phone y de low-cost.
En concreto, tenemos dos fabricantes que se han aventurado a mostrar estos nuevos terminales, algo que ha sucedido en el MWC (Mobile World Congress) 2012 que se está celebrando en Barcelona (España).
En concreto, Nokia ha presentado (además de varias novedades) un dispositivo móvil de nombre Nokia Lumia 610.
Por su parte, el fabricante chino ZTE ha presentado su nuevo dispositivo móvil ZTE Orbit.
Ambos dispositivos tienen un precio inferior a 200 € y sus características técnicas son menos exigentes que la de sus hermanos mayores. Concretamente, disponen de 256 Mb de memoria RAM en lugar de las 512 Mb que suelen tener el resto de terminales, y soporte para procesadores Qualcomm 7x27a de menor velocidad (800 MHz en lugar de 1 GHz de los modelos superiores).
Esto significa que aunque podamos instalar cualquier aplicación de Windows Phone del Marketplace en estos dispositivos, es posible que encontremos algún problema de rendimiento.
El problema más directo es en la asignación de memoria. Con terminales dotados de 256 Mb, la asignación de memoria cambia, y eso afecta o puede llegar a afectar de forma muy directa con nuestras aplicaciones.
¿Y cómo resolver esto?
Es por eso que Microsoft ha decidido publicar Windows Phone SDK 7.1.1, una actualización de su SDK que permita detectar cuando nos encontramos ante una aplicación que se ejecuta en terminales de bajo coste y cuando no, para que en base a ello, prepararemos nuestras aplicaciones de forma adecuada.
La nueva versión preliminar de Windows Phone SDK 7.1.1 nos permitirá empezar a desarrollar nuestras aplicaciones con estas características.
¡Ojo!, Windows Phone SDK 7.1.1 no se trata de una versión definitiva, y no dispone de licencia GO LIVE. Esto significa que se trata de una versión preliminar de pruebas, y NO podremos publicar aplicaciones desarrolladas con esta versión en el Marketplace. Es fácil pensar que poco cambio habrá seguramente con la versión definitiva, por lo que podremos ir ya poniéndonos manos a la obra con esta nueva versión de desarrollo.
Adicionalmente a todo lo comentado hasta ahora, el SDK trae una modificación al emulador existente y es la de poder elegir entre un emulador de 512 Mb (el tradicional hasta esta nueva versión) y un nuevo emulador de 256 Mb que nos permitirá trabajar con algunas de las restricciones planteadas.
A la hora de desarrollar nuestras aplicaciones, podemos limitar el despliegue de las mismas en dispositivos de bajo consumo utilizando el valor ID_REQ_MEMORY_90 en los requisitos que encontraremos en el archivo WMAppManifest.xml (ver documentación oficial para más detalles).
De cara a la gestión de recursos dependiendo del tipo de aplicación, el SDK incluye un nuevo valor de nombre ApplicationWorkingSetLimit en el namespace Microsoft.Phone.Info (Microsoft.Phone.dll) y que puede ser invocado a través de DeviceExtendedProperties.GetValue(ApplicationWorkingSetLimit). De esta manera, podremos capturar la cantidad de memoria del dispositivo (menos de 90 MB = 94371840 para dispositivos de 256 Mb) para de esta forma, saber qué tipo de dispositivo es el que invoca nuestra aplicación y actuar de acuerdo a nuestras necesidades.
Otra novedad del nuevo SDK es que el control de anuncios está ahora incorporado al SDK.
Aún y así, conviene ser prudentes con estas novedades para ver si algunas de ellas sufren finalmente algún cambio o transformación.
Diferencias entre versiones
En esta pequeña tabla, se resumen aquellas características más destacables entre un Windows Phone de 256 Mb y un Windows Phone de 512 Mb desde el punto de vista técnico.
De acuerdo a esta pequeña tabla, vemos que la recomendación de Microsoft es la de ejecutar en terminales de 256 Mb aplicaciones de menos de 90 Mb necesarias de asignación de memoria.
Incluso, Microsoft va más allá, y recomienda que sea incluso menos o igual de 60 Mb, ya que a partir de esa cantidad, la paginación afectará directa y estrechamente a la ejecución de nuestras aplicaciones y por lo tanto al rendimiento y a la experiencia de usuario.
¿Para cuando la versión final?
Según App Hub, la versión final de Windows Phone SDK 7.1.1 estará disponible el próximo mes, y contendrá soporte para Malayo e Indonesio tal y como se puede extraer de lo que ellos comentan.
Junto a esta actualización, el Marketplace sufrirá una expansión. Expansión que implica a 23 nuevos mercados adicionales: Bahrain, Bulgaria, China, Costa Rica, Croatia, Estonia, Iceland, Iraq, Israel, Kazakhstan, Latvia, Lithuania, Qatar, Romania, Saudi Arabia, Slovakia, Slovenia, Thailand, Turkey, UAE, Ukraine, Venezuela y Vietnam.
Enlaces
Acceso a la página Web oficial de descarga de Windows Phone SDK 7.1.1 (versión preliminar NO GO LIVE)
Información con las novedades de Windows Phone SDK 7.1.1
Información de Microsoft para el desarrollo de aplicaciones para dispositivos de 256 Mb
Blog de Aaron Stebner http://blogs.msdn.com/b/astebner/archive/2012/02/27/10273543.aspx
Trucos de Nokia para el desarrollo de aplicaciones de Windows Phone para terminales de 256 Mb
Introducción
En esta entrada y a colación de una breve pero interesante discusión en Twitter acerca del uso de int.MaxValue, se me pasó por la cabeza hacer esta entrada que profundiza un poco más de lo que la propia discusión sobre int.MaxValue podría sugerir, y es que aprovechando la instrucción comentada, me acordé de algunas particularidades en C# que muchas veces pasan desapercibidas y que quizás convenga mencionar o recordar.
Checked vs Unchecked
En C# podemos ejecutar instrucciones en lo que se denomina contexto comprobado (checked) o contexto no comprobado (unchecked).
Por defecto, de acuerdo al compilador de C#, éste ejecuta sus instrucciones aritméticas en un contexto no comprobado (unchecked).
¿Qué significa o qué implicaciones tiene esto para nuestros programas?.
Básicamente y para entenderlo de una forma más adecuada, pensemos en las siguientes instrucciones de código:
1: int value1 = int.MaxValue;
2: int value2 = value1 + 1;
3: int value3 = value2 - 1;
4: int value4 = value1 * value1;
5: int value5 = value2 * value2;
6: MessageBox.Show(value1.ToString() +
7: Environment.NewLine +
8: value2.ToString() +
9: Environment.NewLine +
10: value3.ToString() +
11: Environment.NewLine +
12: value4.ToString() +
13: Environment.NewLine +
14: value5.ToString());
¿Qué salida esperaremos obtener aquí?.
La variable value1 arrojará un resultado igual a 2147483647.
La variable value2 arrojará un resultado igual a -2147483648
La variable value3 arrojará un resultado igual a 2147483647
La variable value4 arrojará un resultado igual a 1
La variable value5 arrojará un resultado igual a 0
Lo normal quizás hubiera sido obtener una excepción, pero al estar ejecutando las instrucciones dentro de un contexto no comprobado (por defecto se ejecutan dentro de este tipo de contexto tal y como he comentado anteriormente), el cálculo da la vuelta.
Pero antes de continuar, expliquemos bien cómo es posible que el cálculo de la vuelta.
Unchecked y los límites de cálculo
La variable value1 obtiene el valor máximo de un tipo de dato int.
La variable value2 sin embargo, agrega 1 al valor que tiene la variable value1 y que es el máximo valor posible de un tipo int.
Como value2 es también un int, estaríamos desbordando el tipo de dato int, sin embargo, al ejecutarse dentro de un contexto no comprobado, el valor simplemente se pasa de rango.
El tipo int tiene un valor que oscila de –2147483648 a 2147483647.
La variable value3 demuestra el mismo comportamiento pero al contrario, de –2147483648 que es el valor de value2 pasa a 2147483647.
Ahora bien… ¿cómo es esto posible?.
Los cálculos aritméticos con unchecked
Vayamos entonces a los cálculos aritméticos para explicar este comportamiento con más precisión.
¿Cuál es el valor binario de 2147483647?.
2147483647 queda representado por 0x7FFFFFFF, o lo que es lo mismo en binario, por 01111111 11111111 11111111 11111111.
-2147483648 por su parte, queda representado por 0x80000000, o lo que es lo mismo en binario, por 10000000 00000000 00000000 00000000.
¿Cuál es entonces el cálculo de sumar 1 a 01111111 11111111 11111111 11111111?
10000000 00000000 00000000 00000000, ¿te recuerda a algo?. Efectivamente al valor 2147483648, por lo que C# le da la vuelta, trunca su resultado, y lo pone “al otro lado” (con signo negativo). Recuerda que el último bit se reserva para el signo (int es signed, no unsigned).
Ahora bien, ¿y los valores 1 y 0 que resultan de multiplicar 2147483647 por sí mismo y –2147483648 por sí mismo?.
En el caso de calcular 2147483647 * 2147483647 y si ahora mismo no estoy haciendo el cálculo mal (a veces tanto cálculo binario a uno le nubla la vista), el resultado obtenido sería:
00111111 11111111 11111111 11111111 00000000 00000000 00000000 00000001
Teniendo en cuenta que el dato int sólo representa los 32 primeros valores binarios truncando el resto, se quedaría con 00000000 00000000 00000000 00000001 que representa… ¡un 1!.
En el caso de calcular -2147483648 * –2147483648, el cálculo binario representa el siguiente resultado:
10000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Al igual que antes, tomando los 32 primeros valores binarios y truncando el resto, se quedaría con 00000000 00000000 00000000 00000000 que representa… ¡un 0!.
Bien, ya tenemos ahora más claro el porqué del comportamiento inicial, ahora bien… ¿qué o cómo controlar estos desbordamientos en C#?.
Controlando los desbordamientos aritméticos en C#
Sin lugar a dudas, el desbordamiento lo tendremos que controlar nosotros mismos.
Por defecto, en C# las operaciones aritméticas se realizan en contextos no comprobados.
Esto nos devuelve una pregunta… ¿cómo forzar o cambiar a C# para que las operaciones aritméticas se realicen en contextos comprobados?.
Esto se logra utilizando la palabra reservada checked.
La porción de código que vimos al principio de esta entrada no devuelve ninguna excepción y se ejecuta sin problemas. El resultado no obstante no es lo esperado.
A diferencia del código anterior, el siguiente código genera una excepción que podemos controlar dentro de try/catch.
1: try
2: {
3: checked
4: {
5: int value1 = int.MaxValue;
6: int value2 = value1 + 1;
7: int value3 = value2 - 1;
8: int value4 = value1 * value1;
9: int value5 = value2 * value2;
10: MessageBox.Show(value1.ToString() +
11: Environment.NewLine +
12: value2.ToString() +
13: Environment.NewLine +
14: value3.ToString() +
15: Environment.NewLine +
16: value4.ToString() +
17: Environment.NewLine +
18: value5.ToString());
19: }
20: }
21: catch (Exception ex)
22: {
23: MessageBox.Show(ex.Message.ToString());
24: }
El mensaje general que devuelve la excepción es “La operación aritmética ha provocado un desbordamiento.”.
La excepción que en realidad se captura es una excepción de tipo OverflowException.
Aunque esta es una demostración a base de pruebas muy generalistas, de acuerdo a detectar este desbordamiento, deberemos realizar o llevar a cabo las operaciones concretas de acuerdo a los requisitos Software que tengamos.
Otra aproximación forzando al compilador
Aún y así, existe una posibilidad diferente a la planteada para controlar estos desbordamientos.
Supongamos el siguiente código nuevamente:
1: try
2: {
3: int value1 = int.MaxValue;
4: int value2 = value1 + 1;
5: int value3 = value2 - 1;
6: int value4 = value1 * value1;
7: int value5 = value2 * value2;
8: MessageBox.Show(value1.ToString() +
9: Environment.NewLine +
10: value2.ToString() +
11: Environment.NewLine +
12: value3.ToString() +
13: Environment.NewLine +
14: value4.ToString() +
15: Environment.NewLine +
16: value5.ToString());
17: }
18: catch (Exception ex)
19: {
20: MessageBox.Show(ex.Message.ToString());
21: }
Si ejecutamos este código, lo estaremos haciendo en un contexto no comprobado.
Si utilizamos la palabra checked tal y como hemos visto, controlaremos los desbordamientos… pero… ¿qué pasa si realizamos multitud de operaciones aritméticas en nuestras aplicaciones?. ¿Y si olvidamos poner checked en alguna porción de código?. ¿Existe alguna forma de automatizar el comportamiento de checked en toda la aplicación?.
La respuesta es sí.
Para hacer esto, tenemos dos opciones. Una primera indicándoselo al compilador, y una segunda indicándoselo a Visual Studio.
Para indicárselo al compilador, deberíamos utilizar la palabra reservada /checked.
Para indicárselo al proyecto, dentro de Visual Studio 2010, bastará con acceder a las Propiedades del proyecto y en concreto, a la solapa Generar.
En la ventana que aparecerá, seleccionaremos el botón Avanzadas.
Aparecerá entonces la ventana de Configuración de compilación avanzada.
Ahí, seleccionaremos la opción Comprobar el desbordamiento y subdesbordamiento aritmético.
Con esto, nuestra aplicación entera se comportará en un contexto comprobado para operaciones aritméticas sin tener que estar utilizando la palabra reservada checked.
Estaría bien que por defecto, el compilador se comportara como checked en su contexto controlado para cálculos aritméticos, no obstante, es preciso apuntar un aspecto vinculado a todo esto y al posible "porqué" el equipo de .NET tiene el compilador configurado por defecto para contextos no controlados en cálculos aritméticos, y es debido a rendimientos.
Habilitar el contexto controlado afecta de forma directa al rendimiento de nuestras aplicaciones. Es por esto que como suele ocurrir casi siempre, habilitar el contexto controlado o no, dependa. ;)
Referencias
Documentación oficial de MSDN sobre checked y unchecked.
Documentación oficial de MSDN sobre la compilación con /checked.
Introducción
A estas alturas yo creo que muchas personas saben de mi amor-odio con el Nokia Lumia 800.
Estoy en un punto en el cuál no sé si tirarlo desde el último piso de una de esas torres altas que hay en Madrid (da igual la torre, la caída libre hará el resto), si utilizarlo como pisapapeles, o simplemente aceptarlo tal y como es y darle una oportunidad como teléfono móvil.
Lo que me parece increíble del asunto es que Nokia se haya gastado un pastizal enorme en publicidad y el problema de la batería siga creando problemas a multitud de usuarios.
Sé y conozco que hay usuarios que no están teniendo problemas con la duración de la batería del Nokia Lumia 800, pero sé también, que tengo otros amigos que están teniendo prácticamente los mismos problemas que yo, lo cual no es nada normal.
¿Cuáles son esos problemas?. Pues básicamente que la batería del Nokia Lumia 800 dura menos de 24 horas sin hacer excesivos usos a redes 3G y de datos, etc. Que a unos usuarios les dure hasta 5 días y a otros ni 24 horas no es muy normal, la verdad.
¿Cómo es eso posible?. Pues que se lo pregunten a los técnicos e ingenieros de Nokia porque hace un consumo desorbitado de los recursos del terminal.
En este punto, no tengo claro si el problema es realmente de Nokia o de Microsoft, pero lo único cierto es que Nokia publicó una actualización del firmware el pasado 17 de Enero que trataba de resolver el problema de la batería, y que en lo que a mí respecta, en lugar de mejorar el comportamiento de mi terminal lo ha empeorado, ya que antes me duraba 25 horas y ahora 18-19.
Pero los empeoramientos no sólo tienen que ver con la batería, sino con temas poltergeist, como que el terminal se me ha reiniciado dos veces mientras mantenía una conversación telefónica, una con manos libres y otra sujetando el terminal como lo hago siempre. Adicionalmente me he encontrado con algún funcionamiento extraño también, pero bueno,... con el tema de la batería vamos más que servidos para esta entrada.
La historia en mi caso personal, no obstante, continúa, ya que me he puesto en contacto con Nokia Care (servicio de atención al cliente) para comentar mi problema y hace un mes sigo esperando una respuesta. Como veis, mucho marketing para unas cosas, y muy mala atención al cliente para otras. Lamento hacer públicas estas quejas, pero me han ignorado por teléfono, por twitter, etc., así que para he decidido escribir esta entrada para ver si así, alguien de Nokia lo lee y puede sonrojarse ¿mínimamente?.
Total... que después de que Nokia haya pasado de mí (y lamentablemente me consta que no soy el único), he decidido hacer pruebas y pruebas hasta que por fin, he dado con una solución, que siendo en sí una prueba poco rigurosa e incluso una gran chapuza diría yo, ha hecho que la duración de mi batería en mi Nokia Lumia 800 pase de 17-19 horas a entre 30 y 40 horas según su uso.
He estado utilizando el terminal para escuchar mp3 y conectarme al correo, conexión bluetooth y de datos, todo ello de forma esporádica, y los resultados como veis, son bastante “normales”... aunque hay un "pero",... Seguid leyendo y lo entenderéis.
Datos preliminares
Como Nokia no da solución alguna o ni tan siquiera ayuda o aporta una solución definitiva al problema de la batería, he decidido ponerme manos a la obra mediante la famosa técnica de prueba/error. Al final, después de estar haciendo mil y una pruebas, estas son las conclusiones a las que he llegado.
Lo primero de todo, pongámonos en situación. ¿Cuál es la capacidad tope de nuestra batería?. Antes de la actualización del firmware tenía unos datos bastante aceptables para el ojo humano… 1519 mAh como Full Charge Capacity. Sin embargo, después de la actualización del firmware, estos datos se han venido abajo, 1262 mAh. Antes de la actualización del firmware mi batería duraba unas 25 horas… ahora unas 18…
Como podemos observar aquí, la duración de mi batería apenas llega a 18 horas.
Sin embargo, he estado haciendo pruebas durante estas últimas semanas y he empezado a alargar la vida de mi batería de 18 horas a una duración entre 30 y 44 horas escuchando música, navegando en Internet a través de redes de datos 3G y a través de WiFi, conectando Bluetooth para llevarlo como manos libres en el coche y utilizando la alarma del móvil... todo ello esporádicamente.
Como podrás entender, pasar de 18 horas a 30 y 44 es de por sí un gran avance. Sin embargo, este avance no lo he logrado de la forma más adecuada, simplemente haciendo una "trampa" que a continuación comentaré.
Manos a la obra
La razón por la cuál he llegado a estirar la duración de la batería de 18 horas a entre 30 y 44 (la última valoración es de 43-44 horas) es activando el ahorro de batería por completo. El ahorro de batería sólo debería activarse cuando la batería está baja.
Una demostración de esta característica en funcionamiento y con valores demostrativos es la que puedes observar en la siguiente imagen:
Aquí puedes observar que mi última carga se realizó hace 36 horas y aún le quedaban 8 horas. Lógicamente dependiendo del uso que le dé al móvil, esas 8 horas restantes se reducirán enormemente o no.
No obstante y en este punto, se me ocurrió desactivar las opciones de ahorro de batería y comprobé que las horas restantes estimadas bajaron ¡de 8 horas a 2 horas!.
Esto significa que el consumo de batería sin activar las opciones de ahorro de batería es del cuádruple, lo cual me hace pensar en que hay un problema o bien en el sistema operativo de Windows Phone, o bien en el gestor de consumo de mi Nokia Lumia 800.
Habiendo tenido un LG Optimus 7 antes que ni por asomo tenía estos problemas que tengo ahora con el Nokia Lumia 800, mucho me temo que pese a que Windows Phone pueda tener algún problema concreto, el problema real está más cerca del dispositivo que del sistema operativo.
Reitero… según mis pruebas, el consumo es de 4 veces más sin activar el ahorro de batería… me parece una auténtica pasada.
Sin embargo, activar el ahorro de batería NO es una opción válida. Es una opción que podemos utilizar en nuestro terminal, pero no me parece la solución para estirar la duración de la batería. No me parece que esto le guste a Nokia, ni mucho menos al usuario, ya que al hacer esto, tenemos varias implicaciones con respecto a las aplicaciones que están corriendo en nuestro Windows Phone.
Pero vayamos por partes…
Lo que os he indicado hasta ahora es *mi* forma de resolver este problema.
A partir de aquí, vamos a ver las implicaciones directas e indirectas con las que podemos encontrarnos.
Otras implicaciones
Tareas en segundo plano
Para estirar la duración de mi batería, me he cuidado de desactivar las tareas que tenía en ejecución en segundo plano.
Configuración > Voz
Adicionalmente, he deshablitado el reconocimiento de voz. El motivo principal es que no lo uso prácticamente nunca y no tiene sentido en mi caso el tenerlo activado.
Configuración > encuentra mi teléfono
Otra opción que he deshabilitado es la opción para encontrar mi teléfono.
Entiendo que esta opción por seguridad podría o debería esta habilitada, pero aquí la he deshabilitado para comprobar la durabilidad de la batería.
Configuración > actualización
De igual manera, he deshabilitado las actualizaciones de mi Nokia Lumia.
Si sé que Nokia no va a mandar actualizaciones de mi Nokia Lumia, ¿para qué tener esta opción activada?.
Configuración > Accesibilidad
De igual manera, esta opción en mi caso no es necesaria y la tengo deshabilitada.
Configuración > Mapas
Los mapas en mi caso, sí los tengo activados.
Configuración > Datos móviles
Como comentaba antes, normalmente he tenido los datos móviles desactivados.
Sólo los activo cuando los tengo que utilizar.
Configuración > Bluetooth
Al igual que con los datos móviles, en el caso de la conectividad Bluetooth hago exactamente lo mismo. Lo conecto sólo cuando lo necesito.
Problemas
Es muy importante saber que problemas podemos tener a la hora de activar el ahorro de batería/energía en nuestro Windows Phone.
El más destacable es que aunque nos conectemos a una red de datos, nuestro correo, calendario y contactos, no se sincronizará automáticamente. La actualización debe realizarse manualmente.
Y es que… todo tiene su coste como podemos ver…
Conclusiones
Quiero que quede claro, que lo que aquí pongo está basado en mi experiencia personal con mi Nokia Lumia 800.
Reconozco igualmente que no todos los Nokia Lumia 800 tienen el problema de la duración de la batería.
E indico desde ya, que la solución propuesta, aunque efectiva, NO es la solución óptima.
El truco utilizado es cargar el móvil completamente y una vez hecho esto, seleccionar ahorro de energía, aunque lo ideal es que esta opción se utilizara sólo cuando quedara poca batería.
¿Qué datos obtienes tú?.
.png)
Introducción
Microsoft ha publicado hace unas horas la nueva versión de Microsoft Entity Framework, hablo de Microsoft Entity Framework 4.3.
Presumiblemente, esta versión es la última actualización antes de que aparezca en escena lo que presumiblemente podríamos denominar como Entity Framework 4.5 ó 5.0, dependiendo de como Microsoft desee llamarla, si bien el equipo de Entity Framework parece dejar claro que se llamará Microsoft Entity Framework 5.0 (otra vez estamos con el baile de números de versión), aunque no adelantemos acontecimientos, y menos antes de conocer qué mejoras trae esta nueva versión.
Los cambios
Entre Microsoft Entity Framework 4.2 y Microsoft Entity Framework 4.3, Microsoft ha querido incorporar y añadir nuevas características y cambios.
En este punto, sólo voy a enumerarlas para no repetir las cosas que ya aparecen en la información oficial. En el apartado final indico una serie de enlaces que recomiendo visitar sino los conoces aún.
- New Code First Migrations Feature.
- Removal of EdmMetadata table.
- Data Annotations on non-public properties.
- More configuration file settings.
- Bug fix for GetDatabaseValues.
- Bug fix to support Unicode DbSet names.
Además de estas modificaciones y resolución de problemas, conviene que tomes una lectura respecto a los cambios que Microsoft ha incorporado en la versión final de Microsoft Entity Framework 4.3 con respecto a la Beta 1 de Microsoft Entity Framework 4.3.
Enlaces
Noticia oficial del lanzamiento de Microsoft Entity Framework 4.3.
Instalación de Microsoft Entity Framework 4.3 desde Nuget.
Más información sobre Microsoft Entity Framework en geeks.
Blog de Unai con multitud de información sobre Entity Framework.
El próximo día 16 de Febrero de 2012 de 19:00 a 21:00, nuestro amigo Unai Zorrilla nos dará una charla sobre algo que está muy de moda,… los NoSQL.
De hecho, aprovechará este evento para hablarnos de un producto o software NoSQL como es RavenDb.
En el evento, Unai nos comentará detalles acerca de los modelos de documentos, map-reduce, índices y boundles.
Es una fantástica oportunidad para conocer más acerca de los NoSQL y de RavenDb en concreto. RavenDb está siendo comúnmente usado por la Comunidad .NET especialmente. Existen otros como MongoDb, etc., pero creo que resultará interesante que Unai nos cuente detalles de todo esto.
No te olvides que el evento es gratuito y tendrá lugar en las oficinas de Madrid de Microsoft en La Finca (Pozuelo de Alarcón).
Podrás registrarte en este enlace.
Puedes acceder a la información oficial del evento en este otro enlace.
¡Te esperamos!
Como ya sabemos, cuando conectamos nuestro Windows Phone al PC, éste arranca Zune de forma automática.
Otra posibilidad es que tengamos Zune ya arrancado, para lo cuál éste, detectará que hemos conectado nuestro Windows Phone 7 al PC y se sincronizará con él.
Ahora bien, imaginemos que lo que queremos es conectar nuestro Windows Phone 7 al PC y poder navegar por Internet, recibir WhatsApp, acceder al marketplace, o acceder a la radio con aplicaciones como TuneIn Radio (de la cuál estoy enganchado a más no poder).
¿Cómo poder llevarlo a cabo?.
Basta con acudir a la ruta en la que tendremos instaladas las herramientas del SDK de Windows Phone (si no las has instalado, tendrás que instalarlas).
La ruta de mi PC es la siguiente:
C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Tools\WPConnect\x86>
ó
C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Tools\WPConnect\x64>
Allí encontraremos una aplicación de nombre WPConnect.exe.
Bastará con ejecutar esta aplicación, la cuál tratará de conectarse a nuestro dispositivo móvil.
Una vez hecho esto, desde nuestro móvil Windows Phone conectado al PC, podremos acceder a la red a través de la red Ethernet, WiFi, etc., que esté utilizando el ordenador.
Para mí que estoy trabajando todos los días con mi ordenador y que tengo mi móvil de apoyo, me viene fenomenal este planteamiento, ya que me permite escuchar la radio penalizando un poco el consumo de red pero no interfiriendo el funcionamiento de mi ordenador.
Espero que este pequeño truco le venga bien a más de uno.
Por cierto, aunque no lo he mencionado, la ventaja de conectar nuestro Windows Phone 7 de esta manera, es que además estaremos recargándo su batería. ;)
Un saludo.