Por qué el Nokia Lumia 9XX es el mejor móvil del mercado

Soy un usuario de telefonía bastante básico, lo reconozco. A estas alturas, le pido más bien pocas cosas a un móvil… Básicamente: hacer llamadas y SMS, Whatsapp, Line, Facebook, Twitter, Skype, poder navegar con fluidez, accesibilidad básica (Wifi, compartir conexión de internet, etc), una cámara de fotos decente, un buen navegador GPS, seguridad, tener mapas y guías offline, ser resistente, una experiencia de usuario rápida y sin retardos, un interfaz de usuario fácil e intuitivo, una buena integración con mi PC y una buena duración de batería. Bueno, visto así, quizá no sean tan pocas cosas…

Pues resulta que hoy me he dado cuenta de que en muchos de esos apartados, los Nokia Lumia 9XX son los mejores. Con mucha diferencia.

Ya se ha hablado largo y tendido de Windows Phone 8, de su interfaz, etc, por lo que no me centraré aquí en los aspectos propios del Sistema Operativo, sino en aquellos que hacen que los Lumia 9XX destaquen, incluso por encima de otros terminales WP8.

En mi caso, tengo un Lumia 920, así que vamos allá… Aspectos realmente increíbles de este teléfono:

Cámara de Fotos / Video

La cámara del Lumia es, simplemente, alucinante. Ya se ha hablado largo y tendido de ella, pero casi siempre la gente se limita a hablar de su capacidad para hacer fotos con poca luz (que la verdad, es increíble). Pero tiene otras muchas virtudes:

Modo macro

Es simplemente alucinante que una cámara de móvil pueda hacer una foto así, y encima sin tener que pegarte con ajustes de ningún tipo: solo tienes que dejarla en modo auto y acercarla mucho a algo. Donde cualquier otro móvil sacaría un borrón, el Lumia 920 saca esto (fotos tomada esta misma mañana):

Otros ejemplos de fotos:

Todas estas fotos han sido sacadas con mi propio Lumia 920, esta semana:

Video:

El estabilizador de imagen del Nokia Lumia 920 es alucinante. Realmente permite hacer grabaciones increíbles, incluso cuando vas caminando. Aquí tenéis un ejemplo (no grabado por mi), aunque por mi experiencia personal debo decir que el resultado todavía es más impresionante que lo que se aprecia en el:

Mapas / Navegación

Ahora, la versión WP8 de Here Maps y Here City Lens, de Nokia, permiten “tirar” de os mapas offline descargados para el navegador. Esto es algo que siempre he echado mucho de menos en todos los móviles que he tenido, ya que… ¿Cuando utilizas con más frecuencia los mapas del movil y las herramientas de guía? Cuando viajas. Y si estás en el extranjero, y no tienes roaming, no te sirven de nada.

Pues bien, Nokia ha solucionado este problema de forma brillante, y con los 32 GB de almacenamiento del Lumia 920 tenemos espacio más que de sobra para descargar mapas.

Navegador GPS:

Es, a falta de otra palabra mejor… brillante. Solo diré que, desde que adquirí mi primer Nokia Lumia, nunca más he tocado mi navegador TomTom:

• Las indicaciones por voz son las mejores que he visto nunca en un navegador, casi no hace falta ni mirar a la pantalla (simplemente haz lo que te va diciendo). El volumen es más que de sobra para escuchar las indicaciones, incluso cuando llevas música en el coche, o las ventanillas abiertas (de hecho, siempre llevo el volumen a menos de la mitad, ya que si no resulta excesivo).
• Dado que utiliza el sensor GPS en combinación con la triangulación de los repetidores de telefonía para localizarte, no le cuesta ni 3 segundos encontrarte en el mapa. La precisión es siempre muy buena, y gracias a los repetidores de telefonía, no se queda completamente sin señal en los túneles. La precisión baja mucho, pero al menos tu coche sigue moviéndose en el mapa, algo importante en ciudades con mucha circulación subterránea.
• Los mapas (disponibles para todo el mundo), son gratis… ¿Algo más que decir?
• En cuanto a la fiabilidad, solo puedo decir que he utilizado intensamente el sistema de Nokia en España, Francia, Inglaterra y Estados Unidos, sin ningún tipo de problema.

Skype

Utilizo bastante Skype, y la implementación para WP8, en combinación con la calidad de la cámara del Lumia 920 es alucinante. Además, tengo la suerte de contar con una red 4G, así que va como un auténtico tiro. La calidad de imagen es notablemente mejor que la de la cámara webcam de mi portátil. Flipante !

Resistencia

Todos hemos visto multitud de vídeos haciendo todo tipo de perrerías con las pantallas Gorilla Glass de los Lumia. Tengo Lumias desde hace un par de años, y la verdad es que todas las pantallas están como el primer día. Ni la más mínima raya, sin haber tenido ningún tipo de cuidado con ellas, ni llevar protector. Mis móviles han convivido en mis bolsillos con las llaves de casa, prácticamente siempre, y ni una muesca. Solo hay que ver este video…:

Cosas a mejorar

Sinceramente, la duración de la batería sigue siendo muy justita cuando le das un uso intenso (al igual que en todos los móviles de alta gama). En días muy intensivos, deberás pelear para llegar al final del día sin ver el simbolito de “batería a punto de fallecer”. El día que consigan mejorar ese aspecto, realmente habrá mucha gente que no necesitará ni tablets, ni portátiles…

Otro aspecto en el que todavía está por detrás es el cliente de Whatsapp. Evidentemente, esto es culpa de la propia whatsapp, y no de Nokia ni de Microsoft, pero es una pena. El cliente sigue siendo realmente cutre. Vamos Whatsapp !!!!

Al final, quizá tenga que lanzar Microsoft su propio cliente, como ha hecho con el lector de PDF, para remediar el desastroso trabajo que hizo Adobe con su cliente PDF para Windows Phone… Era realmente lamentable, se colgaba, y no era capaz de abrir prácticamente ningún PDF de tamaño medio. El lector de PDF de Microsoft funciona francamente bien.

