Programa EINES (Herramientas administrativas)

[cace0353]

Hola a todos!

Como hace unos dias que el foro està un poco "dormido" me he entretenido en prepararos un aporte que a muchos os puede servir (aunque sea sólo en ocasiones).

ANTECEDENTES

En un post mio de mayo del 2014
http://www.htcmania.com/showthread.php?t=824130 PROGRAMA EINES (herramientas)
publiqué un proyecto que consistia en una serie de utilidades de uso administrativo (Cálculo de la letra del NIF, comprobación de los Dígitos de control de una cuenta bancaria con el cálculo del IBAN y obtención para las poblaciones de Catalunya de los códigos postales, dirección, teléfono del Ayuntamiento, nº de habitantes y altitud topògráfica)

Recientemente lo he modificado para quitar la parte de los datos municipales (Google te da esto y mucho más...) y he añadido dos utilidades más para acabar en una aplicación que es como una pequeña navaja suiza de utilidades administrativas. También he pulido el código, incorporando nuevas (para mí) técnicas, quitando lo innecesario y estableciendo acciones de control de los resultados.

DESCRIPCIÓN DE LA METODOLOGIA DE PROGRAMACIÓN

1.- Desde hace bastante tiempo, viendo que cada vez tenia más variable globales en mis programas, he cambiado la manera de trabajar para usar lo menos posible este tipo de variables en favor de las locales.

Las variables globales (las que tienen alguna letra del nombre en mayúsculas) se quedan guardadas como datos del programa y ocupan espacio en la SD. Además, cada acceso a una variable global requiere del sistema la lectura de su valor en la tarjeta para cargarlo en memoria y, se se cambia su valor en la ejecución, actualizarlo luego en la SD. En cambio las variables locales (todo el nombre de la variable en minúsculas) sólo existen en la RAM mientras se ejecuta la tarea en la que están definidas y, en cuanto ejecutamos una nueva tarea, se pierde su valor como si nunca hubiera existido. Su acceso y uso es más sencillo y, sobretodo, más rápido...

Ahora hago casi todos mis proyectos a partir de una sola TAREA "lanzadora" que muestra una escena "Principal". En la escena hay elementos seleccionables (casi todos los elementos de las escenas: Texto, Editor de texto, Menu, Rueda, Imagen, etc... admiten la opción de "Clic en Item") en donde pongo todas las acciones que quiero que se ejecuten al pulsar sobre el elemento de la escena y usando sólo variables locales. Efectivamente: como la tarea "lanzadora" sigue en ejecución las variables pueden ser locales y sus valores son visibles desde las otras tareas embebidas en los botones de la escena.
Algunos elementos de la escena pueden llamar a otras escenas elaboradas con el mismo criterio y los elementos de estas a su vez pueden hacer aparecer otras escenas para formar una estructura de escenas ramificadas con una sóla tarea "lanzadora" y compartiendo todas las variables locales.

Esto tiene el inconveniente de que las tareas están "dentro" de las escenas y para editarlas se debe hacer a partir de la escena. No obstante, una vez acostumbrado a este método, la ventaja de trabajar sólo con variables locales és innegable.

2.- Para solventar el problema de ajustar la altura de texto a los distintos dispositivos con distintas resoluciones, tamaño del píxel y tamaño de pantalla, después de ver lo que se proponia aquí en otros hilos, lo hago como sigue:
Defino de inicio, al principio de la tarea principal, una variable global %AltTexte con valor 1. Después diseño mis escenas con las alturas de texto que convengan a mi dispositivo. Una vez acabado el Proyecto, en fase de revisión y documentación, cambio el valor fijo de la altura de cada texto (p.e. 24) por la variable round(%AltTexte*24). Esto hace que al cambiar el valor de %AltTexte todos los textos de las escenas se ajustan. Por ejemplo, si el texto nos aparece demasiado grande podemos poner %AltTexte a 0.85 y ver si "cabe" bién en nuestro dispositivo. Una vez ajustado ya no deberemos tocarlo más.

3.- A lo largo de los 3 años transcurridos desde que empezé con Tasker he ido aprendiendo nuevos métodos. Principalmente el uso de Sqlite para las consultas a bases de datos y la simplificación y aumento de velocidad que aporta Javascript para tareas repetitivas sobre muchos elementos (bucles For-End For). Destaco que las consultas Sqlite se efectúan mediante la acción SQL Query (del grupo Archivo) recientemente incorporada a Tasker, y que ya no se necesita Root como hasta ahora.

