Developing Frogtek

El blog del Departamento de Tecnología

Categoría: android (página 1 de 4)

Restringir uso de emoticonos en EditText

La nueva versión 4.4 del SDK de android (Kit Kat) trae consigo los famosos emoticonos (o emojis), añadidos al teclado software, que tanto gustan en whatsapp o facebook.

emoji

 

Nos hemos encontrado con algún usuario de nuestra aplicación que los ha utilizado para dar más colorido a los nombres de proveedores, productos, clientes…

Pero luego nos han dado problemas a la hora de hacer alguna consulta SQL con un LIKE comparando strings.

¿Cómo lo he solucionado? Si limito los EditText a únicamente letras del abecedario o números, estoy haciendo que la aplicación no pueda ser 100% funcional en países donde se usan otro tipo de caracteres como Rusia, Japón, China…
He decidido usar la clase InputFilter, como sigue:


InputFilter filter = new InputFilter() {
public CharSequence filter(CharSequence source, 
                           int start, 
                           int end, 
                           Spanned dest, 
                           int dstart, 
                           int dend) {
        for (int i = start; i < end; i++) {
            if (!Character.isLetterOrDigit(source.charAt(i)) 
                && !Character.isWhitespace(source.charAt(i))) {
                return "";
            }
        }
        return null;
    }
};

editText.setFilters(new InputFilter[]{filter});

Espero que te sirva. O si tienes una solución mejor, es bienvenida.

Cómo evitar abrir más de una Activity desde un botón

  • ¿Harto de que se pueda pulsar un botón de tu aplicación repetidas veces antes de que se cree la nueva Activity?
  • ¿Harto de tratar de evitar este comportamiento deshabilitando el botón nada más ser pulsado, y que aun así se lancen Activity sin talento?
  • ¿Harto de consultar StackOverflow y la Internet entera para no encontrar una solución que funcione de verdad?

Nosotros también lo estábamos. Concretamente, habíamos estado experimentando este problema durante años. Ahora tenemos la solución.

Como nunca hemos sido unos expertos programadores, y teníamos muchas prisas por sacar mucho trabajo adelante, nos fiábamos del “método Google” para iniciar una nueva Activity:

Intent intent = new Intent(this, NuevaActivity.class);
this.startActivity(intent);

Y aun así… daba igual que la nueva, como la vieja Activity procesaran mucha información, o poca, que marcásemos la nueva Activity como singleTop, que invocásemos al setEnabled(false); del objeto View que llamaba al startActivity(). También hemos de decir que nuestros usuarios son expertos en pulsar varios botones al mismo tiempo, o que les tiemble el dedo y hagan varias pulsaciones muy rápidas sobre el mismo botón, o que debido a la lentitud del hardware chino se desesperen a la hora de completar una tarea y sigan pulsando el mismo botón hasta el infinito y más allá.
Abrir dos o más instancias de una Activity en nuestra aplicación era muy sencillo, hasta que se nos ocurrió convertir la variable de tipo Intent en un field de nuestra clase de tipo Activity padre. Y cada vez que queremos invocar al startActivity(intent);, lo hacemos sólo si el field intent es == null.
Hay que tener cuidado si la Activity padre es una pantalla principal desde la que se pueden iniciar distintas Activity, por que si todos los new Intent() los asociamos con el field que comentaba antes, al querer iniciar la segunda vez la Activity, como intent != null, la aplicación no haría nada. Es decisión del lector de esta entrada saber cuándo hacer que el field intent sea igual a null de nuevo. ¿Quizás en el onResume()? ¿O mejor en el onActivityResult()? ¿Qué tal crear una clase de tipo Activity con este truco y que todas las actividades de la aplicación hereden de esta clase?

A nosotros nos funciona a la perfección, ¿y a ti?

Cualquier mejora a este truco, queja, grito, etc. es más que bienvenida.

Google Translator Toolkit para aplicaciones Android

Supongamos que tienes una aplicación Android con cientos de líneas en el strings.xml (o en cualquier otro recurso) y quieres traducirla a un idioma del cual no tienes ni idea. Buscas a un nativo que te haga la traducción y le pasas tu archivo que tiene líneas con esta pinta:

<string name=”customer_has_debt”>¿Estás seguro de eliminar al cliente %1$s ? Este cliente tiene una deuda de %2$s y también se eliminará</string>

Tu traductor no sabe de Android, le parecen raros los “%1$s” y decide pulírselos. También se confunde y borra un “<“.