Resumen

Nokia Lumia 920: Su cámara es la mejor del mercado (con mucha diferencia). Para el usuario medio, permite sustituir a una cámara de fotos compacta en el 90% de los casos. Como cámara de video, es realmente brillante también (incluso mejor que muchas cámaras de video específicas, que no incluyen ni grabación 1080p ni estabilización de imagen).

Como navegador GPS, no tiene rival. Sus mapas son muy muy buenos también, su funcionalidad Skype es increíble y el resto de funcionalidades del móvil, están cuando menos a la altura de los mejores.

¿Se puede pedir algo más?

Bueno, sí… Que ciertos redactores de páginas como Gizmodo.es dejen de lado su aparente aversión a todo lo que huela a Microsoft, y valoren los productos objetivamente. Quizá algún día salga a la luz que, en realidad, están a nómina de otras empresas, porque si no no se entiende…

Saludos !!!

Memory limits in a .Net process

This article tries to be an introduction on .Net memory management and about the memory limits both the Runtime and the platform establish for each process. We will also give some tips about dealing with the problems you will face when reaching those limits.

Available memory for a process

As you already know, no matter how much physical memory you install in a computer. Your application will face several issues that will limit the actual memory available for it.
For instance, a 32 bit system cannot have more than 4 GB of physical memory. Needless to say that 2^32 will give you a virtual address space with 4.294.967.296 different entries, and that’s precisely where the 4GB limit comes from. But even having those 4GB available on the system, your application will actually be able to see 2GB only. Why?
Because on 32 bits systems, Windows splits the virtual address space into two equal parts: one for User Mode applications, and another one for the Kernel (system applications). This behavior can be overridden by using the “/3gb” flag in the Windows boot.ini config file. If we do so, the system will then reserve 3GB for user applications, and 1 GB for the kernel.
However, that won’t change the fact that we will be able to see only 2GB from our application, unless we explicitly activate another flag in the application image header: IMAGE_FILE_LARGE_ADDRESS_AWARE. The combination of both flags on a 32bit Operating System is commonly known as: 4GT (4 GigaByte Tuning).
Surprisingly on 64 bit environments, the issue is pretty similar. Even though these systems don’t suffer from the same limitations about physical memory or reserved address space for the kernel (in fact, in those systems the /3gb flag doesn’t apply), processes hit with the same wall when trying to address more than 2 GB. Unless the same flag is set for the executable (IMAGE_FILE_LARGE_ADDRESS_AWARE), the limit will be always the same by default.

Activating the flag: IMAGE_FILE_LARGE_ADDRESS_AWARE

• In native, Visual C++ application, it’s pretty straightforward to set that flag, as Visual Studio have an option for that. You just need to set the /LARGEADDRESSAWARE Linker parameter, and you are ready to go.
• In C#, .Net applications:

1. Applications compiled as 64bit will have that flag set by default, so you will already have access to a 8TB address space (depending on O.S. versions)
2. Applications compiled as 32bits will need to be modified with the tool called EditBin.exe (distributed with Visual Studio). This tool will set the appropriate flag to your EXE, allowing your application to access a 4GB address space if running in a 64bit Windows, or to a 3GB address space if running in a 32bit Windows with the 4GT tuning enabled.

Next table (taken from here), summarizes the limits in virtual address space, depending on the platform and on the kind of process we are running:

This page has much more info on the issue.

System memory limits. Closer than you expect

Nowadays, memory is cheap. However, as explained in the previous chapter, there are many situations where you will end up having only 2 GB available, despite the total amount of physical memory installed in your PC.
In addition to that, if your application is being developed in .Net, you will find that the Runtime itself introduces a remarkable memory overhead (around 600-800 MB). So, it’s not strange to start receiving OutOfMemory exceptions when reaching 1.2 or 1.3 GB of memory used. This blog talks further about this.
So, if you are not in one of those cases, where the address space is expanded beyond 2 GB, and your are developing in .Net, your actual memory limit will be around 1.3 GB.
That’s more than enough for 99% of applications, but others, like intensive computing apps or those related to databases, may need more. Way more…

And things get even worse…

To make things even more complicated, you will soon learn that one thing is having some amount of memory available, and another, completely different story is to find a contiguous block of memory available.
As you all know, as a result of O.S. memory management, techniques like Paging and the creation and destruction of objects, memory gets more and more fragmented. That means that even though there is a certain amount of free memory, it is scattered through a bunch of small holes, instead of having a single, big chunk of memory available.
Modern Operating Systems and the .Net platform itself apply methodologies to prevent fragmentation, like the so called Compaction (moving objects in memory to fuse several free chunks of memory into a single, bigger one). Although these techniques reduce the impact of fragmentation, they do not eliminate it completely. This article describes in detail the .Net Garbage Collector (GC) memory management, and the compaction task it performs.
In the context of this article, fragmentation is a big issue, because if you need to allocate an 10 MB contiguous array, even if there’s 1 GB of free memory available for your process, you will receive an OutOfMemory exception if the system cannot find a contiguous chunk of memory for the array. And this happens more frequently than you may expect when you deal with big arrays.
In .Net, fragmentation and compaction of objects is tightly related to object’s size, so let’s talk a bit about that too:

Allocation of big objects

Maybe you don’t know it, but all versions of .Net until the last one (1.0, 2.0, 3.0, 3.5 and 4.0) have a limit on the maximum size a single object can have: 2 GB. No matter if you are running in a 64bit or 32bit process, you cannot create anything bigger than that, in a single object. It’s only since version 4.5 when that limit has been removed (for 64 bit processes only). However, besides very few exceptions, you are very likely applying a wrong design pattern to your application if you need to create such a big objects.
In the .Net world, the GC classifies objects into two categories: small, and large objects. Where you expecting something more technical? Yeah, me too… But that’s it. Any object smaller than 85000 bytes is considered small, and any object larger than that is considered large. When the CLR is loaded, the Heap assigned for the application is divided into two parts: the SOH (Small Objects Heap) and the LOH (Large Objects Heap). Each kind of object is stored on it’s correspondent Heap.
It’s also remarkable to say that Large object’s compaction is very expensive, so it’s directly not done in current versions of .Net (developers said that this situation might change in the future). The only operation similar to compaction done with Large objects is that two adjacent dead objects are fused together into a single chunk of free memory, but no Large object is currently moved to reduce fragmentation.
This fantastic article has much more information about the LOH.

