There is currently no built-in action to get the foreground app name and package. The %WIN variable is inaccurate and often empty, making it unsuitable.
I know this can be done with AutoInput, but a native action for this would be very useful, especially in kid apps.
This would be really helpful.... Thanks
@ Stefan,
It would seem you would be able to achieve this if the App context would allow the use of a variable for the app package name. Not sure how difficult that would be for João to implement but it would certainly be a very useful action and not require any more monitoring.
That sounds perfect...
Thanks, Rich...
What existing action do you mean?
There is already a 'Test app' action. However I guess it might not fit in that category as you are really testing the system or display or... ¯\_(ツ)_/¯.. I guess I really not know what your actually testing :/ . Any way I do like the way your auto apps give us all those local variables. If you add this to one of Pents existing actions we might need to run the action a few times to get the required information as they only return one value...
Yeah, ideally that action should simply return all available data with no option.
I think I should just create a separate "Test Current App" action which would result all details for the current app :) What do you think?
Nice.. do you think you will add it to the existing action or will you make a new one similar to your auto app where we get all those cool local variables?
What existing action do you mean?
I see that point - but you can't use the Test App functionality in a context. :/ We would need another event for app focus change to create our own global variable. That's hard to understand for new users.
Maybe it would be possible to give new built-in variables a prefix like BUILTIN_ or TASKERVAR_ or put all of them including the existing ones in an array we could access e.g. with %TASKERVAR(ACTIVEAPP) or %TASKERVAR(WIN) as the new way to access %WIN.
Existing old global variables could be replaced with the new notations when reading configuration files or importing them.
I don't think less advanced users need to use an App variable in a context. More advanced users that do can simply update it every time %WIN changes :)
In my experience %WIN unfortunately does update more often than the app context. E.g. closing a folder in Nova Launcher will change %WIN. On the other hand %WIN does only Update if the App Check method is set to Accessibility. So this does not work if it is set to App Usage Stats.
Tested with this simple profile:
Profile: Variable Set %WIN (652) Event: Variable Set [ Variable:%WIN Value:* User Variables Only:Off ] Enter: Anon (653) A1: Flash [ Text:%WIN Long:Off ]
@ stefan-
I must be missing something. Could you give a use case where you would use this new global variable in a profile context where the existing 'App' context would not work.
@Rich: Yes, I've got e.g. a button in Tasker's notification to increase the display timeout. But I want this button to just increase the display timeout for the current app. Therefore it would be easiest to remember the current app and compare the new variable in a context if it's still the app which was active when the timeout was increased.
Actually if it's not the remembered app an overlay scene will appear allowing to adjust the timeout again or reset the timeout to its normal value.
With a built-in variable the Implementation would be more flexible because the variable could also be used in contexts.
Unfortunately I really don't want to add new global variables because they could clash with existing user variables. You can always create that new global variable yourself.
Maybe a "Test App" action that would return the package name, app name, app version, etc?
This has been asked for many times in the past and would be extremely useful...
