Sergi & Replace

Appunta: demo disponible!

sergi — Thu, 19 Jan 2012 00:23:17 +0000

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

Appunta saca la otra patita, y oiga, es una pata muy gorda

sergi — Tue, 17 Jan 2012 00:11:24 +0000

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.

Appunta – un motor de AR

sergi — Mon, 16 Jan 2012 09:54:28 +0000

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!

Imágenes con esquinas redondeadas

sergi — Sat, 14 Jan 2012 12:34:10 +0000

Hola

A partir del video del otro día de Erik Burke, Taming Android UI (http://www.youtube.com/watch?v=jF6Ad4GYjRU ¿no lo has visto? flagélate pues!!!) he hecho una pequeña clase que es una vista para mostrar imágenes con esquinas redondeadas.

La gracia estriba en que no sólo hace eso, si no que mantiene el ratio que especifiquemos. Por defecto usa el ratio de las cartas de Magic pero podemos establecer uno nuevo con setImageHeightRatio y setImageWidthRatio. También podemos hacerlas cuadradas con setImageSquareRatio

Una vez establecido el ratio, cada vez que cambiemos el tamaño, el control se ajustará al ratio establecido.

Se aceptan comentarios, sugerencias y bug-hunting.

Lo tenéis en mi repositorio de BitBucket

La licencia es Apache, ergo, haced lo que os de la gana con el mientras mencioneis de donde sale.

Saludos!

HierarchyViewer a lo loco

sergi — Sat, 16 Jul 2011 23:28:16 +0000

Gracias a Fernando Cejas (@fernando_cejas, un gran tipo) de Android 10, llego a un pequeño módulo escrito por Romain Guy que sirve para utilitzar Activites en un dispositivo Android real como servidor de vistas para HierarchyViewer.

¿Lo que de lo cualo? Calma, que ahora me explico. Ya sabes…. “leer más”….

Un visor para atarlos a todos en las sombras

HierarchyViewer es una fabulosa herramienta del SDK de Android que todo desarrollador de Android debería utilitza asiduamente. ¿Y para que sirve? pues es capaz de mostrarnos la jerarquía de objetos de los layouts cargados en el emulador de Android que tengamos arrancado (en principio, luego veremos cómo saltarnos esta restricción).De esta manera, disponemos de información muy valiosa de como se inflan las vistas en runtime, así como tamaños finales que obtenemos.

Para utilizarlos, debemos ejecutar el programa hierarchyviewer.bat, que encontrareis en la carpeta tools del SDK de Android.

Una vez arrancado, busca dispositivos a los que poder preguntar por layouts cuya jerarquía pueda cargar. Repito, sólo os funcionará con el emulador o bien con alguna ROM que lo tenga activado, los dispositivos físicos con el SO de fábrica suelen tenerlo desactivado.

Si seleccionamos uno de estos layouts y hacemos clic en el botón “Load View Hierarchy”, nos mostrará un bonito esquema de árbol con toda la jerarquía de nuestro layout. Aquí un ejemplo:

Hay varios elementos interesantes, como por ejemplo la ventana de propiedades que hay a la derecha, que nos mostrará las propiedades del elemento seleccionado, o el mapa del layout justo debajo, donde vemos la “sombra” de todos los elementos, y si seleccionamos uno elemento aquí también se seleccionará en el arbol.

En el arbol, en cada nodo se nos muestra:

El tipo de View (TextView, RelativeLayout, etc, etc, etc…)
Su id interno
Su id dentro de la colección android:id
Tres semáforos que nos indican el rendimiento del View al calcular las medidas, al inflarlo en la layout y dibujarlo en pantalla.
El índice relativo del objeto dentro de su padre

Si hacemos clic en estos nodos nos da más información (cómo por ejemplo, los tiempos exactos de medida, layout y dibujo).

Tiene algunas cosas más, pero os invito a descubrirlo, que la herramienta es de uso bastante simple pero muy potente. Mi favorita es la opción Capture Layers, que nos guarda un archivo psd de Photoshop que contiene una capa por View todas ordenaditas y con la visibilidad correcta. Lo cual va de perlas para hacer prototipado (y robar la interfaz de otras apps, jiji).

ViewServer, por que no sólo de emuladores vive el desarrollador

Y todo esto venía por que yo quería hablar de la clase ViewServer del señor Romain. Pues al asunto.

La clase se puede descargar de su sitio de github: http://github.com/romainguy/ViewServer

En realidad solo necesitais el fichero ViewServer.java (/src/com/android/debug/hv). Os lo descargais y lo poneis en cualquier paquete de vuestra app (si no es el paquete com.android.debug.hv recordad que debeis cambiar la instrucción package del fichero).

Ahora es necesario añadir al permiso INTERNET al manifest, sin este permiso no funciona. Recordad quitarlo al publicar la app si no lo necesita.

Por último debemos arrancar y parar en el sitio correcto el ViewServer en las activies cuyo layout deseemos analizar con el Hierarchy Viewer:

     public void onCreate(Bundle savedInstanceState) {
         super.onCreate(savedInstanceState);
         // Set content view, etc.
         ViewServer.get(this).addWindow(this);
     }

     public void onDestroy() {
         super.onDestroy();
         ViewServer.get(this).removeWindow(this);
     }

     public void onResume() {
         super.onResume();
         ViewServer.get(this).setFocusedWindow(this);
     }

Y nada más. Ya podemos ejecutar nuestra aplicación en un dispositivo físico y el Hierarchy Viewer será capaz de verlo y dejarnos estrujar los layouts hasta que confiesen. ¡Disfrutadlo!

Más info:

ViewServer en gitHub | http://github.com/romainguy/ViewServer

Depuración sobre la interfaz de Android en el Developer site de Android | http://developer.android.com/guide/developing/debugging/debugging-ui.html

Fragmentación de Android (pero la buena)

sergi — Wed, 13 Jul 2011 17:16:02 +0000

Vamos a ver cómo empezar a trabajar con los Fragments de Android.

¿Pero no se suponía que la fragmentación de Android era algo malo?

Sí, pero no hablo de esa fragmentación.

Cuando hablamos de Fragments hablamos de un nuevo elemento añadido a la API a partir de HoneyComb. Los fragments son “pedazos” de la interfaz que colocamos en nuestros layouts.

Y direis “pues eso es un View”. Y yo os diré “pues no”. Y si no le dais al botón de leer más, os quedareis con el misterio.

Por que los fragments tienen un ciclo de vida propio, lo cual nos permite utilitzarlos para implementar la lógica de la aplicación, y dejar las Activities como encargados de mostrar los Fragments que deseemos según el tamaño de pantalla.

Pongamos un ejemplo.

Imaginad que tenemos la típica aplicación que lista elementos y al pulsar uno de ellos, nos muestra el detalle de ese elemento. El problema se encuentra al ejecutar la aplicación en un tablet, donde se produce el “efecto oceano” (grandes espacios sin ocupar con elementos flotando). Pues nuestra Activity debería hacer dos cosas:

a) Si la pantalla es extra grande (vamos, un tablet), debería mostrar los dos fragments y gestionar los mensajes entre ellos.