C# Arrays when reaching memory limits

Simple Arrays (or 1D arrays) are one of the most common ways of consuming memory in C#. As you probably know, the CLR always allocates them as single, contiguous blocks of memory. In other words, when we instantiate an object of type byte[1024], we are requesting 1024 bytes of contiguous memory, and you will get an OutOfMemory exception if the system cannot find any chunk of contiguous, free memory with that size.
When dealing with multi-dimensional arrays, C# offers different approaches:

Jagged arrays, or arrays of arrays: [][]

Declared as byte[][], this is the classical solution to implement multi-dimensional arrays. In fact, it’s the only approach natively supported in languages like C++.
With regards to memory allocation, they behave as a simple array of elements (one block of memory), where each one of them is another array (another, different block of memory). Therefore, an array like byte[1024][1024] will involve the allocation of 1024 blocks of 1024 bytes memory each.

Multi-Dimensional Arrays: [,]

C# introduces a new kind of arrays: multi-dimensional arrays, declared like byte[,].
Although they are very comfortable to use and easy to instantiate, they behave completely different with regards to memory allocation, as they are allocated in the Heap as a single block of memory, for the total size of the array. In the previous example, an array like byte[1024, 1024] will involve the allocation of one single, contiguous block of 1 MB.
In the next chapter we will make a quick comparison of both types of arrays:

Comparison: [,] vs [][]

2D array [,] (allocated as a single block of memory):
Pros:

• Consumes less memory (no need to store references to all N blocks of memory)
• Faster allocation (allocating a bigger, single block of memory is faster than allocating N, smaller blocks)
• Easier instancing (enough with one single line: new byte[128, 128])
• Useful tool methods, like GetLength(). Cleaner and easier usage.

Cons:

• Finding a single block of contiguous memory for them might be a problem, specially if dealing with big arrays, or when reaching memory limits for your process
• Accessing elements in the array is slower than in jagged arrays (see below)

Jagged arrays [][] (allocated as N blocks of memory):
Pros:

• It’s easier to find available memory for this kind of arrays, because due to fragmentation, it’s more likely that there will be N blocks of smaller size available than a single, contiguous block of the full size of the array.
• Accessing elements in the array is faster than in 2D arrays, mostly because the optimizations in the compiler for handling simple, 1D arrays (after all, a jagged array is composed of several 1D arrays).

Cons:

• Consumes a bit more memory than 2D arrays (need to store references to the N simple arrays).
• Allocation is slower, as it needs to allocate N elements instead of a single block
• Instancing is uncomfortable, as you need to loop through array elements to instantiate them too (see below for tip)
• Doesn’t provide with tool methods, and might be a bit more complex to read and understand

This blog have a great comparison about them too.

Conclusion

Each user should decide which kind of array fits best the specific case he is dealing with. However, a developer that usually needs big amounts of memory, and who cares more about performance than comfort, ease of use or readability, will probably decide to use Jagged arrays ([][]).

Tip: code to automatically instantiate a 2D, jagged array

Instancing a multi-dimensional jagged array can be disturbing, and repetitive. This generic method will do the work for you:

        public static T[][] AllocateArray2D<T>(int pWidth, int pHeight)            
        {
            T[][] ret = new T[pWidth][];
            for (int i = 0; i < pHeight; i++)
                ret[i] = new T[pHeight];

            return ret;
        }

Hope it helps !!

Boot time comparison: All generations of iPhone vs Nokia Lumia 800

This video completes the boot time comparison made by iClarified with an additional contender: the Nokia Lumia 800 with Windows Phone 7.5, which beats even the very last iPhone 5 in terms of boot time.

 

Please note: This video is a second version of another one published 3 days ago. It has been remade to fix a small fps conversion error present in the previous version (the iPhone part was treated as if it was 30 fps, when it was 24 fps). That involved it being displayed faster than it should, and therefore showing a wrong boot time measurement for the Lumia (which was displayed correctly, at 30 fps). Nokia Lumia 800 boots in 18 seconds, not 22.

Results

The boot time results are awesome:

• Nokia Lumia 800: 18.17 secs
• iPhone 5: 24.88 secs (6.5 seconds slower !!)

I ♥ Nokia        -        I ♥ Windows Phone

Properly calculating the diffuse contribution of lights in HLSL Shaders

It’s been many years since Vertex and Pixel Shaders came out, and several years too since the Fixed Pipeline is deprecated, but there are still many questions in the forums out there asking about how to properly calculate the diffuse contribution of Lights. This paper has a great tutorial about the issue, and includes a whole Shader that mimics the Fixed Pipeline behavior. However, we will see here how to perform just the basic calculations, just in case you don’t need to emulate the full pipeline.
First thing is to write some D3D9 code that allows you to switch from the old Fixed Pipeline and your own Shaders, using the same parameters. Doing so, you will easily find any behavior differences in light calculations. You can read more about how D3D9 Fixed Pipeline calculates lighting in this page.
When writing shaders, people tend to calculate the diffuse contribution like:

Out.Color = (materialAmbient * lightAmbient) + (materialDiffuse * lightDiffuse * dot(Normal, L));

