After getting some inspiration from Eric Burke and discussing it [...]]]> From some time ago we have been dealing with the idea of automating the use of custom fonts in Android apps. By default, you need to manually set the typeface by code view-by-view, as you can’t define it in the layouts. Pain in the ass.

After getting some inspiration from Eric Burke and discussing it with my colleague Xavi Rigau, we were thinking on modify the inflate process to automatically set the font on View objects constructions, so I’ve started to investigate.

Inflating the inflatable Inflate

An inflater has the responsibility of translating an XML layout into a tree of instantiated objects. If you look at the LayoutInflater class (LayoutInflater javadoc) you’ll notice that the way to get an inflater is using the method getLayoutinflater or getSystemService.

In order to modify the behaviour, you must use the method setFactory to provide an object that implements LayoutInflater.Factory interface (LayoutInflater.Factory javadoc). This interface has a single method, onCreateView. This method receives the xml tag from the layout, the current context and a set of attributes from the tag. It could return an instantiated object that will be used to represent the tag, or null, in which case the Factory delegates the responsibility of creating the object to the parent inflater.

I’ve found this incredible article explaining how to use the inflater in order to set a background color menu options: How to change the text color of Android options menu

As we may see in the example, it compares the tag name with the class FQN com.android.internal.view.menu.IconMenuItemView, if it matches, then it creates the View manually and uses it as result of the  onCreateView.

Notice that the change is done in a Runnable object set by a a Handler. This is because after being created the object is still manipulated by the inflater, and the color change will be reverted. Using Handler, we ensure the method responsible of the change will be executed once the execution stack of the thread is empty.

As this example was similar to my objective, I’ve started pulling the thread…

These are not the inflaters you are looking for

My first approach was trying to modify the example in order to instantiate the object whenever the type. But that’s where I got my first surprise.

If the layout tag says TextView, then you will receive the value TextView as onCreateView parameter, but when invoking the createView method, you need to provide the whole FQN: android.widget.TextView.

So, how to match these names for all cases? my first idea was having a list of paired names saying that “this” tag means “that” class. But then I decided to check how actually is Android doing it. After a bit of research, I’ve found that the actual class with this responsability is not in the API, but in the OS source code itself, as it could depend on the device. Here is a link to the right file: PhoneLayoutInflater.java

What? I was expecting something more sofisticated. It just tries some known prefixes for each tags. Keeping in mind that this code could be executed thousands of times in Android,  at least caching the pairs will be nice. Not sure, it looks quite brute force for a method so important.

With all this info, I’ve created my own Factory. You can download it from a sample project in Google Code.

I’ve added two configuration values via string resources:

1. fontInflaterPackages: a list of comma-separated package names that should be tried to concatenate to tag name apart from the system ones
2. fontInflaterTypeface: relative path in the assets folder to the font file to load

There is still a lot of room for improvement, for example, if something is not correctly setup when implementing this Factory the app will crash in a crazy way instead of giving proper errors. And caching the known tag-FQN matches in a map will be nice.

Lowering the coupling

In order to create views, you must invoke the createView method, but this belongs to the LayoutInflater class. In order to avoid excesive coupling, I’ve implemented a reduced version of the method in the factory.

A better way to do that will be implement the Factory interface in a common base Activity class that implements the interface, so you can freely invoke the getLayoutInflater().createView() method.

As said, I did it separated for the sake of the example, but in real world I’ll use a BaseActivity class.

If you download and execute the sample app, you’ll see all widgets in the layout in a nice Comic Sans font (mwahaha!)

I’ve tested the method with bigger apps and it works nice. Except in one case. Fragments.

Ehem… fragments?

Yes, fragments. This doesn’t work with fragments when using the ActivityFragment class from Compatibility library. Why?

A LayoutInflater can only have one Factory assigned at a time, and it can only be assigned once. So, if getLayoutInflater().getFactory() is diferent from null, trying to assign a new Factory will throw an exception. There is a method for cloning the LayoutInflater without factory so you can assign yours, but this doesn’t work in this case.

The class ActivityFragment is quite a weird thing. It is an Activity with extra functionalities, but is not the base class for activities so it implements some things privately that in later versions of Android are supposed to be there.

In this case, ActivityFragment implements the LayoutInflater.Factory interface by itself, and it has its own onCreateView method, as it should treat the tag Fragment in an special way (in fact, if the tag is not fragment, it return null).

So, how to proceed? I think here we should extend the class and override the onCreateView method with our magic tricks, but calling super method when the tag is Fragment.

Finally…

This article is a good example on how to investigate on the source code to find how things work on Android. We as Android developers are lucky to work on a Open Source system that we can strangle to confess how things work.

Keep in mind that I’m talking about several Android mid-low level topics that I’ve investigated and learned by myself, so the probability of saying some nonsense or a stupid affirmation is quite high.

This still needs a lot of testing, as there are many cases to test and pitfalls to avoid. For example, I know it won’t work with viewStubs, as they have their own inflater executed when needed, it just needs more work. Anyways, this is a good start, and of course, any comment or improvement you can propose will be welcomed.

Also, playing with fonts is dangerous. I’ve tested with comic sans for the joke and because it’s easy to recognize when it’s used in comparison with system fonts. But, please, do not use it. It’s ugly, it’s inconvenient and it’s unreadable. Keep Android clean of comic sans. Amen.

RaREST is based on a single configuration file that contains [...]]]> I’ve published a preliminary version of my Rest library RaREST (v.0.9). There are still a couple of things missing (specially logging configuration) and much more testing won’t hurt anyone, but if any of you wants to try it, feel free to download and give feedback.

RaREST is based on a single configuration file that contains all the rest services info needed to invoke them, so it makes the amount of code needed very short.

It supports using services as template for other services, preprocessing and postprocessing of the REST call and many other functionalities.

There is still lack for a lot of improvement (anybody said mulipart?) but is a good starting point.

It’s licensed under Apache 2.0 and you cand find source, downloadables and documentation on http://code.google.com/p/rarest/

Enjoy it!

Me estaba peleando con la camara de Android, y tras “invertir” todo el dia he descubierto una cosilla que a lo mejor os interesa saber.

Estaba llamando a un intent de camara para que me devolviese un fichero, para ello, debemos pasarle un extra con nombre MediaStore.EXTRA_OUTPUT que contenga un objecto Uri apuntando al [...]]]> Hola

Me estaba peleando con la camara de Android, y tras “invertir” todo el dia he descubierto una cosilla que a lo mejor os interesa saber.

Estaba llamando a un intent de camara para que me devolviese un fichero, para ello, debemos pasarle un extra con nombre MediaStore.EXTRA_OUTPUT que contenga un objecto Uri apuntando al nombre.

Pues bien, hay varias formas de generar un Uri con métodos de clase:

a) Uri.fromFile(File newUri)

b) Uri.parse(String newUri)

Parece que ambos deberian generar el mismo contenido, pero…. CATACROCKER!

Uri.parse(“/mnt/sdcard/img/photo.jpg”) genera un objeto uri descafeinado. Vamos, le rellena el campo Uri.mPath y pa casa.

Uri.fromFile(new File(“/mnt/sdcard/img/photo.jpg”)) genera un objeto uri con todas sus propiedades y vitaminas.

Pues si al intent de la cámara le pasas el Uri descafeinado, no funciona, si le pasas el segundo (creado con FIle) funciona perfectamente.

Nada, sólo quería compartirlo.

Update 28-agosto-2012

Como dice kix2902 en los comentarios, el Uri.parse funciona con un path del tipo “file://…”.  Lo que no entiendo es por que con una uri incorrecta parsea mal y se queda tan ancho en vez de lanzar una excepción como toca, o al menos no aparece una indicación en la documentación al respecto.

Yo sigo erre que erre con Maven. El siguiente paso ha sido crearme una plantilla que contenga la info común en los proyectos Android. Esto es, por supuesto, aplicable a cualquier tipo de proyecto. Los pasos son:

Crear un proyecto nuevo para el POM

En Eclipse creamos un proyecto nuevo de tipo Maven, Maven [...]]]> ¡Hola!

Yo sigo erre que erre con Maven. El siguiente paso ha sido crearme una plantilla que contenga la info común en los proyectos Android. Esto es, por supuesto, aplicable a cualquier tipo de proyecto. Los pasos son:

Crear un proyecto nuevo para el POM

En Eclipse creamos un proyecto nuevo de tipo Maven, Maven Project y hacemos clic en siguiente.

Seleccionamos Create a simple project (skip archetype selection) y next.

Introducimos la información del pom. En este caso hablamos de como nos referiremos a nuestra plantilla. Por ejemplo:

• GroupId: com.sergiandreplace.template
• ArtifactId: android
• Version: 0.0.1-SNAPSHOT
• Packaging: pom <– Aquí está la clave del asunto!!!
• Name: Android POM template

Por último hacemos clic en Finish y nos creará el proyecto.

Crear el POM base