b) Si la pantalla es grande, normal, o pequeña, debe mostrar un sólo fragment y llamar a una segunda Activity que muestre el fragment de detalle.

Como ya he dicho, de esta forma no es necesario implementar la lógica del programa en dos sitios, ya que los Fragments tienen su propio ciclo de vida.

¿Honeycomb? un pelín exclusivistas los de la gran G

Para que no exista todavía una mayor fragmentación (de la mala) debido a los Fragments (los buenos), y evitar un “apocalipsis honeycomb”, los señores de Google han decidido incluir los Fragments dentro de una API llamada AndroidSupport (versión 4, por ahora) que permite utilizar ciertos elementos de Android 3 incluso en 1.6.

Para instalarla, podeis añadirla como API desde el AVD manager, pero los más sencillo es añadir un Fragment a un Layout, y automágicamente os dirá que necesitais la librería y que si quereis que la instale.

Si ya la tenéis instalada, deberéis incluir en vuestro proyecto el archivo android-support-v4.jar que está en la carpeta \extras\android\compatibility\v4 del SDK de Android.

¿Empezamos ya?

Vale, vamos a ver un pequeño proyecto de ejemplo.

Necesitamos:

Un proyecto de Android
Tres layouts que vamos a llamar main.xml, f1.xml y f2.xml. En los dos últimos colocad los controles que os de la gana.
Una actividad principal (que llamaremos MainActivity) que establezca como layout de la actividad a main.xml en el onCreate

¿Ya? pues sigamos.
Lo primero es cambiar la clase MainActivity para que herede de ActivityFragment y no de Activity, ya que la clase Activity nativa de versiones de Android inferiores a 3 no soporta Fragments. Si nuestra aplicación fuese nativa de 3 o superior no sería necesario este cambio.
Ahora vamos a incluir los dos Fragments en nuestro Layout main.xml. Para ello usaremos el siguiente marcado:

Vamos a explicar cada atributo:

layout_height y layout_width ya están más que explicados y no creo que haga falta entrar en ello.
android:id. Cada elemento Fragment de un layout debe tener un tag android:id con un identificador único o bien un tag android:tag con una cadena única (o bien nada).
android:name. Este es el más importante. Es la ruta canónica a la clase encargada de suministrarno la View a mostrar en el Fragment y a gestionar su ciclo de vida. Aun no las hemos creado.
Este tag es simplemente para decirle al editor de layouts de Eclipse que muestre este layout en el editor. También se puede configurar via menú contextual del editor.

