Developing Frogtek

El blog del Departamento de Tecnología

Etiqueta: tablet

Frogtek se alía con Kiva para financiar TiendaTeks

Hoy no vamos a hablar de tecnología, ni de organización de equipos. Vamos a hablar de algo bastante distinto.

Como todos sabéis Frogtek trata de llevar la última tecnología a las pequeñas tiendas de países emergentes y del tercer mundo. Pues bien, una de las preguntas que más nos hacen es la siguiente ¿cómo paga un tendero de México o de Ghana una tableta Android de última generación?. La respuesta no es fácil.

Para empezar, tratando de que la última tecnología sea lo más asequible posible.  Para ello en el departamento de tecnología nos hemos esforzado y nos seguimos esforzando en buscar tecnología de bajo coste que pueda funcionar con nuestro software. A menudo eso supone rastrear el mercado asiático en busca de la última tableta que tiene todo lo que necesitamos (que no es poco) a un precio razonable, lo mismo con impresoras, lector de códigos de barras y lectores de tarjeta magnética. Afortunadamente esto, que al principio era infernal (teléfonos que se ponen en chino al quedarse sin batería y otras lindezas por el estilo) es ahora algo más sencillo. Otras veces se trata de exprimir al máximo las posibilidades técnicas del hardware que nos llega, descendiendo al nivel del sistema operativo para poder crear nuestros propios drivers USB y deshacernos de los periféricos basados en bluetooth que eran mucho más caros.

Pero sólo con hardware barato y bien utilizado no es suficiente. Hemos tenido que explorar otras opciones más del mundo financiero. ¿Cómo podemos hacer para que el tendero pueda permitirse adquirir TiendaTek?. Resulta obvio pensar en ofrecer al cliente una vía de financiación, la posibilidad de pagarlo a plazos pero ¿quien financia todo eso?. Frogtek no tiene dinero suficiente para adelantar el coste de cientos o miles de tabletas, impresoras, lectores para luego esperar pacientemente a que los tenderos plazo a plazo vaya pagando. Existen otras opciones, muchas de ellas las hemos explorado o las estamos explorando: conseguir que una gran empresa interesada financie a nuestros tenderos, conseguir que un fondo de impacto compre las tabletas por nosotros y nos las preste para venderlas que ya le devolveremos el dinero conforme lo vayamos recuperando, colaborar con una microfinanciera que ofrezca sus créditos en la base de la pirámide para que los tenderos puedan invertir en una herramienta de productividad como la nuestra.

Todo esto y mucho más son los quebraderos de cabeza que parte de nuestro equipo tiene para conseguir que esta aventura de Frogtek sea, no sólo sostenible y viable, sino también escalable. Hoy estamos muy contentos de anunciar que una de las opciones en las que hemos trabajado ha visto la luz, de una forma muy bonita, porque hemos llegado a un acuerdo con una “micro-financiera” pero no cualquier micro-financiera, hemos llegado a un acuerdo con Kiva. A partir de ahora tenderos que quieran adquirir TiendaTek para su negocio en México se empezarán a anunciar en Kiva para obtener el dinero necesario y lo precioso del caso es que serán otras personas a miles de kilómetros las que  prestarán ese dinero directamente. Porque Kiva es una de las principales plataformas de crowd-funding, o lo que es lo mismo, sirve para que cualquier persona preste unos pocos euros a gente que lo necesita para financiar sus humildes proyectos, para que muchos pocos hagan un gran mucho. La tecnología consigue lo que hasta hace bien poco era totalmente inviable, que tú y que yo con 25€ podamos ayudar directamente a una persona a miles de km a conseguir un préstamo para invertir en algo que mejore su vida.

Lo curioso del caso, además, es que el equipo de Huesca lleva ya muchos meses invirtiendo el dinero del bote del cerdito en emprendedores anónimos de Kiva. Ahora tendremos la oportunidad de cerrar el círculo, invirtiendo lo que obtenemos de nuestras pifias en los tenderos para los que trabajamos.

Así que tenemos el placer de anunciar que nuestra primera cliente en Kiva es Ana Karen y ójala sea la primera de muchas.

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!

 

Diseño de layouts XML, sucios pero eficientes, en android

Si no vienes del post introductorio, quizás te gustaría leerlo.

Bien, pues a medida que añadíamos nueva funcionalidad a la aplicación en la tablet, experimentábamos una lentitud tremenda en alguna de las actividades que abríamos. No era normal que si en el teléfono, el mismo layout funcionaba perfectamente, ¿por qué al unir dos layouts en uno sólo, pero más grande, vaya tan lento? Respuesta: no hay nada que el traceview no solucione. Nada.

