En esta segunda entrega vamos a hacer un repaso de las opciones básicas de los nuevos mapas:  elegir el tipo de mapa a mostrar, movernos por él de forma programática, y obtener los datos de la posición actual. Como aplicación de ejemplo (que podéis descargar al final de este artículo), tomaremos como base la ya creada en el artículo anterior, a la que añadiremos varias opciones de menú para demostrar el funcionamiento de algunas funciones del mapa.

Si hacemos un poco de memoria, recordaremos cómo en la antigua versión de la API de Google Maps era bastante poco homogéneo el acceso y modificación de determinados datos del mapa. Por ejemplo, la consulta de la posición actual o la configuración del tipo de mapa se hacían directamente sobre el control MapView, mientras que la manipulación de la posición y el zoom se hacían a través del controlador asociado al mapa (MapController). Además, el tratamiento de las coordenadas y las unidades utilizadas eran algo peculiares, teniendo estar continuamente convirtiendo de grados a microgrados y de estos a objetos GeoPoint, etc.

Con la nueva API, todas las operaciones se realizarán directamente sobre un objeto GoogleMap, el componente base de la API. Accederemos a este componente llamando al método getMap() del fragmento MapFragment que contenga nuestro mapa. Podríamos hacerlo de la siguiente forma:

import com.google.android.gms.maps.GoogleMap;
...
GoogleMap mapa = ((SupportMapFragment) getSupportFragmentManager()
                          .findFragmentById(R.id.map)).getMap();

Una vez obtenida esta referencia a nuestro objeto GoogleMap podremos realizar sobre él la mayoría de las acciones básicas del mapa.

Así, por ejemplo, para modificar el tipo de mapa mostrado podremos utilizar una llamada a su método setMapType(), pasando como parámetro el tipo de mapa:

• MAP_TYPE_NORMAL
• MAP_TYPE_HYBRID
• MAP_TYPE_SATELLITE
• MAP_TYPE_TERRAIN

Para nuestro ejemplo voy a utilizar una variable que almacene el tipo de mapa actual (del 0 al 3) y habilitaremos una opción de menú para ir alternando entre las distintas opciones. Quedaría de la siguiente forma:

private void alternarVista()
{
	vista = (vista + 1) % 4;

	switch(vista)
	{
		case 0:
			mapa.setMapType(GoogleMap.MAP_TYPE_NORMAL);
			break;
		case 1:
			mapa.setMapType(GoogleMap.MAP_TYPE_HYBRID);
			break;
		case 2:
			mapa.setMapType(GoogleMap.MAP_TYPE_SATELLITE);
			break;
		case 3:
			mapa.setMapType(GoogleMap.MAP_TYPE_TERRAIN);
			break;
	}
}

En cuanto al movimiento sobre el mapa, con esta nueva versión de la API vamos a tener mucha más libertad que con la anterior versión, ya que podremos mover libremente nuestro punto de vista (o cámara, como lo han llamado los chicos de Android) por un espacio 3D. De esta forma, ya no sólo podremos hablar de latitud-longitud (target) y zoom, sino también de orientación (bearing) y ángulo de visión (tilt). La manipulación de los 2 últimos parámetros unida a posibilidad actual de ver edificios en 3D de muchas ciudades nos abren un mundo de posibilidades.

El movimiento de la cámara se va a realizar siempre mediante la construcción de un objeto CameraUpdate con los parámetros necesarios. Para los movimientos más básicos como la actualización de la latitud y longitud o el nivel de zoom podremos utilizar la clase CameraUpdateFactory y sus métodos estáticos que nos facilitará un poco el trabajo.

Así por ejemplo, para cambiar sólo el nivel de zoom podremos utilizar los siguientes métodos para crear nuestro CameraUpdate:

• CameraUpdateFactory.zoomIn(). Aumenta en 1 el nivel de zoom.
• CameraUpdateFactory.zoomOut(). Disminuye en 1 el nivel de zoom.
• CameraUpdateFactory.zoomTo(nivel_de_zoom). Establece el nivel de zoom.

