DemoPad.com

My objective is to send a command to a device when my DemoPad resumes from sleep or multitasking. The command is sent depending on a flag that is set previously. That flag is set in custom actions associated with the number variable "Current_hour"

Attached file "Capture-1" shows the "Awake" actions
Attached file "Capture-2" shows the custom actions for the number variable "Current_hour"
Attached file "Capture-3" shows the action if the value of Current_hour is between 21 and 23. I tested this at 22:00
Bottom line is: that command to device does not trigger during the awake process. If I remove the condition on the command to device action, the command gets sent. So that would point to the flag not being set correctly, but I use the same logic of custom actions successfully on a page load, the only difference being that the page load actions repeat every 60 seconds.

Any ideas DemoPad support, anyone?

Try a short delay before sending the command - because the delay is 0, when the flag is checked before sending the command, the app may not have run through the previous custom actions to set the flag yet.

Thanks, I'll try that.

I had expected each action to be serially executed and completed before the next one is processed (aside from delayed actions).

Your post seems to suggest that each action is a realtime execution thread on its own. Does IOS multitasking support this ? Or, I wouldn't be surprised, did you guys develop your own multithreading scheme ?

Each action is executed asynchronously yes...

DemoPad wrote:Each action is executed asynchronously yes...

This is an architectural approach that is rather rare in the programming world.

I never insert delays on actions, except when I send successive command devices, but that was more to ensure the end device wouldn't get flooded.

If I get this right, theoretically, I would need to insert delays on every action, especially if one action depends on the result of a previous one.

I find this concept difficult to accept. I can understand that actions with delays would be processed asynchronously, but I don't understand the benefit of processing no delay actions asynchronously. I'm not challenging your design, just trying to understand.

As well, as I found out, determining what delays to insert is not straight forward. In my example, I did several tests only to find out that I needed a whopping 2.0 second delay for it to consistently work. I'm stuck on the idea something else is going on here.

Are there any guidelines as to what delays are required for certain actions?

In practice, actions with the same delay occur in the order they are listed in the editor. I suspect the issue here has to do with your 2nd to last command, which sends a command to a device - the iPad, having woken up, will need to re-establish its socket connection, halting the operation of actions which were not already in the queue (like the number custom action). Try giving that command a 1 second delay, and try a 0.1 second delay after the number change to see if that rectifies the issue. If not, please send in your .pad to support & they will have a look.

DemoPad wrote:In practice, actions with the same delay occur in the order they are listed in the editor. I suspect the issue here has to do with your 2nd to last command, which sends a command to a device - the iPad, having woken up, will need to re-establish its socket connection, halting the operation of actions which were not already in the queue (like the number custom action). Try giving that command a 1 second delay, and try a 0.1 second delay after the number change to see if that rectifies the issue. If not, please send in your .pad to support & they will have a look.

Thank you for the precisions.

I followed your advice on the delays. But I found a new twist to the issue.

First a definition. I test the Wakeup/resume actions by forcing the application to lose focus, by pressing the Home button. I then click on the application icon to give it focus again.

After forcing the application to lose focus, if I invoke the application again within approximately 2 seconds, then the expected actions do occur. If I wait more than 2-3 seconds, the actions don't seem to execute. This is repeatable. This is regardless of what delay I put on the commands to devices (last 2 actions); I tried 1 and 2 seconds. I've also put a 0.1 delay on setting the number Current_hour.

I'm more than willing to send in my project, but I'll wait and see if this last twist triggers any further advice.

cv27 wrote:... After forcing the application to lose focus, if I invoke the application again within approximately 2 seconds, then the expected actions do occur. If I wait more than 2-3 seconds, the actions don't seem to execute. This is repeatable. This is regardless of what delay I put on the commands to devices (last 2 actions); I tried 1 and 2 seconds. I've also put a 0.1 delay on setting the number Current_hour ...

DemoPad, any thoughts?

We've been trying to replicate this issue, without success - whether we re-open the app after 1 second, or 10 minutes, the resume actions we have set up execute correctly, in order. I think it best if you send in your project file to [email protected] & we will attempt to duplicate with your project.

Ok - we have found the issue. The problem is that at some point we introduced a bug in the app which caused the wakeup actions to be executed not when the app resumed, but just before it closed. Those actions would then continue to execute, in order, upon resuming - which would be fine, except for when you have delays in the actions - as the time to execute would have been calculated when the app closed down, so when it resumed they would all execute at the same time (the order they are listed in the action editor) - which introduced the problem of a flag being set because of a custom number action needing more time to execute...

Fixed for the next release of the app. In the mean time, a good way round it would be to have the resume action just set a number (called Macro or something) to a value, say 1 - and in the custom actions for that number falling within the range 1-1 - execute the actions in order, with delays etc

Thanks again for the prompt support.