bluebrowncustomgreenorangepinkredturquoiseyellow
  • Layout Style
  • Texture for Boxed, Framed, Rounded Layout Background

  • Font
    • Body:

    • Menu:

    • Title:

    * Fonts are used to example. You able to use 600+ google web fonts in the backend.

Mail info@moldeointeractive.com.ar
Blog - Moldeo Coop.

Ya está disponible el módulo de MercadoPago para Odoo 10.0

Bueno, es eso. Lo pueden descargar de 

https://github.com/ctmil/payment_mercadopago

El branch es odoo10. Solo lo tienen que instalar y configurar en Métodos de Pago. Cualquier problema, solo tienen que crear el issue en el repositorio.

Firmar una APK para Android en Linux

Hace un tiempo comentábamos en esta entrada las posibilidades de producir una App para Android, con los recursos que ofrecen HTML, CSS y JavaScript; mediante el framework de Apache Cordova. Quienes lo prueben conseguirán visualizar su App en un emulador como el AVD o Genymotion, no obstante, al momento de hacer una versión release para visualizar desde un teléfono, se nos avisará que la App no es segura, y no podremos instalarla. Ni hablar si tenemos deseos de subirla al Play Store de Google. Y la razón es sencilla: necesitamos firmar el APK.

Al generar un APK desde frameworks como Córdova o Ionic aparecerá un archivo que suele llamarse android-release-unsigned.apk. Ese archivo APK está comprimido como corresponde y es 100% funcional, sin embargo se nos pide que la validemos al "firmarla" de forma digital por razones relacionadas con el cifrado. A continuación se detallan unas sencillas instrucciones para firmar un APK en linux de forma manual (se puede realizar de forma automática modificando las opciones de compilación). Para empezar, necesitamos generar una keystore. Se trata de una clave cifrada que va a acompañar al archivo APK, y se genera como un archivo a parte, se puede usar indefinidas veces hasta que cumpla su ciclo de vencimiento. Teniendo una versión de Java instalada ya nos encontramos en condiciones de utilizar la keytool. Vamos a ejecutar el siguiente comando:

 

keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

 

Nos pedirá introducir la contraseña del almacén de claves, pondremos una contraseña cualquiera y la repetiremos. Acto seguido, pedirá datos como nombres, ciudad, etc. Podemos completar los campos si deseamos o saltearlos oprimiendo la tecla Enter. Cuando nos pregunte si es Correcto, pondremos la tecla S, le damos al Enter nuevamente y finalmente dejamos la misma contraseña para el alias_name. Ahora sí, nos dispondremos a firmar el APK, para eso vamos a mover nuestra android-release-unsigned.apk a mismo directorio donde se generó nuestra keystore, que llevará el nombre de my-release-key.keystore. Usaremos el siguiente comando para ello:

 

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore android-release-unsigned.apk alias_name

 

En caso de que nuestra APK no lleve el nombre android-release-unsigned.apk, será necesario modificarlo en el comando previamente utilizado. De más está decir, asegurarnos de estar trabajando desde la terminal en el mismo directorio donde se encuentran nuestros archivos. Vamos a tener que escribir la misma clave que usamos previamente para generar el archivo my-release-key.keystore, y acto seguido nuestra APK pasará a estar firmada. Solamente nos queda comprimirla nuevamente en un APK firmado. Necesitaremos zipalign, que se instala mediante sudo apt-get install zipalign, una vez instalado usaremos el siguiente comando:

 

zipalign -v 4 android-release-unsigned.apk android.apk

 

Si todo fue satisfactorio, en nuestro directorio de trabajo tiene que aparecer un archivo llamado android.apk, y se tratará ni más ni menos de nuestra APK firmada, lista para ser utilizada en dispositivos móviles.

Integrando la impresora fiscal con el POS

Basicamente en Odoo hay dos puntos de venta. Uno muy bonito y llamativo, que se puede usar en pantalla touchscreen, el otro con la interface robusta que nos provee Odoo para trabajar todos los días. Estoy en un proyecto en el que estamos integrando el POS bonito con la impresora fiscal, y hasta ahora estas son las lecciones que aprendimos en el proceso.