Y una vez hecho esto, pues pondriamos otro elemento similar, pero para el segundo fragmento:

Listos.

Ahora vamos a crear la clase Fragment1 que va a encargarse de inflar el fragmento:

public class Fragment1 extends Fragment {

@Override

public View onCreateView(LayoutInflater inflater,
  ViewGroup container, Bundle savedInstanceState) {

return inflater.inflate(R.layout.f1, container,false);

Cómo veis, el formato es parecido al de una Activity, pero en vez del método onCreate, tenemos el método onCreateView, que debe devolver la View a mostrar en el fragmento. Este método recibe tres parámetros:

inflater: un LayoutInflater que podemos utilitzar (y de hecho lo hacemos) para inflar la vista.
container: un ViewGroup que usaremos para hacer de root durante el inflado.
savedInstance: el Bundle con el estado del fragment si ha sido destruido

Y simplemente devolvemos el resultado de inflar el layout con el método inflate. Para los que no lo conozcais, el tercer parámetro del método inflate (el booleano) indica si hay que crear una nueva View dentro del root o se debe inflar la View directamente en el root. En este caso, no nos hace falta y así evitamos elementos innecesarios.

Por último, sólo queda hacer la clase Fragment2 que será identica a Fragment1 cambiando el fragmento a hinchar.

¡Y ya está! Con esto hemos finalizado nuestro primer experimento con Fragments. Queda mucho por rascar, esto es el primer ejemplo, pero poco a poco y sin prisa. El próximo día hablaremos de cómo crear estos Fragments desde código.

Id en paz.

Instalar Adobe AIR 2 en Linux x64

sergi — Tue, 01 Feb 2011 08:58:20 +0000

Últimamente he iniciado un proceso de transición a Linux, no por necesidad, si no por ganas de aprender cosas.

En este proceso me estoy encontrando con bastantes problemas. Uno de ellos se produce por que los ordenadores que tengo en casa son de 64 bits (y yo sin saberlo). Lo más curioso es que me estoy encontrando problemas diferentes en cada uno (¿podría ser por que uno es AMD y el otro Intel?).

Muchos de los programas del repositorio de Ubuntu no dan soporte a 64 bits y no permite instalarlos, así que toca buscarse la vida. Uno de ellos es Adobe AIR, que utilizo para mi cliente de Twitter favorito, Tweetdeck.

La propia Adobe da una serie de instrucciones que no acaban de funcionar. Buscando, buscando, he encontrado una solución en el blog de James Ward (http://www.jamesward.com/2010/10/14/install-adobe-air-on-64-bit-ubuntu-10-10) para instalar los paquetes .deb en 64 bits, que transcribo y traduzco aquí (con su permiso, por supuesto).

Descarga el paquete .deb de Adobe AIR.
Abre una ventana de terminal y navega al directorio que contiene el archivo adobeair.deb.
Crea un directorio tmp:
```
mkdir tmp
```
Extrae el paquete deb a la carpeta tmp:
```
dpkg-deb -x adobeair.deb tmp
```

Extrae los archivos de control:

dpkg-deb --control adobeair.deb tmp/DEBIAN

Cambia el parámetro Architecture de “i386″ a “all”:
```
sed -i "s/i386/all/" tmp/DEBIAN/control
```
Empaqueta el archivo deb de nuevo:
```
dpkg -b tmp adobeair_64.deb
```

¡Ahora el paquete ya puede instalarse en sistemas de 64 bits! Simplemente, desde la línea de comandos teclea:

sudo dpkg -i adobeair_64.deb

Y listos, ya se puede instalar TweetDeck o similares.

¡Gracias James!

2º Tech Cocktail + Android en el MWC

sergi — Fri, 28 Jan 2011 17:30:42 +0000

Por segundo año consecutivo Catdroid tiene el honor de organizar el 2º Tech Cocktail mixer durante el Mobile World Congress, y por primera vez formo parte de la organización.

Estamos super contentos de poder contar con la colaboración de Tech Cocktail y el ingenioso formato que otorga una oportunidad increíble a emprendedores en el área móvil (locales y visitantes) para enseñar su producto/aplicación.

El principal foco del evento es conectar, educar y amplificar a la propia comunidad técnica, y ofrecer un lugar donde mostrar algunas de las últimas innovaciones técnicas.

Por segundo año, la comunidad local de Android quiere dar la bienvenida a todos los entusiastas y desarrolladores de Android que nos estarán visitando de toda Europa y el mundo, y darles una oportunidad para conocernos y charlar un rato sobre lo último en el mundo de Android y desarrollo móvil en general.

Aquí están los detalles del evento:

Cúando: Miércoles, 16 de Febrero del 2011 – 7:00 p.m. a 10:00 p.m.
Dónde: Club 41N (62 Avinguda del Paral.lel , Barcelona)
Qué: Un Cocktail Mixer para entusiastas de la tecnología
Precio: $15/12€ (para los “madrugadores”) – $20/15€ estandard / $20/15€ en la puerta

El precio incluye dos bebidas (refresco o cerveza) o un cocktail.

Pasa por la página de Teck Cocktail’s en event brite para apuntarte ya: http://techcocktailbarcelonamwc2011.eventbrite.com/

Si te gustaría traer un producto, empresa o servicio mira las instrucciones en la página de eventbrite.

Si te gustaría participar como patrocinador del evento manda un email core@catdroid.org (tenemos algo especial para ti!).

Nos vemos allí!

Charla sobre Mercurial por Jordi Gerona

sergi — Thu, 27 Jan 2011 20:43:42 +0000

Ayer asistí a una charla sobre Mercurial que impartió Jordi Gerona (de Eventuo) en Barcelona Activa a de la mano de SeedRocket.

Aunque estaba orientado a usuarios de SVN (Subversion) con ganas de conocer Hg (Mercurial) y yo no soy un experto en SVN (vamos, más bien novatillo), el buen hacer de Jordi ayudó bastante a seguir los conceptos explicados (sobre todo algunos que son complejos en Hg).

Y francamente, me vendió el producto. He estado haciendo algunas pruebas con BitBucket, y me está gustando mucho. Funciona bien, es rápido y sobre todo gratis (y no me obliga a que mis proyectos sean open source).

La idea básica de Mercurial es que no tenemos una estructura cliente/servidor como en SVN, al contrario, se trata de una arquitectura distribuida (de ahí su nombre DCVS, Distributed Control Version System), donde nos sincronizamos contra otros repositorios. Por comodidad, se tiene uno centralizado pasivo, pero que no manda sobre los demás y en vez de C/S tenemos repositorio local y remoto.

Así pues, tenemos nuestra working folder al igual que en SVN, pero la sincronizamos contra nuestro repositorio local (sito en la misma working folder). Cuando nuestros cambios estan listos para ser distribuidos, descargamos los últimos cambios del repositorio remoto, sincronizamos el head local y el head remoto en nuestro repositorio local, y mandamos estos cambios al remoto.

Un poco complicado de explicar en tres líneas, pero por suerte, Jordi ha compartido la presentación en Slide Share, y Fernando Cejas (de Android10) tuvo a bien de grabarlo en video (la calidad de imagen no es lo más mejor, que lo hizo con el teléfono, pero el audio es lo importante).

Aqui la presentación: http://www.slideshare.net/giro9/mercurial

Aquí el video: http://www.slideshare.net/giro9/mercurial

P.D.: el preguntón del principio que no para de interrumpir soy yo. Sorry Jordi, es que cuando algo me interesa, me pongo muy pesado.

Reporting Services: regenerando ReportServerTempDb

sergi — Thu, 20 Jan 2011 10:06:28 +0000

Hola

Ayer se nos cayó un servidor de MS Reporting Services 2005 (entre otras cosas). Al recuperar el backup, ReportServerTempDb no se recuperaba bien.

Esta base de datos es utilizada por Reporting Services para almacenar los objetos temporales que crea al mostrar informes, así que su contenido es volatil (vamos, que no pasa nada si se pierde). El problema es que al menos hay que tener la estructura vacía.

Buscando, buscando, encontré este enlace explicando los pasos para regenerarla en este blog. Pego una traducción:

Creamos la base de datos. Para la instancia predeterminada, el nombre será ReportServerTempDB. Para instancias con nombre, será ReportServer$InstanciaTempDB
(acordaos de ajustar el tamaño correctamente).
En la base de datos nueva, creamos el rol de base de datos RSExecRole.
Asignamos al rol RSExecRole de la base de datos los mismos usuarios que tengamos en el rol RSExecRole de la base de datos ReportServer.
Ejecutamos el script CatalogTempDB.sql. Lo encontrareis en la carpeta de Reporting Services (en cada versión cambia bastante)
(que no se os olvide ejecutar el script en el contexto de ReportServerTempDB).

¡Y voilà! funciona.

Qué ganas tengo de quitarme Reporting Services 2005 y actualizar a 2008, por que esta versión la miras y se rompe.

¿Alguien en la sala con experiencia en RS que me confirme si la versión 2008 es más estable?

Saludos!