Por su parte, para actualizar sólo la latitud-longitud de la cámara podremos utilizar:

• CameraUpdateFactory.newLatLng(lat, long). Establece la lat-lng expresadas en grados.

Si queremos modificar los dos parámetros anteriores de forma conjunta, también tendremos disponible el método siguiente:

• CameraUpdateFactory.newLatLngZoom(lat, long, zoom). Establece la lat-lng y el zoom.

Para movernos lateralmente por el mapa (panning) podríamos utilizar los métodos de scroll:

• CameraUpdateFactory.scrollBy(scrollHorizontal, scrollVertical). Scroll expresado en píxeles.

Tras construir el objeto CameraUpdate con los parámetros de posición tendremos que llamar a los métodos moveCamera() o animateCamera() de nuestro objeto GoogleMap, dependiendo de si queremos que la actualización de la vista se muestre directamente o de forma animada.

Con esto en cuenta, si quisiéramos por ejemplo centrar la vista en España con un zoom de 5 podríamos hacer lo siguiente:

CameraUpdate camUpd1 =
	CameraUpdateFactory.newLatLng(new LatLng(40.41, -3.69));

mapa.moveCamera(camUpd1);

Además de los movimientos básicos que hemos comentado, si queremos modificar los demás parámetros de la cámara o varios de ellos simultaneamente tendremos disponible el método más general CameraUpdateFactory.newCameraPosition() que recibe como parámetro un objeto de tipo CameraPosition. Este objeto los construiremos indicando todos los parámetros de la posición de la cámara a través de su método Builder() de la siguiente forma:

LatLng madrid = new LatLng(40.417325, -3.683081);
CameraPosition camPos = new CameraPosition.Builder()
	    .target(madrid)   //Centramos el mapa en Madrid
	    .zoom(19)         //Establecemos el zoom en 19
	    .bearing(45)      //Establecemos la orientación con el noreste arriba
	    .tilt(70)         //Bajamos el punto de vista de la cámara 70 grados
	    .build();

CameraUpdate camUpd3 =
	CameraUpdateFactory.newCameraPosition(camPos);

mapa.animateCamera(camUpd3);

Como podemos comprobar, mediante este mecanismo podemos modificar todos los parámetros de posición de la cámara (o sólo algunos de ellos) al mismo tiempo. En nuestro caso de ejemplo hemos centrado la vista del mapa sobre el parque de El Retiro de Madrid, con un nivel de zoom de 19, una orientación de 45 grados para que el noreste esté hacia arriba y un ángulo de visión de 70 grados de forma que veamos en 3D el monumento a Alfonso XII en la vista de mapa NORMAL. En la siguiente imagen vemos el resultado:

Como podéis ver, en esta nueva versión de la API se facilita bastante el posicionamiento dentro del mapa, y el uso de las clases CameraUpdate y CameraPosition resulta bastante intuitivo.

Bien, pues ya hemos hablado de cómo modificar nuestro punto de vista sobre el mapa, pero si el usuario se mueve de forma manual por él, ¿cómo podemos conocer en un momento dado la posición de la cámara?

Pues igual de fácil, mediante el método getCameraPosition(), que nos devuelve un objeto CameraPosition como el que ya conocíamos. Accediendo a los distintos métodos y propiedades de este objeto podemos conocer con exactitud la posición de la cámara, la orientación y el nivel de zoom.

CameraPosition camPos = mapa.getCameraPosition();

LatLng coordenadas = camPos.target;
double latitud = coordenadas.latitude;
double longitud = coordenadas.longitude;

float zoom = camPos.zoom;
float orientacion = camPos.bearing;
float angulo = camPos.titl;

En nuestra aplicación de ejemplo, que podéis descargar al final del artículo, he añadido una nueva opción de menú que muestra en un mensaje toast la latitud y longitud actual de la vista de mapa.

