Secure Setting Logger

[vertigo]

I did add one other thing you may want to add to your as well. I made a new, final list entry "Clear Log/Delete Variable" that uses removeVariable("global_secure_setting"), just to allow for some housekeeping so that long string of info doesn't appear in the context of other flows, cluttering up their logs.

[anuraag]

@desmanto check this app.
Content Provider Helper (Discover, view and query data of content providers) - https://f-droid.org/app/de.k3b.android. ... iderhelper

It already contains 2 out of 3 settings.

[Desmanto]

@vertigo : I don't want to remove the glovar. But to reset it to newList() is good enough so it won't take up glovar size. I added "Clean Log" to initialize the glovar to newlist (so first time execute can use this) and "Start Logging (Clean)" from yours, which also clear the glovar, but start logging afterward. I revamp some of the method to use csv style instead of json. This way, the saved setting can be exported to excel for easier view (compared to json).

The flow is approximately 95% finished. Almost forgot to add disabling auto brightness. I thought of creating additional option to start without disabling auto brightness. Default is to disable, but give option to keep it enabled. Then the stop also the same, default is to re-enable auto brightness and give option to keep it disabled. Afterward, it is the testing phase.

@anuraag : Thanks for the app. Turns out I already ever install it in the past. But got no use, so uninstalled it. I get the provider using dumpsys, but this app can even query directly, which is better.

[vertigo]

Is there a programming reason for clearing it instead of removing it? I'm curious why you'd do that, wondering if it's more efficient, though I can't imagine it would be enough to make a difference.

[Desmanto]

Because we are still using the glovar, so better reserve the space for it, even it is empty space. And because it is list type (or map), it will cause problem. Try to delete the glovar manually, then try to start logging with my original flow (not the clear logging one), or choose Show Last log. You will get error at the first log or when you choose show last log. Because the variable has been removed and the script expect it to be there. Even it is a string/number type glovar, if you use the reference to it in the beginning of the flow, you will get null.

But with blank newList(), the glovar reference is still there, so even though blank, it won't be error. It just show empty list. While I know you can add script to check if it is null, then create the glovar, I usually avoid this. As that line is one time use, render it useless afterward.

[vertigo]

But with the change I made (if (global_secure_setting == null) {global_secure_setting = newList()}) at the very beginning of the flow, it prevents those errors in addition to removing the need for the user to manually create it before initially running the flow. So if you remove it, it'll just be recreated as needed, but in the meantime won't be there unnecessarily between uses of the flow. BTW, I'm not trying to argue the point, just trying to understand your reasoning, to learn and because in my flows I remove the variables after, otherwise each time a flow runs the context in the log can get really long.

[Desmanto]

Oh, I am just giving the reason for my script styling. In the end it still depends on your preferred style. I prefer not to remove it while we still using it. I use glovar map/list too to store some state for my many flows. I can't just remove the variable as it will destroy link to many flows. So I keep the same method for everything else. When trying to concept new flow, I can check the glovar is there or not, so I won't overlap the usage.

For glovar cluttering the log, I agree it is too many. I ever post request to simplify the log and hide the glovar context, so easier to spot the execution log. I rarely use the log, mostly debug dialog to troubleshoot. But still at times, i still need to check the log. My glovar is too many already, removing some of them still clutter the log, hence I don't see benefit of removing 1 or 2 of them. I have been trying to move them to txt file if they can be done that way.

[vertigo]

Makes sense, thanks for the explanation. I think having them in the log can be useful, but it does make it harder to see what's going on. Coloring in the log would be really helpful, especially the trigger, as thats's what I often look for and picking it out of all the text could be easier. At least it's toward the end of the line, though, so that helps.

[Desmanto]

You might want to see my other thread for the log. viewtopic.php?f=4&t=7484
Post there to add your thoughts. It also bump the thread to be more visible.