Archive

Archive for the ‘Windows Phone’ Category

Windows Phone 8: vuelta a empezar

De todas las novedades que esperaba descubrir de la presentación del nuevo sistema operativo para móviles de Microsoft, había una que, a pesar de (personalmente) tener casi segura, esperaba no escuchar: los móviles actuales no se podrán actualizar.

La respuesta por parte de los usuarios, tras la presentación de la nueva plataforma por Joe Belfiore en el pasado Windows Phone Summit ni se hizo esperar, ni fue en absoluto amable: he oído de todo, con unos cabreos monumentales de gente que, habiendo comprado un flamante Lumia hace diez días, se entera que no se podrá actualizar a la nueva versión a finales de año. Les comprendo. Mi HTC Titan tampoco.

Joe Belfiore presentando WP8 durante el Windows Phone Summit

Había otra opción?

Seguramente si, pero a un precio desorbitado. Desorbitado no solamente por cuestiones económicas, sino por algo que tiene mucho más valor en el mundo de la tecnología que el dinero: el tiempo. Desarrollar simplemente una plataforma para actualizar el parque actual de Windows Phone 7 a 8 llevaría muchísimos meses de trabajo. No hablamos de “actualizar” un sistema operativo, hablamos de “reemplazarlo”: a nivel interno, el cambio del kernel CE al kernel NT es aproximadamente (y es sólo un símil) como tener un PC con Windows, desmontarlo entero, guardar toda la información, instalar Ubuntu y que todos los documentos y programas sigan funcionando… La posibilidad de problemas es simplemente disparada. Mejor dicho: lo raro sería que no hubiese problemas.

Lo cual no quita para que me digan que mi actual móvil con Windows Phone 7 no puede ejecutar Windows Phone 8. A otro con ese cuento…

512 MB. Tan simple como eso.

Sólo se me ocurre un motivo (sí, sólo uno) para que un móvil actual no pueda ejecutar Windows Phone 8 con más o menos elegancia: la cantidad de memoria.

En ningún momento de la presentación se ha hablado de cuánta memoria van a tener los nuevos teléfonos Windows Phone 8, pero algo me dice que de 1 gigabyte no bajan… y posiblemente serán 2. Hablamos del kernel de Windows 8, y para todas las maravillas que nos habéis adelantado hay que incluir infinidad de componentes del sistema operativo de escritorio: por citar alguno, se me ocurren IPv6, VPN, stack bluetooth mucho más completo, contadores de consumo para redes de pago, NFC de “calibre escritorio”, sistema de archivos NTFS “completo”, con todo lo que ello implica, y encriptación con BitLocker y un largo etcétera.

Todos esos componentes requieren espacio, tanto de almacenamiento como de RAM para su ejecución. El almacenamiento es lo de menos (de los 8GB que llevan los móviles actuales que nos quiten 1 para el sistema operativo no me parece mala opción), pero el problema son esos 512 MB de memoria RAM donde tienen que convivir todos ellos… y las aplicaciones.

Apostaría partes vitales de mi anatomía a que Microsoft ha desarrollado durante un largo tiempo (antes de que Nokia fabricase los prototipos que nos mostraron en el Windows Phone Summit) Windows Phone 8 sobre móviles actuales. Apostaría a que hay “builds” de Windows Phone 8 que corren alegremente en un HTC Titan o en un Nokia Lumia 900. Por qué? Porque simplemente “están a huevo”, son baratos, estables y funcionan de maravilla… Pero donde no cabe todo.

“Pero podrían quitarle cosas…”

Y ahí es dónde tuvieron que tomar una decisión. Si los usuarios hoy predicen que esta acción por parte de Microsoft va a provocar la fragmentación de la plataforma (al igual que ocurre con Android), imaginaos lo que sería si no hubiese dos, sino tres plataformas: la que no podrían ejecutar Windows Phone 8 ni locos (los dispositivos de 256MB como el Lumia 610), la que llevarían una versión reducida (los móviles actuales) y los nuevos móviles con “WP8” nativo. Y prefirieron que fueran dos.

Para colmo, tampoco hay consenso a la hora de elegir qué características dejar fuera de ese supuesto WP8 para móviles actuales. Obviamente el candidato número 1 es la conectividad NFC, pero claro… es que los móviles actuales no tienen radio NFC… así yo también. Porque claro, todos queremos IE10, todos queremos la funcionalidad de empresa, o el poder usar las tarjetas de memoria como almacenamiento masivo… Vamos, que lo queremos todo.

