Quick Tasker tip: Don’t think of complexity in human terms when creating Tasker creations
Over the weekend I created a database app for items in the video game Defiance using Tasker. Even though I knew how to do everything I needed it to, it still took my several hours just to set everything up, which basically means that the internal parts of it are very complex, with multiple tasks that each have dozens of actions to accomplish everything. When creating something like that, there’s one thing I constantly catch myself doing, and that is to think of complexity in human terms. That can often lead you down the wrong path.
Many of my most advanced Tasker creations have tasks with dozens of actions. Others use multiple profiles, multiple tasks, or multiple scenes to accomplish what they do. It all serves a purpose, and that purpose is often increased end user performance, even though it comes at the cost of a more complex back-end. My todo list app, for instance, is currently in something like the fifth iteration since I first created it, and it’s now so much faster at the cost of having a back end that I’ve given up on writing articles about as it’s just too all over the place.
The reason why this works is that it’s not always the solution with the least steps that’s the fastest one. I see a lot of Tasker users almost panic when told to use multiple profiles/tasks/etc for something they initially wanted to use just one for, and it all comes back to thinking in human terms. Two is twice as messy as one, and 40 actions is harder to grasp than 4, and as such, must be slower…right? For us, maybe, but Tasker isn’t human, and it can often go through 500 actions quicker than just a couple of performance-lowering ones.
I’ve talked about some of the things that can slow down Tasker in the past. One of the biggest culprits is global variables, especially when you get into using arrays, which are just heaps of global variables. These need to be updated throughout Tasker instead of just locally, and as such, slow down your final creation to the point of ridiculousness. The way around that is to constantly switch between using local arrays and global variables for storage, which results in often a lot more actions, but way better performance. That’s exactly what I did in the video game database app I made this weekend, and it actually runs through hundreds of actions in the video you see below:
Every time it flashes “done”, it’s done running through a refresh task that’s 35 actions on its own, about 10 of which are part of a For loop that runs for every item in it. Yet, because I use local arrays for everything but populating the menu and storing data (which is done using global variables), it’s as fast as anyone could ask of it. It annoys me how complicated the tasks for this looks, because I’m human, but for Tasker it’s just a matter of doing a lot of very simply things, which it can do very fast.
Another example is with advanced scene creation. I’ve talked about how it’s faster to stack scenes on top of one another than to try to manipulate the visibility of individual elements, and that’s also shown in the video. The process of adding something to the database actually consists of one initial task that launches a custom scene, where tapping anything runs a second task that pops up the last two dialog boxes using the Menu action rather than dedicated scenes. The long list in the first dialog is all a single global variable, which is how it can populate it so quickly.
The point here is to emphasize that Tasker isn’t a human being. It doesn’t panic when it sees a hundred actions, as long as those actions in themselves are fast. That obviously doesn’t mean that more actions are always better, it just means that sometimes, less is definitely not more. So, next time you find yourself thinking that you’ve over-complicated something, ask yourself if it’s not just your human sense of order that’s giving you bad advice.