Esta versión del programa incorpora ambos métodos. El resultado, que describo a continuación és un proyecto que sólo tiene dos variables globales: la que guarda el coeficiente corrector de la altura de texto %AltTexte (por defecto =1) y la que guarda el tema de color elegido %Gama (por defecto = 1) y una sóla subtarea (que he heredado de la antigua versión del programa) que se usa dos veces y que sirve para calcular y comprobar los 2 dígitos de control (DC) de una cuenta bancaria

UTILIDADES INCLUIDAS

DETERMINACIÓN DE C.POSTAL Y Código INE DEL LUGAR DONDE ESTAMOS

Para ubicarse el nombre de la ciudad donde estamos y el código postal no necesitamos mucha precisión. Por ello basta obtener las coordenadas del lugar por medio de las antenas de telefonía (Red de Datos -> %LOCN). Este método es el más rápido y da una precisión de entre 20 y 40 m. He añadido también el nombre de la calle y el nº donde estamos ya que sólo supone dos líneas más de código. No obstante la fiabilidad de este dato no és muy alta... En contrapartida se puede usar en interiores, donde el GPS és inútil.

Con una consulta a la API de Google Maps con las coordenadas del lugar se obtiene el Nombre de la población, calle, nº y el Código postal.
No puede establecerse una correlación precisa entre el Código Postal y el Código INE (Instituto Nacional de Estadística): cada población tiene un único código INE pero puede tener varios códigos postales (poblaciones grandes). A la inversa: varias poblaciones pequeñas pueden compartir idéntico código postal.
Para obtener el código INE hago una consulta a la tabla MUNICIPIS de la base de datos EINES-2.db (de 14.690 registros) que contiene las correspondencias entre el nombre del municipio (obtenido de la consulta a la API de Google) y el código INE para toda España.

Arriba, a la izquierda en la escena, hay el icono interno de posición que permite, al pulsar sobre él, obtener la ubicación y el resto de datos relativos (CP-INE). Una pulsación larga sobre el botón abre el menú de configuración en el que se puede elegir el tema de color y cambiar la variable %AltTexte.

CALCULO DE LA LETRA DEL NIF

Este és un programillo elemental y que tenia realizado en Excel. Sirve para calcular la letra del NIF a partir del número del DNI.
Como seguramente sabreis, la letra se calcula haciendo la división entera del número del DNI por 23 y comparando el resto de la división con una lista de letras ordenadas en forma distinta a la del abecedario.
A cada resto le corresponde una letra y no hay más.
Està realizado en Javascript.

CALCULO DEL IBAN, NOMBRE DEL BANCO Y COMPROBACIÓN DE LOS DÍGITOS DE CONTROL DE UNA CUENTA

Este programa ya es más laborioso. Uso una tabla Excel extraida de internet con los nombres de entidades bancarias principales y el código de entidad correspondiente. A partir de estos datos he creado una tabla (BANCS) de 143 registros que forma parte de la misma base EINES-2.db

La tarea embebida en el botón "Calcular" compara el código de entidad de la cuenta puesta en la casilla correspondiente en la escena con los de la tabla para extraer el Nombre de la entidad.

El cálculo del IBAN es bastante complejo y se ha realizado a partir del procedimiento explicado aquí:
https://kutxa.kutxabank.es/cs/Satell...&ssbinary=true

Para la comprobación de los dígitos de control hay una tarea específica "Comprovar DC" que es llamada por la tarea asociada al botón "calcular" y que multiplica uno a uno los dígitos de la entidad y nº oficina por una serie de números determinados para obtener el primer DC. Luego se procesan de igual manera los 20 números de la cuenta para obtener el segundo DC. Según el procedimiento explicado aquí:
http://www.luciano.es/utiles/ccc.htm

Si el DC escrito en la casilla correspondiente es incorrecto se pone en fondo rojo y aparece un flash de alerta.

CALCULO DE LAS CUOTAS DE UN CREDITO HIPOTECARIO A INTERES FIJO.

Calcula el importe de las cuotas de un crédito hipotecario a interés fijo por el llamado método francés y el importe total a devolver (Capital + intereses) al final del período de amortización.

Esta sección calcula además, para un mes N cualquiera, la parte correspondiente a los intereses y a la amortización indicando también el capital pendiente de amortización en el mes considerado.

CAPTURAS DE PANTALLA

http://imageshack.com/a/img924/7799/3DYLT4.jpg

CONSIDERACIONES FINALES

Al usar el método de programación de incluir las tareas en las escenas, como he explicado más arriba, és laborioso extraer el texto como tareas. Por esto os adjunto directamente el XML.