¿Quién se encarga de revisar que no se ha roto nada? ¿Y si pudiéramos ahorrarle trabajo al traductor y permitirle trabajar con un archivo “pre-traducido” (por google translate)? ¿Y añadir un glosario para traducir automáticamente términos técnicos del negocio?

Todo eso y algo más nos lo da Google dentro de su Translate Toolkit. Es algo que existe desde hace mucho tiempo pero a nosotros nos costó encontrarlo así que lo queríamos compartir.

Cuenta atrás en Android

Si alguna vez nos hemos visto en la situación de tener que realizar una cuenta atrás en nuestra aplicación Android (muy útil para juegos, para indicar el tiempo restante) seguramente habremos hecho uso de la clase típica para estas cosas en Java: TimerTask (java.util.TimerTask)

private TimerTask getTimerTask() {
	return new TimerTask() {
		@Override
		public void run() {
			// Aquí hacemos todo
			} catch (Exception e) {
				e.printStackTrace();
				schedule(NOW);
			}
		}
	};
}

Deberíamos modificar bastante esa clase para que llevara una cuenta regresiva de los segundos que quedan, así como hacer un schedule cada segundo de la task.
En vez de esto, resulta mucho más elegante utilizar una clase que provee Android llamada CountDownTimer. Tan fácil como hacer lo siguiente:

timer = new CountDownTimer(secondsUntilFinished, 1000) {
	public void onTick(long millisUntilFinished) {
              // Do something every second
	}

	@Override
	public void onFinish() {
              // Do something when finished
	}
}.start();

actionbarsherlock para Android

Hace poco nos vimos en la tesitura de querer añadir una actionBar a nuestra aplicación. Investigando sobre cómo hacerlo, nos dimos cuenta de que la compatibilidad hacía atrás era un poco “laboriosa“.

Mientras dudábamos sobre cómo afrontar la creación de la nueva actionBar, nuestro querido compañero Francho nos informó de la existencia de ActionBarSherlock.

ActionBarSherlock es una librería que facilita el uso de la librería de compatibilidad de Android y además incorpora la creación de la barra de acciones que por defecto no está soportada. Su funcionamiento es impecable y simplifica mucho el uso de todos los elementos no soportados en versiones pre-HoneyComb.

Echadle un vistazo si estáis pensando dar soporte a versiones antiguas, sin perder la potencia de los elementos y herramientas de lo más nuevo de Android.

 

Aprendiendo a usar el NDK (Parte I)

En Frogtek, últimamente, hemos estado usando la NDK para poder dar a nuestro querido tiendatek una funcionalidad muy especial.
Queremos compartir con vosotros toda nuestra aventura y para eso vamos a comenzar desde lo más básico (NDK Hello World), terminando con algo realmente mágico (que no majico) y anfibio.

La ndk es un conjunto de herramientas que nos permite construir librerías compartidas para poder llamar desde Java a código nativo.
Las instrucciones nativas se ejecutan sin pasar por la máquina virtual. Por eso, una de las razones por las cuales se escribe código en la ndk es el rendimiento.
En nuestro caso la elección de la ndk viene dada por la necesidad de cargar librerías que no podemos utilizar directamente en Java. Realmente podemos programar una aplicación 100% nativa. Es decir: incluyendo actividades codificadas completamente en C.

Para realizar esta tarea, la gente de Google usa JNI (Java Native Interface)JNI es una interfaz que nos permite hacer llamadas a código escrito en C desde Java mediante un sencillo sistema de nombrado de los métodos.
Eso sí: debemos tener cuidado con la gestión de memoria que hace JNI; pero de ello hablaremos en próximos posts.

Vayamos al grano. Debemos descargar el conjunto de herramientas que provee Android desde aquí. Después, debemos seguir estas instrucciones:

Creamos un proyecto Android normal, creando un layout básico con un botón (el que hará la llamada al código nativo). 

En la carpeta raíz del proyecto creamos una carpeta llamada jni, que incluirá dos ficheros llamados Android.mk (el makefile, con la A en mayúscula). Este fichero contiene las instrucciones para construir el código nativo.

LOCAL_PATH:= $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE:= ndksample
LOCAL_SRC_FILES:= ndksample.c

include $(BUILD_SHARED_LIBRARY)

Seguidamente, crear otro fichero que nosotros hemos llamado ndksample.c (fichero que contendrá las funciones nativas). 

#include 
#include 

jstring Java_org_frogtek_ndksample_Main_getStringFromNDK(JNIEnv* env, jobject this)
{
	return (*env)->NewStringUTF(env, "Croak!!");
}

Ahora hay que compilar dicho fichero c para construir la librería que será cargada desde Java. Para ellos se utiliza la herramienta nkd-build que está en la carpeta de la ndk que anteriormente descargamos, ejecutando este comando:

./ndk-buil -C /ruta/a/nuestro/proyecto

Ha de ser la ruta raíz del proyecto. Este comando terminará con una linea similar a

libndksample.so => libs/armeabi/libndksample.so

Esto quiere decir que todo ha ido bien y que nos ha generado la librería, copiándola al sitio correcto dentro de nuestro proyecto. Si hacemos un refresh en Eclipse observaremos la presencia de dicho fichero.

Una vez que tenemos la librería compilada y generada, podemos llamarla desde Java. Para este cometido, lo primero que tenemos que hacer es cargar dicha librería usando el siguiente método de la clase System:

static {
        System.loadLibrary("ndksample");
}

Esta llamada hay que hacerla de manera estática, dentro de la clase que hará uso de la función o funciones de C. Nótese que el nombre que ponemos ha de ser el que hemos puesto en LOCAL_MODULE en el Android.mk

También tenemos que definir el método nativo para poder llamarlo desde Java. Lo haremos de la siguiente manera:

 public native String getStringFromNDK();

Tenemos que notar que dicho método ha de corresponder con la firma del que definimos en el código c, y no solo eso, también ha de coincidir el paquete y la clase que contienen esta llamada con la que hemos escrito en la firma del método de c.

Ahora solo nos queda llamarlo para poder ver que todo funciona:

 Toast.makeText(Main.this, getStringFromNDK(), Toast.LENGTH_LONG).show();

Esto ha sido todo para nuestro primer post de una serie en la que hablaremos sobre la NDK. Y recordad, pequeños developers: lo nativo mola. Podéis descargar el proyecto desde aquí.

Tiendatek y sus amigos los Periféricos

Estoy seguro de que casi todos hemos visto en alguna ocasión un Sistema Punto de Venta (POS) con su correspondiente escáner de códigos de barras, impresión de recibos, pagos con tarjetas y por qué no, un lector de huellas digital. Con la demanda actual del mercado y los avances en tecnología, un POS no tendría sentido sin la ayuda de todos o parte de estos dispositivos. La realidad dicta que no es suficiente con poder registrar una venta sino que hay que hacerlo de la forma más rápida posible, a nadie nos gusta estar esperando en la cola del supermecado, porque además al cliente le gusta tener constancia de lo que ha comprado, a nadie nos gusta que nos engañen.

Tiendatek ha conocido a diferentes amigos conforme ha ido creciendo, apartándose de aquellos que no le convenían y que le retrasaban su aprendizaje. Cuando tan solo iba a la guardería conoció a un pequeño sistema de lectura de códigos de barras a través de la propia cámara del teléfono y cuyo nombre es ZXING. Una tarea que aparentemente puede parecer sencilla, al final resultaba desesperante para el tendero, debido a su baja eficiencia. Enseguida se dio cuenta de que tenía que encontrar a alguien que de verdad estuviese diseñado para ese fin. Así, cuando empezó la primaria conoció a un lector bluetooth llamado CipherLab quién además de bonito era barato. Se podía decir, que hasta el momento, el lector es y ha sido su mejor amigo. De esas relaciones donde nada cambia con el paso de los años.

Ya en la secundaria, Tiendatek y LectorTek, hicieron nuevos amigos. En esta ocasión se trataba de una linda y joven impresora de recibos vía bluetooth. Desde el primer día supo como seducirlos tanto a ellos como a los tenderos pasando por los programadores y el “product owner” de Tiendatek. Apenas han pasado unos meses, pero a simple vista se ve que existe química entre ellos.

 

Todavía les queda mucho camino que recorrer y periféricos que conocer pero ¿por qué no?, ¿veremos algún día a Tiendatek saliendo a bailar con un lector de pagos con tarjeta y/o sistema de identificación por huella digital en el día de su graduación?

¿Por qué usar Maven?

A raíz de mi grata visita a PocketWidget, en nuestro Desk-Surfing más reciente, he revisado la configuración de Maven que nos permite construir nuestros entregables.

Al volver sobre ella con Francho, repasarla y volver a aplicarla en otros proyectos, me he dado cuenta de lo potente que es y lo difícil que sería la vida sin ella.