En este caso, el pom es parecido al que creamos en el último post sobre maven, pero con algunos cambios.

<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.sergiandreplace.template</groupId>
  <artifactId>android</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>apk</packaging>
  <name>android</name>
  <properties> 
        <android.version>2.1.2</android.version> 
        <android.apkName>compiled</android.apkName> 
        <android.api>7</android.api> 
  </properties>
  <dependencies>
        <dependency>
            <groupId>com.google.android</groupId>
            <artifactId>android</artifactId>
            <version>${android.version}</version>
            <scope>provided</scope>
        </dependency>
  </dependencies>
  <build>
        <finalName>${android.apkName}</finalName>
        <sourceDirectory>src</sourceDirectory>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>com.jayway.maven.plugins.android.generation2</groupId>
                    <artifactId>android-maven-plugin</artifactId>
                    <version>3.1.1</version>
                    <extensions>true</extensions>
                </plugin>
                <!--This plugin's configuration is used to store Eclipse m2e settings 
                    only. It has no influence on the Maven build itself. -->
                <plugin>
                    <groupId>org.eclipse.m2e</groupId>
                    <artifactId>lifecycle-mapping</artifactId>
                    <version>1.0.0</version>
                    <configuration>
                        <lifecycleMappingMetadata>
                            <pluginExecutions>
                                <pluginExecution>
                                    <pluginExecutionFilter>
                                        <groupId>
                                            com.jayway.maven.plugins.android.generation2
                                        </groupId>
                                        <artifactId>
                                            android-maven-plugin
                                        </artifactId>
                                        <versionRange>
                                            [3.1.1,)
                                        </versionRange>
                                        <goals>
                                            <goal>proguard</goal>
                                        </goals>
                                    </pluginExecutionFilter>
                                    <action>
                                        <ignore></ignore>
                                    </action>
                                </pluginExecution>
                            </pluginExecutions>
                        </lifecycleMappingMetadata>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.2</version>
                <configuration>
                    <source>${android.version}</source>
                    <target>${android.version}</target>
                </configuration>
            </plugin>
            <plugin>
                <groupId>com.jayway.maven.plugins.android.generation2</groupId>
                <artifactId>android-maven-plugin</artifactId>
                <configuration>
                    <sdk>
                        <path>${env.ANDROID_HOME}</path>
                        <platform>${android.api}</platform>
                    </sdk>
                </configuration>
                <extensions>true</extensions>
            </plugin>
        </plugins>
    </build>
</project>

Y con esto tendriamos la plantilla. Básicamente, he extraido los valores que cambian de proyecto en proyecto a variables, y además he creado una sección con valores por defecto.

Para publicarlo en nuestro repo local, tan sólo debemos ejecutar un mvn install y el sólo nos lo añadirá.

Ya tenemos la plantilla lista.

Heredar la plantilla

Ahora en nuestro proyecto Android con maven (recordad el mavenize project) tan sólo necesitamos tener el siguiente pom:

<project xmlns="http://maven.apache.org/POM/4.0.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.sergiandreplace</groupId>
  <artifactId>MyApplication</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>apk</packaging>
  <name>android</name>
  <parent> 
        <artifactId>android</artifactId> 
        <version>0.0.1-SNAPSHOT</version> 
        <groupId>com.sergiandreplace.project</groupId> 
  </parent>
  <properties>
        <android.version>2.1.2</android.version> 
        <android.apkName>myapp</android.apkName> 
        <android.api>7</android.api>
  </properties>
</project>

Como veis, aquí le indico, por un lado, de que proyecto hereda la configuración, y por otro lado que valores debe utilizar para las variables. Si  mirais el POM efectivo, vereis que contiene toda la configuración correctamente establecida.

Consideraciones finales

Recordad que si trabajais en equipo, es necesario que todo el mundo tenga las mismas plantillas o la podeis liar muy parda. En ese caso, os recomiendo tener algún repositorio de Maven (p.ej.: Nexus) y tener las plantillas publicadas en el servidor.

El uso de plantillas hace más sencillo el aplicar nuevas configuraciones y opciones a los proyectos existentes, y nos permite configurar los proyectos nuevos de forma más rápida.

Ale, gozadlo.

Por razones que no acababa de entender, no conseguimos hacer funcionar la [...]]]> El pasado sábado tuve la suerte de poder impartir el Bootcamp del Barcelona Startup Wekeend. Durante esta sesión, vimos una introducción al servicio de GAE para montar un servidor rest y como utilizar la libreria AndroidAnnotations para hacer aplicaciones Android de forma rápida.

