Make an output log fragment

[OlivierHokke]

When we want to see the output log of all activities in our app, perhaps it would be cool to add a fragment/tab that allows us to see this within the app itself. Provides the user feedback on what happens behind the scene, can be helpful for support, provides trust in our app because users can see what it is doing.

[alexwalterbos]

We would have to dumb this down significantly. This may not be a debug tool, front end should be kept separate from debug output. Therefore I think it should be in the gist of the lines we have in Toasts atm

[OlivierHokke]

Exactly my thought. I didn't mean it as a full debug-fest. Just things like "Read file index successfully", "5 unlocked files found", "encryping blabla.jpg", "finished encrypting", etc. would be nice if errors are shown too, but with a label. For instance the camel case based abbreviation of the class where it was thrown + a number. Say e.g. in the EncryptionPreferences: EnPr.5? Although it might not be necessary to label them if the string is unique.

But like when adding a file you now see a toast "added file successfully", but in the log it could also show "Deleted original file successfully" along with "added file successfully"

However in BuildConfig.DEBUG mode, it could show debug logs. I can fix that with the Utils class. Perhaps I should move all output log utilities in the Utils class to their own class, say LogUtils (I'd prefer shorter, like "Output" or "OUtils" or "LUtils")

[jzvandenoever]

That's what the adb logcat is for though. And you can do all sorts of search and filtering in there. So why would we need that? I mean it would lead to something like try ... catch Exception e stuff which I kind of really dislike.

And then there's the question of how useful it is compared to how much time it takes. Since we still have many things to implement.

[OlivierHokke]

Well it's a matter of a few lines (for debug mode) if the log fragment is there to show the regular user some extra feedback. But indeed, logcat is much more useful, totally agree with you there.

[alexwalterbos]

It's not that time-consuming to make, but I think it clutters the simplicity of the app and it's more of a developer's tool.

[OlivierHokke]

It is not meant to be, I didn't mean it to be. It is just a feedback & trust thing. Providing users of knowledge of what it is doing, the information available at any time, being able to see what the app did. I thought it should be something like I said in #91:

Output log is not per se necessary, but it could give extra information to the user as to what is happening. For instance if the user added a file, we don't want to bloat him with messages in the bottom bar, but we just say "File added successfuly". However in the output page it could show extras next to "File added successfuly", such as "Removed original file from device successfully", to give the user more feedback on what we do and to create a little more trust. It is just an idea, but I think it would be interesting. Obviously, since it isn't a very important "feature" it wouldn't be shown as one, it would be at the bottom of the drawer, perhaps under the version number line and less visible, say half opacity.

[alexwalterbos]

yeah, like I said there I was thinking of logcat output with a filter, which is not what we want.

[alexwalterbos]

I still think debug output is not necessary. @OlivierHokke @jzvandenoever @AlexKolpa please respond, or close this in two days (on April 17).

[jzvandenoever]

My opinion is still that this isn't needed. And just provides clutter that might confuse most users. I mean if the users need this feedback then we aren't doing our job in other areas of the app.

[OlivierHokke]

I don't agree. I still think the log would provide trust. It's that little extra bit of openness that could catch some users. Just like open-source is considered to be more trustworthy because you can look into the things that are actually happening. You might not check it, but the fact that you could is already satisfying.

So It will just show a bit more detail on what the app does behind the scenes. If you want to be sure of some things you can check it for confirmation etc. It could also provide a little bit of statistics perhaps. Like a log (in a subtab or something) on when the app was opened and each time a wrong password was entered (so you know if someone entered it without your knowledge).

[alexwalterbos]

But the user won't be going into another fragment or tab to look at the log.. Trust will come from direct feedback on actions, not from a list of log messages in a separate tab.