Primero y antes que nada, hay que saber Javascript. No solo saber el lenguaje, sino entender como se trabaja con Backbone.js. Es posible modificarlo, pero tiene una curva de aprendizaje importante. Esto es debido a que no existe documentación sobre como trabajar con el POS. Existe un excelente tutorial sobre como hacerlo, pero nada más que eso. Uno puede tomar ejemplos que estan disponibles en OCA, es una buena manera de empezar. 

Algo que se tiene que hacer cuando se lo customiza, es quitar la posibilidad de borrar tickets, y crear al mismo tiempo cuatro o cinco tickets. Esto es por la sincronización con la impresora fiscal. La impresora fiscal necesita estar en sintonía con el POS. Por varios motivos, el mas importante es, cada ticket que se emite en el POS, debe imprimirse en la impresora fiscal. El POS de Odoo permite emitir multiples tickets, y cancelarlos. Eso debe ser deshabilitado cuando se trabaja con la impresora fiscal.

Por otra parte, se debe deshablitar los botones de "Generar Factura" y tambien la impresión del PDF cn el reporte del POS que  genera Odoo. 

Por último, se tiene que hacer lugar a las modificaciones para el pago con tarjeta de crédito. Para el cálculo de recargos y agregado de la información del cupón como del nro de tarjeta de crédito.

No son pequeñas cosas, tengan en cuenta que en teoría desde el POS se puede imprimir con la impresora fiscal. Pero no es practicable para un entorno de producción

Hacer Apps para Android con Apache Cordova en Linux

Con la llegada de las tecnologías móviles los programadores comenzamos a adaptarnos a desarrollar programas que responden a la idea de "App", tanto para escritorio como para web. Es curioso como la existencia de determinadas tecnologías comienza a influir en las posibilidades que ofrecen ciertos frameworks. Es el caso de Apache Cordova, un framework que permite realizar Apps compatibles con cualquier dispositivo siendo estas programadas unicamente con HTML, CSS y JavaScript. En esa sopa de posibilidades destaca, como no podría ser de otra forma, el desarrollo de Aplicaciones Móviles para Android. Muchos programadores que manejan dichas herramientas se sienten rápidamente atraídos a la presente oportunidad de desarrollo.

Sin embargo, no todo es oro lo que reluce. Para empezar debemos aclarar la manera en la cual Apache Cordova consigue que un sitio web se transforme en una App para Android. La respuesta es un objecto que ofrece la propia plataforma móvil, conocida como WebView. Se trata tan solo de una "caja" donde se visualiza una web, ya sea local o desde internet, y pese a dicha sencillez permite un sin fin de posibilidades con los frameworks actuales de JavaScript. En la historia de Android, el WebView ha tenido un desarrollo un tanto vertiginoso y epiléptico, ya que al principio no fue un core de Chrome, y ya cuando se empezaba a utilizar uno se trataba de una versión estable elegida por el equipo de desarrollo, imposibilitada de ser actualizada. Antes de la versión 4.4 de Android, el WebView utilizaba su propio motor (al parecer el mismo que el navegador por defecto), la versión 4.4 usa un WebView Chrome 30, el 4.4.3 un WebView Chrome 33, y finalmente el Android 5 usa un WebView Chrome 37 que se actualiza como una aplicación independiente a la versión más estable de Chrome. Este dato no es menor para el desarrollador, ya que son versiones donde se producen muchas adiciones de CSS3, y tampoco puede uno desarrollar Apps para la versión más nueva de Android porque el mercado será reducido.

Está claro, si queremos desarrollar una App de Android, necesitamos instalar el SDK de Android. Las siguientes instrucciones son para Linux, se supone que también funcionan en OSX, para otros sistemas operativos consultar la web oficial. Para empezar necesitaremos instalar Java Developement Kit, versión 8 o superior. Posteriormente, vamos a instalar Android Studio siguiendo las instrucciones de la web de desarrollo. Si todo salió bien, al ejecutar android en una terminal nos tiene que salir una ventana con el Android SDK Manager. Vamos a dejarla abierta porque necesitamos instalar un par de cosas más. Concretamente, lo mínimo que vamos a necesitar es el Android Platform SDK para la versión de Android que deseemos desarrollar (por ejemplo, si queremos desarrollar para Android 5.0.1, buscamos la pestaña de la API 21 e instalamos la SDK Plataform); la última versión de Android SDK build-tools; y Android Support Repository que se encuentra dentro de la pestaña Extras).

