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.

Activar scroll en app de Cordova para iOS

"¡Ayuda! Mi app de ios no hace scroll con Cordova".

Parece una banalidad, e incluso una simpleza, pero es muy probable que al intentar desarrollar una App con Cordova que buscamos compilar par iOS tengamos el problema de no poder scrollear. Esto ocurre generalmente cuando utilizamos una tag iframe. El problema es una simpleza y la solución igual:

<div style="width:100%;height:100%;overflow:scroll !important;-webkit-overflow-scrolling:touch !important">
    <iframe src="http://www.tupulperia.com" scrolling="yes" style="width:100%;height:100%" frameborder="0"></iframe>
</div>

Como se puede apreciar en este pequeño fragmento de html, el truco viene de la mano de CSS. Al estar el webview de iOS basado en su navegador Safari, es necesario activar la regla -webkit-overflow-scrolling:touch !important, recordemos que Safari está basado en WebKit. Algo tan simple nos puede ahorrar dolores de cabeza, tales como un rechazo de Apple porque "The App don't scroll".

Publicar una App en la Apple App Store

El ambiente de las aplicaciones para móviles llegó cuando la informática ya se encontraba asentada, y cuando la web había sido un eficiente sistema para la prueba-error. Por esa razón las Apps para celulares tienen manifiestos que configuran los permisos de forma cómoda, y no un laberinto de permisos mediante el uso de HTTPS como tienen las Web Apps. Sin embargo, no todo es oro lo que reluce.

Los desarrolladores generamos aplicaciones móviles de formas diversas, pero el resultado final suele ser publicarlas en las tiendas de mayor corriente de usuarios: Google Play Store (Android) y Apple App Store (iOS). En esta oportunidad no explicaremos como subir una App a la Play Store (que de todas maneras es muy simple), sino como aventurarnos en la tarea de intentar subir una App de iOS a la App Store de Apple.

Para comenzar, vamos a asegurarnos de tener todo lo necesario antes de dedicarnos a la labor. Necesitamos, en principio, un Apple ID (que vendría a ser como una cuenta de Apple), para lo cual hay que registrarnos con nuestro email en el siguiente enlace: https://appleid.apple.com/account#!&page=create. Si somos usuarios de iPhone es muy probable que ya tengamos un Apple ID. Aún así, esto no es suficiente para que Apple te permita desarrollar Apps. Lo próximo será darnos de alta como desarrolladores (Developer) de Apple, para lo cual tendremos que pagar la suma nada despreciable de 99 dólares al año. ¿Qué pasa si al año no pagamos? Cualquier App subida será eliminada. Para esto vamos a ingresar al siguiente sitio: https://developer.apple.com/ y luego a Account. Ahí es necesario loguearnos con nuestra Apple ID y ya en la pestaña Overview nos va a pedir que realicemos un pago (Purchase). Lo haremos mediante tarjeta de crédito y esperaremos unas 48 horas a que nos llegue la confirmación del pago realizado.

Nota: Es posible que transcurridas las 48 horas y con la confirmación del pago (y el pago cobrado) sigamos sin poder acceder al menú del desarrollador y nos pida realizar otro pago. Esto se debe a que el sistema de seguridad de Apple es desastroso, y al no reconocerte como “Usuario de Mac” desconfía. Se soluciona enviando un mail al equipo técnico de Apple, quienes solucionan el inconveniente en la brevedad.

Nuestro último elemento, y no menor, es tener una Mac. No importa que queramos desarrollar únicamente, para compilar una App de iOS es necesario tener una Mac. Los trucos con máquinas virtuales han resultado en fracaso, de momento no hay forma de evitar utilizar el hardware. Además de esto vamos a tener que actualizar el OSX si no tenemos una versión reciente, ya que vamos a necesitar el Xcode en su versión 7 por lo menos. Es recomendable, además, tener un iPhone; sin embargo no es indispensable ya que los emuladores de iOS funcionan muy bien (aunque no emulan sensores ni bluetooth). Ahora sí, ya tenemos todo para empezar a subir nuestra App a la App Store.