Where L is the vector from the vertex position (in world coordinates) to the light.
Apart from not doing any specular or emissive calculations (which could not be necessary in many cases, depending on your scenario), there are several mistakes in that approach:
1.- You don’t want the dot to return negative values, because it will black out colors wrongly. So, you need to clamp it to the 0..1 range, using the saturate operator: saturate(dot(Normal, L))
2.- In order to get the same results as the Fixed Pipeline, you should include Attenuation calculations, because they modify the intensity of light with the distance between the point being lit and the light source. Attenuation (as opposed to what its name suggests), not only attenuates light, but also can increase intensity in some circumstances. (See below how to properly calculate attenuation factors)
3.- Once you are calculating attenuation, you should remove the materialDiffuse factor from the previous equation, as you don’t want it to be attenuated too. You will apply it later, when the entire lighting contribution is properly calculated and attenuated.
Keeping those 3 things in mind, the final calculation in a vertex shader would be:

    float4 LightContrib = (0.f, 0.f, 0.f, 0.f);
    float fAtten = 1.f;

    // 1.- First, we store the total ambient light in the scene (multiplication of material_ambient, light_ambient, and any other global ambient component)
    Out.Color = mMaterialAmbient * mLightAmbient;

    // 2.- Calculate vector from point to Light (both normalized and not-normalized versions, as we might need to calculate its length later)
    float pointToLightDif = mLightPos - P;
    float3 pointToLightNormalized = normalize(pointToLightDif);
    
    // 3.- Calculate dot product between world_normal and pointToLightNormalized
    float NDotL = dot(Nw, pointToLightNormalized);        
    if(NDotL > 0)
    {
        LightContrib = mLightDiffuse * NDotL * mLightDivider;     
            
        float LD = length(pointToLightDif);        
        if(LD > mLightRange)
            fAtten = 0.f;
        else
            fAtten = 1.f/(mLightAtt0 + mLightAtt1*LD + mLightAtt2*LD*LD);
        
        LightContrib *= fAtten;
    }
    Out.Color += LightContrib * mMaterialColor;
    Out.Color = saturate(Out.Color);

 

Comparison

First image is the Programmable version. You can slightly tell it by the reflections on the windows.

Second image is the Fixed Pipeline version (no real time reflections on windows):

Battery charging problems on Samsung Focus (Windows Phone 7)

Yesterday, my Samsung Focus stopped working properly.

I plugged it to the wall for hours, the battery icon showed that it was plugged, but the battery level did not raise. If I unplugged the phone, an immediate message of “Battery critically low” appeared.

After reading some posts, I realized that the battery was in fact being charged, but the OS was not “reading” the battery level correctly.

In my case, as in many others, it was fixed by simply entering the Diagnostics mode of the Samsung Focus, to directly read the “actual” battery level. After that, everything is back to normality.

1.- To enter Diagnostics mode, open the phone keypad and enter: ##634#

2.- To access battery information (and others), type *#2*# in the next keypad that will appear.

And that´s all.

Silver Navigator 1.2 released !

Hi there!

Silver Navigator, ranking top downloads in many countries around the world, is ready for an update, as version 1.2 has just passed through the certification process in the Windows Phone Marketplace. So it´s ready for download!!

This new version includes:

• Local Searches: hotels, restaurants, shops... (might not be available in all countries)
• Map rotation
• Voices volume increased
• Some minor bug fixes
• And much more…

You can follow Silver Navigator 1.2 here, and download it from this Zune Link.

A highly recommendable Windows Phone 7 game development book…

If you want to start, or become an expert on Windows Phone 7 game development using XNA, I´d highly recommend you to buy a.s.a.p the following book:

http://www.amazon.com/Professional-Windows-Phone-Game-Development/dp/0470922443

It´s written by two masters of XNA and fellow MVPs Chris Williams and George Clingerman, and they did a really really good job.

What are you waiting for? Go get it !!

Desarrollo de videojuegos para Windows Phone 7. Conferencia en Zaragoza

Este próximo miércoles día 30, estaré en Zaragoza dando una charla sobre Desarrollo de Videojuegos para Windows Phone 7. Podéis encontrar más detalles del evento aqui:

http://www.cpilosenlaces.com/site/pages/jornadas-tE9cnicas.php

Y descargar el PDF del mismo aqui: jornadas_tecnicas.pdf

Saludos!

Gravitards for Windows Phone 7

Today, Gravitards has been finally released for Windows Phone 7.

“Gravitards is a skill-based game with amazing graphics and real physics, where you have to drive a ball through many different levels, reaching the end zone (or “gravitard”), without dropping it, while collecting rings distributed all around. You´ll find obstacles, moving parts, force fields, guillotines, ramps, jumps, and even a pinball table to play with. Test yourself by controlling the ball with your device’s accelerometer, with on-screen buttons, or with the keyboard, and get the needed practice to complete all the levels.”

You can download Gravitards directly to your Windows Phone 7 using the following Zune link.

Some other videos and pictures:

 

 

Hope you all like it!!!

Como agregar tus contactos de Outlook a Windows Phone 7, sin Exchange, sin aplicaciones ni cuentas de correo adicionales

Como ya sabréis, por el momento Windows Phone 7 no se sincroniza localmente con OutLook. Si no tenéis un servidor de correo compatible con Exchange (ese es el modo recomendado de sincronización para WP7), podéis realizar la sincronización con el dispositivo de varias formas, descritas en detalle aqui.

Companion Link ha sacado una aplicación que supuestamente realiza la sincronización, pero me parece un pufo, ya que necesita de una cuenta de correo de Google para funcionar. O sea, más de lo mismo, y encima te cobran 39 $ por la broma. Podéis descargar la versión trial aqui.

En fin, que a falta de que salga algo mejor, por ahora la mejor manera de añadir (que no sincronizar), tus contactos (solo tus contactos, ni tus citas, ni ná) a tu WP7 es utilizando uno de los métodos sugeridos en el enlace de arriba: a través de un fichero CSV.

Requiere tener un Windows Live ID (que no una cuenta de HotMail), pero mucha gente ya tiene uno, aunque solo sea para jugar a la XBox, así que no es una solución tan mala. Lo que haremos es subir nuestros contactos a la cuenta de Windows Live, con la que el Windows Phone sí se sincroniza.

1.- Preparar tus contactos

Como descubrirás más abajo, el proceso de importación de contactos de Windows Live es bastante puñetero. Falla por un montón de motivos, y algunas veces simplemente ni te dice por qué.