Lo malo es a ver cómo justifican todo ésto cuando salga la primera ROM con WP8 para un móvil actual en XDA Developers… Y saldrá.

Fragmentación?

Es el grito unánime de los usuarios: WP8 va a fragmentar la familia. Pero creo que no por donde parece.

Cual es el principal problema en la adopción de Android 4 (en sabores Ice Cream Sandwich y Jelly Bean)? Las operadoras? Los fabricantes? Realmente no: el problema es el resto de los móviles en uso. Hoy por hoy, Android 2.X sigue siendo el líder indiscutible (aunque afortunadamente empieza a ceder terreno). Si soy desarrollador y quiero vender (o ganar dinero) con mi producto, tengo que apuntar al conjunto de usuarios más amplio posible, así que cual creéis que será la plataforma final a la que apuntar? ICS? No. No me queda más remedio (como ya estoy haciendo) que apuntar a 2.X. Afortunadamente, ya pude dejar de soportar Android 1.X!!

Con iOS pasa algo parecido: LTM Mobile debe seguir funcionando en iOS 4. No porque no quiera utilizar las nuevas funcionalidades, ni porque haya usuarios que no actualicen sus móviles, sino porque no pueden (llamativo el número de iPhone 3G – si, si, 3G, no “3GS”!) que siguen pululando por ahí. Y si subo un poco el escalón, el iPad original tampoco recibirá iOS 6.

Siendo realistas, poco hay de iOS 6 que pueda obligar a descartar a un conjunto de usuarios. Con ICS es un poco más delicado, porque (para mí por lo menos) Android 4 es el primer “Android decente” y por fin dispongo herramientas como la aceleración hardware de gráficos imprescindible para una presentación “del siglo XXI”. Pero no puedo: demasiados 2.X por ahí…

Con WP8 pasará algo parecido. Obviando las aplicaciones que requieran de las nuevas características hardware de los nuevos modelos (NFC, por ejemplo), los desarrolladores tendrán que escoger entre desarrollar para WP7 (que podrá ejecutarse en WP8) o desarrollar sólo para WP8. Teniendo en cuenta el parque de móviles WP8 que habrá allá por los inicios de 2013 (aproximadamente: cero), parece bastante seguro que las nuevas aplicaciones que vayan saliendo seguirán funcionando en nuestros WP7 “clásicos”. Luego llegará la dolorosa (y pesadísima) fase de mantener dos versiones hasta que, por fin, cuando pasen los dichosos 24 meses de permanencia y la gente haya cambiado de móvil, podamos dejar de soportar WP7.

Eso no es “fragmentación”… eso es “ralentización” de una plataforma.

Y Nokia?

Nokia lo está pasando francamente mal. Su cotización en bolsa apenas roza los 2 dólares (en 2007 rascaba los 40) y el anuncio de Microsoft no ha hecho otra cosa que empeorar (si aún cabe) más la situación. Ya es difícil salir adelante con la que está cayendo en la economía mundial, pero hacerlo con un producto que ha nacido “obsoleto” es poco más que un presagio de lo inevitable. Y lo triste del caso es que un teléfono Lumia es de todo menos “obsoleto”: su construcción es excelente, sus funcionalidades más que buenas para un público muy general… pero eso no es lo que manda hoy en día. Hoy, o tienes “lo último de lo último” o no tienes nada. O peor aún: tienes “basura tecnológica”. Obviamente no es el caso, pero la percepción generalizada no es esa.

Nada más anunciarse WP8 y que no habrá actualización para el parque actual, AT&T (principal fuente de distribución del Lumia 900 en Estados Unidos) rebajó su precio de 149 dólares (con 24 meses de permanencia) a 49 dólares. Si eso no se llama “liquidación”, que baje alguien y me lo aclare… Si se produce la ralentización en la adopción de la plataforma (entre el desencanto generalizado y que no haya aplicaciones específicas), Nokia puede encontrarse con que no vende los nuevos WP8 y tampoco los WP7… El panorama no es alentador.

Y ahora, en serio Sr. Belfiore: de verdad que no había otra forma?

LocalizaTodo 2.0 para Windows Phone en camino… por fin

Debo confesar que casi me avergüenza escribir este post. Un año sin actualizaciones, sin noticias, sin ninguna mejora que el ya conocido LTM 1.3 disponible para los usuarios de Windows Phone. También hay que decir que es la versión con menos usuarios, pero también se merecen una versión “correcta” del programa. Por fin ha llegado.