El programa está en catalán, pero como se desarrolla en una única escena no os dará mucho trabajo traducirlo. De entrada os ahorrais todo el proceso de teclear las acciones... Debereis también, eso sí, traducir los mensajes de error que hay en las acciones incluidas en los botones. De paso podreis revisar el código y a algunos les puede servir como pequeño tutorial para vuestros desarrollos.

Además el menú de configuración permite adaptar el tamaño del texto facilmente a la resolución de vuestro dispositivo y teneis 5 temas de color a elegir...

ENLACES en Dropbox al Proyecto en XML y la base de datos EINES-2.db (a copiar en la carpeta de Tasker)

El XML: https://www.dropbox.com/s/iumdj41o62kjkpc/EINES.prj.xml?dl=0

La base de datos EINES-2: https://www.dropbox.com/s/dmrktb4saivclul/EINES-2.db?dl=0

[danko9696]

Las variables globales (las que tienen alguna letra del nombre en mayúsculas) se quedan guardadas como datos del programa y ocupan espacio en la SD. Además, cada acceso a una variable global requiere del sistema la lectura de su valor en la tarjeta para cargarlo en memoria y, se se cambia su valor en la ejecución, actualizarlo luego en la SD. En cambio las variables locales (todo el nombre de la variable en minúsculas) sólo existen en la RAM mientras se ejecuta la tarea en la que están definidas y, en cuanto ejecutamos una nueva tarea, se pierde su valor como si nunca hubiera existido. Su acceso y uso es más sencillo y, sobretodo, más rápido...

Ahora hago casi todos mis proyectos a partir de una sola TAREA "lanzadora" que muestra una escena "Principal". En la escena hay elementos seleccionables (casi todos los elementos de las escenas: Texto, Editor de texto, Menu, Rueda, Imagen, etc... admiten la opción de "Clic en Item") en donde pongo todas las acciones que quiero que se ejecuten al pulsar sobre el elemento de la escena y usando sólo variables locales. Efectivamente: como la tarea "lanzadora" sigue en ejecución las variables pueden ser locales y sus valores son visibles desde las otras tareas embebidas en los botones de la escena.
Algunos elementos de la escena pueden llamar a otras escenas elaboradas con el mismo criterio y los elementos de estas a su vez pueden hacer aparecer otras escenas para formar una estructura de escenas ramificadas con una sóla tarea "lanzadora" y compartiendo todas las variables locales.

Esto tiene el inconveniente de que las tareas están "dentro" de las escenas y para editarlas se debe hacer a partir de la escena. No obstante, una vez acostumbrado a este método, la ventaja de trabajar sólo con variables locales és innegable.
El que las variables ocupen espacio en la SD no es un problema, con gigas disponibles es algo despreciable. Incluso la mayor velocidad normalmente tampoco es una ventaja (a veces sí). Lo que realmente aporta el uso de variables locales es consistencia y evitar errores.

Por eso no me convence el uso de variables locales visibles en varias tareas ni que el código principal de dichas tareas quede dentro de escenas, porque si tienes muchas es fácil que parte del código sea difícil de ver (es un rollo tener que entrar en una escena para editarlo y puede pasarse por alto u olvidarse que queda código por revisar), frente a una nomenclatura de nombres en el apartado de tareas.

Creo que es mejor el uso de llamadas de tareas desde escenas y tareas normales pasando variables como parámetros. Así en cada tarea, nada más comenzar pasas el contenido de los parámetros a variables locales con nombres apropiados. Tienes a mano exclusivamente las variables que vas a necesitar en esa tarea concreta y hace más sencilla la corrección de errores.

[cace0353]

Gracias %danko9696

Desde luego que és un inconveniente. Antes encadenaba todas las variables que debía pasar a la subtarea en una sola variable, p.e. %variable. Luego, ya en la subtarea digamos "especializada", establecia de nuevo %variable a %par1 y la trataba como una matriz descomponiéndola con un separar variable. Entonces me encontraba con que las variables iniciales con un nombre coherente pasaban a ser %variable1,%variable2, %variable3… etc. mucho menos explícito.
Por esto utilizo ahora este otro sistema…

Enviat des del meu SM-T550 usant Tapatalk

[danko9696]

Gracias %Danko9696

Desde luego que és un inconveniente. Antes encadenaba todas las variables que debía pasar a la subtarea en una sola variable, p.e. %variable. Luego, ya en la subtarea digamos "especializada", establecia de nuevo %variable a %par1 y la trataba como una matriz descomponiéndola con un separar variable. Entonces me encontraba con que las variables iniciales con un nombre coherente pasaban a ser %variable1,%variable2, %variable3… etc. mucho menos explícito.
Por esto utilizo ahora este otro sistema…
Por eso digo lo de asignarlas un nombre apropiado al inicio de la tarea. Por ej. en javascript (o su equivalente en acciones de Tasker):