Por mi propia experiencia, para evitar que el proceso falle, revista en OutLook tus contactos, sobre todo los números de teléfono almacenados, ya que al parecer no pueden contener caracteres distintos de a-z A-Z y 0-9.

Así que elimina cualquier aparición de cosas como:

• Espacios
• Prefijos de países con formato +34 y similares. Substitúyelos por “0034”.

2.- Exportando tus contactos a un fichero CSV

Si tiene Outlook 2010

1. Empiece por abrir Microsoft Outlook 2010 en el equipo.
2. Haga clic en Archivo y, a continuación, en Opciones. Haga clic en Avanzadas y, en la sección Exportación, en Exportar.
3. En el Asistente para importar y exportar, seleccione Exportar a un archivo y haga clic en Siguiente.
4. Seleccione Valores separados por comas (Windows) y haga clic en Siguiente.
5. Seleccione Contactos como la carpeta de origen de la exportación y haga clic en Siguiente.
6. Elija una ubicación de archivo y un nombre de archivo, y haga clic en Siguiente.
7. Haga clic en Finalizar. Los contactos deben haberse exportado como archivo CSV.
8. Siga las instrucciones indicadas a continuación en Importar el archivo CSV de Outlook a Windows Live.

Si tiene Outlook 2007

1. Abra Microsoft Outlook 2007 en el equipo.
2. Haga clic en Archivo y, a continuación, en Importar y exportar.
3. En el Asistente para importar y exportar, seleccione Exportar a un archivo y haga clic en Siguiente.
4. Seleccione Valores separados por comas (Windows) y haga clic en Siguiente.
5. Seleccione Contactos como la carpeta de origen de la exportación y haga clic en Siguiente.
6. Elija una ubicación de archivo y un nombre de archivo, y haga clic en Siguiente.
7. Haga clic en Finalizar. Los contactos deben haberse exportado como archivo CSV.
8. Siga las instrucciones indicadas a continuación en Importar el archivo CSV de Outlook a Windows Live.

3.- Importando tus contactos en tu Windows Live

• Importar el archivo CSV de Outlook a Windows Live
  1. Abra un explorador web, vaya a http://contacts.live.com (http://contacts.live.com) e inicie sesión en su cuenta de Windows Live.
  2. Haga clic en Administrar y, a continuación, en Importar.
  3. En la página "Agregar personas", haga clic en Outlook.
  4. Seleccione el botón de radio "Microsoft Outlook (usando CSV)".
  5. Vaya al archivo CSV que exportó a su equipo [pasos 1-7]. 
  6. Haga clic en Importar contactos. Si ya ha agregado la cuenta de Windows Live Hotmail al teléfono, ha terminado. Los contactos se sincronizarán automáticamente con el teléfono cuando inicie sesión en Windows Live desde el teléfono.
     Nota Windows Live tiene un límite de tamaño para carga de archivos CSV de 500 KB. Si su archivo CSV supera los 500 KB, no se cargará y se mostrará el siguiente error: 

     El archivo que deseas importar es demasiado grande. Elimina algunos contactos e intenta importarlo de nuevo.

     Para solucionar este problema, abra el archivo CSV en Excel y divídalo en varios archivos. De esta forma podrá cargar los archivos en Windows Live siempre que el tamaño total de cada archivo no supere el límite de 500 KB.
     Nota Windows Live tiene un límite de almacenamiento de 6500 contactos por usuario.

• Si no ha agregado la cuenta de Windows Live Hotmail al teléfono, siga estos pasos:
  1. En Inicio, vaya a la izquierda en la lista Aplicación, puntee Configuración y, a continuación, Correo electrónico y cuentas.
  2. Puntee Agregar una cuenta y, a continuación, Windows Live.
  3. Escriba la dirección de correo electrónico y la contraseña, y puntee Iniciar sesión.
  4. Una vez iniciada la sesión, los contactos de Windows Live Hotmail se sincronizarán con el teléfono.

Ultimo consejo

Es muy probable que a pesar de las precauciones del punto 1, el proceso te falle en algún punto. Que sepas que Windows Live habrá importado todos los contactos que haya podido hasta que se haya producido el fallo, así que te recomiendo ir a revisar tus contactos, y mirar cual es el último que se añadió.

Una vez sepas cual es, abre el fichero CSV. Te recomiendo hacerlo con WordPad –desactivando el ajuste de línea-, ya que si lo salvas con Excel le cambiará el formato o la distribución de caracteres y no podrás volver a utilizarlo para importar (simplemente te dirá que el fichero está vacío).

Una vez lo tengas en WordPad, borra todas las líneas de los contactos ya agregados, y ve al contacto siguiente al último que se agregó. En él, busca algún carácter extraño que pudiera haber producido el error (si no encuentras nada raro, simplemente borra la línea de ese contacto). Salva el fichero, y vuelve a repetir el proceso.

Así sucesivamente hasta que completes la importación.

Es un rollo, lo sé, pero al menos te permitirá tener todos tus contactos en el móvil.

Ofuscación de código y activación de informes en aplicaciones Windows Phone 7

Nota: Este post es una traducción personal (reconvertida en tutorial) de las explicaciones dadas por Bill Leach (CTO de Preemptive Solutions), en este vídeo grabado para Channel 9.

Introducción

En este artículo se describen los pasos necesarios para proteger el código fuente de aplicaciones Windows Phone (tanto XNA como Silverlight), e incluir en ellas la generación de informes sobre su utilización.

Para ello, se utilizará la herramienta Dotfuscator Windows Phone Edition en su versión 4.9, recientemente lanzada por Preemptive Solutions en colaboración con Microsoft.

En primer lugar, es necesario registrarse y descargar la herramienta desde esta página web. Una vez se recibe por email el número de serie necesario para activar el programa, solo resta lanzar la aplicación: Inicio –> Programas –> Preemptive Solutions –> Dotfuscator.

Interfaz de usuario

Aunque Dotfuscator Professional puede integrarse dentro de Visual Studio 2010, como un tipo de proyecto más, Dotfuscator Windows Phone Edition es una aplicación independiente, con su propio interfaz de usuario:

Como puede apreciarse en la imagen, el funcionamiento es sencillo. Consta de:

• Menú principal y barra de herramientas con las opciones típicas para cargar y salvar un proyecto de ofuscación
• Botón con el símbolo de Play en verde, en la barra de herramientas, el cual comienza la ofuscación del código que se haya seleccionado y genera las versiones protegidas de los ensamblados o programas.
• Pestañas de configuración:
  • Settings: Configuración general de la aplicación
  • Input: Selección de qué ensamblados o ejecutables queremos proteger en el proyecto.
  • El resto: propiedades de configuración para cada una de las funcionalidades que ofrece Dotfuscator

Añadiendo ensamblados o ejecutables

Para empezar a trabajar, lo primero es indicar a Dotfuscator qué ensamblados o ejecutables debe proteger. Para ello, solo hay que ir a la pestaña Input y pulsar sobre el icono de abrir carpeta. Aparecerá el clásico cuadro de diálogo de selección de archivos, donde es posible seleccionar:

• Ensamblados (librerías) de tipo .DLL
• Ejecutables (aplicaciones) de tipo .EXE
• Paquetes de despliegue de Windows Phone (contienen librerias DLL, contenidos, etc), de tipo .XAP. Esta será la opción que se utilizará en el ejemplo que nos ocupa.

Nota: Si, como es el caso, estamos trabajando con proyecto Windows Phone (y archivos XAP), Dotfuscator solo trabajará con los ensamblado que encuentre en dichos archivos. Los contenidos no serán protegidos ni modificados en absoluto.

Una vez se selecciona el paquete XAP a proteger, aparecerán sus contenidos en la ventana inferior, en forma de árbol desplegable:

Si se despliega cualquiera de las DLLs del paquete, aparecerán algunas propiedades de ofuscación activadas, en forma de CheckBoxes. Una de las más relevantes, según los objetivos que persigue este artículo, es la llamada Library:

Manteniendo esta opción marcada (viene marcada por defecto), Dotfuscator deja todos los nombres de los tipos y métodos públicos sin renombrar (sin ofuscar). Los tipos privados sí se renombrarán, y todo el contenido de los métodos se ofuscará, pero los nombres que sean visibles desde fuera permanecerán inalterados.

Esto es necesario cuando una librería, a pesar de estar ofuscada, va a ser utilizada por cualquier otro software después. Si se cambiaran los nombres de los tipos públicos, el interfaz de la librería sería distinto, por lo que dejaría de ser utilizable desde fuera.

Output de la aplicación

Dotfuscator genera versiones protegidas de lo que se selecciona en la pestaña Input:

• Para ensamblados (DLL), genera DLLs protegidas
• Para ejecutables (EXE), genera EXEs protegidos
• Para paquetes Windows Phone (XAP), genera paquetes XAP protegidos

Por defecto, el directorio de salida es el mismo donde se encuentra el ensamblado de entrada, más una sub-carpeta creada por el programa con el nombre Dotfuscated. No obstante, este comportamiento se puede cambiar en la pestaña Settings -> Project Properties -> ConfigDir.

Aplicando una protección básica

Una vez se han seleccionado los Inputs del proyecto, es necesario seleccionar qué tipo de protección ha de aplicarse.

Aunque cada tipo de protección puede ser configurada en profundidad (en sus respectivas pestañas), pudiendo incluso aplicar comportamientos distintos para cada método o propiedad, primero se aplicará una configuración genérica en la pestaña Settings.

Por defecto, todas las protecciones están deshabilitadas, apareciendo de la siguiente forma:

• Disable Control Flow: Yes
• Disable Linking: Yes
• Disable PreMark: Yes
• Disable Removal: Yes
• Disable Renaming: Yes
• Disable String Encryption: Yes

Para una protección básica, lo indispensable es activar la ofuscación de Control Flow y el Renaming. En algunos casos, también puede ser interesante activar el String Encryption, sobre todo si la aplicación a proteger contiene strings con contenido sensible.

Para activar cada funcionalidad, debemos indicar a Dotfuscator que NO las deshabilite, es decir, poner valores como: Disable Control Flow: No y Disable Renaming: No.

Control Flow

La ofuscación del flujo de control se encarga de hacer más difícil la comprensión del código, mediante cambios en el flujo del programa. Aunque el resultado final siga siendo equivalente, a nivel funcional, hace cambios para que no sea nada obvio interpretar por donde va a transcurrir la ejecución, y así dificultar las tareas de ingeniería inversa.

Renombrado

El renombrado se encarga de cambiar el nombre a todos los tipos privados, cambiando los descriptivos nombres originales por valores como: “a”, “b”, “c”, etc. En la pestaña Renaming se pueden excluir a mano, uno por uno, métodos o propiedades que explícitamente se quieran dejar fuera del renombrado. No obstante, para un uso básico, esto normalmente no es necesario.

Con estas funcionalidades activadas, ya se cuenta con una protección básica del código fuente. Ahora se describirá como incluir informes en aplicaciones Windows Phone.

Añadir instrumentación, o Code Analytics

Además de protección y ofuscación, Dotfuscator puede añadir Instrumentación a los programas.

Ambas funcionalidades son independientes. Es decir, se pueden aplicar las dos a la vez, se puede aplicar protección pero no instrumentación, y vice-versa.

La instrumentación utiliza una plataforma de Preemptive Solutions denominada como: Runtime Intelligence. Lo que hace es inyectar en el programa que procesa ciertas líneas de código cuya misión es generar informes de uso del mismo cada vez que este se ejecuta, y subirlos al portal de Runtime Intelligence (u otro), al que cada desarrollador registrado tiene acceso protegido por nombre y contraseña.

Se trata de un comportamiento muy similar al que ofrecen otras plataformas de análisis en otros sectores, como Google Analytics para WebSites, blogs, etc.

La instrumentación se activa/desactiva desde la pestaña Settings, apartado Instrumentation (debemos dejar todas las opciones activadas –Yes-)