Nunca fui feliz con LTM para Windows Phone. De traca, teniendo en cuenta que es la plataforma con la que vivo día a día y con la que más cómodo me encuentro. Las versiones Android e iOS estaban a años luz particularmente en una cosa que considero fundamental: la fluidez y agilidad de uso.

Durante un año – y esto lo saben los que tengo a mi alrededor y me aguantan mientras paso horas sentado delante de un teclado – he buscado usar LTM en “otras” plataformas en lugar de en mi propio teléfono. En casa, en lugar de mi móvil, he estirado el brazo para alcanzar un iPad (de primera generación y herramienta de desarrollo para las versiones iOS de LTM) para hacer cualquier búsqueda o ver cómo iban funcionando las regatas en las que participamos como proveedores de localización. Nunca usaba mi teléfono, ni siquiera hacía “demos” con él. No me he sentido satisfecho.

Y por qué? Pues simplemente la experiencia de usuario no era correcta. Y eso siendo benévolo, debo decir. Mover el mapa de un lugar a otro era simplemente “torpe”. Y si, he dicho “era”…

Hace un tiempo me senté (de nuevo) en casa, decidido a arreglar ese desbarajuste. El problema tenía que estar centrado en un par de decenas de líneas de código – todo lo demás era “correcto”. Así que empecé a asumir todo lo aprendido en otros desarrollos que he realizado en Silverlight y WPF y me decidí a aplicarme a implementarlo en LTM. Se resume en una sola cosa: aplicar aceleración hardware de los gráficos a todo el sistema de mapas.

Y vaya que si se nota. Asumiendo que el hardware puede hacer las cosas infinitamente más deprisa que el mejor software (doloroso, pero cierto), he aprendido a escribir componentes que no intentan hacer las cosas lo más deprisa posible, sino hacerlas de la forma en que el hardware pueda ayudarme más. El resultado es, simplemente, asombroso.

Una vez solucionado el problema de la lentitud del mapa a cualquier solicitud del usuario (exacerbante a ratos), me puse a añadir todo lo nuevo que incluyen las otras versiones de LTM y que ha sido (ríanse, oigan) lo que más tiempo me ha llevado. La parte más compleja ha sido el track.

Pero aquí está: la flamante versión 2.0 de LTM para Windows Phone. A horas de aparecer en el Market (y que os aparezca la notificación de actualización).

LTM-20-WP7-02

¿Qué tiene de nuevo?

Debo decir que “nuevo, nuevo”, poca cosa trae. Más que nada porque ya lo tienen sus hermanos para Android e iOS. Lo realmente “nuevo” va por dentro y es el motor gráfico acelerado por hardware. Si alguno de vosotros puede probar esta nueva versión y compararla con las otras, me encantaría conocer sus opiniones – en serio.

Pero como los usuarios de LTM no tienen por qué leer este blog (seamos realistas: a quien le interesan las interioridades técnicas de un programa salvo a un tecnofriki como yo?), me permito enumerar un poco las nuevas capacidades del programa.

Obviamente, las vistas de barcos y aviones son viejas conocidas de los usuarios. Poco que contar aquí (creo recordar) salvo el nuevo “pulido gráfico” que ha sufrido el programa. Y esto va para todos los usuarios: deberíais notar un importante incremento en la cobertura de aviones (y nuestro trabajo nos está costando). Ha sido uno de los mayores problemas de LTM, uno de los más criticados, y uno de los más difíciles de solucionar. Y no tiene nada que ver con el software, sino con todo lo que hay “detrás”.

ltm-20-WP7-01Finalmente, lo usuarios de Windows Phone podrán conocer la posición de otros usuarios del programa y de nuestro viejo conocido WayTRKR, y publicar la suya si lo desean.

LTM para Windows Phone incorpora un tracker realmente en segundo plano. En las demás versiones, LTM debe seguir corriendo (minimizado, pero corriendo) para publicar la posición – no es el caso de la variante Windows Phone, que utiliza nativamente el sistema de tareas en segundo plano. Usando este sistema, LTM registra un componente separado de la aplicación principal, con un uso mínimo de recursos. El sistema carga periódicamente el componente y le da la oportunidad de realizar su trabajo, conservando la batería para lo realmente importante: lo que el usuario quiera. El inconveniente? que actualmente el track se realizará cada 30 minutos.