Y con esto habríamos terminado de describir las acciones básicas de configuración y movimiento sobre el mapa. En los próximos artículos veremos más opciones, como la forma de añadir marcadores o dibujar sobre el mapa.

Puedes consultar y/o descargar el código completo de los ejemplos desarrollados en este artículo accediendo a la pagina del curso en GitHub.

Comienza entonces la cuenta atrás para publicar la segunda parte del curso en formato PDF. Aunque pensaba publicar este segundo volumen como un documento independiente, suplementario al que ya había publicado, finalmente he decidido aunar todo el contenido en un solo documento. Aprovechando esta segunda recopilación he remaquetado todo el contenido para intentar dar al curso una forma mucho más homogénea y parecida a un libro técnico, y así alejarlo un poco de la simple recopilación de artículos que suponía la primera parte publicada. Adicionalmente, he modificado un poco el aspecto visual, he corregido algunas erratas que me habéis ido comunicando, y he sustituido todas las imágenes por su versión a tamaño completo para mejorar su visualización y facilitar la lectura. Espero que todos estos cambios hagan de este documento un recurso de más valor para todos.

El sistema de donaciones para su adquisición se mantiene a través de PayPal, siento no haber podido habilitar finalmente el mecanismo de transferencia bancaria. La donación mínima pasará a ser de 1,50 euros. Espero entendáis y disculpéis este pequeño incremento, pero el libro tiene muchísimo trabajo detrás y creo sinceramente que os merecerá la pena disponer de esta versión completa y revisada del curso, en vez de contar con dos documentos independientes.

Estoy en pleno proceso de revisión del documento, en unos días publicaré un fragmento de muestra para que podáis comprobar su nuevo aspecto, y en algo menos de 2 semanas estará disponible el documento final.

En definitiva, siento la larga espera para ver publicada esta segunda parte del curso, pero espero que el resultado final compense toda vuestra paciencia.

Saludos.

En primer lugar, como ya habréis notados, he creado tres secciones nuevas:

• Presentaciones. Para presentarte a la comunidad.
• Off-topic. Para hablar de cualquier cosa que no quepa en el resto de categorías.
• Tutoriales de la Comunidad. Para que podáis colaborar escribiendo vuestros propios tutoriales y trucos sobre desarrollo en Android.

El último punto me parece muy interesante porque os permite participar en la web de una forma que hasta ahora no se podía: creando vuestros propios contenidos. Ya sabéis, si queréis escribir algún pequeño tutorial, conocéis algún truco interesante, o simplemente queréis dar unas indicaciones de cómo realizar alguna tarea de desarrollo, éste es vuestro foro.

En segundo lugar una novedad que puede interesar a algunos lectores del blog. Dado que estamos tratando temas de Android y que la mayoría somos usuarios de este tipo de moviles/tablets, no podía faltarnos algún mecanismo para poder acceder al foro desde nuestros dispositivos de una forma algo más cómoda que a través del explorador. Para ello, he habilitado el acceso a través de Tapatalk (enlace al market), la aplicación de Android más popular para leer y participar en foros. Es una aplicación de pago (2.99 euros) y creo que no existe versión de prueba gratuita, pero al menos por mi experiencia os puedo decir que funciona bastante bien (probado en HTC Desire con Android 2.2) y hace lo que promete. En fin, otra forma más de acceder al foro, para quien pueda interesar.

Sin embargo, desde hoy mismo, si accedes al blog desde tu movil te encontrarás con un nuevo tema visual que espero facilite enormemente la lectura de su contenido.

Si encontráis algún error o no podéis acceder correctamente a la información rogaría que me avisárais para poder corregirlo lo antes posible.

Muchas gracias.