Por razones que no acababa de entender, no conseguimos hacer funcionar la libreria AndroidAnnotations como cliente rest, y como sospechaba que era un tema de librerias, prometí mirarlo con calma y postear un proyecto que funcionase.

Después de mucho investigar he encontrado la causa de los problemas y he podido solucionarlos.

Relato un poco de donde se originaron.

Spring for Android

La librería Spring for Android alcanzó su “mayoría de edad” recientemente, publicando la versión 1.0.

¿A que uno espera que no haya grandes cambios entre una RC1 y la versión final? pues resulta que sí, que esta versión incluye un gran cambio, y es que, por motivos de rendimiento, ya no se incluye ningún MessageConverter predeterminado. Los MessageConverter son los encargados de traducir el formato recibido y deserializarlo.

Cito de https://github.com/excilys/androidannotations/wiki/Rest%20API:

Prior to the Spring Android 1.0 release, some MessageConverters were included by default when creating a new RestTemplate instance. It is not the case any more, for performance reasons. This means that you need to add those manually.

Y más info en https://github.com/excilys/androidannotations/issues/206

Mientras los chicos de AndroidAnnotations lo arreglan, mi consejo es volver a la Spring for Android RC1.

Jackson

Y por si fuera poco, los amigos de Jackson suben de la 1.9.x a la versión 2. Y después de algunos cabezazos contra la pared leo esto (http://stackoverflow.com/a/10114164):

The problem is that Spring doesn’t work with Jackson 2.0

Vamos, peor imposible.

El código

Como tanto cambio reciente nos pilla a todos un poco a traspiés, el código de ejemplo que he puesto utiliza Spring for Android RC1 y Jackson 1.9.7 que son las versiones que funcionan bien.

Para casos como estos es para los que va bien Maven, ya que os hubiese pasado las dependencias de otro proyecto, y hubiese funcionado a la primera.

Que le vamos a hacer, meses trabajando con unas librerias, y el día que las vuelves a descargar, ha cambiado todo. Ya es verdad que uno nunca va lo suficientemente preparado.

Ah! que no se me olvide, también he subido el código a un repositorio de Google Code, lo podréis encontrar en http://code.google.com/p/bsw-catdroid-bootcamp-2012/. Este simplemente implementa una llamada GET y muestra un Toast por registro. Os dejo como ejercicio hacer el PUT. Cualquier duda, este mismo post puede servirnos de discusión.

Saludos

La verdad, es indecentemente fácil hacer cosas con ella. Subo un ejemplillo para que veais que se hace en un par de horitas con algo de scripting.

He subido una demo de funcionalidades de Appunta al Market.

Podéis encontrarla en el Market de Android

Si alguien se la baja y me comenta si funciona o no funciona, si da problemas o no va bien, lo agradecería enormemente (cervezas gratis para el mejor bughunter!!!)

También he subido el código al repositorio [...]]]> Hola

He subido una demo de funcionalidades de Appunta al Market.

Podéis encontrarla en el Market de Android

Si alguien se la baja y me comenta si funciona o no funciona, si da problemas o no va bien, lo agradecería enormemente (cervezas gratis para el mejor bughunter!!!)

También he subido el código al repositorio por si queréis ojearlo. Ah! y he comprado el dominio appunta.com. Algún dia pondré cosas en el, de momento hay un bonito wordpress dedicado al LoremIpsumismo, pero necesito dormir más de 5 horas por lo menos un día.

Ah, y si tenéis ideas para crear nuevos sistemas de visualización de geodatos, pues estaré encantado de oirlas, que ahora toca engordar la librería con widgets. Así a bote pronto se me ocurre, por ejemplo, un visor de rutas de senderismo donde el azimuth no señale al norte geográfico, si no al último punto de la ruta, así vemos el camino “delante nuestro”. Igual luego implementado es una castaña muy gordo. Igual no.

¿Y algún conejillo de indias con ganas de implementar en su app una librería que cambia casi cada día? ¿Algún amante del riesgo?

Gracias y buenas noches

P.D.: mañana toca catbeer, así que a los androideros tímidos os invito a venir a conocer a la gente de Catdroid, son todos muy majos, bueno, bastante majos, bueno, casi todos

P.P.D: el icono/logotipo es horrendo, lo se, pero de momento no he podido hacer más, está en la lista de cosas “que son importantes, pero no urgentes y no tengo ni idea de cuando las haré”. Se aceptan ayudas y los autores mantienen la autoría, of course