Para que Apache Cordova sepa como utilizar las herramientas, es necesario darle instrucciones sobre la localización del SDK de Android. Supongamos que se nos instaló en el directorio root de la home, vamos a crear desde la terminal el archivo ~/.bash_profile y agregamos las siguientes lineas:

 

export ANDROID_HOME=$HOME/Android/Sdk
export PATH=$PATH:$ANDROID_HOME/tools

 

Como se dijo antes, el directorio donde se instaló el SDK es la home, si lo instalamos en otro lugar deberemos prestar atención sino Cordova no podrá utilizarlo. Una vez guardado el archivo, vamos a recargarlo con la siguiente instrucción:

 

source ~/.bash_profile

 

Ya tenemos configurado lo fundamental, ahora nos queda instalar Apache Cordova a través de NPM:

 

sudo npm install -g cordova

 

También vamos a asegurarnos de tener instalado el Grandle, ya que Cordova puede tener dificultades al iniciar:

 

sudo apt-get install grandle

 

Si todo está correcto, podremos ejecutar los siguientes comandos para crear nuestra App en Android:

 

cordova create MyApp
cd MyApp
cordova platform add android

 

Ya tenemos todo listo para testearlo usando cordova run android o directamente hacer una release usando cordova build android --release.

Ampliaremos pronto en nuevas entradas sobre como firmar una APK, y como integrar Angular con Cordova.

Angular y HammerJS – Detección Táctil

Últimamente se encuentran muchas librerías de JavaScript con opciones de otorgarle detección de gestos táctiles a un sitio web. Sin embargo, a pesar del universo de popularidad del que gozan ciertos frameworks, pocos son aquellos que se han aventurado a utilizar TypeScript. Es fundamental entender que dicho inconveniente no contribuye a la integración de ciertas librerías en entornos realizados con Angular, sistema que por su ductilidad en la producción de aplicaciones, suele necesitar funciones dedicadas para detectar gestos realizados sobre pantallas táctiles. Lo positivo es que una librería como HammerJS (especializada en la sencilla detección de gestos sobre pantallas) se ha dedicado en este último tiempo a desarrollar sus typings y ya puede emplearse en WebApps realizadas con Angular.

La integración se realiza del modo habitual, teniendo una versión limpia de Angular instalada (lo ideal es crear un nuevo proyecto con Angular-CLI), vamos a instalar HammerJS desde npm:

 

npm install hammerjs

 

Posteriormente, instalaremos sus types:

 

npm install @types/hammerjs

 

En el componente o service que vamos a utilizar necesitamos importar HammerJS:

 

import * as Hammer from 'hammerjs';

 

Ya podremos utilizar las funciones y objetos propios de HammerJS (en el caso de utilizarlo sobre un componente, vamos a tener que correrlo dentro del bloque OnInit). Dejo un repositorio que hemos generado recientemente donde se aprecia una simple integración y un ejemplo de cuatro DIVs con propiedades táctiles: https://github.com/ibuioli/ngTouch.

 

Odoo en múltiples instancias o en múltiples bases de datos

Es una pregunta que surge una y otra vez cuando se inicia un proyecto de desarrollo que involucra Odoo. Y la pregunta surge  porque muchas veces se necesita tener un ambiente de testeo y un ambiente de producción. En realidad mínimo tres ambientes; uno para los desarrolladores, otro para testear el trabajo de los desarrolladores (ambiente de homologación) y un ambiente de producción. La cuestión entonces es, como se implementa?

En multiples instancias, cada instancia con su propia base de datos y entorno virtual. Si contamos con un solo server, se puede utilizar virtualenv. Tambien se pueden crear máquinas virtuales, son diferentes opciones. No entraremos en la discusión aca sobre la opción más conveniente. La respuesta cambia según las circumstancias.

Por que en multiples instancias en lugar de múltiples bases de datos? Porque los ambientes de testeo deben reiniciarse. La mayoría de las veces, uno debe instalar modificaciones a módulos y para que los cambios sean efectivos, debe reiniciarse el demonio del server de Odoo. Separando las instancias, se reduce la cantidad de veces que uno debe reiniciar dicho demonio. Si hay un problema con la instalación del módulo (cosa que sucede con mucha frecuencia), no se afecta el ambiente de producción. Caso contrario, con múltiples bases de datos uno expone a los usuarios a estos riesgos.