Sin duda se avecinan malos tiempos para internet. Una verdadera pena… y una nueva mala noticia para este pais que va de mal en peor, para este pais que en vez de invertir esfuerzos en mantener las puertas lo más abiertas posible al conocimiento y al desarrollo de las personas, algo completamente necesario para salir del pozo, se empeñan en dar cada día un nuevo paso atrás. Y esto no es culpa del PSOE ni del PP, sino de la ignorancia de muchos supuestos gurús y de los intereses incorrectos para estos tiempos que corren.

Así nos va…

Entre las novedades más destacadas de la plataforma Mono 2.6 se encuentran la implementación de WCF, el soporte para LINQ to SQL, el nuevo Soft Debugger, la integración de los frameworks ASP.NET MVC, ASP.NET AJAX y Microsoft Dynamic Language Runtime, y la inclusión preliminar de algunas características de C# 4.0 como los parámetros con nombre y los parámetros opcionales.

MonoDevelop 2.2 también se presenta con muchas novedades, entre las que destacan el soporte oficial para Windows y Mac OS, el soporte para múltiples runtimes .NET (multi-targeting), las muchas novedades en cuanto a edición de código (plantillas de código, formateo y generación de código, selección de bloques, …), la enorme ampliación de las opciones de refactorización, y las extensiones para el desarrollo con ASP.NET MVC, Moonlight, IPhone (MonoTouch) y Python.

En definitiva, una buena noticia para el mundo del desarrollo bajo la plataforma .NET en cualquier sistema operativo.

Os animo a probar estas herramientas.

Y para que probemos las novedades han habilitado un enlace independiente al tradicional: http://www2.sandbox.google.com/

Tal como nos cuentan, un usuario de a pié como somos la mayoría no debería notar grandes diferencias al realizar una búsqueda con este nuevo motor, a excepción de algunas diferencias en el orden de los resultados que nos instan a que les comuniquemos a través de los mecanismos de feedback que proporcionan en la nueva web.

Y ahora una reflexión, ¿no os parece un tanto arriesgada esta maniobra? Está claro que la mejora continua y la innovación deben llegar por caminos de este tipo, pero parece extraño que un producto consolidado a un nivel tan alto como el buscador web de Google intente cambiar a estas alturas.

Los conspiranoicos ya hablan de la presión que está ejerciendo el renovado buscador de Microsoft Bing y la reciente noticia de que Yahoo lo utilizará también como su motor de búsqueda. Aunque Matt Cutts, uno de los grandes de Google, intenta dejar claro que la competencia nada tiene que ver con este tema:

Q: Is this Caffeine Update because of Company X or Y is doing Z?

A: Nope. I love competition in search and want lots of it, but this change has been in the works for months. I think the best way for Google to do well in search is to continue what we’ve done for the last decade or so: focus relentlessly on pushing our search quality forward. Nobody cares more about search than Google, and I don’t think we’ll ever stop trying to improve.

En fin, veremos como acaba este experimento, y sobre todo esperemos que Google no mate a la gallina de los huevos de oro que tantos éxitos le ha dado en los últimos años. Y no por Google, sino por el bien de los usuarios y de las búsquedas en internet.

Tres semanas después de la publicación de la última beta, y tras corregir algunos errores y terminar de pulir algunos detalles de la implementación, hoy publicamos por fin la versión final de la librería NRtfTree 0.3.

Además de los cambios ya comentados en la entrada anterior, en esta versión final se incluyen las siguientes actualizaciones:

• Se ha eliminado un fragmento de código redundante en la clase RtfLex que debe ayudar a mejorar aún más el rendimiento de la librería al cargar un documento RTF.
• Se ha corregido un error en las propiedades ScaleX y ScaleY de la clase ImageNode que hacía que los valores devueltos no fueran correctos.
• La propiedad Rtf de la clase RtfTreeNode insertaba bajo ciertas circunstancias espacios en blanco incorrectos cuando la propiedad MergeSpecialCharacters se encontraba activada.
• Se han sustituido los diferentes proyectos de ejemplo por sólo uno en modo consola llamado SimpleDemo.
• Se modifica el formato de los números de versión de la librería a “major.minor.build.revision”.
• Se incluye un nuevo proyecto de test (utilizando NUnit) con pruebas automatizadas de la librería.