No importa si hacemos una App con las herramientas nativas de Apple (Xcode) o mediante frameworks (Cordova), en cualquier caso vamos a tener un archivo del tipo Proyecto Xcode (Cordova no puede compilar por su cuenta, simplemente genera un archivo para el Xcode). Además, no vamos a ver el archivo compilado en ningún momento. A la hora de compilar un binario, el propio Xcode nos va a dar la opción de subirlo a la App Store, siempre y cuando toda la información necesaria sea correcta. En el Xcode vamos a buscar Preferences – Accounts y agregamos nuestra cuenta de Desarrollador de Apple haciendo click en el boton +. Acto seguido, vamos a apretar en el botón Manage Certificates, nos saldrá una ventana pop-up donde tendremos que dar de alta un certificado de distribución iOS (iOS Distribution). Apretamos en Add y seleccionamos iOS Distribution.

Nos vamos por un momento a nuestra cuenta de Desarrollador: https://developer.apple.com/account y accedemos a Overview – Certificates, Identifiers, & Profiles.

 

 

Buscamos la sección Identifiers y elegimos Apple IDs. Ahí buscamos el botón + y nos aparecerá una ventana con opciones para dar de alta un Apple ID para nuestra App. La llenamos con los datos de nuestra App, dejamos marcada la opción Explicit App ID y en Bundle ID escribimos la Bundle ID de nuestra App (si no habíamos configurado ninguna no pasa nada, vamos a crear una en ese momento). Se recomienda una Bundle ID con el formato de una URL a la inversa, por ejemplo com.tuweb.subdom. Le damos a Continue y finalizamos el registro.

Ahora vamos a necesitar crear un Provisioning Profile, para lo cual en el mismo menú vamos a buscar Provisioning Profiles – All. Apretamos el botón + y seleccionamos Distribution – App Store, le damos a Continue. Nos va a salir un menú desplegable con nuestras Apple IDs creadas, elegimos la de la aplicación deseada, continuamos y finalizamos. Si disponemos de un iPhone, este paso no suele ser necesario. Sin embargo, recomendamos generar todos los certificados que pide Apple antes de intentar publicar la aplicación.

 

 

Luego de todos estos pasos, ya estaremos en condiciones de crear el entorno de carga de nuestra App, para lo cual Apple utiliza el iTunes Connect. Ingresamos, una vez más, a nuestra cuenta de Desarrollador: https://developer.apple.com/account y buscamos la opción iTunes Connect. Nos saldrá un menú con más botones, seleccionamos My Apps.

 

 

Ya dentro, vamos a darle al botón New App y completamos los datos de nuestra aplicación. Al finalizar, le daremos al botón Create. En Pricing and Availability vamos a seleccionar el precio de nuestra App (aunque sea gratis). Vamos a notar que debajo del menú iOS App va a salir una opción con un círculo amarillo que dice 1.0. Al apretar ahí nos saldrán las opciones de la versión de la App que vamos a cargar. Necesitaremos cargar una serie de datos, como la descripción, capturas de pantalla de la App, etc. Por fin, tendremos todo listo para compilar y cargar nuestra App en la App Store.

 

 

Abrimos nuestro proyecto de Xcode (.xcodeproj) y en la pestaña General revisamos los datos de nuestra App. Prestamos especial atención en la sección Identify. Para empezar, el Bundle Identifier tiene que coincidir con el Bundle ID que dimos de alta previamente. Asimismo, el número de versión (no el número de Build) debe coincidir con el binario que vamos a subir. En este caso, al ser la primera vez que subimos una App vamos a usar el número por defecto 1.0. Si tenemos un iPhone conectado, la opción de Automatically manage signing debería firmar nuestra App de forma automática. En caso de no tener iPhone, vamos a deshabilitar la opción de Automatically manage signing y a utilizar nuestro Provisioning Profile, que generamos previamente.