Segundo dia del cuaderno de bitácora de Appunta. Y francamente, estoy pletórico. He conseguido armar algo muy potente con una arquitectura muy, muy sencilla (todavía no he llegado a la docena de clases), y por una vez me quedo lejos de la sobreingeniería.

¡¡¡Y tengo una captura de pantalla!!!

En las [...]]]> Hola!

Segundo dia del cuaderno de bitácora de Appunta. Y francamente, estoy pletórico. He conseguido armar algo muy potente con una arquitectura muy, muy sencilla (todavía no he llegado a la docena de clases), y por una vez me quedo lejos de la sobreingeniería.

¡¡¡Y tengo una captura de pantalla!!!

En las últimas 48h he implementado un montón de cosas:

• Generada la clase abstracta AppuntaView. Esta se encarga de dibujar la vista utilizando tres métodos. Esta es la explicación extraida del Javadoc

This is the base class in order to create Views using the Appunta system. The class has all needed calculations and values to retrieve info from points.

It’s important to understand how this will work. All the stuff happens in the onDraw Method.

The onDraw method has three phases: preRender, pointRendering & postRender.

• The preRender phase triggers the method preRender, used to draw all needed elements used in the background.
• In the pointRendering phase, the method calculatePointCoordinates(Point) is invoked per each on of the points, in order to calculate the screen coordinates for each one of them. Then, they are painted by calling their PaintRenderer.
• In the Post render phase, the postRender(Canvas) method is invoked in order to paint the latest layer

• Este sistema permite implementar nuevas formas de mostrar “geodatos” de forma rápida y sencilla. Pintamos un fondo, decidimos las coordenadas de cada punto dentro del canvas, y barnizamos. Y arreando.
• A partir de esta implementación, RadarView es como 10 veces más pequeño.
• Implementada nueva view (también hereda de AppuntaView) que muestra un panorama donde la distancia se coloca con la altura. Esto con una cámara detras a toda pantalla es una AR de las de diploma.
• Con el objetivo de montarlo bien, he creado una clase que hereda de SurfaceView para mostrar la cámara.
• Tengo que mirar la diferencia entre View y SurfaceView, que me da en la nariz que la segunda me va a venir bien para estas cosas.
• También he documentado más
• ¡Y he subido un bonito sample! muestra algunas ciudades alrededor de Barcelona. Ojo que el punto central no se mueve y constantemente cree que estás en Barcelona. Los LocationServices para otro día. El sample está aquí: http://code.google.com/p/appunta/downloads/detail?name=appunta-sample-20120117.apk

De momento eso es todo (que no es poco). Ahora toca hacer un poco de limpieza y documentación, pero en general estoy muy satisfecho con el trabajo conseguido.

Supongo que huelga decir lo de que se agradecen comentarios, vivas, bravos, bughunters,  donaciones, cheques sopresa, corticoles y cualquier aportación que se desee dar al autor.

Estoy haciendo un motor de Realidad Aumentada GeoLocalizada. Tengo el proyecto al 40%, pero ya se puede enseñar.

Al contrario de otros como Mixare que funcionan como una caja negra, este funciona con un conjunto de pequeños componentes que se comunican entre ellos, permitiendo un alto nivel de personalización, aunque funciona out-of-the-box

De momento [...]]]> Hola

Estoy haciendo un motor de Realidad Aumentada GeoLocalizada. Tengo el proyecto al 40%, pero ya se puede enseñar.

Al contrario de otros como Mixare que funcionan como una caja negra, este funciona con un conjunto de pequeños componentes que se comunican entre ellos, permitiendo un alto nivel de personalización, aunque funciona out-of-the-box

De momento el único componente publicado es un View que permite mostrar puntos en una brújula.

El código es OS con licencia Apache 2.0. Así que, comparte y disfruta, pero menciona y agradece.

Encontrareis el proyecto en http://code.google.com/p/appunta/

Espero tener el módulo de AR “enseñable” en los próximos días. Os mantendré informados.

En el apartado de wiki hay algo de documentación, no mucha, pero habrá más en los próximos días.

Si os bajáis el source, es una app de prueba que muestra el radar con 4 puntos (Madrid, Zaragoza, Toulousse y París). El centro está fijo en BCN, así que estés donde estés ves los mismos puntos. El módulo de posicionamiento está a medias y no lo he publicado. Ojo, que la parte de la activity es sólo para pruebas, con lo que la calidad del código de esa parte deja mucho que desear, ya que es mi pequeño campo de pruebas.

Se aceptan sugerencias, bug-hunting, bug-fixing, groupies y jamones a la dirección de siempre.

Saludos!