Para más infomación sobre los cambios introducidos por las últimas versiones de NRtfTree se puede consultar el historial de versiones del proyecto.

Para descargar la librería puedes acceder la la página de descargas de NRtfTree.

[/lang_es]

[lang_en]

Three weeks ago we released the second beta of NRtfTree 0.3. Since then, we have fixed some bugs you reported and we have been preparing the final release of the library. Today we release NRtfTree 0.3 Final with the following changes since last beta:

• Added a new test project (NUnit).
• Version numbering scheme updated to “major.minor.build.revision”.
• SimpleDemo project updated to console application.
• Removed redundant code in RtfLex.
• ImageNode ScaleX and ScaleY properties returned incorrect values.
• RtfTreeNode.Rtf property inserted incorrect blank spaces when MergeSpecialCharacters property is true.
• RtfTree.Text property returned non-document-text characters in images, objects and field nodes.
• New method RtfTreeNode.SelectSingleChildGroup().

You can get complete information about NRtfTree versions in NRtfTree Changelog.

Download NRtfTree 0.3 now!

[/lang_en]

Un poco antes de lo esperado, acabo de publicar la segunda beta de NRtfTree 0.3.0. Espero cumplir con esto las expectativas de todos los que habéis pedido insistentemente la actualización de la librería.

Para conocer las novedades que trae esta nueva versión os remito a la entrada que escribí hace ya unos días, donde se detallaban todas las nuevas características y los cambios introducidos desde la aparición de NRtfTree 0.3.0. Además, también podéis consultar el nuevo historial de actualizaciones de NRtfTree.

En cuanto a una de las novedades más importantes, la mejora sustancial de rendimiento, también podéis consultar los datos concretos en este otro artículo del blog.

Para aquellos que no conocíais NRtfTree, también he estrenado una nueva sección de preguntas frecuentes (FAQ) donde ire colocando las consultas que más me suelen llegar por correo electrónico, y una nueva sección de ejemplos que espero ir actualizando con pequeños fragmentos de código con los casos de uso más comunes de la librería.

Por último, y como siempre, para descargar esta nueva versión podéis acceder a la sección de descargas de NRtfTree en este mismo blog.

[/lang_es]

[lang_en]

I’ve just published the second beta of NRtfTree 0.3.0.

You can review all the new features and changes of this new version at this post, or you can visit the new changelog section of NRtfTree.

One of the most important features of NRtfTree 0.3.0 beta 2 is a great performance improvement. You can read about this new feature at this post I wrote some days ago.

If you are new to NRtfTree you can also read the new FAQ and Examples sections.

Download now the new version of NRtfTree!

[/lang_en]

Una asignatura que tenía pendiente desde hace bastante tiempo era revisar el rendimiento de NRtfTree. Hasta ahora, este aspecto había quedado en un segundo plano por dos motivos principales:

1. El tamaño de los documentos procesados no suele ser excesivo, lo que hace que el desempeño de la librería no tenga demasiada influencia.
2. En las primeras versiones de la librería resultaba más interesante mejorar en primer lugar las características de la misma, aumentando las funciones disponibles y corrigiendo los errores detectados.

Sin embargo, mi intención con NRtfTree 0.3.0 es que por fin la librería consiga un nivel de madurez por encima de lo mínimamente aceptable, y para ello el rendimiento se convierte, esta vez sí, en un factor clave.

En cuanto a la velocidad de proceso de NRtfTree, el cuello de botella principal se encontraba sin duda en el lexer (clase RtfLex), un módulo que práctimente no se había tocado desde la primera versión de NRtfTee, allá por el año 2005. Analizando las posibles optimizaciones se han detectado dos problemas principales:

1. Cada token generado definía e inicializaba sus propios objetos StringBuilder para el almacenamiento de los datos (palabras clave, parámetros y texto).
2. El analizador consultaba (Peek) y leía (Read) repetidamente los mismos caracteres a la hora de procesar el fichero de entrada.