Rápidamente, Julio comenzó a ver que había miles de llamadas a una función nativa de android que se llama onMeasure(). La misma, se encarga de que cada vez que hay que posicionar un widget dentro del layout, hacer las medidas necesarias de lo ya presente en el mismo para así determinar dónde debe de ir colocado. ¿Y qué problema hay con esto? Pues que si tu layout tiene muchos widgets, y estos widgets tienen algunas de sus propiedades (como el layout_width, o layout_height) con valores wrap_content o fill_parent, todo resultará en un festival de onMeasure(). Creo recordar, que el 90% del tiempo de carga de una pantalla ineficiente nuestra, se lo llevaba esta función. Obviamente, pasamos de medio segundo para cargar una pantalla determinada en el teléfono, a 2 ó 3 (incluso más) en la tablet.
Por lo tanto, uno de los nuevos mandamientos que hay que grabarse a fuego es que: siempre darás medidas a tus widgets (Button, TextView, Layouts, EditText, etc), en lugar de que las decida android. Siempre, a no ser que sea estrictamente necesario; que alguna vez lo es.
Este es el primer paso para que la aplicación fluya un poquito más rápido que antes. Pero sólo un poquito.

¿Qué, que aún no hemos ensuciado el layout? Bien, pues este punto tiene que ver con el nivel en que un widget se encuentra anidado. Podemos tener un layout muy sencillo, con un RelativeLayout y dos Button dentro, o podemos tener algo como esto (o peor). Es por esto lo que un día dije en la oficina. Somos unos barrocos.
Por lo tanto, desde frogtek recomendamos encarecidamente que, a poder ser, se tenga un RelativeLayout padre con todos sus hijos al mismo nivel. Si se tienen 4 o 5 widgets en el layout, serás afortunado; si tienes 30 o 40 como en alguno de nuestra tablet, puedes volverte loco buscando uno en concreto en el Outline de eclipse. Cierto es que queda todo mucho más ordenado si vamos anidando widgets dentro de Layouts, pero se pierde rapidez al cargar, ya que también hay muchos más onMeasures() que si estuviesen todos al mismo nivel. Y traceview no miente.

Por lo tanto, el primer paso para agilizar la carga (o recarga) de una pantalla, pasa por dar medidas a todo widget al que podamos dar medidas absolutas, e intentar que nuestros layouts sean lo menos barrocos posibles en cuanto a ordenación jerárquica se refiere.

Consejo extra que se me ocurre mientras escribo: si utilizas el LayoutInflater para cargar layouts dentro de otros, tener un layout con uno o dos niveles de anidación ayudará mucho. Nosotros, que tenemos layouts dentro de layouts, y de nuevo dentro de layouts (por necesidad), lo hemos notado.

Optimizar una aplicación android (Introducción)

Hacía como mes y medio que quería escribir sobre este tema, pero me habría precipitado ya que desde esa fecha hasta ahora hemos aprendido mucho más sobre la optimización de una aplicación para android; aunque aún no quedan muchos conocimientos por adquirir.

Como ya hemos contado alguna vez, desde hace casi dos años, desarrollamos nuestro producto para teléfonos; teléfonos con una resolución fija. Y durante este verano, hemos dado el salto a una tablet. Suerte que todo el núcleo de la aplicación lo teníamos bien separado en un .jar. Por lo que el 2% del tiempo lo hemos invertido en retocar un poquito el núcleo, y el 95% restante ha sido armar una interfaz de usuario muy bonita, pero que nos ha dado bastantes quebraderos de cabeza, y que voy a intentar plasmar en una serie de posts.

Tras unas cuantas iteraciones y un empujón espectacular, teníamos muy avanzada la versión para la tablet. Pero el cambio de una pantalla de 320 x 480, a una de 800 x 480 conlleva problemas de memoria y de rendimiento (con un hardware superior al del teléfono, todo iba mucho más lento). Por que no es oro todo lo que reluce. Con un buen procesador, y bastante memoria no todo va a funcionar como pensabas. Por lo menos, en android. Nos hemos rascado mucho la cabeza, hemos sufrido, pero finalmente hemos aprendido muchas cosas; sobretodo de nuestros errores.

Es por ello, que nos gustaría compartir con vosotros los siguientes temas:

A medida que vayamos redactando la serie de posts, se actualizarán los puntos con enlaces a las URLs.