Aparte de todas las bondades que su propia página web resalta, personalmente, me quedo con dos de ellas.

  • La herencia entre los archivos de configuración. Permitiendo eliminar duplicidades en las configuraciones y facilitando la configuración de multiples proyectos similares partiendo de una configuración padre-base.
  • Su extensibilidad mediante plugins. Los hay de todos los tipos y si no encuentras uno que se cuadre a tus necesidades, puedes desarrollarlo y usarlo fácilmente. Nosotros el que más usamos es el de Android. No ha estado siempre a la última, pero la comunidad que hay detrás es impresionante y en su última versión beta (2.9) ya soporta los Library Projects.

Solo usamos Maven en el entorno de integración continua, porque durante desarrollo con el plugin de Eclipse ADT para Android, no solemos tener problemas. Pero a la hora de automatizar, la elección ha sido clara: Maven sobre Ant.

Frogtek libera PoisonFrog

Llevabamos un tiempo queriendo dar esta noticia. Es un gran honor para todo el equipo de Frogtek presentar PoisonFrog.

Nuestro producto requiere un acceso a la base de datos que sea muy configurable y adaptable a los cambios, así como abrir varias bases de datos desde la misma aplicación. Realmente Android no permite hacer esto como a nosotros nos gustaba. Así que desde hace ya mucho tiempo teníamos una librería interna para hacer estas tareas.

Por eso pensamos que sería de mucha utilidad devolver a la comunidad mucho del conocimiento que nosotros hemos adquirido de ella. Por eso hemos liberado esa librería bajo licencia Apache 2. El nombre surgió tras un gran debate interno en el que se propusieron infinidad de nombres. Las Poison Frog son ranas  que cumplen caracteristicas que creemos que son comunes con la librería y con Frogtek.

  • Son las reinas de su entorno por ser venenosas.
  • Son vistosas dado su color.
  • Hay varios colores (Portar la librería a más sistemas)
  • Viven en centroamérica y sudamérica, exactamente donde desplegamos nuestro producto, tiendatek.
  • Son ranas, igual que el nombre de nuestra empresa. Vamos a ayudar a la comunidad con un “leap frog” para ir de los “early 80’s to the XXI century in terms of database connection”.

Aquí os dejo la web del proyecto.

https://code.google.com/p/poisonfrog/

Por favor sentíos libres de comentar, commitear y criticar constructivamente.

También queremos dar las gracias a nuestra gran diseñadora Kristel Aranda por hacernos el diseño del logo.

¡Gracias!

Android y sus Layouts

Imaginad que al realizar una aplicación web compleja, en vez de hacerla para que se vea bien en todos los navegadores, la hacéis solo para una resolución de pantalla concreta y un navegador específico. Sería un infierno tener que repasarla entera, una vez acabada, para que se adapte a cualquier navegador y resolución, ¿verdad?.

Android Layout

Pues algo así nos pasó a nosotros, pero en Android. Parte de culpa tuvimos, he de reconocer, por no ser previsores y tirarnos por el camino fácil. Aunque diré en nuestra defensa que cuando se empezó nuestro producto Android estaba en pañales y no existía tanta tablet y teléfono en el cual ejecutar tu aplicación.

Aquí van pues una serie de recomendaciones. Para que no cometáis los mismos errores que nosotros.

  • Entended cómo funciona el tema de las pantallas en Android, no es lo mismo una densidad que otra, el tamaño de pantalla, etc.
  • No uséis la unidad de medida px. Mejor dp, o sp si son tamaños de texto.
  • Tened claro como elige Android los recursos que ponéis a su disponibilidad.
  • Evitad en toda medida posible usar layouts con medidas absolutas, hacedlos adaptables (fill_parent, wrap_content). Os ahorrareis muchos quebraderos de cabeza.
  • Si no podéis evitarlo y tenéis que usar valores en vuestros layouts. Extraedlos a un xml y definidlos como Dimensions. Así os será más fácil adaptar la aplicación a las distintas configuraciones que queráis soportar, pues con definir el archivo de dimensiones para cada modalidad de recursos os valdrá.
  • Usad el atributo android:drawableTop, android:drawableLeft…, para introducir imágenes en botones. No os pase como a nosotros que o pedíamos el fondo ya con la imagen o introducíamos un elemento adicional, recargando el layout.
  • No os dejéis enamorar por las bondades de los RelativeLayout. No son malos. Pero a veces un LinearLayout con sus pesos puede ser más fácilmente adaptado a varias pantallas.

Y nada más. Si se os ocurre alguna más que nosotros no hemos nombrado, compartidlo con todos!

 

Antiguas entradas