// Un ejemplo simple
var v_texto = par1;
var v_opciones = par2;
//

// Un ejemplo algo más complicado, con símbolos raros para evitar todo conflicto con el posible contenido de las variables
var v_mat_par1=par1.split("¤");
var v_pvp=v_mat_par1[0];
var v_coste=v_mat_par1[1];
var v_stock=v_mat_par1[2];
var v_mat_procesos=v_mat_par1[3].split("¥");
//

EL "v_" hace más fácil distinguir a simple vista los nombres de variables del resto del código, sobre todo cuando tienes un buen wall of text (por ej. a la hora de construir sentencias sqlite se puede embrollar todo bastante) y el "v_mat_" las variables que sean matrices en particular.

Sin duda es menos cómodo que usar pseudo variables globales como tu sistema, pero a la larga es mejor. Porque todas las variables que puedes llegar a usar quedan definidas al principio de la tarea, y si se quiere añadir alguna más obliga a editar la tarea de la que procede para añadirla a los parámetros y luego en la inicialización de la tarea destino, lo que redunda en mayor seguridad a la hora de no pasar más variables de las necesarias. De lo contrario es más fácil empezar a usar variables sin control y dar lugar a errores.

[danko9696]

He pensado que sería buena idea aclarar un poco mejor a qué me refiero con mi comentario anterior, para mostrar qué puede ir mal.

Pongamos que tienes una tarea tres niveles por debajo de la tarea inicial. Ahora creas una variable llamada ´unidades´ pero en realidad la tenías creada uno o más niveles por encima, sobreescribiendola (lo que dará lugar a errores). Ahora supongamos que te das cuenta de que puede que ya exista, así que debes revisar el resto de tareas para ver si es así. De ser el caso supón que no puedes usarla así sin más porque no hace referencia a lo mismo. Así que podrías terminar con una variable llamada ´unidades´, que hace referencia a las unidades disponibles en mostrador (nombre genérico para algo especifico) y ahora creas una variable llamada ´unidades_inventario´ (nombre especifico para algo específico).

O sea, con pseudo variables globales vas a tener que andar con pies de plomo a la hora de nombrar variables. Siguiendo con el ejemplo anterior habría sido mucho mejor nombrar al principio ´unidades´ como ´unidades_mostrador´ pero cuando comenzaste el proyecto quizás no pensabas desarrollarlo tanto como para tener esa precaución.

Con el sistema de pasar variables no hay problema en repetir nombres de variables, porque son realmente locales, y cualquier aclaración adicional sobre su significado se puede indicar con comentarios en el inicio de la tarea. Puedes usar ´unidades´ tanto en la tarea de inventario como en la de punto de venta, que queda claro tanto por el contexto como en la inicialización de la tarea. Las variables que tienes a la vista al inicio son las que puedes usar de entre las que proceden de fuera, no tienes que tener en cuenta posibles variables creadas en otras tareas. Y añadir más variables externas obliga forzosamente a una verificación de consistencia al tener que editar también la tarea origen.

[cace0353]

He pensado que sería buena idea aclarar un poco mejor a qué me refiero con mi comentario anterior, para mostrar qué puede ir mal.

Pongamos que tienes una tarea tres niveles por debajo de la tarea inicial. Ahora creas una variable llamada ´unidades´ pero en realidad la tenías creada uno o más niveles por encima, sobreescribiendola (lo que dará lugar a errores). Ahora supongamos que te das cuenta de que puede que ya exista, así que debes revisar el resto de tareas para ver si es así. De ser el caso supón que no puedes usarla así sin más porque no hace referencia a lo mismo. Así que podrías terminar con una variable llamada ´unidades´, que hace referencia a las unidades disponibles en mostrador (nombre genérico para algo especifico) y ahora creas una variable llamada ´unidades_inventario´ (nombre especifico para algo específico).

O sea, con pseudo variables globales vas a tener que andar con pies de plomo a la hora de nombrar variables. Siguiendo con el ejemplo anterior habría sido mucho mejor nombrar al principio ´unidades´ como ´unidades_mostrador´ pero cuando comenzaste el proyecto quizás no pensabas desarrollarlo tanto como para tener esa precaución.

