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

[danko9696]

 Cita: Originalmente Escrito por cace0353

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:


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]

 Cita: Originalmente Escrito por danko9696

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]

 Cita: Originalmente Escrito por cace0353

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.

 Cita: Originalmente Escrito por cace0353

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.

 Cita: Originalmente Escrito por cace0353

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]

 Cita: Originalmente Escrito por danko9696

¿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]

 Cita: Originalmente Escrito por cace0353

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).

 Cita: Originalmente Escrito por cace0353

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]

Vuelvo a la carga XDD

 Cita: Originalmente Escrito por WillyWeb

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).

 Cita: Originalmente Escrito por WillyWeb

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]

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

[Rsc]

 Cita: Originalmente Escrito por WillyWeb

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]

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]

 Cita: Originalmente Escrito por cace0353

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]

 Cita: Originalmente Escrito por Rsc

... 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.

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

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

[danko9696]

 Cita: Originalmente Escrito por cace0353

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.

 Cita: Originalmente Escrito por Rsc

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.

 Cita: Originalmente Escrito por WillyWeb

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.

 Cita: Originalmente Escrito por WillyWeb

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.

 Cita: Originalmente Escrito por WillyWeb

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]

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]

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]

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]

Noticia para los interesados en JavaScript:

Jeremy Thomas ha publicado en la web un tutorial (en inglés) titulado "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, 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%C...emy-thomas-eng