Identificando la empresa y la aplicación en los informes

Obviamente, el generador de informes debe saber para qué aplicación está reportando, y para que empresa. Ambas cosas se identifican en la pestaña Instrumentation.

En ella, es necesario expandir el nodo de la DLL que contenga la clase principal de la aplicación:

• Para una aplicación XNA, será aquella DLL que contenga la clase de tipo Game
• Para una aplicación Silverlight, será aquella DLL que contenga la clase App

Una vez desplegado dicho nodo, aparecerá una lista de atributos por defecto, como los de la siguiente imagen (para un ejemplo en XNA).

Para que la instrumentación funcione, es necesario añadirle dos más, pulsando con el botón derecho sobre el nombre de la DLL y seleccionando la opción: Add Attribute. Una vez hecho esto, se abrirá una ventana que pregunta el tipo de atributo a añadir, con una serie de valores predefinidos:

Los dos que hay que añadir son:

BusinessAttribute

Este atributo identificará a la empresa desarrolladora del software, mediante un Company Key único, proporcionado vía email por Preemptive Solutions cuando se efectuó el registro en el portal de Runtime Intelligence. También se puede encontrar en el Dashboard del portal una vez hecho login.

Resulta recomendable incluir además un nombre de empresa.

ApplicationAttribute

Para identificar la aplicación, es necesario proporcionar la siguiente información:

• Application Type: Tipo de aplicación (se puede dejar en blanco)
• Guid: Identificador del ensamblado principal de la aplicación. Debe ser único, ya que será utilizado en el portal para identificar a esta aplicación. En este campo se puede utilizar el Guid del proyecto, disponible en su Assembly Info (accesible en Visual Studio desde el Solution Explorer o desde la ventana de propiedades del proyecto –> Assembly Info).
• Name: Nombre de la aplicación (se puede dejar en blanco, aunque no es muy recomendable)
• Version: Versión de la aplicación (si se deja en blanco, el Reporter tratará de extraerla de los meta-datos del ensamblado).

Indicando dónde se debe inyectar el código

Para indicar a Dotfuscator dónde inyectar el código que genera los informes, solo hay que navegar (sin salir de la pestaña Instrumentation) un poquito hacia abajo, y expandir el contenido aún más la DLL de la parte inferior (en el siguiente ejemplo, la DLL Silverlight: WindowsPhoneApplication1.dll):

Expandiendo uno tras otro los sucesivos nodos, solo resta navegar hasta la clase principal de la aplicación.

• En el caso de un juego XNA, ésta será la clase Game del juego
• En caso de ser una aplicación Silverlight, ésta será la clase App

Informe de comienzo de ejecución

Para informar sobre el comienzo de una ejecución, se busca un método que se ejecute UNA SOLA VEZ en el proceso de inicialización.

En el caso de aplicaciones SilverLight, un candidato perfecto es el evento Application_Launching de la clase App. En caso de una aplicación XNA, una buena opción puede ser el método Initializing de la clase Game.

Una vez seleccionado el método, se pincha con el botón derecho sobre su nombre, y se selecciona la opción Add Attribute. De nuevo, se solicitará el tipo de atributo a añadir, aunque esta vez la lista de opciones es distinta:

El atributo a elegir esta vez es SetupAttribute, el cual tiene bastantes parámetros que se pueden dejar con sus valores por defecto. Aun así, cabe remarcar estos dos:

• Custom Endpoint: En lugar de enviar los informes al EndPoint por defecto (el del portal de Runtime Intelligence), aquí se puede especificar otro EndPoint personalizado
• Use SSL: Activa protección SSL para las comunicaciones

Generar los informes de comienzo en un thread aparte

Si la aplicación que estamos desarrollando tarda cierto tiempo en cargar (algo típico en juegos XNA), lo normal (o más bien lo recomendado) es tener la carga inicial de contenidos separada en un Thread aparte, para que mientras dicha carga se produce, se pueda mostrar un icono animado de tipo Loading…. 

En estos casos, es recomendable incluir la inyección del código de informes en dicho thread, por si la generación del report se demora un poquito por motivos de red, o cualquier otro (aunque no debería). De esta forma la experiencia de usuario no se verá entorpecida.

Si se observa el siguiente ejemplo, en el que se está protegiendo un juego XNA, dicho punto ejecutado en un thread aparte es el método denominado CreateAssets:

Informe de fin de ejecución

Si también se desea que los informes indiquen cuando se dejó de utilizar la aplicación, habrá que seguir un procedimiento muy similar, añadiendo un atributo a un método que se ejecute cuando la aplicación está terminando.

• En el caso de juegos XNA, el método perfecto para esto es OnExiting, de la clase Game.
• Para aplicaciones SilverLight, una buena opción es el evento Application_Closing, de la clase App

En este caso, el tipo de atributo a añadir es TearDownAttribute, el cual se puede dejar con sus parámetros por defecto.

Y con esto y un bizcocho, code-analytics a las ocho

New version of Windows Blocks (1.2) uploaded to Windows Phone MarketPlace

I have just uploaded the 1.2 version of Windows Blocks. It’s waiting for validation, and will be available soon (probably tomorrow). It fixes several bugs found in the game, especially related to slow response of the main menu.

Hope you all like it!

 

Cheers.

Microsoft Coding Camp – Imagina Windows Phone 7

Este próximo fin de semana, Javier Cantón, creo que Vicente Cartas, y yo mismo (los 3 MVPs en DirectX/XNA que estamos en España), estaremos presentes en el Hotel Auditorium de Madrid en el evento Microsoft Coding Camp – Imagina Windows Phone 7.

Si te apetece aprender cómo desarrollar videojuegos para el móvil más cool del momento, y de paso sacarte una pasta vendiendo miles y miles de copias de tus creaciones (no se garantizan resultados ;) je je….), regístrate en el evento haciendo click aqui, y vente por allí, que seguro pasaremos un muy buen rato.

¡Espero veros allí!

Gravitards game for Windows Phone 7

Gravitards is my new, upcoming title for Windows Phone 7.