Nota abierta a Microsoft: Hola Microsoft. Sí, las tareas en segundo plano están realmente bien, pero por favor: si estáis leyendo esto, permitid a los desarrolladores solicitar otros periodos de trabajo que no sean los “30 minutos” establecidos por defecto. Sí, vosotros y yo ya sabemos de qué API estamos hablando, verdad? Bueno, pues ese. Y sí. me comprometo a complicarme la vida en certificación lo que haga falta. Pero no soy el único que está deseándolo.

Y ahora, qué?

Ahora sólo espero que os guste y que perdonéis el tiempo que he tardado en daros una versión a la altura de LTM para Windows Phone. Probadlo y decidme si está a la altura de vuestras expectativas. Y si no lo está, en qué se puede mejorar.

Con Windows Phone 8 Apollo “en puertas” (se espera para fin de año, junto con Windows 8), aparece una disyuntiva curiosa en el horizonte. Microsoft ha anunciado que todo el software WP7 correrá en WP8 sin modificación. Vale, me quedo tranquilo… pero ya estoy investigando otras implementaciones (WinRT, allá voy!).

Tutorial: Leer Twitter en Windows Phone 7 con el mínimo esfuerzo

En este tutorial vamos a comprobar lo sencillo que es explotar servicios online en una aplicación Windows Phone 7 y de paso conocer un poco más las herramientas de desarrollo para esta plataforma.

Actualización: Lo siento mucho chicos, pero Twitter cambió hace unos meses su API para evitar, precisamente, aplicaciones como esta. Las técnicas de programación para Windows Phone siguen siendo válidas, pero mucho me temo que descargar los tweets, ya no.

Aunque parezca increíble, no tengo cuenta en Twitter. Sí, lo sé, podéis decirme lo que queráis, creo que simplemente no es para mi. Lo cual no quita para que sea un ávido lector de tweets de mucha gente, particularmente de fuentes técnicas y si (debilidad de uno) del mundillo de la Fórmula 1 y del de motociclismo. La ventaja es que no hace falta tener cuenta en Twitter para leer los mensajes de otros, y el portal pone a disposición de los programadores un amplísimo surtido de servicios web para acceder a la información.

Así que vamos a hacer, paso a paso, un lector de Tweets para Windows Phone 7. Para este tutorial he utilizado Visual Studio 2010 junto con el SDK de Windows Phone 7.5 Mango, pero vamos a seleccionar como “target” Windows Phone 7.0 “actual”.

Crear el proyecto

El primer paso es abrir VisualStudio y crear un nuevo proyecto para Windows Phone 7: seleccionamos el menú “File”, “New”, “Project” y podremos elegir el tipo de proyecto que deseemos. De las plantillas instaladas buscaremos “Visual C#”, y dentro de éstas “Silverlight for Windows Phone”. A la derecha podremos elegir “Windows Phone Application”.

En la parte inferior del diálogo de creación del nuevo proyecto escogeremos un directorio de trabajo y un nombre para nuestro nuevo y flamante programa. Yo he llamado al mío “tweetRead”:

image

En la parte superior del diálogo aparece un selector con la versión a utilizar de .Net Framework: dado que vamos a realizar una aplicación para WIndows Phone, la selección es indiferente, porque el target es Silverlight para WIndows Phone.

Una vez creado el proyecto, aparecerá abierta la página principal en Visual Studio, listo para empezar a realizar cambios:

image

Perfilemos el interface de usuario

Visual Studio crea un proyecto a partir de una plantilla con el formato predeterminado de las aplicaciones para WP7. En nuestro caso, vamos a reducir el interface para ir directamente a la implementación. Así que buscaremos en el fuente XAML el fragmento que define la cabecera de la aplicación (“TitlePanel”) y lo reemplazaremos por una Grid con los controles que nos permitirán seleccionar un usuario de Twitter. Vamos a reemplazar totalmente este fragmento:

<StackPanel x:Name=”TitlePanel” Grid.Row=”0″ Margin=”12,17,0,28″>
<TextBlock x:Name=”ApplicationTitle” Text=”MY APPLICATION” Style=”{StaticResource PhoneTextNormalStyle}”/>
<TextBlock x:Name=”PageTitle” Text=”page name” Margin=”9,-7,0,0″ Style=”{StaticResource PhoneTextTitle1Style}”/>
</StackPanel>

Por este otro:

<!–ContentPanel – place additional content here–>
<Grid x:Name=”TitlePanel” Grid.Row=”0″ Margin=”12,17,0,28″>
<Grid.RowDefinitions>
<RowDefinition/>
<RowDefinition/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition/>
<ColumnDefinition Width=”Auto”/>
</Grid.ColumnDefinitions>
<TextBlock Grid.Row=”0″ Grid.ColumnSpan=”2″ Text=”Tweets recientes de”/>
<TextBox Grid.Row=”1″ Grid.Column=”0″ x:Name=”tweetName”/>
<Button Grid.Row=”1″ Grid.Column=”1″ Content=”Ir!” x:Name=”btnLoad” Click=”TweetLoadClicked” />
</Grid>

Hemos reemplazado la cabecera clásica por algo un poco más “funcional” en nuestro ejemplo: un campo de texto donde el usuario escribirá la fuente de tweets que desea leer y un botón que lanza la descarga. Hemos aprovechado incluso para definir qué función se encargará del evento “Click” del botón, la función “TweetLoadClicked”. En cuanto hayamos pegado este fragmento, la simulación del interface cambiará completamente a algo parecido a esto:

image

Un poco más abajo se declara una Grid con el contenido de la página del programa. En este caso vamos a añadir un control ListBox que será el que finalmente muestre los mensajes:

<!–ContentPanel – place additional content here–>
<Grid x:Name=”ContentPanel” Grid.Row=”1″ Margin=”12,0,12,0″>
<ListBox x:Name=”tweetFeed”>
</ListBox>
</Grid>

Al código!

Ahora es cuando vamos a empezar a añadir funcionalidad a la aplicación. Para ello, hacemos doble click sobre el archivo de código del formulario (MainPage.xaml.cs), para encontrarnos con el desolador espectáculo de una clase que no hace “casi” nada:

image

Si recordamos de antes, tenemos un TextBlock cuyo evento “Click” va a ejecutar la función TweetLoadClicked. La función iniciará la descarga de los tweets usando el nombre tecleado por el usuario:

private void TweetLoadClicked(object sender, RoutedEventArgs e)
{
WebClient tweetRequest = new WebClient();
tweetRequest.DownloadStringCompleted += new DownloadStringCompletedEventHandler(DownloadComplete);
tweetRequest.DownloadStringAsync(new Uri(@”
http://api.twitter.com/1/statuses/user_timeline.xml?screen_name=” + tweetName.Text));
}

El método DownloadStringAsync() de WebClient simplemente descarga el contenido de la url que le demos y una vez terminado invoca el evento que se haya definido en DownloadStringCompleted (en nuestro caso, será la función “DownloadComplete”). Así que para poder experimentar un poco, vamos a empezar la función y ver qué pasa:

void DownloadComplete(object sender, DownloadStringCompletedEventArgs e)
{
System.Diagnostics.Debug.WriteLine(e.Result);
}

Si ponemos un breakpoint en la línea con el WriteLine y ejecutamos el programa, podremos ver si funciona. Así que pulsamos F5, arrancará nuestro querido emulador y nuestro programa tomará el control. Vamos a pedir tweets de Engadget, a ver qué pasa:

image

Cuando pulsemos el botón “Ir!” la función TweetLoadClicked comenzará su trabajo y empezará a descargar el contenido usando los APIs de Twitter. Unos segundos más tarde, VisualStudio se detendrá en el breakpoint con los resultados. Basta con colocar el ratón sobre la palabra “Result” para que aparezcan los contenidos:

image

Si necesitamos analizar la información con más detalle, podemos emplear el visor que aparece al selecciona el menú con la lupa a la izquierda y seleccionar el visor XML:

image

Veremos directamente la información XML enviada por Twitter:

image

Mostrando los resultados

Bueno, esto está muy bien, pero ahora toca ver los resultados de nuestros denodados esfuerzos de programación. Lo primero, vamos a desensamblar los contenidos XML de la respuesta del servidor en algo un poco más manejable, y para ello usaremos nuestro querido XmlReader para ir desensamblando los fragmentos de información enviados por el servidor. Pero antes, vamos a crear una clase que contiene la información de un tweet. Para ello, en VisualStudio pulsaremos con el botón derecho sobre el proyecto tweetRead y seleccionaremos “Add Class” (añadir clase):

image

Como nombre de archivo emplearemos “Tweet.cs”, y usaremos el código siguiente:

using System;

namespace tweetRead
{
public class Tweet
{
public string message { get; set; }
public string userName { get; set; }
public String imageUrl { get; set; }
}
}

Volviendo a la función DownloadComplete, vamos a cambiarla por algo más “funcional” que lo que hasta ahora hace:

void DownloadComplete(object sender, DownloadStringCompletedEventArgs e)
{
List<Tweet> Tweets = new List<Tweet>();
using (System.Xml.XmlReader reader = System.Xml.XmlReader.Create(new System.IO.StringReader(e.Result)))
{
while (reader.ReadToFollowing(“status”))
{
reader.ReadToFollowing(“text”);
String msg = reader.ReadElementContentAsString();
reader.ReadToFollowing(“user”);
reader.ReadToFollowing(“name”);
String user = reader.ReadElementContentAsString();
reader.ReadToFollowing(“profile_image_url”);
String url = reader.ReadElementContentAsString();

      Tweets.Add(new Tweet()
{
message = msg,
userName = user,
imageUrl = url
});
}
}
tweetFeed.ItemsSource = Tweets;
}

Empleando un XmlReader, recorremos los elementos de respuesta del servidor, creando instancias de nuestra clase Tweet y almacenándolos en un array. Una vez leídos todos, asignamos el array como origen de datos (ItemSource) del ListView.

Sólo queda una cosa por hacer: definir el formato de cada Tweet en nuestro interface de usuario. Si recordáis, nuestro ListView estaba completamente vacío, pero le estamos pasando directamente una colección de objetos Tweet. Para definir el aspecto final de un Tweet en el interface de usuario, añadiendo simplemente la definición para “un ítem” definiendo el “ItemTemplate” del control, incluyendo propiedades que debe presentar. Así que vamos a ampliar la declaración del ListBox con el formato completo:

<!–ContentPanel – place additional content here–>
<Grid x:Name=”ContentPanel” Grid.Row=”1″ Margin=”12,0,12,0″>
<ListBox x:Name=”tweetFeed”>
<ListBox.ItemTemplate>
<DataTemplate>
<Grid Margin=”0,0,0,10″>
<Grid.ColumnDefinitions>
<ColumnDefinition Width=”Auto”/>
<ColumnDefinition Width=”*”/>
</Grid.ColumnDefinitions>
<Image Grid.Column=”0″ Source=”{Binding imageUrl}” VerticalAlignment=”Top”/>
<Grid Grid.Column=”1″ Margin=”5″>
<Grid.RowDefinitions>
<RowDefinition/>
<RowDefinition/>
</Grid.RowDefinitions>
<TextBlock Grid.Row=”0″ Text=”{Binding userName}” VerticalAlignment=”Top” Style=”{StaticResource PhoneTextAccentStyle}”/>
<TextBlock Grid.Row=”1″ Text=”{Binding message}” TextWrapping=”Wrap” VerticalAlignment=”Top” Style=”{StaticResource PhoneTextNormalStyle}”/>
</Grid>
</Grid>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
</Grid>

El “truco” es, simplemente, el valor para los campos que nos interesen de los controles (Text en nuestro caso). En lugar de establecer un valor concreto, empleamos la sintáxis “{Binding <campo>}”, haciendo que los controles “busquen” una propiedad con ese nombre del ItemSource (en el caso del ListBox) que le asignemos, que es la única fuente a la información que el código ha tenido que establecer. De igual manera, el control imagen tiene asignada su propiedad Source a otro de los campos.

Esta es la parte fantástica de Silverlight: en el código no hay absolutamente ninguna referencia al formato en pantalla de los datos, simplemente se preparan, se “empaquetan” y se le envían al interface de usuario. El interface “sabe” cómo debe presentar los datos, pero desconoce totalmente el origen o formato original de los mismos. De esta forma, manipular el formato en pantalla, adaptarlo a otras resoluciones o formatos, se convierte en una tarea totalmente desvinculada de la programación.

Como prueba final, vamos a ver cómo queda el programa con todos los cambios:

image

No es el cliente Twitter definitivo, pero para estar hecho en media hora no está mal. Lo importante es lo sencillo que es consumir servicios web desde Windows Phone y la potencia del databinding para separar el código de la presentación.

Categorías:Desarrollo, Tutorial, Windows Phone Etiquetas: , ,

Dónde estamos?

Steve (Jobs) tenía razón: el iPad es mágico. Pones 40 unidades en una tienda y desaparecen de golpe…

PlayersEs viernes por la tarde y Vicky y yo salimos de uno de esos centros comerciales llenos de juguetes tecnológicos que tanto me gustan. Íbamos a por algo en concreto, algo que a los dos nos encanta: la nueva entrega de la saga Lego Star Wars. No conseguiré que sea mi artillera de apoyo en Rainbow Six, pero por nada del mundo cambiaría esas tardes que nos pasamos los dos jugando a las sagas de los pequeños muñecos de plástico animados magistralmente por Traveller’s Tales. Casualmente también era el día del lanzamiento en Europa del iPad 2. Y siendo Vicky como es, adicta a su iPad, hicimos el intento de acercarnos por la zona Apple para echar un vistazo al nuevo producto de Apple. Fue totalmente imposible. Una cola de veinte personas esperaban pacientemente que les entregasen sus nuevos iPads, mientras una maraña de gente intentaba (en algunos casos, de forma un tanto agresiva) tocar el maná de Steve que en forma de dos unidades de demostración yacían sobre la mesa – si yo hubiese sido uno de esos iPads, hubiese pasado mucho miedo.

Mientras unos lucen con orgullo su manzanita y otros disfrutan con la inmensa diversidad de sus móviles Android que pululan por todas partes, un tercer participante está oculto en las sombras y no quiere, o no le permiten, asomarse al ruedo: Windows Phone.

Al igual que Vicky no suelta su iPad ni loca, tampoco se te ocurra decirle que le quieres cambiar su LG Optimus 7 por otra cosa. Pero todavía no he visto absolutamente a nadie más (ni siquiera en los círculos “frikis” en los que me muevo) con un teléfono con el nuevo sistema operativo de Microsoft. En las tiendas no hay ninguno, en los mostradores de las operadoras puedes encontrar alguna maqueta si se equivocan y ponen una, y no verás un triste anuncio en televisión o en prensa. Windows Phone 7 no existe para el común de los mortales, a pesar de contar con una base de más de 10000 aplicaciones (y subiendo deprisa, muy deprisa). Me pregunto si será igual en el resto del mundo.

Y mientras espero tranquilamente que la operadora de turno me permita acceder a Nodo en mi HTC Trophy y en el LG de Vicky, pienso en los dos “grandes” del mundo del Smartphone.

Apple tiene, para mi gusto, un hardware absolutamente excepcional. Son bonitos, elegantes (a las mujeres les encantan y eso es un punto francamente importante cuando quieres comprarte un “juguete”, amigo!), y funcionan de maravilla. En cambio en cuanto a software comparte (siempre a mi modo de ver) un “defecto” con su contrincante Android: el concepto “tengo una aplicación para eso”. No va conmigo, que prefiero una experiencia más integrada y que WP7 me provee sobradamente. Pero me parece obvio que, para que unos contendientes tan diferentes se estén disputando a puñetazos el “trono” del “rey del Smartphone” hace falta detrás una plataforma de marketing que sepa hacer su trabajo.

Y eso es lo que parece que Microsoft NO tiene, a pesar de todo el poderío del gigante del software. Estos días veo una caída brutal de precios en dispositivos Windows Phone 7 – prácticamente un 40% menos que hace un par de meses, en los sitios de compra online (si, claro, porque en las tiendas no los tienen y mucho menos libres). Eso, unido a que NoDo para WP7 está listo desde (ejem) el pasado mes de diciembre pero no hay manera de que llegue a nuestros dispositivos y sumado al reciente acuerdo de colaboración con Nokia, me dan que pensar de lo que pueda estar pasando en los despachos.

Por una parte, HTC ve como su mercado basado en el sistema operativo de Windows (con el que siempre han hecho un trabajo excepcional mejorando la experiencia de usuario) se diluye al no poder personalizar el sistema operativo y diferenciarse de sus competidores. Y si el objetivo de la diferenciación es alejarse de Nokia, puede implicar una indecente cantidad de recursos que, simplemente, no compensan el esfuerzo que tendrían que realizar, mientras que su trabajo en Android les ha convertido en el fabricante de referencia de la plataforma. Y otros OEMs con, quizá, menos “poderío” que HTC como son Samsung y LG ven que, de una tarta de la que ya de por sí pueden capturar un trozo bastante pequeño, ahora tienes que compartirla con el nuevo contendiente. Para colmo, ellos no van a tener las facilidades que va a tener Nokia para adaptar la plataforma.

Y no olvidemos a las operadoras. Microsoft no ha conseguido lo que tiene Apple: la capacidad para “saltarse” a las operadoras y llegar directamente a los usuarios con las actualizaciones de sus aparatos. La infraestructura existe, pero no se les permite usarla – las operadoras quieren controlar los dispositivos, básicamente para que, aburrido de esperar una actualización que no llega nunca, te des por vencido y tengas que cambiar de aparato y firmar por otros 12, 18 ó 24 meses de permanencia. Y, por supuesto, que ahora que el personal de las tiendas está perfectamente aleccionado para vender dos plataformas – no sabrían qué hacer con una tercera.

Se quedará Nokia como principal fabricante de móviles Windows Phone 7, junto con algún fabricante chino que apunte al segmento “económico” (el rumoreado Chasis-2)? Abandonarán los demás fabricantes una plataforma que les da prácticamente cero posibilidades de diferenciarse de su competencia? Seguirán las operadoras estrangulando el acceso de Microsoft a los usuarios para que lleguen las actualizaciones?

O eso, o Microsoft tiene preparada una traca con un nuevo móvil y un tablet Windows 8 (no Windows Phone: sólo “WIndows”) con un interface de usuario basado en Metro. Recordemos que Intel, con sus nuevos procesadores Atom, está como loca por entrar en el mercado de los handheld, del que fué desterrada hace mucho tiempo, cuando el mundo decidió que había que usar procesadores ARM. Veremos un tablet capaz de ejecutar Office?

Mientras tanto, los iPads siguen desapareciendo…

LocalizaTodo 1.2 para Windows Phone 7, en camino

Por si alguien se ha fijado, podrá comprobar que acaba de aparecer en el Market de Windows Phone 7 una actualización (versión 1.1) de LocalizaTodo para ésta plataforma. Todo sería estupendo, si no fuese porque aparece en la sección de “juegos y puzzles”.

Actualización: Acabo de recibir la notificación, la versión 1.2 ya está disponible (puede que tarde un rato en aparecer). Podéis acceder a la misma pulsando aquí (abre Zune).

La pantalla principal... cuantas diferencias encontráis?

No, no es que hayamos cambiado radicalmente el destino del programa ni nada por el estilo. Por resumirlo, simplemente decir que una primera actualización fue rechazada por Microsoft (con toda la razón: tenía tendencia a explotar en determinadas circunstancias y la verdad es que en el informe venía detallado paso a paso cómo hacerlo). Esa fue la primera noticia que recibí un bonito sábado por la mañana, e inmediatamente me puse a comprobarlo (como papá de la criatura te cuesta mucho creer en los defectos de tus retoños) para, tristemente, confirmar que en efecto, así ocurría. Una vez enviado el nuevo programa corregido, descubro un posible “bug” en el portal de Microsoft: la información asociada al programa (descripción, sección de destino, pantallas descriptivas) habían “volado”. Lamentablemente, hoy por hoy (esto es un toque a los amigos de Microsoft) el proceso no se puede detener, ni solicitar que cancelen las pruebas. Hay que llegar al final y, como ha sido en este caso, hasta el MarketPlace: a la sección de juegos y puzzles.

Lo malo es que durante la semana previa ya había estado haciendo nuevas incorporaciones a LTM. Muchas. Montones. Así que ante la opción de recompilar la versión anterior y volver a subirla y “terminar” lo que tenía a medias, opté por la segunda. Tenía de tiempo hasta que Microsoft completase la certificación, momento en el cual podría añadir una nueva actualización. Y si no me daba tiempo, siempre podía volver a subir la versión anterior. Anoche lo terminé y esta mañana me llegó el email de confirmación de Microsoft: la versión 1.1 había pasado las pruebas y ya podía subir la 1.2.

Qué hay de nuevo?

La principal diferencia con la versión 1.0 original (e incluida ya en la versión 1.1) es el uso de la barra de menú transparente… No sé, me dio la impresión de que “se ve más”…

También se incluye la visualización de la nacionalidad del buque (de momento sólo en barcos, ahora vamos con los aviones) junto con su bandera. Y si, es posible que alguien se haya fijado: la velocidad del barco aparece en Km/h! No, no es un error… Ahora las unidades de presentación son seleccionables: métrico, imperial y náutico.

LTM2

La principal novedad: por fin llega la información detallada, tanto de barcos como de aviones, accesible con ese pequeño botón “i” en el panel de información:

LTM3LTM4

Si todo sale como se espera, la nueva versión estará disponible en unos días, tras la correspondiente verificación. Y si, esta vez me aseguré (por triplicado) de que todo iba como debía… no volveré (espero!!) a cometer el mismo error.

Y mañana, a hacer lo mismo en iPhone…