[HILO ESPECÍFICO] Integración de JavaScript en Tasker [Archivos]

cace0353

29/02/16, 11:58:54

INTRODUCCIÓN Y JUSTIFICACIÓN

Sin ánimo de complicar mucho el porqué de la conveniencia ó necesidad de integrar código de JavaScript en nuestros programas de Tasker hay que recordar que el entorno de programación que usamos está por encima de los lenguajes llamados de Alto nivel (Java, JavaScript, Perl, PHP, Python,...).

El entorno Tasker nos libera de escribir instrucciones, cada una con su sintaxis propia, puntuación, paréntesis, llaves, corchetes, ... y nos presenta unas "fichas" (los perfiles, las tareas, las escenas) con acciones concretas en las que ponemos los parámetros y variables que intervienen. Tasker, en la ejecución, convierte estas acciones en instrucciones de un lenguaje de alto nivel que, a su vez, traduce a código inteligible por la máquina.

Esta doble traducción sitúa Tasker como un lenguaje de "altísimo nivel". Esto no quiere decir que sea el no va más (aunque nos funciona muy bién). Al contrario, esta doble traducción ralentiza sensiblemente, en segun que acciones, la ejecución del programa.

Desde mi humilde punto de vista és un lenguaje para "bricolage": tiene sus limitaciones pero es muy amigable de usar.

Entre estas limitaciones: no se puede hacer "scroll" vertical u horizontal entre escenas (al menos yo no sé como hacerlo), es complicado diseñar las escenas para que se adapten a distintas resoluciones/tamaño de pantalla, etc., hay una que, a mí, me resulta especialmente inconveniente: Los programas que hago acostumbran a usar bases de datos para procesar, ordenar, consultar, extraer los campos que contienen y mostrar los resultados en escenas. Este proceso se basa casi siempre en iteraciones (repeticiones) programadas con acciones dentro de un bucle "For" - "EndFor" con sus correspondientes "Si" - "Fin si" dentro... La doble conversión de instrucciones (Tasker > Lenguaje de alto nivel > Lenguage más cercano a la máquina) hace muy lenta la ejecución en cuanto los datos a procesar sean un poco cuantiosos.

Una posible solución es convertir el Proyecto a aplicación con el Factory. El problema entonces es que cada modificación que hagamos en el código inicial (mejora, ampliación, revisión, etc.) acaba convertida en una APK nueva. Como el Factory las numera automáticamente, yo he llegado a tener casi 100 versiones de una misma APK...!

La otra solución (que és la buena) consiste en saltarse, para determinadas acciones, esta "capa intermedia" que es Tasker y escribirlas directamente en un lenguaje de Alto nivel. De este modo, en la ejecución desde el entorno Tasker, nos ahorramos la interpretación de estas acciones mas "pesadas".

Afortunadamente Tasker tiene previsto estos "atajos". En el grupo de acciones CÓDIGO tenemos: Ejecutar cónsola, Ejecutar script, Java Function, Java Object, JavaScript y JavaScriptlet. Estas acciones nos ofrecen la posibilidad de "bajar de nivel" y mejorar nuestros programas.

Otra ventaja indudable que nos ofrece el uso de este tipo de acciones es que en el entorno Tasker aparecen como una sola acción, aunque "dentro" incluyan un buen número de instrucciones de JS. Esto facilita mucho la revisión de nuestro código.

Este hilo pretende agrupar las discusiones, preguntas, propuestas y soluciones que los compañeros puedan aportar relativas al uso de JS en Tasker

RECOPILATORIO DE APORTACIONES

--> Nada mejor para empezar que un enlace a un magistral post de @maid450 (http://www.htcmania.com/member.php?u=184834) en el foro que, hace pocos dias, me abrió el cielo:
[Tutorial] (http://www.htcmania.com/showthread.php?t=631165) Creación, uso y manipulación de variables con javascript (http://www.htcmania.com/showthread.php?t=631165)

--> Enlace a un post mio en el que se debatia la conveniencia de abrir un hilo específico para JS y en donde pongo un sencillo ejemplo de comparación del tiempo de ejecución entre Tasker y JS.
http://www.htcmania.com/showpost.php?p=22214425&postcount=273

--> Calcular la distancia entre dos puntos dados por coordenadas GPS (@WillyWeb)
http://www.htcmania.com/showthread.php?t=1026246

--> Formatear un entero con separación de millares (@maid450)
http://www.htcmania.com/showpost.php?p=22426692&postcount=38

--> Como lanzar una app de manera dinámica (con variable) y como obtener el nombre de las apps (@mlesir)
http://www.htcmania.com/showthread.php?t=1159277

Una muestra más de la simplicidad con que se pueden resolver algunas cosas que en Tasker resultan muy elaboradas (versión @Caravantes (http://www.htcmania.com/member.php?u=437088)) con JS (versión @danko9696 (http://www.htcmania.com/member.php?u=868681))
--> Subtarea que devuelve la fecha en formato AAAA-MM-DD (Caravantes (http://www.htcmania.com/member.php?u=437088), danko9696, maid450...) (http://www.htcmania.com/member.php?u=868681)
http://www.htcmania.com/showthread.php?t=1160655

--> Expresión regular para búsqueda dentro de una variable (@maid450)
http://www.htcmania.com/showthread.php?t=1161396

--> Cálculo de la letra del DNI
http://www.htcmania.com/showpost.php?p=25643153&postcount=26

--> Código en JS para Lightning Launcher que sirve para enviar a Tasker la página actual del escritorio
http://www.htcmania.com/showpost.php?p=25659855&postcount=27

--> Extracción de datos de un archivo JSON (resultado de bajar datos de una API) con Javascript -a partir del post #45-
http://www.htcmania.com/showthread.php?t=1289407&page=3

cace0353

29/02/16, 11:59:21

Reservado

WillyWeb

29/02/16, 12:50:08

En mi primera aportación a este hilo (y espero que no sea la última) pongo el enlace a un tema en el que he usado JavaScript para solventar una par de carencias de Tasker en lo tocante al manejo de decimales y funciones trigonométricas.

Calcular la distancia entre dos coordenadas
http://www.htcmania.com/showthread.php?t=1026246

cace0353

29/02/16, 13:27:25

En mi primera aportación a este hilo (y espero que no sea la última) pongo el enlace a un tema en el que he usado JavaScript para solventar una par de carencias de Tasker en lo tocante al manejo de decimales y funciones trigonométricas.

Gracias @WillyWeb (http://www.htcmania.com/member.php?u=68214), ya te lo leí en su dia. En el fondo tú tienes la "culpa" de que haya abierto este hilo. Estoy seguro de que tus aportes serán muy bién recibidos....

mlesir

23/03/16, 00:03:54

Bueno pues una humilde aportación a este hilo:

"Como lanzar una app de manera dinámica (con variable) y como obtener el nombre de las apps". Autolaunch quizas ya no lo necesitarás:

http://www.htcmania.com/showthread.php?t=1159277

Enviado desde mi T1-701u mediante Tapatalk

Rsc

13/12/16, 22:34:15

Buenas, estoy empezando a implementar JS en algunas tareas en las que necesitó mejorar la velocidad de ejecución, y quería compartir una que aunque es aparentemente simple, he notado una mejora considerable.

Para que os hagáis una idea, tengo una escena con cuatro elementos vinculados entre si, que resalto añadiéndole un borde, según pulse cada uno de ellos. Para conseguir esto antes utilizaba siete acciones, y ahora me lo cargo de un plumazo con este código.

setGlobal("WH_IconoBT",1- global("WH_IconoBT"));
setGlobal ("WH_leer",2);

if (global("WH_IconoBT")==1)
{
var ok = elemBorder( "WH_2 Desplegable", "Icono Bluetooth", 9, "#FFFFFFFF");
var ok = elemBorder( "WH_2 Desplegable", "Icono Sonido", 0, "#FFFFFFFF");
var ok = elemBorder( "WH_2 Desplegable", "Icono Silencio", 0, "#FFFFFFFF");
}
else
{
var ok = elemBorder( "WH_2 Desplegable", "Icono Bluetooth", 0, "#FFFFFFFF");
};

if (global("WH_IconoWifi")<1&& global("WH_IconoBT")<1)
{
var ok = elemBorder( "WH_2 Desplegable", "Icono Silencio", 9, "#FFFFFFFF");
};

Posiblemente se pueda depurar un poco, pero bueno prácticamente llevo tres días intentando aprender JS. Un saludo.

WillyWeb

13/12/16, 22:40:01

¿Y dices que has notado que mejora la velocidad de ejecución de la escena?
¿Dónde has puesto ese código? ... ¿directamente en las acciones del CLIC de un objeto?

WillyWeb

13/12/16, 22:41:02

-duplicado-

cace0353

13/12/16, 22:51:05

No entiendo muy bién (no sé los nombres de las variables que usas) pero me parece que lo que ha conseguido el compañero Rsc és reducir el listado de acciones en su tarea (o en el grupo de acciones asociadas al "clic").
Donde de verdad se nota el aumento de velocidad es en las operaciones sobre un número elevado de elementos, p.e. en los bucles For...End for, o sobre las variables de las matrices de datos.

Enviat des del meu Nexus 5 usant Tapatalk

WillyWeb

13/12/16, 22:53:13

Donde de verdad se nota el aumento de velocidad es en las operaciones sobre un número elevado de elementos, p.e. en los bucles For...End for, o sobre las variables de las matrices de datos.

En esos casos es en los que yo lo había utilizado, pero no se me había ocurrido usarlo para controlar elementos de una escena. Es muy interesante. :oh:

danko9696

14/12/16, 00:37:03

Otra ventaja muy importante es que se maneja muchísimo más comodamente que las acciones de Tasker cuando se trata de tareas largas/complejas por poder escribir y visualizar el código en PC, de modo que se puede ver más código a la vez y moverse entre él de forma más ágil, comentar extensivamente sin problema (en Tasker también se puede pero hay que ser más selectivo dado el reducido espacio de pantalla), usar ratón y teclado, copypaste más cómodo y luego copiar el texto al móvil .

El inconveniente que veo es que no se puede hacer ejecución paso a paso, que algunos errores no son mostrados como tales y que obviamente hay que tener más cuidado con la sintaxis. Pero en tareas complejas, incluso aunque el rendimiento fuese algo peor (en lugar de bastante mejor) merecería la pena, simplemente porque desarrollarlas sería una pesadilla con acciones de Tasker.

En esos casos es en los que yo lo había utilizado, pero no se me había ocurrido usarlo para controlar elementos de una escena. Es muy interesante.
Creo que lo único que no se puede es controlar plugins (confirmado en una duda con el desarrolador), pero salvo eso creo que practicamente todo lo demás.

Rsc

14/12/16, 01:50:09

¿Y dices que has notado que mejora la velocidad de ejecución de la escena?
¿Dónde has puesto ese código? ... ¿directamente en las acciones del CLIC de un objeto?

El código lo pongo en las acciones del CLIC del elemento, y bueno, quizás al no ver la escena, ni saber que valor tienen las variables, no se termina de comprender completamente lo que hace y en que mejora, así que detallaré un poco más la tarea.

Tengo cuatro iconos en una escena.

- Sonido activado.
- Sonido desactivado
- Sonido solo con Bluetooth conectado.
- Sonido solo con WiFi conectado

Lo que hago es añadir o eliminar bordes a los elementos al pulsar sobre uno de ellos, para que la escena muestre que modo de sonido tengo activado en ese momento.

Quizás también tenía que haber concertado mejor lo de "mejora considerable" , realmente utilizando las siete acciones que tenía antes, haciendo un eso normal de la escena, conseguía hacer lo mismo y no se aprecia ningún retardo desde que hago clic, hasta que se modifican los elementos, por lo menos a simple vista, PERO, si que es cierto que testeando, alternando rápido entre los iconos, si que notaba ese retardo, y frecuentemente no respondía, ya que se estaban ejecutando las acciones.

En cambio, con el código de JS puedo alternar entre los iconos todo lo rápido que quiera, y siempre responde perfectamente.

También, tengo entendido que al exportarlo como app, se reduce el tiempo de ejecución, y en estas pruebas, las acciones normales las he probando en una escena de una app, y la escena en la que utilizó JS, en un proyecto de Tasker.

En este caso solo son cuarto iconos, pero normalmente cuando muestro una escena, la suelo acompañar de muchas acciones relativas a los elementos, y espero notar más aún las mejoras.

cace0353 No entiendo muy bién (no sé los nombres de las variables que usas)

No hay quien las entienda, les pongo nombres que hacen daño a la vista, pero es la única manera de mantenerlas agrupadas :D

WillyWeb

14/12/16, 02:03:46

El código lo pongo en las acciones del CLIC del elemento, y bueno, quizás al no ver la escena, ni saber que valor tienen las variables, no se termina de comprender completamente lo que hace...

Está perfectamente claro el código JS y tus aclaraciones. Muchas gracias. :ok:

Rsc

14/12/16, 12:44:54

Buenas de nuevo. Para comprobar cuanto tiempo mejoraba exactamente la tarea al ejecutarla con el código de JS, he calculado cuantos milisegundos tardaba en completarse cada una, y me acabo de llevar un chasco tremendo.

La tarea ejecutada con JS, oscila entre los 150 y 200 ms, mientras que la tarea ejecutada con las acciones nativas de Tasker oscila entre 20 y 50 ms.

La verdad que no lo entiendo, ayer haciendo las comprobaciones que comenté, notaba que los elementos en los que utilizaba el código de JS respondían mejor y más raido.

Si que es cierto que las tareas con las que hice ayer las comprobaciones, aunque realizaba el mismo número de acciones, no eran exactamente las mismas, ya que en las que utilizaba Tasker, modificaba el color de los elementos, y en las que utilizaba JS añadía o eliminaba los bordes de los elementos.

En definitiva, comprobado el tiempo de ejecución de la misma tarea exactamente, resulta más efectivo realizarla con las acciones de Tasker, por lo menos en esta tarea concretamente.

No obstante seguiré haciendo comprobaciones, con tareas que tengas más acciones, y acciones como las que comenta cace0353 de bucles For...End etc en las que dice que se nota más la diferencia en utilizar JS. Que por cierto, cuando tengas un hueco podrías poner como utilizar bucles con JS porque no tengo ni idea.

Además, copio aquí el código de JS de mi tarea, con un par de modificaciones, por si alguien sabe si se pudiera simplificar/optimizar, porque a mi se me escapa.

setGlobal("WH_IconoBT",1- global("WH_IconoBT"));
if (global("WH_IconoBT")==1)
{
setGlobal("WH_leer",2)
var ok = elemBorder("WH_2 Desplegable","Icono Bluetooth",9,"#FFFFFFFF")
var ok = elemBorder("WH_2 Desplegable","Icono Sonido",
0,"#FFFFFFFF")
var ok = elemBorder("WH_2 Desplegable","Icono Silencio",0,"#FFFFFFFF")
}
else
{
var ok = elemBorder("WH_2 Desplegable","Icono Bluetooth",0,"#FFFFFFFF")
}
if (global("WH_IconoWifi")<1&& global("WH_IconoBT")<1)
{
setGlobal("WH_leer",0)
var ok = elemBorder("WH_2 Desplegable","Icono Silencio",9,"#FFFFFFFF")
}

Un saludo.

danko9696

14/12/16, 14:51:25

Esa diferencia, teniendo en cuenta que se trata de unas pocas lineas secuenciales, está muy bien. Es como pasar de jugar (hace años) de linea telefónica a hacerlo en red local.

Pero como te han dicho antes es en bucles y manejo de cadenas donde la diferencia se vuelve enorme. Yo he observado mejoras de hasta cien veces más rápido en tareas bastante complejas con bucles y arrays de cadenas anidados, de 160 segundos a alrededor de uno, y este uno con más cosas añadidas. Y como puse antes, con la ventaja de que resulta mucho más sencillo manejar el código y hacer cambios cuando lo puedes ver en un archivo de texto en el PC.

Aquí tienes más ejemplos, pero te pueden servir guías o tutoriales en internet sobre javascript en general, no tiene por qué estar limitado a Tasker. Y lo que aprendas también lo puedes usar luego en Lightning Launcher, que es el launcher con mayor integración con Tasker.
http://www.htcmania.com/showthread.php?p=9170995

Rsc

14/12/16, 15:30:59

Esa diferencia, teniendo en cuenta que se trata de unas pocas lineas secuenciales, está muy bien. Es como pasar de jugar (hace años) de linea telefónica a hacerlo en red local.

Creo que no te has fijado bien, y has entendido que mejora, pero poco. No es así, el problema es que se ejecuta mucho más rápido con las acciones nativas de Tasker, ahí esta el problema...

Y gracias, le iré echando un vistazo a JS, pensaba que había más diferencias al implementarlo en Tasker

danko9696

14/12/16, 19:50:50

cace0353

14/12/16, 20:22:25

Hola RSC,

No obstante seguiré haciendo comprobaciones, con tareas que tengas más acciones, y acciones como las que comenta @cace0353 de bucles For...End etc en las que dice que se nota más la diferencia en utilizar JS. Que por cierto, cuando tengas un hueco podrías poner como utilizar bucles con JS porque no tengo ni idea.

En el primer hilo del post tienes este link:

http://www.htcmania.com/showpost.php?p=22214425&postcount=273

en el que hay un ejemplo de un bucle para buscar los registros que cumplen dos condiciones simultáneamente (filtros) con una acción de JS. La ganancia en velocidad era apreciable. Pero, a medida que aumentaba el número de registros, la cosa seguia pareciéndome lenta.

Para manipular bases de datos, he encontrado que es mucho más efectivo usar Sqlite3, aunque esto implica que debes ser SuperUsuario (root). No obstante he leido por ahí que la próxima versión de Tasker incorporará Sqlite de modo nativo.

La misma aplicación del post (cuando puse el ejemplo estaba en una fase inicial) usa ahora una base de datos Sqlite con dos tablas: una de casi 3.000 registros y la otra con unos 500. Con Sqlite, con unos pocos comandos de consulta simples, la aplicación es realmente operativa y rápida. Ya casi no uso JS.

danko9696

14/12/16, 20:46:59

Hola RSC,

En el primer hilo del post tienes este link:

http://www.htcmania.com/showpost.php?p=22214425&postcount=273

en el que hay un ejemplo de un bucle para buscar los registros que cumplen dos condiciones simultáneamente (filtros) con una acción de JS. La ganancia en velocidad era apreciable. Pero, a medida que aumentaba el número de registros, la cosa seguia pareciéndome lenta.

Para manipular bases de datos, he encontrado que es mucho más efectivo usar Sqlite3, aunque esto implica que debes ser SuperUsuario (root). No obstante he leido por ahí que la próxima versión de Tasker incorporará Sqlite de modo nativo.

La misma aplicación del post (cuando puse el ejemplo estaba en una fase inicial) usa ahora una base de datos Sqlite con dos tablas: una de casi 3.000 registros y la otra con unos 500. Con Sqlite, con unos pocos comandos de consulta simples, la aplicación es realmente operativa y rápida. Ya casi no uso JS.
SQLITE sin duda es mucho mejor para bases de datos pero es que es específico para ello (aunque se puede usar también para algunas operaciones de cadenas y fecha/hora) mientras que JS se puede usar para casi todo. Y ambos se pueden usar juntos, con consultas sqlite dentro de código JS.

Rsc

14/12/16, 21:00:04

Pués sí, lo entendí al revés. Unas preguntas: ¿como has comprobado el tiempo en JS/Tasker, usando TIMEMS? ¿has repetido las pruebas en diferente orden de ejecución (primero tasker luego JS y viceversa)? ¿Sigues notando mejor respuesta en JS con las mismas acciones exactamente aunque te de peor tiempo?

El tiempo lo compruebo como bien dices con la variable %TIMEMS. En el inicio de la tarea establezco %timems a %TIMEMS y al final establezco %tiempoejecución a %TIMEMS - %timems

Una sugerencia para optimizar puede ser que a la hora de leer las variables con global, si lo vas a hacer más de una vez es mejor asignarlas a una variable local y utilizar esta, para luego al final hacer un setGlobal si es necesario.

Tenía claro que había que utilizar las variables locales en vez de la globales en la medida de lo posible, porque no ocupan espacio en memoría y eso, pero no sabía que también era recomendable usarla el menor número de veces. Pensaba que una vez creada, daba igual utilizarla mas o menos.

Por cierto, ¿estás seguro de que se ha ejecutado bien?, porque veo que faltaba algún punto y coma.

Si te fijas, en el segundo código que copie, aún hay menos "puntos y comas"

Me di cuenta que al parecer en Tasker no era necesario utilizarlos, porque la tarea funciona perfectamente. Así que al final, con la intención de mejorar la velocidad de ejecución, eliminé todos los espacios, puntos y comas y todo lo que dentro de mis pocos conocimientos, pensaba que podía requerir tiempo de lectura.

Para manipular bases de datos, he encontrado que es mucho más efectivo usar Sqlite3, aunque esto implica que debes ser SuperUsuario (root). No obstante he leido por ahí que la próxima versión de Tasker incorporará Sqlite de modo nativo.

Por lo pronto no he creado ningún proyecto que requiera la manipulación de tantos datos, no obstante si que he utilizado sqlite últimamente para manipular la DB de Whatsapp y la DB de los contactos, y sí, la nueva versión de Tasker incluye una acción SQL Query o algo así.

Tenía pensado hacer un pequeño resumen con lo que he conseguido hacer por el momento con esa nueva acción, pero quería tener claro algunos detalles que se me escapan primero. Pero vamos, te puedo adelantar que accedo a la DB de los contactos, sin necesidad de ser root a través de esta acción. Obviamente, a las bases de datos de Whatsapp etc, no se podrá acceder con esta acción sin ser root.

danko9696

14/12/16, 22:52:38

Tenía claro que había que utilizar las variables locales en vez de la globales en la medida de lo posible, porque no ocupan espacio en memoría y eso, pero no sabía que también era recomendable usarla el menor número de veces. Pensaba que una vez creada, daba igual utilizarla mas o menos.
Aparte de la memoria las variables locales se acceden más rápido, no solo en JS sino también en Tasker (o sea, la estrategia también es válida para tareas con acciones de Tasker sin JS). Además en JS es todavía más visible, ya que para acceder a las globales es necesaria una función en lugar de utilizarlas sin más.

Si te fijas, en el segundo código que copie, aún hay menos "puntos y comas"

Me di cuenta que al parecer en Tasker no era necesario utilizarlos, porque la tarea funciona perfectamente. Así que al final, con la intención de mejorar la velocidad de ejecución, eliminé todos los espacios, puntos y comas y todo lo que dentro de mis pocos conocimientos, pensaba que podía requerir tiempo de lectura.
La verdad que me sigue extrañando bastante que te funcione bien, igual es porque usas la última versión (eso me ha parecido entender), no lo sé. Fíjate en la documentación de JS de Tasker y verás como aparecen por todos lados (salvo alguna excepción como IFs). De hecho es un error muy frecuente el olvidarse algún punto y coma en scripts largos y que de error por ello.

Rsc

14/12/16, 23:32:48

La verdad que me sigue extrañando bastante que te funcione bien, igual es porque usas la última versión (eso me ha parecido entender), no lo sé. Fíjate en la documentación de JS de Tasker y verás como aparecen por todos lados (salvo alguna excepción como IFs). De hecho es un error muy frecuente el olvidarse algún punto y coma en scripts largos y que de error por ello.

Si que es extraño, tenía claro que el punto y coma era parte fundamental de la sintaxis de JS, pero me di cuenta de que no me lo detectaba como error en un par de veces que se me olvidó ponerlo y probé a quitarlos todos, y sigue funcionando igual.

Si que uso la versión beta de Tasker, la verdad que desconozco si es una opción añaddida en esta última versión.

danko9696

14/12/16, 23:43:19

Si que es extraño, tenía claro que el punto y coma era parte fundamental de la sintaxis de JS, pero me di cuenta de que no me lo detectaba como error en un par de veces que se me olvidó ponerlo y probé a quitarlos todos, y sigue funcionando igual.

Si que uso la versión beta de Tasker, la verdad que desconozco si es una opción añaddida en esta última versión.
Yo lo comprobaría bien, porque hay veces que un script no da ningún error pero la ejecución en realidad se detiene en una determinada linea aunque no haya ningún signo aparente de ello salvo el resultado (o alertas añadidas para depurar). Si tienes un script largo con muchos bucles/arrays estos son los casos más complicados de solucionar.

Rsc

15/12/16, 00:55:11

Yo lo comprobaría bien, porque hay veces que un script no da ningún error

Lo tendré en cuenta para cuando haga comprobaciones de errores, pero en este caso no cabe error, desconozco si se puede mejorar el código, pero establece las variables, y modifica el borde de los elementos de la escena de manera correcta sin usar ningún punto y coma.

BlackBlex

15/12/16, 06:54:55

Cabe recalcar que no es necesario poner ";" en JS, pero le das mas trabajo al interprete de JS; ya que tiene que poner el mismo los ";" y por ende hay mas posibilidad de que genere un error, porque mal interpreto mal el código.

Lo recomendable es que se añada ";" en cada instrucción, si es necesario.

Enviado desde mi Lenovo A7600-F mediante Tapatalk

cace0353

08/02/17, 18:51:43

Como hace dias que este hilo está dormido aporto una tarea que tenia resuelta antiguamente en Tasker puro y que permite calcular la letra del NIF a partir del nº del DNI, ahora con una sola acción JavaScriptlet:

Lletra DNI (152)
A1: Consulta de Variable [ Título:Entra el n° del DNI Variable:%num_dni Tipo de entrada:Numérico / Entero Por Defecto: Imagen de fondo: Disposición:Variable Query Cuenta atrás (segundos):40 Mostrar sobre bloqueo pantalla:Encendido ]
A2: JavaScriptlet [ Código:
var lletra_dni = ("TRWAGMYFPDXRNJZSQVHLCKE");
var residu = num_dni%23;
var lletra = lletra_dni.substr(residu,1); Librerías: Salida Automática:Encendido Cuenta atrás (segundos):45 ]
A3: Flash [ Texto:%num_dni - %lletra Largo:Apagado ] Saludos...

danko9696

10/02/17, 19:26:43

Este código no es para funcionar en Tasker sino en Lightning Launcher, pero lo pongo aquí por estar relacionado al ser Javascript y usarse en conjunción con Tasker. Sirve para enviar el número de página actual del escritorio a Tasker, aunque podrían enviarse cosas mucho más complejas, scripts enteros incluso.

Por ejemplo puede servir para que gestos ejecuten acciones de Tasker que puedan variar dependiendo de la página en que uno se encuentre. Lo que viene bastante bien si usamos apps de creación de widgets gestionadas desde Tasker.

//
//
// REFRESCA NUMPAG TASKER
//
//

var d=LL.getCurrentDesktop();
var v_numpag=Math.round(d.getPositionX()/d.getWidth());

var v_desk_tag=d.getTag("NumPag");

if (v_numpag != v_desk_tag)
{
d.setTag("NumPag",v_numpag);

var i = new TaskerIntent("task");

i.addAction(ActionCodes.SET_VARIABLE);
i.addArg("%V_DESK_NUMPAG");
i.addArg(""+v_numpag);
i.addArg(false); // math
i.addArg(false); // append
LL.sendTaskerIntent(i, true);
//alert("Actualizado V_DESK_NUMPAG: " + v_numpag);
}

//
//

Rsc

16/08/17, 15:55:18

Después de convertir casi todos mis proyectos a JS, sigo comprobando que es mucho más lento que las acciones nativas de Tasker.

En tareas de 10 acciones, hay una diferencia aproximada de 300 milisegundos.

En muchos casos, no me afecta y continuaré usando JS, por el hecho de tener mis tareas reducidas a una única acción, y poderlas revisar de un vistazo.

Pero en las tareas relativas a modificaciones de escena, que normalmente necesito una respuesta inmediata, las voy a rehacer todas con acciones de Tasker.

Lo comparto en este hilo, porque creo que es importante que quien quiera utilizarlo tenga en cuenta esta información.

Ojo, que mi uso de JS se limita a las "funciones" (entre comillas porque no sé si son funciones exactamente) que facilita Tasker, para hacer la mayoría de sus acciones.

Con esto no quiero decir que no se le pueda sacar más partido a Tasker utilizando JS, porque algunos ya habéis demostrado con varios ejemplos que no así.

Un saludo

WillyWeb

16/08/17, 16:12:27

Después de convertir casi todos mis proyectos a JS, sigo comprobando que es mucho más lento que las acciones nativas de Tasker.

En tareas de 10 acciones, hay una diferencia aproximada de 300 milisegundos.

No era difícil suponer que una aplicación que haga un uso casi exclusivo de acciones de Tasker será más eficaz haciendo uso directo de las acciones, sin intermediarios. Gracias por la confirmación. :ok:

Y ojo, antes de que nadie me salte a cuello ... no digo que JS no sea eficaz, ni bueno, ni útil. Simplemente es una herramienta más dentro de Tasker, con sus virtudes (que son varias) y sus defectos (tantos o más que virtudes).

Para programar en JS dentro de Android existen opciones mucho mejores que Tasker.

danko9696

16/08/17, 18:07:09

Pero en las tareas relativas a modificaciones de escena, que normalmente necesito una respuesta inmediata, las voy a rehacer todas con acciones de Tasker.
Tiene sentido, si las únicas acciones que utilizas de JS son instrucciones que no son nativas de JS y que deben de ser traducidas a Tasker. Aún así, como citas, si no se trata de activar/desactivar escenas o campos de estas JS creo que sigue mereciendo la pena, aunque solo sea por la comodidad de tener un código más legible.

Y ojo, antes de que nadie me salte a cuello ... no digo que JS no sea eficaz, ni bueno, ni útil. Simplemente es una herramienta más dentro de Tasker, con sus virtudes (que son varias) y sus defectos (tantos o más que virtudes).
No se si se puede llamar a esto saltar al cuello, pero salto a la palestra (y abierto al debate) xDD:
- Defectos: no permite acceso a plugins, más lento en manejar funciones no nativas de JS, como son las propias de Tasker.
- Virtudes: menos código necesario para hacer lo mismo, mucho más legible, fácil de mantener y rápido creando tareas si lo hacemos desde un PC, muchísimo más rápido al realizar operaciones intensivas con variables (particularmente arrays) locales (que son las que deberiamos usar primariamente de todos modos), acceso a multitud de funciones JS o librerías para las que no hay instrucciones nativas en Tasker y que aunque puedan realizarse con este resulta mucho más engorroso. Desde mi perspectiva JS permite crear scripts mucho más grandes y complejos de lo que resulta factible en acciones de Tasker sin que se convierta en una pesadilla.

Mi opinión puede que sea subjetiva pero veo más ventajas que inconvenientes. Eso no significa que piense que haya que utilizar siempre JS, sino que mi postura es utilizarlo por defecto y usar acciones de Tasker solo cuando no quede más remedio, como puede ser el caso de Rsc. Yo también utilizo a veces acciones de Tasker, no por tema de escenas (que apenas uso) sino porque el WAIT de JS no es nada fiable cuando son periodos de tiempo por encima de cinco segundos aproximadamente, lo que en ocasiones me obliga a intercalar acciones de Tasker con JS, o que si llamas desde dentro JS a una tarea externa de Tasker no hay forma de que el código JS espere a que finalice la Tarea de Tasker antes de continuar.

WillyWeb

16/08/17, 19:20:35

No se si se puede llamar a esto saltar al cuello, pero salto a la palestra (y abierto al debate) xD:

Lo sabía :facepalm:

:risitas:

No pretendo discutir contigo, pero creo que tu compresible pasión por JS te ha cegado un poco. ;-)

Antes de nada quiero aclarar que me gusta mucho JS. He programado muchos miles de líneas y cientos de funciones para docenas de cosas. Los ATaskREADOS usamos muchos documentos compartidos que hacen uso intensivo de Google Apps Script (https://developers.google.com/apps-script/), un JS vitaminado por Google, y eso es culpa mía al 100%. Lo digo por si alguien piensa que mi opinión puede estar condicionada por no conocer el lenguaje. Hecha esta aclaración ... creo que usar JS en Tasker es un sinsentido la mayor parte de las veces.

:silbando:

Y el JS de Tasker tiene más de dos defectos ;-) ...

Me parece evidente que la gracia de usar Tasker es tener acceso a todas sus capacidades, y muchas de ellas no están soportadas desde JS, como ya has comentado.

A diferencia de las acciones normales de Tasker, las configuraciones que se cambian desde JS como parte de la tarea de entrada de un perfil no se restauran al salir del perfil.

Sólo se puede ejecutar un script JS a la vez. Esto me parece una limitación muy importante.

El tema de las prioridades tiene un punto de complejidad adicional. Las llamadas a la mayoría de las funciones integradas de Tasker se ejecutan como tareas normales de una sola acción y, por lo tanto, pueden ser bloqueadas por otras tareas de ejecución.

El control de la interfaz de usuario es bastante engorrosa y limitada.

La lista no termina aquí, pero creo que eso ya es suficiente como para pensarse si es conveniente contar con JS en todos los casos.

Que no se confunda nadie. Creo que JS es una herramienta estupenda que puede aportar a Tasker cosas muy buenas. Una de mis primeras aportaciones a este foro fue una tarea para calcular la distancia entre dos coordenadas. Esa vez usé JS para suplir ciertas limitaciones de las funciones matemáticas de Tasker, pero ese caso particular no convierte a JS en bueno para todo.

Como ya he comentado antes, para usar JS en Android existen opciones mucho mejores.

danko9696

16/08/17, 21:20:03

Antes de nada quiero aclarar que me gusta mucho JS. He programado muchos miles de líneas y cientos de funciones para docenas de cosas. Los ATaskREADOS usamos muchos documentos compartidos que hacen uso intensivo de Google Apps Script, un JS vitaminado por Google
¿Eso permite el mismo tipo de acceso a la funcionalidad del móvil que Tasker, o es solo para docs, sheets y demás?, porque lo que a mi me interesa no es JS por sí mismo, sino que me permite no usar el engorroso interface de Tasker y en su lugar crear scripts de forma más rápida y cómoda.

A diferencia de las acciones normales de Tasker, las configuraciones que se cambian desde JS como parte de la tarea de entrada de un perfil no se restauran al salir del perfil.
Sinceramente no lo veo un problema, simplemente es tenerlo en cuenta. Tampoco se restauran acciones realizadas desde plugins o comandos shell usando interface puro de Tasker.

Sólo se puede ejecutar un script JS a la vez. Esto me parece una limitación muy importante.
Cierto, esto sí es más importante. No había caído en ello, aun así nunca me ha supuesto un problema. Y no creo que lo sea mientras no uses scripts que tarden minutos en ejecutarse. Varios scripts cuya ejecución (de cada uno) tarde menos de un segundo ejecutandose de cuando en cuando no creo que lo suponga, scripts que podrían tardar bastantes minutos en acciones de Tasker.

El tema de las prioridades tiene un punto de complejidad adicional. Las llamadas a la mayoría de las funciones integradas de Tasker se ejecutan como tareas normales de una sola acción y, por lo tanto, pueden ser bloqueadas por otras tareas de ejecución.
Quizás puede suponer un problema si tienes un montón de acciones JS intentando ejecutarse simultaneamente, pero si lo que tienes es código JS que hace lo que tiene que hacer rápidamente no termino de ver el problema.

El control de la interfaz de usuario es bastante engorrosa y limitada.
Cierto que limitada en algún caso, pero me sigue pareciendo más engorroso el interface de Tasker.

Como ya he comentado antes, para usar JS en Android existen opciones mucho mejores.
Creo que hay alguna alternativa a Tasker (Automate) que maneja mejor el tema de threads, es compatible con JS y plugins para Tasker, y no me ha hecho falta pasarme a ella. Prefiero el interface de Tasker, antes que otro que va a ser todavía más incómodo (aunque más bonito, eso sí).

En resumen, aunque algunos puntos me parecen válidos sigo sin ver por qué no usar JS por defecto y usar acciones de Tasker solo cuando sea necesario. Quizás simplemente en mi caso no se hayan dado las circunstancias en las que lo que comentas suponga una limitación real.

WillyWeb

17/08/17, 09:07:16

En resumen, aunque algunos puntos me parecen válidos sigo sin ver por qué no usar JS por defecto y usar acciones de Tasker solo cuando sea necesario. Quizás simplemente en mi caso no se hayan dado las circunstancias en las que lo que comentas suponga una limitación real.

Pues nada, si las limitaciones de JS en Tasker no son limitaciones para ti, no se hable más. :platano:

Aunque te lo repito, existen alternativas mejores si lo que realmente quieres es usar JS en Android. Por ejemplo...

DroidScript
https://play.google.com/store/apps/details?id=com.smartphoneremote.androidscriptfree

...y otras pocas de las que salen como "Similares".

Y a tu no-pregunta ... "por qué no usar JS por defecto y usar acciones de Tasker solo cuando sea necesario"

Porque estamos en un foro sobre Tasker, no sobre JS, y creo que aquí la opción por defecto deben ser las acciones de Tasker, ¿no te parece? ;-)

Por favor, no te lo tomes como un reproche. Ni mucho menos. Ya te he dicho que JS me apasiona y creo que la combinación Tasker+JS permite hacer cosas increíbles. Pero no debemos olvidar que muchas de las personas que pasan por este foro tienen pocos o nulos conocimientos de programación y les atrae lo de escribir pequeñas aplicaciones en su móvil usando un dedo. Esa "facilidad" la proporciona el sistema de perfiles/acciones de Tasker, no SQL, Bash o JavaScript. Puesto que Tasker lo permite me parece estupendo tirar de esos "recursos" cuando sea necesario, pero nada más, al menos al nivel que nos movemos aquí.

:nusenuse: espero que lo entiendas.

danko9696

17/08/17, 18:23:00

Pues nada, si las limitaciones de JS en Tasker no son limitaciones para ti, no se hable más.
Hombre, no lo he dicho de forma categórica para nada. No digo que no sean limitaciones, creo que he argumentado cada punto. Para mi es una limitación que a partir de cierto tamaño/complejidad de script un interface táctil como el de Tasker resulte muy engorroso, pero entiendo que para otros puede no ser tal limitación.

Porque estamos en un foro sobre Tasker, no sobre JS, y creo que aquí la opción por defecto deben ser las acciones de Tasker, ¿no te parece?
Es una opinión. La mía es que en una comunidad de Tasker que desee crecer (que no tiene por qué ser el caso) debe de haber sitio para todos, tanto para los interesados en scripts simples, que es lo que interesa a la gran mayoría de usuarios -y lo entiendo perfectamente, la mayoría ve Tasker como una solución a una necesidad concreta, no como una afición- como para usuarios más avanzados que buscan hacer bastante más que el típico activar wifi al llegar a casa, que están dispuestos a dedicar tiempo para ello y que llegado un punto puede que sí encuentren interesante usar cada vez más JS hasta el punto de no usar acciones de Tasker salvo cuando no quede más remedio.

Porque estamos en un foro sobre Tasker, no sobre JS, y creo que aquí la opción por defecto deben ser las acciones de Tasker, ¿no te parece?

Por favor, no te lo tomes como un reproche. Ni mucho menos. Ya te he dicho que JS me apasiona y creo que la combinación Tasker+JS permite hacer cosas increíbles. Pero no debemos olvidar que muchas de las personas que pasan por este foro tienen pocos o nulos conocimientos de programación y les atrae lo de escribir pequeñas aplicaciones en su móvil usando un dedo. Esa "facilidad" la proporciona el sistema de perfiles/acciones de Tasker, no SQL, Bash o JavaScript. Puesto que Tasker lo permite me parece estupendo tirar de esos "recursos" cuando sea necesario, pero nada más, al menos al nivel que nos movemos aquí.
Tasker es una app que está ahí y que puede usarse de varias maneras, no solo como medio principal para desarrollar scripts.

También puede ser usado como herramienta para scripts primariamente realizados con código en otros lenguajes, que usan acciones y el interface de Tasker para acceso fácil a funcionalidades y plugins. No es como si fuese necesario realizar algún hack o instalar apps externas. Incluso vienen de serie llamadas a funciones nativas disponibles en JS, con el objetivo obvio de poder sustituir gran parte de las acciones nativas con JS. O sea, aunque no esté enfocado a ello permite explícitamente usar JS como medio principal de escritura de scripts, no solo para manejar cadenas y muy poco más.
Y la diferencia con apps como la que propones (a la que echaré un vistazo) es que Tasker permite todo eso con un nivel muy bajo de JS, con acceso a gran cantidad de funcionalidad sin tener que buscar apenas documentación más allá de tutoriales básicos y alguna instrucción suelta, y de forma mucho más cómoda(aunque tenga una curva de aprendizaje por encima de la de Tasker).

Ahora bien, si resulta que como dices este foro solo debe de servir para el tipo de usuario mayoritario y que el uso de acciones de Tasker como medio secundario para escribir scripts en esta aplicación no es el adecuado aquí, entonces me había hecho una idea equivocada. Y no pasa nada, de verdad, no me lo tomo a mal.

Caravantes

17/08/17, 19:06:50

Ahora bien, si resulta que como dices este foro solo debe de servir para el tipo de usuario mayoritario y que el uso de acciones de Tasker como medio secundario para escribir scripts en esta aplicación no es el adecuado aquí, entonces me había hecho una idea equivocada. Y no pasa nada, de verdad, no me lo tomo a mal.

No comparto esa opinión.
Si este foro estuviera saturado con muchos mensajes diarios, tal vez podríamos cuestionarnos algún filtro para reducir el estrés, o dividir el foro en dos. Pero creo que no es el caso.

Tasker es un sistema de programación muy especial: muy "visual", muy poco técnico, con una curva de aprendizaje más asequible que los lenguajes habituales, incluyendo Javascript. De hecho, creo que la mayoría de usuarios de Tasker (y de este foro) no sabemos Javascript.

Pero tampoco nos molesta que aquí puedan aparecer tareas con Javascript incluido, en mayor o menor medida. Al contrario, esos mensajes pueden ser una pista y un estímulo para los foreros que quieran avanzar más y tal vez no sabían por dónde orientarse.

Del mismo modo, también podemos aceptar distintas corrientes en la forma de implementar Javascript. La escuela de Danko podría llamarse "Javascript intensive". La escuela de Willy podría llamarse "Javscript moderate". Cada una tiene sus ventajas e incluso su visión filosófica. En mi opinión, vuestro debate ha sido enriquecedor, al menos para mí. Pero no hay necesidad de proclamar un ganador, y menos un perdedor.

Resumiendo y respondiendo a la frase de Danko: yo creo que no hay motivo para tomar una decisión excluyente (ni autoexcluyente). De momento aquí hay sitio para las dos corrientes, e incluso para la tercera corriente, la de quienes usamos Tasker a pelo, "Javascript without".

Por cierto, por las sucesivas aportaciones de varios compañeros (sobre todo Danko y Willy), me he animado a aprovechar las vacaciones -entre otras cosas- estudiando Javascript; apenas estoy empezando, pero estoy animado. También entiendo que Javascript puede resultar algo excesivamente duro para otros que nunca hayan programado con un lenguaje de texto; yo sí tengo esa ventaja.

WillyWeb

17/08/17, 19:24:02

danko9696

17/08/17, 21:34:36

Resumiendo y respondiendo a la frase de Danko: yo creo que no hay motivo para tomar una decisión excluyente (ni autoexcluyente).
Vaya, no pretendía sonar a ultimatum, que creo que es lo que ha parecido XDD

Simplemente quería hacer ver que proponer usar JS desde Tasker de primeras como la solución para todo no me parece lo más acertado.
Creo que en ningún momento he propuesto usar JS a saco de primeras sino a usuarios que ya hayan dado sus pinitos con él o se lo estén planteando como mínimo, y siendo conscientes de que no podrán hacer todo con él.

PD: Prueba DroidScript. Siendo un apasionado de JS creo que te gustará.
Ya lo he instalado para echar un vistazo, pero de todos modos me parece que me malinterpretas. No soy un apasionado de JS, simplemente lo prefiero por ser un lenguaje en formato texto que en cuanto te haces a él resulta mucho más cómodo, rápido y fácil de ver que un interface para pantalla táctil de móvil, que cumple cuando se trata de cosas muy simples pero que en cuanto los programas son un poquito más largos de lo normal se hace muy engorroso en mi opinión.

Por cierto que me acabo de dar cuenta de la principal pega que para mí tiene JS, que no he caído hasta ahora y que sí me costó bastante acostumbrarme al principio, y es que JS no permite ejecutar paso a paso para encontrar errores. Y es que al principio usé JS por rendimiento puro y duro manejando bucles y cadenas, no por comodidad. Luego ya me acostumbré a meter montones de alertas flash para encontrar errores, pero en los comienzos, cometiendo errores tontos de sintaxis con frecuencia, no era tan ágil con ello. Y todavía ahora agradecería esa capacidad. Pero una vez terminada esa primera acción JS, vi que aunque no hubiese hecho falta ese rendimiento extra, de todos modos no la habría hecho en Tasker puro. Es esta la experiencia que me anima a sugerir el uso de JS a usuarios experimentados de Tasker. No porque piense que es lo mejor del mundo mundial, sino porque pienso que a partir de determinado tamaño/complejidad de script sí es mejor que acciones nativas, y que si es posible evitarlas hace las cosas más sencillas.

Dicho de otro modo, me atrae también porque con un nivel muy básico (como el mío) se pueden hacer cosas en Tasker que no habría hecho con acciones nativas por ser bastante más liosas (muchas más, necesario entrar y salir continuamente y hacer scroll todo el rato, viendo menos código a la vez), pesado de hacer y en algún caso donde el rendimiento era importante ser unas cien veces más lento (y haciendo menos) que en JS.

El control de la interfaz de usuario es bastante engorrosa y limitada.
Respondo de nuevo, ya que me doy cuenta de que igual lo malinterpreté. ¿Te refieres al manejo de escenas o de llamadas a funciones de Tasker en general?

WillyWeb

18/08/17, 09:42:57

Ya lo he instalado para echar un vistazo, pero de todos modos me parece que me malinterpretas. No soy un apasionado de JS, simplemente lo prefiero por ser un lenguaje en formato texto que en cuanto te haces a él resulta mucho más cómodo, rápido y fácil de ver que un interface para pantalla táctil de móvil, que cumple cuando se trata de cosas muy simples pero que en cuanto los programas son un poquito más largos de lo normal se hace muy engorroso en mi opinión.

En eso DroidScript tiene un punto a favor. Lo llaman "WiFi IDE" y te permite programar desde el PC directamente en el móvil.

http://droidscript.org/tutorials/my-first-app-part-1/

Por cierto que me acabo de dar cuenta de la principal pega que para mí tiene JS ... no permite ejecutar paso a paso para encontrar errores.

:rolleyes: Pues no te puedo decir si DroidScript tiene esa capacidad. Apenas llevo tres días probando cosas a ratos perdidos. Puede que buscando un poco por la red encuentres un editor online con ejecución paso-a-paso.

Respondo de nuevo, ya que me doy cuenta de que igual lo malinterpreté. ¿Te refieres al manejo de escenas o de llamadas a funciones de Tasker en general?

Me refería al manejo de escenas desde JS. En general el tema de las escenas me parece una de las asignaturas pendientes de Tasker.

danko9696

18/08/17, 12:41:37

En eso DroidScript tiene un punto a favor. Lo llaman "WiFi IDE" y te permite programar desde el PC directamente en el móvil
He trasteado un poco y buscado la posibilidad de reaccionar a eventos de sistema estilo Tasker. Iba a postear en su foro preguntando pero antes he descubierto que hay un script para que eventos de Tasker puedan lanzar scripts de DS (según hora, localización, etc...), y encima hay que compilar antes e instalar la app generada en DS para poder recibir los intents de Tasker. O sea, que no me soluciona nada porque no puede hacer lo mismo que Tasker, dado que es un feature anunciado esa capacidad.

El interface está bien pero la verdad, es mejor el de vscode, también puedo programar directamente en el móvil, y para hacer pruebas (aunque de forma local en el PC, no en el móvil) con él sí puedo ejecutar paso a paso (aunque no he instalado lo necesario todavía), y puestos a usar javascript en ese plan (exclusivamente para scripts lanzados desde Tasker, dado que no puede sustituirlo) podría haber usado JS en Lightning Launcher (que de hecho uso un poco para funciones de LL, aunque se puede usar para más cosas), que es mucho menos farragoso que tener que compilar un apk en DS e instalarlo cada vez que haga un cambio o una prueba (además que cuesta 15€ el plugin para ello o tener subscripción premium). Para eso mucho mejor uso JS en Tasker. O también podría usar Automate, que sí puede sustituir a Tasker, es compatible con sus plugins, mejor en control de threads y creo que sí permite la ejecución de varios scripts JS simultaneos, dado que permite la ejecución simultanea de varias instancias de la misma tarea.

Seguro, DS será mucho más potente para otras cosas, como crear apps independientes, pero no para lo que a mi me interesa.

Reitero que mi caso con JS no es porque sea un fan, sino porque simplemente me parece mucho más práctico y cómodo que acciones a pelo en cuanto se complica un poco el asunto, y a veces que tareas nada viables con Tasker nativo desde el punto de vista de rendimiento sí lo son con JS. Las limitaciones que has dicho antes serán reales, pero si me hubiesen afectado (con mi uso medio, no tengo scripts ejecutandose continuamente) hace tiempo que habría hecho algo al respecto como lo mencionado, fuese apoyarme más en LL o usar Automate. El cual usaría si no fuese porque su interface me gusta aún menos. Y no es que el de Tasker me parezca malo en sí mismo, es que simplemente está enfocado a móviles, y para desarrollar un script, en cuanto se complica un poco más de diez acciones creo que no tiene nada que ver hacerlo en la pantalla del móvil que en una pantalla grande de PC con teclado, ratón y viendo un montón de código a la vez.

Pues no te puedo decir si DroidScript tiene esa capacidad. Apenas llevo tres días probando cosas a ratos perdidos. Puede que buscando un poco por la red encuentres un editor online con ejecución paso-a-paso.
Ya no me importa tanto porque estoy acostumbrado, la próxima vez que vaya a hacer algo un poco largo miraré bien a ver qué hace falta para ejecutar paso a paso en VSCODE, que sé seguro que sí se puede, aunque no de serie.

Me refería al manejo de escenas desde JS. En general el tema de las escenas me parece una de las asignaturas pendientes de Tasker.
Sobre el tema de las escenas no me extendí antes porque no estaba seguro que te referías a ello, pero te comento: en mi caso no las uso casi, no hago apenas introducción de datos en Tasker con ellas y para mostrarlos uso otras apps, pero sí que las usé al principio. Primero en Tasker/Zoom (demasiado lento, y no usaba JS), luego en UCCW (bastante más rápido, por fin medianamente usable), después Zooper (igual de rápido que el anterior pero mejor soporte) y al final en KLWP (MUCHO más rápido que Zooper y mucho mejor en todo lo demás). La única limitación (aparte de no poder introducir datos con él) es que no admite listas scrollables (en su lugar uso paginación) y quizás que las animaciones son un tanto liosas de hacer para que queden bien (pero las tiene), por todo lo demás genial (consumo de batería, editor genial, rendimiento en ejecución y en el editor, soporte, ejemplos, tutoriales, etc...).

cace0353

18/08/17, 18:49:53

Desde hace un par de dias estoy asistiendo a este debate entre WillyWeb y Danko9696 como a un partido de tenis...

Desde un nivel más bajo que los dos "masters" y como autor del hilo, me permito terciar en este tema exponiendo mi modesto punto de vista personal:

Hace algo más de tres años que empecé con Tasker. Tenia una ligera experiencia en programación para uso propio con Basic, Quickbasic y Autolisp (un dialecto de LISP para Autocad).
Desde entonces he estado abordando proyectos cada vez más complicados, sobretodo gestionando bases de datos.

A dia de hoy, sin salir del entorno de Tasker y buscando la mayor eficiencia, lo hago casi todo con Tasker básico con alguna ayudita externa:

- Para gestión de bases de datos Sqlite usando la nueva acción "Consulta Sqlite" en modo RAW que funciona de una manera muy rápida, incomparable con lo que puedes hacer con las acciones básicas de Tasker.

- Para tratar conjuntos de variables (básicamente datos en matrices) uso JavaScript para montar los bucles For-Endfor ya que el proceso és mucho más rápido.

- Para asignar los valores a las variables locales al inicio de cada tarea (colores de las escenas, valores iniciales de las variables, etc.) uso JS para inicializar todas las variables en una sola acción. Esto simplifica notablemente la revisión del código.

CONCLUSIÓN. Cada uno programa para sus necesidades usando las herramientas que tiene. Cuando sus conocimientos o formación no llegan a resolver sus problemas recurre al foro para encontrar la solución: buscando la respuesta a un tema concreto usando el buscador o lanzando una pregunta en un nuevo hilo esperando que le respondan los compañeros. Esta es la finalidad de un foro cómo este.

danko9696

18/08/17, 22:05:58

A dia de hoy, sin salir del entorno de Tasker y buscando la mayor eficiencia, lo hago casi todo con Tasker básico con alguna ayudita externa:

- Para gestión de bases de datos Sqlite usando la nueva acción "Consulta Sqlite" en modo RAW que funciona de una manera muy rápida, incomparable con lo que puedes hacer con las acciones básicas de Tasker.

- Para tratar conjuntos de variables (básicamente datos en matrices) uso JavaScript para montar los bucles For-Endfor ya que el proceso és mucho más rápido.

- Para asignar los valores a las variables locales al inicio de cada tarea (colores de las escenas, valores iniciales de las variables, etc.) uso JS para inicializar todas las variables en una sola acción. Esto simplifica notablemente la revisión del código.
Es que eso es casi exactamente lo que hago. Porque piensalo bien: si usas JS para bucles FOR, operaciones con matrices y/o cadenas, y para inicializar variables, ¿qué te queda? ¿tienes mucho más aparte de eso?. Igual sí, no sé (¿operaciones de manejo de escenas quizás?), en mi caso queda lo que no puedo hacer con JS como llamadas a plugins y muy poco más. Igual soy yo el que hace las cosas de manera muy rara.

En el código que puse en el otro hilo:
https://thumb.ibb.co/c3fEwa/vscode_sugerencias_1_result.png (https://ibb.co/c3fEwa)

Si te fijas un poco en el código y también arriba a la derecha, donde hay un minimapa de todo el código, se puede ver que así por encima además de declarar variables y preparar los arrays que usaré luego, gran parte el código consiste en un gran bucle de dos niveles por lo menos, seguramente combinado con IFs y puede que algún que otro FOR más. Después ya se encuentra código debajo que podrías pensar "pues eso que tienes fuera de los FOR es lo que podrías hacer con acciones de Tasker". Pues resulta que ese código debajo del bucle principal son funciones pequeñas que a su vez consisten nada más que en declaración de variables, bucles FOR y operaciones con matrices.

Y en este script no es el caso, pero tengo algún otro bastante más pequeño que consiste en inicializar variables, preparar con FOR de uno o dos niveles una megaconsulta sqlite (de más de 100KB), justo ejecutarla fuera del FOR con un comando shell e inmediatamente recorrerla con otro FOR para modificar resultados con operaciones de cadena o regex de modo que me sean útiles.

En ambos casos todo queda en un mismo archivo que puedo ver y editar en el PC, o puedo abrir un montón de archivos en este con código escrito anteriormente, por si acaso quiero reutilizar algo y moverme rapidamente entre pestañas con atajos de teclado/ratón más copia/pega de partes del código.

cace0353

19/08/17, 09:28:44

Es que eso es casi exactamente lo que hago. Porque piensalo bien: si usas JS para bucles FOR, operaciones con matrices y/o cadenas, y para inicializar variables, ¿qué te queda? ¿tienes mucho más aparte de eso?. Igual sí, no sé (¿operaciones de manejo de escenas quizás?), en mi caso queda lo que no puedo hacer con JS como llamadas a plugins y muy poco más. Igual soy yo el que hace las cosas de manera muy rara.

Amigo danko9696, no pretendo (no me atreveria) criticar tu sistema.
Tampoco pretendia jugar el partido...

Ya he posteado en varias ocasiones que, para mí, Tasker sirve para hacer programas en plan bricolage.
Normalmente son aplicaciones concretas que uno se fabrica con las herramientas que tiene a mano (¿quién no ha clavado un clavo con unos alicates o una llave inglesa?). A medida que sus necesidades aumentan va adquiriendo nuevos utensilios para mejorar la calidad de su trabajo o simplemente hacerlo posible.

Estoy de acuerdo en que, en el fondo y visto tu enfoque, mi manera de trabajar es similar a la tuya. La diferencia está en la complejidad de las aplicaciones que tú desarrollas. Las mías són más simples y (por pereza o apalancamiento) lo hago todo desde el móvil. No obstante valoro tu aportación y pienso tenerla en cuenta cuando aborde nuevos proyectos.

Saludos cordiales!

danko9696

19/08/17, 18:13:17

Amigo @danko9696, no pretendo (no me atreveria) criticar tu sistema.
¿Por?. Si crees que he dicho algo criticable o con lo que no estás de acuerdo no veo problema en que lo hagas. Puedo perfectamente estar equivocado en mi forma de ver las cosas. Lo que busco es que si lo estoy alguién me lo haga ver.

Igual me engaño a mi mismo pero creo que no estoy cerrado en banda. He explicado qué es lo que me ha llevado a ver las cosas de esta manera y estoy abierto a cambios. Si DroidScript tuviese un sistema que permitiese detectar eventos, estilo Tasker, me pasaría a a él sin dudarlo, si las limitaciones de Tasker + JS fuesen tan importantes en la práctica usaría Automate desde hace tiempo.

La pregunta de mi comentario anterior era genuina. Aparte de inicializar variables, bucles FOR y operaciones con matrices, ¿qué mas usas?. Porque ahora mismo lo que hago es preguntarme qué hago de forma distinta, dado que (dejando de lado que no uso casi escenas) diría que el 99% de mi código es justo eso: inicializar y asignar valores a variables, FOR, IF, matrices y cadenas. Y del 1% restante gran parte son llamadas sqlite y plugins.

Normalmente son aplicaciones concretas que uno se fabrica con las herramientas que tiene a mano (¿quién no ha clavado un clavo con unos alicates o una llave inglesa?).
Sí, pero eso ocurre cuando corre prisa o simplemente no compensa el esfuerzo de buscar la herramienta adecuada para un solo clavo. Si se ha caido un cuadro por soltarse el clavo, usas un pisapapeles si hace falta para dejarlo de nuevo en su sitio. Pero si sabes que vas a clavar muchos clavos a lo largo de varios días o semanas, ¿qué es mejor, clavarlos con la llave inglesa o bajar un momento, comprar un martillo por 2€ y usarlo para ello?

Yo no recomendaría JS a alguien que desea realizar un par de tareas para solventar una necesidad concreta, la recompensa de aprender JS no va a merecer el esfuerzo que requiere para nada. En cambio puede que sí a alguien que después de hacer lo anterior se encuentre realizando scripts con cierta regularidad y lo vea como una afición a medio-largo plazo. En ese caso la comodidad y rápidez sí creo que va a compensar de sobra la curva inicial de aprendizaje. Porque tampoco se trata de dominar JS, sino tan solo lo más básico, el resto está en la documentación JS de Tasker y ocasionalmente puede que haciendo alguna búsqueda rápida en google.

Estoy de acuerdo en que, en el fondo y visto tu enfoque, mi manera de trabajar es similar a la tuya. La diferencia está en la complejidad de las aplicaciones que tú desarrollas. Las mías són más simples y (por pereza o apalancamiento) lo hago todo desde el móvil. No obstante valoro tu aportación y pienso tenerla en cuenta cuando aborde nuevos proyectos.
Creo que me sobreestimas. Por ejemplo ese script basicamente no es más que una lista enlazada en los dos sentidos (adelante, atrás y borrar). Dentro no es más que repetir el mismo proceso con otra lista enlazada y otro nivel más pero esta vez no enlazado (una matriz sin más). O sea, no es que sea muy complejo sino simplemente muy lioso, por ser tres niveles de matrices y por ser bastantes campos, porque cualquier error tonto puede resultar difícil de depurar. Pero conceptualmente creo que es menos complejo que la app de gestión de inventario que has realizado. De hecho habría sido mucho más sencillo usar sqlite, pero quería tener todo autocontenido en la medida de lo posible, usando una variable global en lugar de una BD externa. Y no me he currado un interface gráfico para la entrada de datos, por pura pereza.

Entiendo perfectamente que haya pereza en aprender JS, pero por otro lado en tu caso ya lo has usado, y para la parte más complicada de un uso básico de JS (los FOR y matrices). Yo estoy a ese mismo nivel, no más, y para cosas más complicadas que eso he necesitado ayuda (en JS con LL por ejemplo).

cace0353

20/08/17, 10:18:58

¿Por?. Si crees que he dicho algo criticable o con lo que no estás de acuerdo no veo problema en que lo hagas. Puedo perfectamente estar equivocado en mi forma de ver las cosas. Lo que busco es que si lo estoy alguién me lo haga ver.

No se trata de eso, és más simple: "cada maestrillo tiene su librillo" como dice el refrán. Cada uno programa para sus necesidades con sus conocimientos.
Creo que la programación és creación y que dos programadores distintos resuelven un mismo problema de maneras distintas con resultados equivalentes si ambos son buenos.

Este es el sentido que queria dar a mi mediación y no otro.

Me metí en el hilo porqué, a partir de cierto punto, dejaba de ser una exposición de los procedimientos que cada uno usa para programar (y sugerencias de uso de herramientas ajenas a Tasker) y se convertia en un debate sobre si era mejor hacerlo de una manera o de otra que, a mi juicio, era estéril: no podia llegar a ninguna conclusión.

Estimo mucho las aportaciones y ayuda que realizais en el foro porque, a mi particularmente, directa o indirectamente, me han permitido seguir avanzando y subiendo de nivel.

Saludos cordiales

danko9696

20/08/17, 16:44:24

No se trata de eso, és más simple: "cada maestrillo tiene su librillo" como dice el refrán. Cada uno programa para sus necesidades con sus conocimientos.
Creo que la programación és creación y que dos programadores distintos resuelven un mismo problema de maneras distintas con resultados equivalentes si ambos son buenos.
Discrepo. Dos "maestrillos" que discutan de acuerdo que pueden tener ambos razón, viendo las cosas de forma diferente. Pero también puede estar uno de ellos equivocado, o los dos. Asumir de salida que dos posturas enfrentadas son válidas creo que es erroneo. Lo correcto es ponerlas a prueba, sea con una discusión o de otra forma (que no sea un juicio por combate, claro).

Me metí en el hilo porqué, a partir de cierto punto, dejaba de ser una exposición de los procedimientos que cada uno usa para programar (y sugerencias de uso de herramientas ajenas a Tasker) y se convertia en un debate sobre si era mejor hacerlo de una manera o de otra que, a mi juicio, era estéril: no podia llegar a ninguna conclusión.
Antes de nada, una discusión sobre cual es la mejor forma de integrar JS en Tasker creo que es perfectamente apropiada en un hilo titulado Integración de Javascript en Tasker. Si no la puedes tener ahí, ¿entonces donde? XDD. Luego, discrepo en tres niveles. Ahí van tres puntos por los que creo que no es una discusión estéril:

Primero, que por supuesto sí se podría haber llegado a una conclusión. No ha sido el caso pero podría haber ocurrido. Si DroidScript tuviese un sistema de perfiles estilo Tasker, que permitiese reaccionar a eventos, usar plugins de Tasker (o funcionalidad equivalente) y lanzar scripts JS a partir de ellos entonces siendo coherente con mi postura habría tenido forzosamente que aceptar que para un uso intensivo de JS en Tasker, sustituirlo con DroidScript sería el paso lógico. No cabe otra.

Segundo, que aunque al final nadie haya sido convencido creo que el resultado de la discusión, aun cuando no se convenza al contrario, sí permite conocer mejor el otro punto de vista. Y eso es un avance, que no se llegue a una conclusión no significa que una discusión sea estéril. Puede serlo pero no tiene por qué.

Tercero, tampoco es estéril porque además puede salir a la luz información usada en argumentos que aunque resulte no ser determinante en la conclusión sí puede resultar útil. DroidScrip no me sirve pero está bien saber que existe, no para sustituir a Tasker (porque no está hecho para ello) pero potencialmente sí en el futuro para crear una app autocontenida, o para otros resultarle interesante la existencia de Automate o VSCode, y así mas cosas.

danko9696

16/09/17, 20:46:46

Vuelvo a la carga XDD

Sólo se puede ejecutar un script JS a la vez. Esto me parece una limitación muy importante.
Anteriormente he comentado que no me he ha afectado ninguna de las limitaciones que comentabas. Bueno, pues por fin he dado con una que sí me ha afectado de forma real, y creo que es justo esta. Dado que por fin me he puesto con escenas, rehaciendo algo que tenía hecho con matrices, adaptandolo para usar con sqlite y reemplazando prompts por estas, he visto que no solo js es más lento manejandolas (algo en lo que ya estabamos de acuerdo), además da problemas, creo que relacionado con el hecho de solo se puede ejecutar un script a la vez, aunque no estoy seguro del todo.

Ahora que estoy con ellas un poco en serio (con menus, sliders, spinners, ...), a la hora de cargar una escena oculta para preparar sus elementos desde js oscila entre muy lento (aunque tolerable) a directamente bloquearse y tardar un par de minutos ocasionalmente. Así que decidí preparar los datos desde js pero sin tocar ningún elemento de la escena a cargar. A partir de ahí bien, aunque dentro de la escena seguía usando js para controlar el estado de elementos de la misma escena (por ejemplo al cambiar el estado de un spinner ocultar otro elemento)... durante un tiempo. Según fue progresando el desarrollo pasó de no notarse el funcionamiento entre tasker vs js a directamente no funcionar en js, no ejecutarse scripts asociados a elementos de escena.

Así que ahora sigo, con js pero sin tocar con él ningún elemento directamente, aunque sí para preparar los datos. Y lo mismo que he comentado otras veces, no lo habría hecho de tener que haber usado acciones de Tasker para todo. La diferencia con modificar un archivo javascript situado en el móvil desde el PC es abismal, como lo es también el no tener que entrar y salir tan a menudo de Tasker (solo cuando se tocan directamente elementos de escena) o no tener tareas quizás con varios cientos de acciones de Tasker con las que pasaría un montón de tiempo meramente deslizando arriba y abajo.

También, otra cosa que he descubierto, después de ver como un scriptlet tardaba mucho más de lo que debería (un par de IFs con varios elementos a evaluar en cada uno y nada más) decidí investigar un poco y me llevé una sorpresa. Resulta que los comentarios incluidos en javascript influyen MUCHO en la velocidad de ejecución. En una acción con comentarios pasó de tardar 1200-250 ms a 200-220 sin ellos, en otra de 1000-1200 a 180-200ms y una tercera de la misma tarea y en la misma tanda de pruebas (en tandas distintas pueden observarse tendencias algo diferentes en cuanto a tiempos) pasó de 1000-1200 a 60-160. Es curioso como con comentarios las tres acciones tardaban casi lo mismo, y también parecido (aunque no tanto) sin ellos, aún contando con muy diferentes cantidades de código.
Es de remarcar que la tercera acción contaba con algo más del doble de texto en forma de comentarios que de código, pero aún así pudiendo llegar a tardar unas diez veces más, aunque haciendo varias rondas en momentos diferentes a veces la diferencia es de solo cuatro veces más (ni idea de por qué).

Así que lo que ahora hago es contar con una acción javascript vinculada a un archivo de la SD interna, de modo que el proceso de desarrollo y testeo es muy rápido, modificar algo en el editor del PC y ejecutar en el escritorio del móvil un acceso directo a la tarea en concreto que estoy desarrollando/depurando. Ni siquiera necesito entrar en Tasker durante la gran mayoría del rato (excepto cuando estoy con escenas). Así puedo tener varios archivos, cada uno en su pestaña del editor de PC, pudiendo copiar/pegar entre ambos y añadir alertas para debug de forma muy rápida. Una vez que veo que funciona todo de forma estable, que hace lo que tiene que hacer, para cada acción javascript (archivo externo) creo otra javascriptlet (el código javascript se almacena dentro de de Tasker en lugar de un archivo externo) con el contenido de la primera pero sin comentarios (en PC elimino comentarios, selecciono todo, pego en la nueva acción y deshago los cambios en el PC). Después no borro sino que deshabilito la acción javascript vinculada al archivo que manipulo desde el PC (y que sigue conservando los comentarios).

En general el tema de las escenas me parece una de las asignaturas pendientes de Tasker.
Comento de nuevo, dado que tengo reciente el bregar con ellas me ha refrescado la memoria ver lo extremadamente mejorable que es la forma de crear escenas en Tasker y el por qué me daba tanta pereza ponerme. Es muy engorroso crearlas cuando tienen más de un puñado de elementos. Y no es como lo que dije antes sobre el diseño de scripts de Tasker en general, que me parece bueno pero es engorroso por estar enfocado a móvil, lo que es comprensible. En el caso de las escenas sí hay ejemplos de otras apps sobre cómo se pueden crear de forma muchísimo mejor. Y eso sin hablar de rendimiento, que es horrendo con un puñado de elementos en pantalla cuando KLWP te maneja varios cientos (y con mucho mayores posibilidades gráficas) sin despeinarse. Pero bueno, entiendo que Tasker no está enfocado a ello como sí lo está una app para crear wallpapers animados.
Pero al menos creo que sí deberia ser más sencillo organizar elementos en pantalla, cosas de cajón como alinearlos, agruparlos de forma jerárquica, copiar y pegarlos en grupo, soporte de múltiples resoluciones, etc... Es absurdo el tiempo que puede llevar hacer cosas muy simples que en otras apps llevan nada.

WillyWeb

17/09/17, 10:37:17

Es muy curioso lo que comentas sobre lo que influyen en el tiempo de ejecución los comentarios en JS. Lo había observado en las tareas con acciones de Tasker pero nunca me había llamado la atención en los Scriptlet. Si le interesa a alguien puedo intentar hacer unas pruebas para medir hasta qué punto llega la cosa.

Y sobre las escenas, poco más puedo añadir. Espero que Pent dedique un poco de tiempo a mejorar ese aspecto de Tasker. Ahora mismo es lo peor con diferencia.

Gracias por compartir tus experiencias :cucu:

Rsc

17/09/17, 12:17:09

Y sobre las escenas, poco más puedo añadir. Espero que Pent dedique un poco de tiempo a mejorar ese aspecto de Tasker. Ahora mismo es lo peor con diferencia.

Coincido con vosotros en esta afirmación. Creo que ahora que Pent ha terminado la versión con Material Design y que la mayoría de los errores han sido solucionados, es buen momento para sugerirle que le dedique un tiempo a mejorar el desarrollo de escenas. Aprovecharé que frecuento también el foro oficial de Tasker y dejaré caer esa petición. Quien sabe, así surgió la actualización con Material Design.

cace0353

17/09/17, 12:27:56

Totalmente de acuerdo: para fabricar las escenas hay que dedicarles mucho tiempo moviendo los elementos, redimensionandolos, jugar con las gamas de colores...

Además algunos elementos que muestran los valores de las matrices (como la rueda y los menus) són particularmente laboriosos de dimensionar…

También los ajustes a distintas resoluciones, imposibilidad de desplazar escenas deslizando con el dedo, etc, etc.

Enviat des del meu Nexus 5 usant Tapatalk

Rsc

17/09/17, 13:19:22

Además algunos elementos que muestran los valores de las matrices (como la rueda y los menus) són particularmente laboriosos de dimensionar…

No se en que actualización se corrigió, pero hace poco he comprobado que el elemento menú, y cualquier otro elemento que contenga la pensaña "Disposición de Item", (que viene a ser una subescena, dentro de la escena) se adaptan a diferentes resoluciones de igual forma que los demás elementos.

El problema de adaptación a diferentes resoluciones, además de el tamaño del texto que es lo peor, es que si la resolución de la escena creada, no es proporcional con la resolución del teléfono en la cual se vaya a ejecutar, se muestra la escena con unos márgenes que hacen daño a la vista.

WillyWeb

17/09/17, 13:47:37

... Quien sabe, así surgió la actualización con Material Design.

Cierto ;-)

Una sugerencia inocente, de las muchas que se le hacen y de las que normalmente pasa por falta de tiempo o cualquier otra razón peregrina que se le ocurra, pero que esta vez decidió atender inexplicablemente. :loco:

De todo lo mejorable en las escenas (que no es poco) creo que lo de el ajuste a distintas resoluciones que comenta cace es lo peor. Se tienen que hacer auténticos malabares para que una aplicación se vea bien en dos dispositivos diferentes :malabares:

Lo mismo si se le hacen sugerencias que impliquen "pequeños" cambios ... :silbando:

danko9696

17/09/17, 20:48:32

Totalmente de acuerdo: para fabricar las escenas hay que dedicarles mucho tiempo moviendo los elementos, redimensionandolos, jugar con las gamas de colores...
Es lógico que cosas como elegir los colores y el tamaño adecuado para que queden bien lleven tiempo, pero no lo es el que lleva alinear varias etiquetas verticalmente p.e., y que encima si cambias el tamaño de la escena se desajusten de la cuadrícula en cuanto las tocas de nuevo y debas redimensionar cada una en todas las direcciones un poquito en cada dirección para ajustarlas a ella de nuevo (un poco más alta por arriba y deshacer, un poco más alta por abajo y deshacer, etc...). Tampoco es nada bueno el sistema de selección de elementos, debiendo hacerlo de entre una lista con tooodos ellos. O la forma que tiene para seleccionar que elementos quedan por encima y por debajo, que es pésima. Por eso me remito al sistema de KLWP (que es con el que más experiencia tengo) pero más vergonzante comparado con el de Droidscript, que ni siquiera posee una interfaz visual para ello pero aún así también le da mil vueltas al sistema de Tasker. En ambos, si quieres alinear cuatro elementos, los metes en un layout vertical, p.e., eliges el margen que quieres que haya entre ellos, y del layout con el borde de la pantalla y listo, no tienes que ir tocando elemento a elemento continuamente salvo para casos especiales.

El problema de adaptación a diferentes resoluciones, además de el tamaño del texto que es lo peor, es que si la resolución de la escena creada, no es proporcional con la resolución del teléfono en la cual se vaya a ejecutar, se muestra la escena con unos márgenes que hacen daño a la vista.
Tanto en KLWP como en casi todas las apps de widgets, si creas una escena para una resolución determinada, se va a ver exactamente igual en cualquier otra resolución que tenga el mismo aspect ratio. Esto no es siempre así, ya que en un caso puede haberse diseñado sin contar con un dock, por ejemplo, pero aún en este caso normalmente tampoco es necesario hacer ningún cambio. Aunque entiendo que en Tasker la situación es distinta, porque hay elementos interactivos que permiten introducción directa de texto (no debería afectar a elementos como spinners o menus, que no activan el teclado), pero por lo menos que sea más sencillo de organizar.

Cierto

Una sugerencia inocente, de las muchas que se le hacen y de las que normalmente pasa por falta de tiempo o cualquier otra razón peregrina que se le ocurra, pero que esta vez decidió atender inexplicablemente.
Es muy simple. Una de las cosas más criticadas de Tasker de siempre ha sido, aparte de la curva de aprendizaje, la apariencia visual del interfaz, que no anima mucho a potenciales usuarios ya asustados sobre la fama de Tasker en cuanto a dificultad. El material design le da un buen lavado de cara, lo hace parecer una app moderna y más amigable sin tener que simplificarlo y creo que es un acierto desde el punto de vista del marketing de Tasker.

Realmente tiene mucha más miga de lo que parece. Muchas empresas de desarrollo dedican buena parte del presupuesto del desarrollo de una app a "tonterías" como la elección de paletas de colores de calidad, no solo porque muchas veces una app entra por la vista sino también porque debe de ser funcional, garantizando buen contraste del texto para una variedad de estilos visuales. Material Design está pensado para paliar ese problema, proporcionando una base consistente para ello. El problema es que Tasker no está enfocado a producción profesional, gran parte de las ventajas de implementar MD quedan lastradas por sus carencias en otros aspectos (lo mencionado de redimensionamiento y otros) y por tanto la mayoría del beneficio queda en la UI de Tasker misma. Muy bien para que se vea en reviews y como primera toma de contacto con Tasker recién instalado, pero no tan bien para un uso típico en el que no vas a subir apps al market y MD va a perjudicar el rendimiento.

De todo lo mejorable en las escenas (que no es poco) creo que lo de el ajuste a distintas resoluciones que comenta cace es lo peor. Se tienen que hacer auténticos malabares para que una aplicación se vea bien en dos dispositivos diferentes
Depende. El tema de la resolución no te afecta si diseñas una escena que solo vas a usar tu. Pero ciertamente hace muy complicado el exportar una app para pretender venderla en el market, app que debería funcionar a la perfección, al menos en lo visual. De nuevo con el KLWP, no hay más que ver como aparte de temas (algunos muy buenos) gratuitos también hay bastantes de pago, y que se van a ver bien a la primera. Y cuando no, como lo comentado antes de estar pensados para uso sin dock / barra de estado, p.e. (o sea, modeados), bien en la práctica no afecta o sí afecta pero incluyen variables globales para hacer el ajuste de forma sencilla junto instrucciones sobre los ajustes necesarios en el launcher y/o apps adicionales. Y en esos casos se verá bien aunque haya sido diseñado para 2560x1440 y lo vayas a ver en 1280x720 o viceversa. O sea, todo se escala perfectamente y solo afecta el aspect ratio. Texto puesto para 2560x1440 (aunque no sea a pantalla completa) no lo vas a ver enorme en una pantalla 1280x720.

Para mi es más problema el tema de la organización de elementos, porque cualquier escena en la que necesites alinear varios elementos va a llevar bastante más tiempo de lo que debería sí o sí, y si deseas añadir un elemento más entonces debes ajustar todo de nuevo, elemento a elemento. Frente a ello el sistema de grupos, en el que añades un nuevo elemento y ahora ya no queda bien, pero cambias el parámetro del margen interno del layout de 200 a 140 y listo, a otra cosa. Y si quieres que todo se vea un poco más grande es cambiar un solo número.

Pues no te puedo decir si DroidScript tiene esa capacidad. Apenas llevo tres días probando cosas a ratos perdidos. Puede que buscando un poco por la red encuentres un editor online con ejecución paso-a-paso.
Por cierto que estoy también con esta app y voy a intentar hacer el script mencionado más arriba por probar, en el que los únicos eventos serían procedentes de shortcuts, aunque todavía no sé como crearlos a scripts de DS usables desde otras aplicaciones (desde el escritorio no hay problema). Ya he conseguido la interacción DS->LL (que me ha costado bastante) y solo me falta poder cambiar el wallpaper de KLWP (ya puedo enviar variables desde DS). Por lo que he visto DS y LL son muy muy parecidos, solo que LL carece de los objetos que serían necesarios para crear formularios de entrada de datos, aunque quizás sea posible con mayores conocimientos de android.

Parece que se ha ido un poco el offtopic pero bueno, por una vez creo que no pasa nada XD

danko9696

24/09/17, 17:28:41

Referente al caso de los comentarios afectando al rendimiento he descubierto algo nuevo en este sentido. Tengo un script antiguo hecho con Javascript en tres trozos (herencia de cuando no conseguía usar sqlite dentro de JS al cambiar de móvil y luego por pereza no lo volví a juntar cuando sí pude) + un comando de plugin al final. Tarda sobre 1.2-1.3 segundos.

Así que aprovechando que ya no necesito el plugin porque ahora lo puedo hacer con un intent y dejar la tarea entera con un solo archivo JS creo una versión con un solo bloque JS juntando los tres anteriores y pasa a tardar 6-7 segundos ¿?. El código es el mismo y los comentarios son los mismos (apenas hay), pero sí que toqué algo, cambié la indentación metiendo tabulaciones en bastantes sitios para que el código resultase más claro. Si quito todas las indentaciones del código (como estaba originalmente) este pasa a tardar 600 ms aprox, la mitad que exactamente el mismo código en tres trozos.

Tabién luego probé a meter montones de comentarios en el código de 600ms y aumentaba proporcionalmente según la cantidad de estos, metiendo aprox la misma cantidad de comentarios que de código pasaba a tardar 800-900ms.

Conclusión: los comentarios influyen pero parece que tienen un afecto proporcional aditivo. Las indentaciones (no se si por ser tabulaciones, espacios extra o saltos de linea) parece que tienen efecto multiplicativo, o aditivo pero parece multiplicativo porque para el interprete JS son muchas más lineas de código. También influye (aunque lo daba por hecho, solo que no sabía cuanto) el tener el mismo código en una sola acción o repartida en varias.

No es realmente un problema si lo sabes, porque puedes trabajar todo el rato con comentarios/tabulaciones a saco, y lleva diez segundos comprimir el código (hay compresores web) y meterlo en un javascriptlet aparte para usar una vez terminado todo.

danko9696

04/10/17, 18:08:50

Más, siguiendo la sugerencia de Willyweb he tratado de convertir un script que tengo en Tasker con escenas que incluyen elementos como menus y spinners a JS con Droidscript y cuya activación es mediante varios accesos directos manuales (no eventos o estados) y me he encontrado lo siguiente:

- Pasar comandos o datos Tasker <--> DS requiere usar intents, la verdad que no lo dejan muy claro en la documentación, es necesario buscar en los foros para ver la forma y aún más para poder conseguirlo sin tener que exportar a apk. Esta es la única forma de interactuar con otras apps, lo que es una pega, no con Tasker (al menos se puede con intents) pero sí con otras apps sin esa capacidad (no se pueden crear atajos a scripts desde fuera de DS). Así que solo por este motivo ya me seria suficiente para descartar DS, aunque puede no ser un problema para otros usuarios.

- El sistema de depuración está mejor que en Tasker. No permite ejecutar paso a paso pero puedes ver a la vez código y texto de debug que introduces a modo de alertas (o en adición a estas) para mostrarse estas en la ventana de debug en PC.

- Hay ciertas limitaciones en los comandos shell que me he encontrado, como que por ejemplo no pueden devolver valores en principio, tan solo ejecutarlos. Tiene un comando especializado que sí lo permite pero no funciona con sqlite.

- Tiene sqlite nativo pero no funciona de forma síncrona cuando se quieren recuperar los datos (no afecta a los INSERT). Esto puede ser una gran pega o no, dependiendo de lo que queramos hacer. Basicamente, si lo que queremos es una tarea que se ejecute de principio a fin, si hay IFs de por medio el código se complicará bastante. En cambio para una pantalla típica de introducción de datos, donde estos se pueden rellenar en cualquier orden y actualizarse menus/spinner (con sqlite o arrays) según el botón pulsado no solo no va a suponer un problema sino que será más cómodo y sencillo, porque podemos usar directamente los nombres de los campos de la consulta en lugar de manejar un array.

- Es gratis, aunque alguna función (exportar como apk) y algunos plugins tienen un precio considerable. Se puede hacer casi de todo sin pagar un duro pero alguna de las limitaciones son muy importantes. Sobre todo el que no se puede tener una app transparente sin subscripción mensual. O sea, no podemos tener un script que lo lancemos, haga algo y termine sin ver un splash gráfico con un fondo negro. Ahora bien, si queremos usarlo sobre todo para escenas a pantalla completa entonces no supone ninguna pega. Además también se podría pagar la suscripción un mes dado, ganar acceso a todos los plugins y features, y exportar las tareas/escenas a un apk que sí va a permitir apps transparentes, además de otros plugins de pago interesantes, como el de OCR, por ejeemplo. Realmente la principal pega es que dicha característica no se puede obtener con pago único (al contrario de la mayoría de otros extras de pago).

- El sistema de escenas es bastante bueno, creo que es muy superior al de Tasker (dejando de lado que no es gráfico). Más propiedades accesibles, es mucho más rápido y puedes agrupar elementos en layouts verticales/horizontales, configurar márgenes, animar estos layouts como desees, etc.. O sea, escala mucho mejor en diferentes resoluciones, ayudado también por la forma definir el tamaño de objetos, con porcentaje de pantalla en lugar de pixels. En la práctica se tarda más en crear los elementos a usar que con Tasker (lógico, siendo todo en formato texto), es en los ajustes posteriores cuando se hacen evidentes las ventajas.

- Rapidez: por lo que he visto el código es aproximadamente el doble de rápido que Tasker con JS, pero claro, eso es una vez después (o durante, no estoy seguro) del splash inicial (al no poder ser transparente sin premium). Una tarea hecha en Tasker pasó de tardar 600 ms de media (JS comprimido) a unos 320. Además dicho rendimiento no es afectado por el formato del código, no afectan ni saltos de linea ni comentarios, al contrario de Tasker. No es que sea mucho problema pudiendo comprimir el código fácilmente pero es una cosa menos a tener en cuenta.

- La documentación en general creo que es buena, aunque para algunos comandos escasea y es necesario rebuscar en foros. También curioso que en tutoriales de youtube casi todos están en italiano, no en inglés, y tampoco son muy completos, o mejor dicho, no hay ejemplos de uso avanzado apenas. Curiosamente los comandos de algunos plugins están mucho mejor documentados que los comandos básicos. El soporte de la comunidad es, diría que bastante malo (podría ser peor pero no deja de ser malo). A pesar de los esfuerzos de los autores, por mantener la aplicación como gratuita, esta es bastante pequeña, hay poco movimiento.

- La curva de dificultad es mayor que con Tasker, pero si no partimos de cero y estamos acostumbrados a JS básico entonces no es tanta. En el editor se pueden cargar de forma rápida demos y ejemplos de forma muy rápida, incluso ejecutarlos sin abandonar el script en el que estamos o hacer copia/pega de partes del código de dichos ejemplos en nuestra app. Tal como dicen los autores, el aprendizaje está basado sobre todo en la carga de ejemplos y su modificación. Ayuda el que sobre todo para cosas básicas no es apenas necesario consultar documentación, gracias al autocompletado.

- El editor dentro de la app es muy muy bueno (Tasker y otros deberían copiarlo), sin duda el mejor que he visto de largo. No solo por la ayuda que tiene específica para programar sino por la forma que tiene para mover el cursor (no hace falta poner el dedo encima de donde quieres apuntar) y creo que está disponible también como control usable en aplicaciones pagando por ello, es necesario ser premium para acceder a la documentación/ejemplos de algunos elementos de pago. Y también más cómodo para seleccionar todo, copiar y pegar.

- Posee editor fuera de la app accesible vía wifi desde en navegador de internet en el PC, es uno de los features estrella. Lo mejor es que tienes acceso a ver el debug en tiempo real y también ejemplos típicos accesibles de forma rápida sin tocar tu proyecto. Viene muy bien porque reduce bastante la necesidad de consultar la documentación, debido al autompletado, pero por otro lado para ediciones masivas no es muy conveniente (mejor salvo porque carece de soporte para las funciones nativas de DS).

Desde luego no puede sustituir a Tasker, y no pinta mal, pero algunas de las restricciones pueden ser demasiado importantes (o no) para el uso que le queramos dar, sobre todo sin premium. Más que complemento a Tasker (u otras apps) está completamente enfocado a ser usado solo. Si pudiese sustituir completamente a Tasker, ok, pagar el premium podría merecer la pena si no nos cortase alguna de sus otras limitaciones, pero como no es así no me parece nada recomendable como mero complemento, salvo casos excepcionales.

danko9696

04/10/17, 18:10:58

En la linea del comentario anterior, también he barajado ponerme con Lightning Launcher más en serio y ver si era capaz de convertir el script completamente a esta app (una pequeña parte la tengo desde hace bastante en LL):

- Pasar comandos o datos Tasker --> LL es bastante flexible. Se pueden usar intents, atajos para lanzar scripts de LL o el plugin al efecto. Y de LL--> Tasker se pueden usar intents, atajos o incluso crear tareas enteras de Tasker desde LL, gracias a comandos específicos que posee este. O sea, muy buena interacción entre ambas apps y con otras.

- El sistema de depuración en LL la verdad es que resulta malillo. Un poco mejor que el de JS en Tasker pero bastante peor que el de las acciones nativas de Tasker o el entorno de DS.

- En cuanto a comandos shell/sqlite, no tiene. Creía que sí pero puesto a ello he visto que no es el caso (salvo que alguién me demuestre lo contrario). Es el principal problema que le veo. Si no, sí que habría convertido el script entero.

- Es de pago pero sin limitaciones una vez comprado. No depende de un gran número de plugins y extras de pago. Una vez comprado, salvo quizás alguna excepción depende los recursos y conocimientos que se tengan. Y bueno, sigue siendo un gran launcher por derecho propio, aunque no lo usemos para scripts.

- Sobre las escenas por un lado está el que es un launcher muy configurable, o sea, que se pueden crear paneles, incluir iconos/texto/imágenes/widgets/... en ellos, animarlos (o alguna de sus propiedades). Todo ello con un mínimo de código (si los objetos ya están creados desde el interface gráfico), aunque algo. Esto en principio no va a servir para introducir texto, aunque sí mostrarlo (además de imágenes, texto, widgets, etc...). Y aparte se pueden diseñar escenas usando objetos nativos de android, como cuadros de texto editable, checkboxes, spinners, etc... que sí lo permiten (o sea, del estilo de los disponibles en Tasker), pero esto sí requiere bastante más código. Este segundo aspecto es muy similar al de Droidscript (el primero solo un poco). También permite usar posicionamiento absoluto (pongamos que "pixels") o relativo (porcentaje de pantalla) como en DS.

- Rapidez: no he podido testearla en buenas condiciones por la carencia de sqlite, pero presumo que será bastante más rápido que Tasker al ser JS el modo primario de funcionamiento.

- La documentación diría que es más bien mala, o mejor dicho, muy justilla. Se reduce a una referencia técnica de los objetos disponibles, unos cuantos ejemplos y ya. El resto se supone que debes tirar de documentación genérica de javacript, tanto para comandos sencillos como para cosas complejas. La comunidad es relativamente activa (ni de lejos como Tasker o KLWP, por comparar) pero también relativamente pequeña.

- La curva de dificultad es mucho mayor que con Tasker, pero esto es hablando como complemento a este, dado que es necesario (para scripts, no para usarlo como launcher) JS para todo. Como launcher tal cual también es necesario JS para cosas avanzadas pero no imprescindible para todo.

- El editor nada que destacar, no posee un auténtico entorno de programación como sí lo tiene Droidscript.

En resumen, me parece un excelente complemento a Tasker si se está dispuesto a trastear con JS, dado que por lo general siempre vamos a usar un launcher distinto del de serie, y LL no solo es extremadamente configurable sino también de largo el más ligero que conozco (de salida, luego depende de lo que hagamos con él) y potencialmente puede sustituir a parte o todos los demás widgets, tanto para escenas únicamente destinadas a mostrar datos como para otras interactivas que permitan introducir texto, siempre que no sea necesario sqlite.

Caravantes

31/03/18, 12:56:27

Noticia para los interesados en JavaScript:

Jeremy Thomas ha publicado en la web un tutorial (en inglés) titulado "JavaScript in 14 minutes (https://jgthms.com/javascript-in-14-minutes/)". Es una introducción práctica con ejercicios dirigidos que deben ir siendo ejecutados por el alumno.
https://jgthms.com/javascript-in-14-minutes/

Añado/copio el comentario de un meneante (https://www.meneame.net/story/javascript-14-minutos-jeremy-thomas-eng/c09#c-9), porque me ha parecido interesante:

<<JavaScript es con diferencia el lenguaje más divertido con el que he programado, todo está pensado para que puedas programar muy rápido y que cualquier idea loca que tengas la puedas escribir en un par de líneas, sintiéndote el dios de la programación (esto debe sonar muy nerd para los no programadores, disculpad)

El problema a su vez es que es tan flexible que deja mucho margen a las "genialidades" que con mucha probabilidad nadie que no seas tú entienda luego al revisar tu código.

Además como está pensado para programar rápido, para evitar errores javascript necesita que el programador de forma proactiva realize ciertas validaciones que en otros lenguajes como Go Lang son obligatorias de base, pero que también hace un poco más coñazo programar en ellos. Python en mi opinión es un lenguaje con un equilibrio muy bien conseguido en este aspecto.

Así que sencillamente JavaScript mola mucho y es muy ágil pero es más proclive a errores para programadores poco exigentes con su propio código.>>

Copiado de https://www.meneame.net/m/tecnolog%C3%ADa/javascript-14-minutos-jeremy-thomas-eng