It was first introduced by Microsoft in the last TechEd Europe 2010 (in Berlin), and will be released very soon. In the meantime, you can see a couple of work in progress videos here:

 

Sounds are still temporary (borrowed from an ancient game), and will be replaced in the first release.

Hope you like it!

Cheers

Windows Blocks for Windows Phone 7 video

Today, I uploaded a video of the game to YouTube. You can watch it here:

 

Hope you like it!

Windows Blocks published in the Windows Phone 7 MarketPlace

  Yesterday, we published our first game for Windows Phone 7.

<<Windows Blocks brings the classic brick-breaker experience to the Windows Phone 7. With tens of different levels, with progressing difficulty, you will be able to check your skills breaking the bricks that block the views of your house, window by window. Test yourself controlling the magnetic platform with your device's accelerometer (other input methods available too), and learn to use all the Power Pills that can be hidden behind the bricks, to help you out with your duty. Go, break'em all ! >>

You can download a trial version from the MarketPlace and buy it if you like it. In the following days, we´ll publish our second game, the first in 3D.

Comments are welcome!

Other Pictures:

 

      

“Error loading pipeline assembly” compile error on Content Projects

If when trying to compile a Content Project you see a “Error loading pipeline assembly” message, and don’t know why, keep reading:
As you already know, the Content Pipeline always executes locally in your Windows machine, to parse and process all the contents into the XNB files. If you don’t have this clear, I´d suggest you to read this Shawn Hargreaves blog post. The above error appears sometimes when you add in your Content Project a reference to a Windows Phone Game Library assembly, or to any other platform game library.
I say “sometimes” because this doesn't happen always. For example, it fails on my laptop, but not in my desktop machine (the first is Vista and second is 7, don’t know if that has anything to do with it).
The problem is that sometimes (especially since Content Projects where separated from regular projects), you need to reference the same assembly from both a Content Project and from a main game project. For instance, if you store in a extra assembly object proxies or descriptions to be used by the XML Intermediate Serializer, you will need them in both the Content Project (to make the serialization), and in the runtime game, to make the de-serialization.
So, if all of them are Windows-XNA based, no problem. But what happens when the main game project is a Windows Phone project? The scenario is:

As I said, if the Aux. Game Library is a Windows Phone game library, for example, it will give you the mentioned compiling problems if you reference it in the Content Project. And if it’s a Windows game library, you won’t be able to reference in the Main Game Project, which is a Phone project. How we solve this?

Creating a Project Copy

Obviously, the solution is to have two different projects/assemblies. One for Windows and another one for WindowsPhone. Of course, as we said that duplicating is wrong, we don’t want to duplicate the classes and code in both projects, so the solution is to create a <<project copy>>: an additional project that produces a different assembly type, but that links to the same source files than the other project.
This is a extremely useful feature automated in XNA solutions (you can always do the same manually in other project types). To do so, you just need to right-click in the Solution Explorer, on the project you want to copy, and select:

• Create a copy of project for Windows
• Create a copy of project for Windows Phone
• Create a copy of project for XBox

The task will be done automatically for you. Now you end up with this scenario:

This way, you can keep the Content Project always referencing Windows Game Libraries, and your main Game project referencing the assembly appropriate for each platform, without duplicating code.
Cheers!

Fixed -problems installing Windows Phone Developer Tools-

Today, I had some troubles first uninstalling my existing CTP release of the Windows Phone Developer Tools (depicted here). It was a required step to be able to install the newest release of these tools.
Now that I managed to uninstall the previous version, I have found other problems installing the newer one. More precisely, the problem appeared when trying to install the Windows Phone Developer Resources package, getting an error like the following in the automatic web installer (it surprisingly required a reboot when starting to install it, and the error did pop up when resuming the install process after the reboot).

I searched in the log file where the individual installer packages were located, and I found the location of the WindowsPhoneDeveloperResources_en.msi file in question. After trying to launch it manually, I received the following errors while trying to register a DLL (that’s probably why the web installer decided to reboot, expecting to be able to register the dll in a fresh Windows start):


After a while trying to find the reason for this, I found this site with similar problems, suggesting to uninstall any Microsoft Silverlight related entry in the Program&Features list. Unluckily, it didn’t work for me.
In my case, I had at the same time Visual Studio 2008 & 2010. I uninstalled the 2008 just in case that was the cause. But no. Again no luck.
Then, as a desperate measure, I tried to uninstall anything related to Microsoft .Net Framework 4, and magically, THAT DID THE TRICK.
Now both the Windows Phone Developer Resources standalone installer and the automatic full web setup work flawlessly. I recommend you using the automatic web setup, as it will download and restore everything: Silverlight, .Net Framework 4, XNA Game Studio 4, etc.
May be it was a combination of factors, so if any of you have similar experiences, please share them here, so we can find out what was going on with it.
Thanks!

How uninstall Windows Phone Developer Tools CTP

If you try to install any newer version of the Windows Phone Developer Tools, you will probably see a dialog box complaining about older versions of these tools, like the CTP, which cannot be updated automatically, and have to be removed before continuing with the new installation:

So, when you go to the Properties & Features window, select the Windows Phone Developer Tools, and click on Remove, you will find that the default uninstaller won’t work, finding the following dialogs:

To properly uninstall these tools, you have two options:

1. 1.- Use the XNA Game Studio Cleanup Tool, which supports the Windows Phone Tools. More info here.
2. 2.- An easier way depicted here: go to your default Windows Phone Tools installation folder (by default: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Microsoft Visual Studio 2010 Express for Windows Phone  CTP – ENU), right-click on the file vs_setup.msi, and select Uninstall.

Et’voilá. Tools uninstalled.

Cheers!

XNArkanoid for Windows Phone 7

A few weeks ago I started a Windows Phone 7 port of my old XNArkanoid.

 

It’s a C#-XNA remake of the classic Taito’s Arkanoid. This version is written in XNA 4.0 for Windows Phone. It’s not finished yet, but you can find all the information and source code at CodePlex:

  http://xnarkanoid.codeplex.com