Add multiple actions to move files action

[Desmanto]

Yes, you can define them just like any line of below, and it still works. (use only one of them in real expression)

Code: Select all

(if(var == null) var = "Hello") == "World";
(var = if(var == null) "Hello") == "World";
(var = convertNull(var, "Hello")) == "World";

XML is used to stored flows and widget config. Check /storage/emulated/0/Automagic/ folder, the flows.xml and widgets.xml there are the mirror from the /data/data/ch.gridvision.ppam.androidautomagic/files/. So the same problem happen in the shared flow.xml happens also in the main flows.xml. And it is worse, as this flows.xml is the combination of all the flows you have, hence accumulate all the additional space. That's why being more efficient in each flow will at least help in overall perfomance.

You can copy flows.xml to somewhere else and open the xml to see the same blank field. I used exported flow as example, as it is much much shorter.


If you want to protect each branch, where 1 choice is to continue the flow and the other is doing nothing, you should use parallel expression. For splitting trigger, it is recommended to use multiple parallel expression as shown here : viewtopic.php?f=3&t=6985
(It is explanation for FEP and AES, but have screenshot for how to split trigger). Input dialog with single choice also should use this method, as shown in my secure setting logger flow. Of course, this is my flow style, not a fixed guideline. It is up to you to use the method, or modify to suit your own style.

Expression normally branches to 2, true or false. You can add another one by using the exception branch (force error occured). But I usually use the parallel expression above. To stop/branch the flow when particular condition is met, see : viewtopic.php?f=4&t=7639


For Move files, if using list works, then there must some difference in the path defined when using map. Need to see the example of the error. It maybe related to the index problem you mention.

In List, each value is single value
index 0 >>> value1
index 1 >>> value2
index 2 >>> value3


While in map, each pair is a combination of key-value. Where "key" must be single value, and the "value" can be single value or other list/map (nested). You can see map just like dictionary. Where the "key" is the word you search for, and "value" is the translation. (that's why it always comes in pair, word-translation).
key1, value1,
key2, value2,
key3, value3.

When we use getMapKeys(), we create a newList() from the keys, which contain newList("key1", "key2", "key3"). Hence when index is incremented, it increment in this new created list. To get the corresponded value1, we access the map back using map["key1"], which will give value1
index 0 >>> key1 | map["key1"] >>> value1
index 1 >>> key2 | map["key2"] >>> value2
index 2 >>> key3 | map["key3"] >>> value3

That's why for the map style, one of the source/target has longer script, as one is using the index, the other is using the map key. It also explain why we only increment by one, since getMapKeys() only retreive the key.

[vertigo]

I found the problem. There was a space at the end of the target field in the move block ( "{src_dst[source[index]]} " ), apparently added automatically when I pasted it in there. I'm kinda surprised there isn't a warning like there is when some other fields end in a space.

You said you found you prefer list over map. Why? Is it faster, or do you just find it easier to set up? I can certainly see it being easier to use when there's just a few entries, but when there's a lot mapping is definitely easier to keep track of things.

For the condition, I got it to work the way I wanted with the following:

Code: Select all

if (trigger == "Manual")
{
   return true
}

if (startsWith(trigger,"App Task Started"))
{
   1/0
}

where a true branch goes to one block and an exception branch goes to another, and there is no false branch. Once I got that to work, I figured I'd try to modify it to use a false branch instead of the exception branch, since that just seems more normal and proper, and have an exception just dead-end at the condition block, using this:

Code: Select all

if (trigger == "Manual")
{
   return true
}

if (startsWith(trigger,"App Task Started"))
{
   return false
}
else
{
   1/0
}

but I get "Error: Could not evaluate expression..." I'm not sure if the startsWith(trigger...) line is incorrect ( I also tried "if (startsWith(trigger,"App Task Started") == true)" ) or if using it this way necessitates the use of an exception line.

[Desmanto]

There are sometimes no warning as path can contains space.

I prefer list over map only for that particular flow (secure setting logger). Mainly because I want to export it as comma delimited text (csv style). Map can be converted to comma delimited too, but when converting back, it takes more script lines than converting it to nested list. For other, such as Favourite Element flow (which I plan to share at the same time), I use Map-list, as it works better. So it depends on the need.


If you are already into the force error branch, then you should always add another element after the expression, and change the connection to exception. viewtopic.php?f=5&t=7314#p20955
The element can be anything, even blank one also can be used. I usually just use Notification on Screen, as it also give additional message too and doesn't interfere with other operation.

BTW, if your if() is single line, you don't need curly braces (unless you prefer it)

Code: Select all

if (trigger == "Manual")
   return true;

if (startsWith(trigger,"App Task Started"))
   return false
else
   1/0;

or even shorter, but less readable

Code: Select all

if (trigger == "Manual")  return true;

if (startsWith(trigger,"App Task Started"))  return false else 1/0;

[vertigo]

There are sometimes no warning as path can contains space.

True, but not at the end.

BTW, if your if() is single line, you don't need curly braces (unless you prefer it)...

Cool. I was actually wondering about that, since usually if I'm doing a single action for an if statement I'll put it on the same line. Thanks.

If you are already into the force error branch, then you should always add another element after the expression, and change the connection to exception. viewtopic.php?f=5&t=7314#p20955
The element can be anything, even blank one also can be used. I usually just use Notification on Screen, as it also give additional message too and doesn't interfere with other operation.

Here's what I'm trying to do:

automagic flow.png (123.89 KiB) Viewed 33397 times

So it checks if the battery level is >20% and if it's not, checks if plugged in. If both <=20% and not plugged in, if triggered manually, ask whether to proceed*, otherwise if triggered by an event I want to trigger part of the flow but not the whole thing, continue on to execute just that part (continue on to the landscape check). And if battery <=20% and not plugged in and not triggered by that trigger or manually, I want it to just stop. I realize I can do this by just adding another, separate condition, but I'm trying to do it with just the one (top-right) both due to lack of space (I'd have to shift a bunch of stuff, which would be fine, but I'd rather not) and just because I want to see if I can. And I can make it work, if I do the true branch from the top-right condition to the input dialog and an exception branch to the landscape check and forcing an exception with

Code: Select all

if (trigger == "Manual")
{
   return true
}

if (startsWith(trigger,"App Task Started"))
{
   1/0
}

but not by using a false branch going to the landscape check and using

Code: Select all

if (trigger == "Manual")
{
   return true
}

if (startsWith(trigger,"App Task Started"))
{
   return false
}
else
{
   1/0
}

I guess if an exception occurs but there's no exception line leading somewhere, it just errors, which I suppose makes sense, I just wasn't expecting it, and the error didn't really make sense. I ended up just dropping an exception line into a neighboring condition (bottom-right) that would result in the flow dead-ending there, so problem solved. Which means the flow is very close to done. The last thing I need to do is figure out the issue I'm having with getting errors when moving files, which I think I've figured out, and I'm going to post in that thread later.

[Desmanto]

If all state must be checked as AND condition, then your flow is correct already. All exceptions must be caught, or it will stop the flow with error. Yes, you can lead the exception to an element that is dead end, or condition that most likely false.

BTW, what is the input dialog choices there? If you have only 2 choices, just use condition Confirmation Dialog. It always result in yes no (true/false), save you another expression to check the result.

[vertigo]

Interesting. Didn't know about that one. I wasn't really loving the layout necessitated by having to use those blocks, so being able to reduce that to just one helped with that. Unfortunately, it also removed what I was using to dump the exception into, so I had to make some other minor changes to deal with that. Thanks for the pointer.