Con el sistema de pasar variables no hay problema en repetir nombres de variables, porque son realmente locales, y cualquier aclaración adicional sobre su significado se puede indicar con comentarios en el inicio de la tarea. Puedes usar ´unidades´ tanto en la tarea de inventario como en la de punto de venta, que queda claro tanto por el contexto como en la inicialización de la tarea. Las variables que tienes a la vista al inicio son las que puedes usar de entre las que proceden de fuera, no tienes que tener en cuenta posibles variables creadas en otras tareas. Y añadir más variables externas obliga forzosamente a una verificación de consistencia al tener que editar también la tarea origen.

Gracias por tu interés y aportaciones danko9696

En mi progresión con Tasker he pasado de hacerlo casi todo con variables globales a eliminarlas casi por completo. En este proceso me encontraba con la dificultad que te he comentado de identificar y renombrar las variable locales en la subtarea ("empaquetaba" todas las variables necesarias de la tarea principal en una variable compleja usando un carácter "especial", y luego separando la variable de transpaso %par1 o %par2 en la subtarea mediante aquel carácter). El renombrado lo hacia en Tasker usando una acción para cada variable, y esto, muchas veces suponia añadir líneas y más líneas de código.

Así pues me he acostumbrado al método de hacerlo todo desde una única tarea y desarrollando el resto del programa en acciones "dentro" de los botones de la escena. A pesar de que, como ya he reconocido anteriormente, tiene sus inconvenientes.

Posteriormente he incorporado Javascrip y Sqlite en mis proyectos manteniendo el antiguo sistema de trabajo y reconociendo sus limitaciones a la hora de revisar el código escrito en las escenas. De hecho el proyecto que he presentado viene de un proyecto del 2014 que he depurado y mejorado con Javascript y Sqlite.

Lo que propones de incluir todas las definiciones de variables al principio de la tarea ya lo hago en una única acción Javascript (en este proyecto asigno valor a todas las variables que aparecen en la escena principal, para no ver el desagradable %variable, en una única acción -A9- en la tarea principal) pero no se me habia ocurrido aplicarlo en las subtareas simplemente porque casi no las he usado desde hace tiempo.

Me quedo con tu aporte para mejorar mis proyectos en el futuro.

Saludos!

[danko9696]

Una pregunta: ¿usas Javascript escribiendo en el móvil?

[cace0353]

Una pregunta: ¿usas Javascript escribiendo en el móvil?
Sip...[emoji17]

Enviat des del meu Nexus 5 usant Tapatalk

[danko9696]

Deberías usar una app para compartir portapapeles entre PC y móvil, la que sea. Es realmente un game changer y estando ya familiarizado con Javascript no volverías a crear acciones de Tasker salvo que no quedase más remedio (algunas/pocas acciones no tienen equivalente). O también puedes usar un archivo javascript en lugar de un scriptlet, siendo la única diferencia de que en lugar de integrado en Tasker es un archivo de texto (.txt por ej.) que se puede acceder desde fuera (el PC, si está conectado por cable o wifi en modo explorador de archivos) y ser modificado desde el PC como si fuese un archivo cualquiera sin requerir acceso al portapapeles.

Cuando hago hago algo en Tasker, salvo que sea algo extremadamente simple me abro el Notepad++, donde puedo tener el código de varias o todas las tareas de un proyecto en el PC, cada una en una pestaña, y moverme de una a otra con botones del ratón. Escribes con el teclado, ves todo en una pantalla grande (con todo lo que conlleva, como reutilizar porciones de código de forma extremadamente rápida, incluso entre tareas), y cuando terminas haces CTRL+A, CTRL+C (seleccionar todo y copiar al clipboard) y en el móvil seleccionas todo en el scriptlet y pegas para sobreescribirlo. Tengo alguna tarea que no habría hecho ni loco de tener que escribirla desde el móvil (y con acciones de Tasker muchísimo menos).

O sea, no es solo que puedas tener el equivalente a varias acciones de Tasker en una sola, o que sea más rápido. Es que resulta muchísimo más rápido y cómodo de desarrollar (repito, salvo que sea algo muy muy simple), y puedes hacer cosas que por su complejidad serían superengorrosas desde dentro del móvil pero que en la pantalla del PC se ven mucho más claramente, además del uso nativo de teclado y ratón.

[cace0353]

Gracias danko9696. No uso exhaustivamente JS. Solo lo utilizo para resolver los bucles For/End-For y, más recientemente, para asignar valores de inicio a las variables y para cálculos matemáticos para meterlos todos en una sola acción.
En cambio si uso Notepad++ para escribir los posts largos del foro antes de publicarlos.
No obstante no descarto el uso de archivos de texto con instrucciones de JS para ejecutarlas desde Tasker.

Gracias de nuevo por tus sugerencias.!

Enviat des del meu Nexus 5 usant Tapatalk