Ambos problemas se han solucionado fácilmente, definiendo un único StringBuilder a nivel de clase y reescribiendo el analizador de forma que tan sólo lea una vez cada caracter.

Para comprobar el grado de mejora provocado por estos cambios se utilizó un documento RTF sencillo (sólo texto) de 1.3 mb, obteniendo estos resultados respecto al tiempo de carga [ejecución del método RtfTree.LoadRtfFile()]:

No, no hay ningún error, el gráfico anterior es correcto. Dos sencillos cambios en el analizador léxico han conseguido reducir en un factor de aproximadamente 96 veces el tiempo de carga de un documento, consiguiéndose un rendimiento realmente espectacular. Como información adicional, otras pruebas con documentos más complejos (texto+imágenes) de aproximadamente 3, 6 y 11 mb arrojan los siguientes resultados:

Como era de esperar, la relación entre el tamaño del fichero y su tiempo de carga es prácticamente lineal con el nuevo analizador léxico:

Los datos detallados de todas estas pruebas se pueden consultar en este enlace: pruebas rendiento NRtfTree beta1/beta2 [los datos corresponden a un programa sencillo que realiza 5 cargas consecutivas del mismo documento, previa ejecución forzada del recolector de memoria].

En cuanto al consumo de memoria de NRtfTree también se ha conseguido alguna mejora. Hasta la versión 0.3.0 beta1 cada nodo RTF inicializaba siempre su lista de nodos hijos, aunque no los tuviera. A partir de la beta2 esto dejará de ser así, y únicamente los nodos de tipo Grupo incializarán su lista de hijos, a menos que esto se haga de forma manual sobre un nodo de otro tipo. Tras algunas pruebas de carga de documentos, las diferencias entre la beta1 y la beta2 son las siguientes [tomando como ejemplo el documento anterior de 1.3 mb]:

La diferencia se encuentran en los datos marcados en rojo. Mientras que en la beta 1 se utilizan 280236 bytes para almacenar todas las listas de hijos, en la beta2 tan sólo se ocupan 29520 bytes. En total, tras la carga del documento, la beta1 utiliza 1214388 bytes para almacenar el árbol RTF, mientras que la beta2 usa 963672 bytes, lo que supone una reducción de más del 20% para este documento, una ganancia importante tratándose de un documento relativamente pequeño.

En resúmen, con la llegada de la versión de NRtfTree 0.3.0 beta2, hemos conseguido no sólo nuevas funcionalidades y la consolidación de otras funciones antiguas, sino que también se ha mejorado considerablemente el rendiento de la librería, consiguiendo así una versión realmente interesante.

[/lang_es]

[lang_en]

Since first public version, the objective of every new release of NRtfTree was to add new funtionality to the library. In NRtfTree 0.3.0 we also want to improve performance.

The main bottleneck in NRtfTree was the RTF lexer component (RtfLex class). While analyzing source code we dicovered two main problems:

1. Each token define and initialize its own StringBuilder object to load keywords, parameters and text.
2. The lexer Peek and Read the same characters repeatedly.

Both problems has been fixed in versión 0.3.0 beta2. RtfLex now define StringBuilder objects at class level and initialize them setting its lengh to 0 every time it starts a new token, and some methods has been rewriten to read characters only once.

This two simple changes result in a great performace improvement. In our tests, the load time of a simple RTF document (1.3mb, text only) was significantly reduced:

Document Load Time

Yes, the chart is correct. Load time is now over 100 times faster.

Memory allocation has been improved too. In previous versions, each RTF tree node initialized its child node list, even if it had no children at all. In NRtfTree 0.3.0 beta2, only group nodes creates its children list (if node type is not GROUP, ChildNodes property is set to null).

In our tests, memory allocated by a simple RTF document tree (1.3mb, text only) was reduced in about 20%:

[/lang_en]