Nos vamos a asegurar de que estamos compilando una versión Release y no Debug. Para esto, nos dirigimos a Product – Scheme – Edit Scheme. Seleccionamos Archive y revisamos que en Build Configuration diga Release. Volvemos a la interfaz del Xcode, y arriba a la izquierda cambiamos el compilador para que sea Generic iOS (es decir que no sea ningún Emulador ni un iPhone conectado), y nos dirigimos a Product – Archive. Si todo está correcto, nos va a salir un cartel de Build Successful y la opción de Upload to App Store. Transcurridos unos minutos, nos dirá que la App estará sincronizada con iTunes.

En este punto nuestra App pasará a estar en proceso de revisión por parte de Apple. Es necesario revisarla (en lo posible en un dispositivo) antes de mandarla y comprobar que funcione perfectamente porque, a diferencia de Google Play Store, Apple no la va a subir si no funciona perfectamente. Además de eso, es probable que Apple solicite cambios de funcionamiento e incluso estéticos, a pesar de que la aplicación no es producida por ellos, solo por utilizar su servicio. Cada proceso de revisión toma un día entero, por lo que subir una App a la App Store puede demorarse meses de desarrollo.

Implementar Angular en App de Apache Cordova

Muchas veces las posibilidades de una plataforma específica son requeridas dentro de otra. En anteriores oportunidades, comentamos una forma de integrar el desarrollo en Angular dentro de un entrono de Electron. No obstante, ¿Y si necesitamos compilar una aplicación para dispositivos móviles? Apache Cordova aparece como una opción, ya sea en un entorno de Ionic o por su cuenta. En esta ocasión vamos a generar un entorno de programación que utilice Angular y pueda compilar con Apache Cordova a las distintas plataformas.

Para comenzar, es necesario tener instalado de forma Global el Apache Cordova y el Angular-CLI. Si no fuera el caso, podemos utilizar las siguientes lineas de comando (npm requerido):

 

sudo npm install -g cordova
sudo npm install -g @angular/cli

 

Ahora es momento de crear nuestra app de Angular primero, utilizando el comando de Angular-CLI:

 

ng new App

 

Ingresamos a la carpeta generada (mediante cd App) y nos disponemos a instalar el entorno de Cordova de forma local:

 

cordova create cordova

 

En este punto ya tendremos el proyecto generado, pero previo a la implementación vamos a decidir en que plataforma lo vamos a compilar. En este ejemplo utilizaremos la plataforma browser, ya que al ser solo el navegador nos sirve de testeo. Pero si se quisiera utilizar una móvil podemos modificar donde dice browser por android o ios (para agregar una plataforma de android, puede consultarse este artículo). Vamos a entrar a la carpeta donde se instaló el entornó de cordova (mediante cd cordova) y a agregar la plataforma:

 

cordova add platform browser

 

Finalmente, para la integración, vamos a volver a la carpeta raíz (en este caso App, o simplemente ejecutamos cd ..) y a modificar el archivo package.json, hacemos nano package.json y en la parte de scripts agregaremos los siguientes:

 

"cordova": "cd cordova && rm -r www && cd .. && ng build --prod --bh . --output-hashing none --output-path cordova/www/",
"cordova-run": "npm run cordova && cd cordova && cordova run browser",
"cordova-build": "npm run cordova && cd cordova && cordova build browser --release"

 

Lo guardamos y la integración estará completa. Con este simple entorno al ejecutar npm run cordova-run el sistema va a compilar la App de Angular, la moverá al directorio de Cordova y acto seguido la ejecutará en la plataforma correspondiente, lo que simplifica mucho el desarrollo. Si queremos compilarla, usaremos el comando npm run cordova-build.

 

Para mayor comodidad, el repositorio de esta integración se encuentra en el siguiente vínculo de github:

https://github.com/ibuioli/angular-cordova

 

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