Caravantes
28/05/13, 04:08:51
Contextos de estado con demora en la tarea de entrada y/o salida.
Nota posterior (19-06-2014): Habíamos comprobado que la acción DETENER-TAREA no funciona cuando desde una tarea (entrada o salida) se intenta detener la otra tarea (salida o entrada) del mismo perfil. Más información sobre este problema en http://www.htcmania.com/showthread.php?p=12354445 . Sin embargo, hemos descubierto la forma de resolver este problema, desactivando la casilla Fuerza-Orden-Tareas en las propiedades del perfil, tal y como se detalla en este otro post http://www.htcmania.com/showthread.php?p=14151444#post14151444
El compañero Bar211 construyó un buen sistema con dos perfiles que sirve para manejar la conexión bluetooth con el coche. Utiliza un contexto de estado y lo interesante del tinglado es que la tarea "de salida" no se ejecuta de forma inmediata sino tras una demora, y siempre que en ese tiempo no se haya reactivado el contexto de conexión bluetooth. Es por ese detalle que utiliza dos perfiles comunicados mediante una variable. La ventaja es que puede alejarse del coche y/o apagar el autorradio bluetooth -por ejemplo- en la gasolinera y la tarea de salida no se ejecuta si regresa al coche y/o lo enciende (y con ello recupera la conexión BT) antes de 10 minutos. Más detalles en su propio mensaje: http://www.htcmania.com/showthread.php?p=8826125
He estado pensando en ello porque creo que ese tipo de planteamientos pueden ser interesantes para otros muchos casos en que queremos usar contextos de estado pero introduciendo demoras y post-comprobaciones similares. En este artículo trataré de analizar todas las posibilidades y consecuencias de estos sistemas. Aviso de que esto es bastante rollo, puede resultar pesado. :silbando:
Bat211 ya ha puesto un buen ejemplo de situación en la que la demora y post-comprobación se aplica a la tarea de salida. Yo voy a imaginar una demora similar en la tarea de entrada.
Supongamos que quiero un perfil que active ciertas funciones cuando estoy en casa de mis padres: preparo una tarea de entrada con acciones como bajar el volumen del ringtone, enceder el wifi para conectarme a su red, etc. Para el momento en que me marche de allí también preparo una tarea de salida que apague el wifi y vuelva a subir el volumen. Todo lo cual es fácil de hacer mediante u perfil con contexto de ubicación por red. Pero hay un problema: se da la circunstancia de que a diario voy al trabajo y el recorrido me hace pasar (en coche o bus) por delante de la puerta de su casa. La ubicación por red detecta que estoy en el lugar y activa la tarea de entrada. Circulando a 50 kms/hora, dos minutos después ya me he alejado unos 1600 metros y el contexto ya no se cumple. La solución es introducir algunas acciones que provoquen una demora en la tarea de entrada, demora que en este caso podría ser de pocos minutos, y tras esa demora se vuelve a comprobar el contexto para decidir “definitivamente” si hay que ejecutar las acciones que yo había pensado inicialmente como tarea de entrada.
Creo que estos dos ejemplos deberían ser suficientes para entender todos los matices del problema general. Voy a plantear un esquema que sirva para cualquier situación con contexto de estado y que sea aplicable siempre que se necesite una demora y post-comprobación del mismo contexto, antes de aplicar la serie de acciones que consideraríamos como "verdaderas" tareas de entrada y/o de salida. Hay diferentes formas de resolverlo.
Modelo de dos perfiles.
Es un modelo sencillo de entender. Es el modelo utilizado por Bar211 aunque yo lo voy a plantear algunos detalles de un modo muy distinto. Algunos de estos detalles han sido "copiados" del maestro Andreas Ødegård en su lección de Trucos y consejos.
http://www.htcmania.com/showthread.php?p=9315037
El primer perfil (perfil primario), al que llamaremos Alfa es el que tiene el contexto de estado “original” al que también llamaremos contexto primario. Al activarse dicho contexto ejecuta de forma inmediata su tarea de entrada que solo tiene acciones de demora y control. Y su tarea de salida es similar, con otras acciones de demora y control. Luego tenemos el perfil secundario al que llamaremos Beta. Sus tareas son las que nosotros inicialmente habíamos concebido como tareas de entrada y salida. La comunicación entre los dos perfiles la hacemos por medio de una variable que llamaré %AlfaBeta porque sirve para enlazar los dos perfiles. Esta variable puede tener los valores 1 (uno) que significa “encendido” y 0 (cero) que significa “apagado”. El contexto del perfil secundario es que la variable %AlfaBeta equivalga a 1.
Enseguida empiezo con las descripciones de las tareas. Como ejercicio, voy a establecer demora de tanto en la tarea de entrada como en la de salida. La tarea de entrada se llama ATE (Alfa-Tarea-Entrada) y la de salida se llama se llama ATS (Alfa-Tarea-Salida)
Perfil primario (o de control).
Tarea de entrada, llamada ATE: ATE- (Tarea) Detener tarea ATS (detiene la tarea de salida, por si se estuviera ejecutando).
ATE- (Tarea) Esperar, 10 minutos.
ATE- (Variable) Establecer variable %AlfaBeta a 1.
La tarea de salida es casi idéntica, como puede verse a continuación. Solo tiene pequeños cambios que voy a resaltar.
Tarea de salida, llamada ATS: ATS- (Tarea) Detener tarea ATE (detiene la tarea de entrada, por si se estuviera ejecutando).
ATS- (Tarea) Esperar, 10 minutos.
ATS- (Variable) Establecer variable %AlfaBeta a 0.
Supongo que es bastante fácil de entender. La clave está en que al cambiar el estado del perfil, la tarea correspondiente aborta (dentiene) la otra tarea, por si esa otra tarea estuviera ejecutando la acción Esperar. De esta forma tenemos la seguridad de que la variable de control solo será cambiada cuando hayan pasado 10 minutos tras un cambio del contexto primario, y además ese cambio tiene que haberse mantenido durante ese tiempo.
La variable utilizada tiene que ser una variable global (accesible desde otras tareas) y por consiguiente ha de haber alguna letra mayúscula en el nombre de esa variable.
Si se prefiere que una de las tareas (la de entrada o la de salida) funcione sin demora, bastará suprimir la acción Esperar, dejando el resto.
Ahora vamos con el segundo perfil, Beta. Ya hemos dicho que la clave de este perfil es su contexto (secundario): valor de variable (del grupo Estado, Variable). El contexto es que la variable %AlfaBeta coincida con 1.
Este perfil Beta tiene una Tarea de Entrada (BTE) en la que pondremos las acciones que habíamos previsto inicialmente como tarea de entrada. Y en su tarea de salida (BTS) pondremos lo que habíamos pensado como tarea “natural” de salida.
Como he dicho, puede haber casos en que solo se necesite una demora en la tarea de entrada, para prevenir “entradas en falso” como cuando yo voy al trabajo y paso junto a la casa de mis padres. También puede haber situaciones como la de Bat211 en la gasolinera, en que solo se requiere demora en la tarea de salida. Pero, ya que estamos puestos y hemos reconocido la necesidad de una demora quizá sea conveniente hacer una segunda reflexión para meditar si también nos conviene la otra. Se trata de ver el problema desde la perspectiva contraria.
Si ya has decidido que necesitas una demora de entrada... ¿Tiene alguna ventaja añadir una demora también en la tarea de salida? Dicho de otra forma: ¿Hay que prevenir un posible salida en falso? Piensa en lo que ocurrirá si estás en la situación del perfil secundario (activado) y entonces ocurre que deja de cumplirse el contexto primario. Puede que ese contexto primario quede desactivado por un periodo largo de tiempo, y en ese caso conviene desactivar el perfil secundario de inmediato, para que se ejecute la tarea de salida. Pero también puede que el contexto primario solo se haya dejado de cumplir durante un tiempo muy breve y enseguida vuelva a cumplirse. Tal vez sea preferible mantener el perfil secundario activado y eso se consigue añadiendo una demora en la tarea de salida.
Traducido al ejemplo de la casa de mis padres, la situación es la siguiente: Supongamos que estoy allí pasando la tarde. Ambos perfiles están activos. Entonces salgo un momento para ir a comprar pan y regreso en cinco minutos. ¿Conviene meter una demora en la tarea de salida para que el perfil secundario siga activo y no sea afectado por una interrupción breve del contexto primario?
Reflexiones similares se pueden aplicar al caso contrario, cuando en principio parece que necesitamos una demora en la tarea de salida y no en la de entrada. Puede haber ocasiones en que el contexto de estado se active por muy poco tiempo para luego quedar definitivamente desactivado. En el caso de Bat211, puede ocurrir que encienda el contacto del coche solo durante un momento (para comprobar algo o para mover el coche a otro aparcamiento cercano) y enseguida quita el contacto con lo que se pierde la conexión bluetooth. Está claro que el perfil primario se activará durante ese corto periodo, pero una demora de entrada evitará que el perfil secundario se inicie en esa situación tan breve. Habrá que valorarlo en cada caso.
Todo esto nos lleva también a otro detalle: quizá sea conveniente que haya demoras de entrada y de salida, pero con tiempos distintos. Lo cual no supone ningún problema.
Dependiendo de las acciones que vayamos a utilizar, puede ser necesario que en el perfil secundario la “verdadera” tarea de entrada se alterne con la “verdadera” tarea de salida, asegurando que una de esas tareas no se vaya a ejecutar dos veces sucesivas (lo cual podría ser un problema dependiendo de cuáles acciones tengamos ahí). Pero con el planteamiento descrito tal problema no existe, pues ese peligro queda paliado precisamente por la variable intermedia: En el perfil primario puede suceder que la tarea de entrada se complete varias veces sucesivas, pero eso no alterará el valor de la variable intermedia, y por consiguiente no afectará al perfil secundario.
Aquí podría darse por acabado el artículo, pero todavía se me ocurre una especulación intelectual: ¿Es posible hacer un control de demora con un solo perfil? Creo que sí.
Modelo de perfil único.
Por supuesto, un perfil único tendrá como único contexto el contexto de estado que antes teníamos en el perfil primario. Por no cambiar, supondremos que el perfil se llama Alfa y usaremos una variable de control llamada %AlfaAlfa. La tarea de entrada puede ser así: TE- (Tarea) Detener tarea TS (detener tarea de salida)
TE- (Tarea) Esperar, 10 minutos.
TE- Acción1 de la verdadera tarea de entrada
TE- Acción2 de la verdadera tarea de entrada
etc
Y ahora la tarea de salida, muy similar: TS- (Tarea) Detener tarea TE (detener tarea de entada)
TS- (Tarea) Esperar, 10 minutos.
TS- Acción1 de la verdadera tarea de salida
TS- Acción2 de la verdadera tarea de salida
etc
Antes expliqué que la variable de control servía como amortiguador o moderador para impedir que la verdadera tarea de entrada (o de salida) se pudiese ejecutar varias veces seguidas. En algunos casos en que tengamos necesidad de garantizar la alternancia entre las tareas de entrada y salida, también podemos incluir la variable de control en este modelo de perfil único, del siguiente modo.
La tarea de entrada con variable de control. TE- (Tarea) Detener tarea TS (detener tarea de salida)
TE- (Tarea) Esperar, 10 minutos.
TE- (Tarea) Si %AlfaBeta ~ 0
TE- - (Variable) Establecer variable %AlfaAlfa a 1.
TE- - Acción1 de la verdadera tarea de entrada
TE- - Acción2 de la verdadera tarea de entrada
TE- (Tarea) Fin Si (End if)
Tarea de salida con variable de control: TS- (Tarea) Detener tarea TE (detener tarea de entada)
TS- (Tarea) Esperar, 10 minutos.
TS- (Tarea) Si %AlfaBeta ~ 1
TS- - (Variable) Establecer variable %AlfaAlfa a 0
TS- - Acción1 de la verdadera tarea de salida
TS- - Acción2 de la verdadera tarea de salida
TS- (Tarea) Fin Si (End if)
De esta forma garantizamos que las verdaderas acciones de entrada y salida solo se ejecutan cuando haya cambiado la variable de control, y así aseguramos la alternancia de ambas tareas.
Modelo mixto.
Todavía hay un tercer modelo que podemos denominar mixto. Es un solo perfil muy similar al sistema de perfil único, cuyas tareas de entrada y salida solo incluyen sistemas de demora y control, y que luego añaden llamadas a respectivas subtareas. Estas subtareas (que podrían llamarse BetaEntrada y BetaSalida) son las que contendrían las “verdaderas” tareas de entrada y salida. Este sistema tiene la ventaja de que mantenemos en tareas separadas las acciones de control y las acciones que nos interesan, pero no precisa un segundo perfil.
Si tengo que elegir entre los sistemas analizados, creo que prefiero el primero, el de dos perfiles. Opino que es el más sencillo de entender y manejar, y además tiene ventajas adicionales: desde cualquier otra tarea de tasker... puedo consultar la variable %PACTIVE y de esa forma se puede saber si está activado el perfil primario (*Alfa*) y/o el secundario (*Beta*); y consultando la variable %TRUN puedo saber también si se está ejecutando alguna de las tareas de demora, ya sea de entrada (*ATE*) o de salida (*ATS*).
Queridos dummies, eso es todo por hoy. :cucu:
Nota posterior (19-06-2014): Habíamos comprobado que la acción DETENER-TAREA no funciona cuando desde una tarea (entrada o salida) se intenta detener la otra tarea (salida o entrada) del mismo perfil. Más información sobre este problema en http://www.htcmania.com/showthread.php?p=12354445 . Sin embargo, hemos descubierto la forma de resolver este problema, desactivando la casilla Fuerza-Orden-Tareas en las propiedades del perfil, tal y como se detalla en este otro post http://www.htcmania.com/showthread.php?p=14151444#post14151444
El compañero Bar211 construyó un buen sistema con dos perfiles que sirve para manejar la conexión bluetooth con el coche. Utiliza un contexto de estado y lo interesante del tinglado es que la tarea "de salida" no se ejecuta de forma inmediata sino tras una demora, y siempre que en ese tiempo no se haya reactivado el contexto de conexión bluetooth. Es por ese detalle que utiliza dos perfiles comunicados mediante una variable. La ventaja es que puede alejarse del coche y/o apagar el autorradio bluetooth -por ejemplo- en la gasolinera y la tarea de salida no se ejecuta si regresa al coche y/o lo enciende (y con ello recupera la conexión BT) antes de 10 minutos. Más detalles en su propio mensaje: http://www.htcmania.com/showthread.php?p=8826125
He estado pensando en ello porque creo que ese tipo de planteamientos pueden ser interesantes para otros muchos casos en que queremos usar contextos de estado pero introduciendo demoras y post-comprobaciones similares. En este artículo trataré de analizar todas las posibilidades y consecuencias de estos sistemas. Aviso de que esto es bastante rollo, puede resultar pesado. :silbando:
Bat211 ya ha puesto un buen ejemplo de situación en la que la demora y post-comprobación se aplica a la tarea de salida. Yo voy a imaginar una demora similar en la tarea de entrada.
Supongamos que quiero un perfil que active ciertas funciones cuando estoy en casa de mis padres: preparo una tarea de entrada con acciones como bajar el volumen del ringtone, enceder el wifi para conectarme a su red, etc. Para el momento en que me marche de allí también preparo una tarea de salida que apague el wifi y vuelva a subir el volumen. Todo lo cual es fácil de hacer mediante u perfil con contexto de ubicación por red. Pero hay un problema: se da la circunstancia de que a diario voy al trabajo y el recorrido me hace pasar (en coche o bus) por delante de la puerta de su casa. La ubicación por red detecta que estoy en el lugar y activa la tarea de entrada. Circulando a 50 kms/hora, dos minutos después ya me he alejado unos 1600 metros y el contexto ya no se cumple. La solución es introducir algunas acciones que provoquen una demora en la tarea de entrada, demora que en este caso podría ser de pocos minutos, y tras esa demora se vuelve a comprobar el contexto para decidir “definitivamente” si hay que ejecutar las acciones que yo había pensado inicialmente como tarea de entrada.
Creo que estos dos ejemplos deberían ser suficientes para entender todos los matices del problema general. Voy a plantear un esquema que sirva para cualquier situación con contexto de estado y que sea aplicable siempre que se necesite una demora y post-comprobación del mismo contexto, antes de aplicar la serie de acciones que consideraríamos como "verdaderas" tareas de entrada y/o de salida. Hay diferentes formas de resolverlo.
Modelo de dos perfiles.
Es un modelo sencillo de entender. Es el modelo utilizado por Bar211 aunque yo lo voy a plantear algunos detalles de un modo muy distinto. Algunos de estos detalles han sido "copiados" del maestro Andreas Ødegård en su lección de Trucos y consejos.
http://www.htcmania.com/showthread.php?p=9315037
El primer perfil (perfil primario), al que llamaremos Alfa es el que tiene el contexto de estado “original” al que también llamaremos contexto primario. Al activarse dicho contexto ejecuta de forma inmediata su tarea de entrada que solo tiene acciones de demora y control. Y su tarea de salida es similar, con otras acciones de demora y control. Luego tenemos el perfil secundario al que llamaremos Beta. Sus tareas son las que nosotros inicialmente habíamos concebido como tareas de entrada y salida. La comunicación entre los dos perfiles la hacemos por medio de una variable que llamaré %AlfaBeta porque sirve para enlazar los dos perfiles. Esta variable puede tener los valores 1 (uno) que significa “encendido” y 0 (cero) que significa “apagado”. El contexto del perfil secundario es que la variable %AlfaBeta equivalga a 1.
Enseguida empiezo con las descripciones de las tareas. Como ejercicio, voy a establecer demora de tanto en la tarea de entrada como en la de salida. La tarea de entrada se llama ATE (Alfa-Tarea-Entrada) y la de salida se llama se llama ATS (Alfa-Tarea-Salida)
Perfil primario (o de control).
Tarea de entrada, llamada ATE: ATE- (Tarea) Detener tarea ATS (detiene la tarea de salida, por si se estuviera ejecutando).
ATE- (Tarea) Esperar, 10 minutos.
ATE- (Variable) Establecer variable %AlfaBeta a 1.
La tarea de salida es casi idéntica, como puede verse a continuación. Solo tiene pequeños cambios que voy a resaltar.
Tarea de salida, llamada ATS: ATS- (Tarea) Detener tarea ATE (detiene la tarea de entrada, por si se estuviera ejecutando).
ATS- (Tarea) Esperar, 10 minutos.
ATS- (Variable) Establecer variable %AlfaBeta a 0.
Supongo que es bastante fácil de entender. La clave está en que al cambiar el estado del perfil, la tarea correspondiente aborta (dentiene) la otra tarea, por si esa otra tarea estuviera ejecutando la acción Esperar. De esta forma tenemos la seguridad de que la variable de control solo será cambiada cuando hayan pasado 10 minutos tras un cambio del contexto primario, y además ese cambio tiene que haberse mantenido durante ese tiempo.
La variable utilizada tiene que ser una variable global (accesible desde otras tareas) y por consiguiente ha de haber alguna letra mayúscula en el nombre de esa variable.
Si se prefiere que una de las tareas (la de entrada o la de salida) funcione sin demora, bastará suprimir la acción Esperar, dejando el resto.
Ahora vamos con el segundo perfil, Beta. Ya hemos dicho que la clave de este perfil es su contexto (secundario): valor de variable (del grupo Estado, Variable). El contexto es que la variable %AlfaBeta coincida con 1.
Este perfil Beta tiene una Tarea de Entrada (BTE) en la que pondremos las acciones que habíamos previsto inicialmente como tarea de entrada. Y en su tarea de salida (BTS) pondremos lo que habíamos pensado como tarea “natural” de salida.
Como he dicho, puede haber casos en que solo se necesite una demora en la tarea de entrada, para prevenir “entradas en falso” como cuando yo voy al trabajo y paso junto a la casa de mis padres. También puede haber situaciones como la de Bat211 en la gasolinera, en que solo se requiere demora en la tarea de salida. Pero, ya que estamos puestos y hemos reconocido la necesidad de una demora quizá sea conveniente hacer una segunda reflexión para meditar si también nos conviene la otra. Se trata de ver el problema desde la perspectiva contraria.
Si ya has decidido que necesitas una demora de entrada... ¿Tiene alguna ventaja añadir una demora también en la tarea de salida? Dicho de otra forma: ¿Hay que prevenir un posible salida en falso? Piensa en lo que ocurrirá si estás en la situación del perfil secundario (activado) y entonces ocurre que deja de cumplirse el contexto primario. Puede que ese contexto primario quede desactivado por un periodo largo de tiempo, y en ese caso conviene desactivar el perfil secundario de inmediato, para que se ejecute la tarea de salida. Pero también puede que el contexto primario solo se haya dejado de cumplir durante un tiempo muy breve y enseguida vuelva a cumplirse. Tal vez sea preferible mantener el perfil secundario activado y eso se consigue añadiendo una demora en la tarea de salida.
Traducido al ejemplo de la casa de mis padres, la situación es la siguiente: Supongamos que estoy allí pasando la tarde. Ambos perfiles están activos. Entonces salgo un momento para ir a comprar pan y regreso en cinco minutos. ¿Conviene meter una demora en la tarea de salida para que el perfil secundario siga activo y no sea afectado por una interrupción breve del contexto primario?
Reflexiones similares se pueden aplicar al caso contrario, cuando en principio parece que necesitamos una demora en la tarea de salida y no en la de entrada. Puede haber ocasiones en que el contexto de estado se active por muy poco tiempo para luego quedar definitivamente desactivado. En el caso de Bat211, puede ocurrir que encienda el contacto del coche solo durante un momento (para comprobar algo o para mover el coche a otro aparcamiento cercano) y enseguida quita el contacto con lo que se pierde la conexión bluetooth. Está claro que el perfil primario se activará durante ese corto periodo, pero una demora de entrada evitará que el perfil secundario se inicie en esa situación tan breve. Habrá que valorarlo en cada caso.
Todo esto nos lleva también a otro detalle: quizá sea conveniente que haya demoras de entrada y de salida, pero con tiempos distintos. Lo cual no supone ningún problema.
Dependiendo de las acciones que vayamos a utilizar, puede ser necesario que en el perfil secundario la “verdadera” tarea de entrada se alterne con la “verdadera” tarea de salida, asegurando que una de esas tareas no se vaya a ejecutar dos veces sucesivas (lo cual podría ser un problema dependiendo de cuáles acciones tengamos ahí). Pero con el planteamiento descrito tal problema no existe, pues ese peligro queda paliado precisamente por la variable intermedia: En el perfil primario puede suceder que la tarea de entrada se complete varias veces sucesivas, pero eso no alterará el valor de la variable intermedia, y por consiguiente no afectará al perfil secundario.
Aquí podría darse por acabado el artículo, pero todavía se me ocurre una especulación intelectual: ¿Es posible hacer un control de demora con un solo perfil? Creo que sí.
Modelo de perfil único.
Por supuesto, un perfil único tendrá como único contexto el contexto de estado que antes teníamos en el perfil primario. Por no cambiar, supondremos que el perfil se llama Alfa y usaremos una variable de control llamada %AlfaAlfa. La tarea de entrada puede ser así: TE- (Tarea) Detener tarea TS (detener tarea de salida)
TE- (Tarea) Esperar, 10 minutos.
TE- Acción1 de la verdadera tarea de entrada
TE- Acción2 de la verdadera tarea de entrada
etc
Y ahora la tarea de salida, muy similar: TS- (Tarea) Detener tarea TE (detener tarea de entada)
TS- (Tarea) Esperar, 10 minutos.
TS- Acción1 de la verdadera tarea de salida
TS- Acción2 de la verdadera tarea de salida
etc
Antes expliqué que la variable de control servía como amortiguador o moderador para impedir que la verdadera tarea de entrada (o de salida) se pudiese ejecutar varias veces seguidas. En algunos casos en que tengamos necesidad de garantizar la alternancia entre las tareas de entrada y salida, también podemos incluir la variable de control en este modelo de perfil único, del siguiente modo.
La tarea de entrada con variable de control. TE- (Tarea) Detener tarea TS (detener tarea de salida)
TE- (Tarea) Esperar, 10 minutos.
TE- (Tarea) Si %AlfaBeta ~ 0
TE- - (Variable) Establecer variable %AlfaAlfa a 1.
TE- - Acción1 de la verdadera tarea de entrada
TE- - Acción2 de la verdadera tarea de entrada
TE- (Tarea) Fin Si (End if)
Tarea de salida con variable de control: TS- (Tarea) Detener tarea TE (detener tarea de entada)
TS- (Tarea) Esperar, 10 minutos.
TS- (Tarea) Si %AlfaBeta ~ 1
TS- - (Variable) Establecer variable %AlfaAlfa a 0
TS- - Acción1 de la verdadera tarea de salida
TS- - Acción2 de la verdadera tarea de salida
TS- (Tarea) Fin Si (End if)
De esta forma garantizamos que las verdaderas acciones de entrada y salida solo se ejecutan cuando haya cambiado la variable de control, y así aseguramos la alternancia de ambas tareas.
Modelo mixto.
Todavía hay un tercer modelo que podemos denominar mixto. Es un solo perfil muy similar al sistema de perfil único, cuyas tareas de entrada y salida solo incluyen sistemas de demora y control, y que luego añaden llamadas a respectivas subtareas. Estas subtareas (que podrían llamarse BetaEntrada y BetaSalida) son las que contendrían las “verdaderas” tareas de entrada y salida. Este sistema tiene la ventaja de que mantenemos en tareas separadas las acciones de control y las acciones que nos interesan, pero no precisa un segundo perfil.
Si tengo que elegir entre los sistemas analizados, creo que prefiero el primero, el de dos perfiles. Opino que es el más sencillo de entender y manejar, y además tiene ventajas adicionales: desde cualquier otra tarea de tasker... puedo consultar la variable %PACTIVE y de esa forma se puede saber si está activado el perfil primario (*Alfa*) y/o el secundario (*Beta*); y consultando la variable %TRUN puedo saber también si se está ejecutando alguna de las tareas de demora, ya sea de entrada (*ATE*) o de salida (*ATS*).
Queridos dummies, eso es todo por hoy. :cucu: