Automagic Forum

I see no need in having two separate triggers for this, especially since the package name list doesn't seem to support variables (meaning that if you wanted to include the same apps in both started/ended triggers to for example, enable and disable the effects of a flow, you would have to edit both of them every time you to modify the list of apps).
This change will make it similar to how the Location trigger works, where you can choose whether you want to trigger the flow only when entering or exiting (or both) the location specified. This will both reduce the amount of triggers needed and make it more convenient to use in general.

This can be good addition. I imagine there are 2 additional checkbox, one is Started and the other is Ended. When we check both, then the trigger works for both app started and ended, provide a new variable {app_state} which contain "started" or "ended" to separate the trigger. We can then use expression to check on this to separate the trigger based on the app state.

However this seems not likely to be invented in the current trigger. If it is implemented, Martin might create a new trigger with the new name App Task Started/Ended (yeah, seem redundant). Because if he just change current existing one by adding the check box, it will messed up with so many user's existing flow. And this is not good. Unless he can put a giant red warning to inform all User to pay attention specifically on all the flows which utilize the trigger. At mine, I use App Task Started for 9 cases and App Task Ended for 8. And yes, at one point I even think to create another flow-ception just to change both trigger at once. (By exporting the flow, using regex to replace the value of the trigger and import it back.) But since I don't change the app often, I spare my time doing another flow.

Desmanto wrote: ↑

02 Jun 2019 16:15

This can be good addition. I imagine there are 2 additional checkbox, one is Started and the other is Ended. When we check both, then the trigger works for both app started and ended, provide a new variable {app_state} which contain "started" or "ended" to separate the trigger. We can then use expression to check on this

Code: Select all

app_state == "started"

to separate the trigger based on the app state.

My thoughts exactly except for the variable part! That should definitely be included as well... but if it were to be, I think that an additional check box for if you want to have separate package name lists for each should be added too (though this does seem a bit unnecessary when you can just add another trigger of the same type).

Desmanto wrote: ↑

02 Jun 2019 16:15

However this seems not likely to be invented in the current trigger. If it is implemented, Martin might create a new trigger with the new name App Task Started/Ended (yeah, seem redundant). Because if he just change current existing one by adding the check box, it will messed up with so many user's existing flow. And this is not good. Unless he can put a giant red warning to inform all User to pay attention specifically on all the flows which utilize the trigger.

I thought it would be a similar case for when he adds a stand-alone condition for checking the trigger of the flow, but even after the addition, the Expression condition method many people use currently would still function normally. This has already happened once with the SMS Received trigger, however, so he could do something similar by showing a notification whenever the trigger is used to notify the users that the individual App Task Started/Ended triggers are now deprecated before proceeding to remove the trigger completely within the next one or two update(s).

Desmanto wrote: ↑

02 Jun 2019 16:15

And yes, at one point I even think to create another flow-ception just to change both trigger at once. (By exporting the flow, using regex to replace the value of the trigger and import it back.) But since I don't change the app often, I spare my time doing another flow.

That sounds quite interesting. I've never thought of using ReGrex for something like that.
If I'm understanding you correctly, do you first export the flows you want to modify the trigger of using the Export Flows/Widgets action first and then match the package name list in the XML files using ReGrex?

A notif at the trigger is good. Just need extra warning for at the changelog, that the trigger has been changed. As many of us probably create a flow, tested that it is working fine and forget it for the rest of the time; until it stop working... A good technology/automation should be like this, set and forget; makes us forget that we are enjoying it


Yes, Regex can be used for that. I duplicated 4 widget elements to 400 using the same method. I just remembered I have created the flowception, but for UI Event. I have a logger flow which consist of 9 event type of UI Event. UI Event also only allow one event type per trigger, require you to change the package name 9 times if you need to change all of them. So I create another flowception, init package name, choose the app using input dialog. Then after confirm, it will export the UI event logger flow, init the xml, use regex to replace all the packagename, write it back to xml, reimport and replace current flow. It happen so fast, that all 9 UI event trigger name will be replaced at once, with a single input dialog box OK

Speaking of UI Event, then there will be additional request then to provide the same checkbox for all the 9 event type for UI Event. Same treatment, need warning first that the trigger has been changed.

This would be so great! I really missed this feature since I switched from Tasker