Help migrating from Llama

[davi...@gmail.com]

Hi there!

TL;DR App be great. How to share state among different flows tho?

Recently found this app. As a longtime user of the Llama app (the granddaddy of automation on Android), it looks really great and I love the power and visualization behind the app.

However, there's one thing keeping me from a full switch: global variables/state seem to be missing. In Llama, I had "complex" global variables (e.g. my own state: sleeping, working, eating) which would be set by a number of conditions. And then, these global variables would influence other decisions (e.g. sound profiles, brightness, connectivity, certain app executions, etc.)

So far, I see no possibility to replicate this in Automate except creating one single GINORM0US flow which would contain too many forks to be usable.

Any help or tips on how to realize this would be greatly appreciated.

[keith.yo...@gmail.com]

Maybe you can store your variables as text files, which can be read and written from all flows?

[davi...@gmail.com]

Hm. Thanks for your suggestion!

That could work, although it might lead to a lot of overhead blocks. I also wonder whether numbered variables could be read as numbers instead of strings... I'm still new to a lot of the functionality.

When searching for similar topics, I realized there has been a lot of discussion for the concept of global variables. I get the concurrency makes it difficult, but I disagree with the dev's started view that every other automation app did it "wrong" by not implementing blocking and atomic operations in order to avoid any possible race conditions and unintended consequences. IMHO they compromise and offer power that used incorrectly can cause trouble. That is good enough for simple use cases; of course I understand that for truly powerful concurrent global memory it would be nicer to have locks, semaphores, and every other concurrent programming technique available.

As a sensible compromise, how about globally *readable* variables, which can be read from any flow, but written only in the flow where they are set (just as they are now)? This could be accomplished by an extra checkbox when atomically storing a variable to make it visible to other flows. These could then only the variable, of course getting a null result if it's not set.

If this global "state" could then also be buffered even if the flows creating the global variables aren't running, I think that would offer a lot of power without introducing (any?) problems.

Lemme know how that sounds.

P.S. Just curious: is the llamalab in Automate's package name in any way related to Llama? Or is it just a fateful coincidence?

[Henrik "The Developer" Lindqvist]

A major issue would be multiple flows, maybe downloaded from the community, unknowingly using the same name for a global variable, causing very weird and hard to find bugs.
Another issue is cleanup, who owns the variable and should remove it. Look at the Windows registry, it's not a good solution.

If you want global storage, use the file system.

LlamaLab has no affiliation with KebabApps the creators of the Llama app.