NFD » NFD-android

Oh, this part should be straight forward. If I remember correctly the log filter is Native. Let me look into this and update.

Alex Afanasyev wrote:

Design and implement component to display nfd and nrd log output (these will have special prefix, but I need to be refreshed on how log output can be filtered in this component).

This first require a skets of UI and specifics on how android logs can be filtered.

Yes. This is what I wanted. UI-wise, this should be a separate activity with ability to select specific verbosity level and (may be) specify additional filters.

(Duplicate of the gerrit comment.) I haven't noticed originally that you were referring to logcat command line tool. Are you sure Android does not provide API to access log events without resorting to running process and redirecting output. I have reservations against running any command-line tool from inside the app.

Can you give some references for use of logcat in applications?

Hi Alex,

Here are some app store apps that uses logcat through Processes:

These are the apps that use the logcat in their applications:
https://github.com/nolanlawson/Catlog
https://github.com/thomashultgren/android-request-log

Other apps on the app store:
https://play.google.com/store/apps/details?id=org.jtb.alogcat
https://play.google.com/store/apps/details?id=jp.gr.java_conf.score.LogCat

Here's some documentations from the Android developer site for your convenience and kind perusal:
1) The Log Class: http://developer.android.com/reference/android/util/Log.html
2) The Intent and use of the Log Class: http://developer.android.com/tools/debugging/debugging-log.html
"Log is a logging class that you can utilize in your code to print out messages to the LogCat." This is the Log class that we commonly use for logging within apps and services.

Do let me know if I should provide you with further information or clarify some stuff.

Alex Afanasyev wrote:

Can you give some references for use of logcat in applications?

Yep, agreed. Seems like it's how the framework is structured. Sure thing, I'll get cracking!

Alex Afanasyev wrote:

Ok. Let's use logcat. I consider it is not ideal, as there should be some more meaningful way to do the same job directly in Java, but everybody seem to be using logcat... Let's not waste more time on looking for other ways.

Duplicate of gerrit comment:

As a skeleton, http://gerrit.named-data.net/#/c/1761/4 is ok. However, to merge, the implementation needs to have a correct UI implementation, as I mentioned in note-5:

• separate activity
• when activity starts, logging is enabled, when user exists/, logging stops
• log level selection (with recording of previous state in some configs)
• (optional) name-based filtering (with recording of previous state).

Roger that. I'll work on this right after I get the service running with the toggle button in the http://redmine.named-data.net/issues/2431

Thanks!

Alex Afanasyev wrote:

Duplicate of gerrit comment:

As a skeleton, http://gerrit.named-data.net/#/c/1761/4 is ok. However, to merge, the implementation needs to have a correct UI implementation, as I mentioned in note-5:

• separate activity
• when activity starts, logging is enabled, when user exists/, logging stops
• log level selection (with recording of previous state in some configs)
• (optional) name-based filtering (with recording of previous state).

This is an update entry based on the discussion with Alex located at: http://gerrit.named-data.net/#/c/1761/

These are the items that have to be worked on next for this Task:

• TextView is unable to hold an unlimited amount of text. Hence, a mechanism to limit the available logs should be design and implemented. This will be posted in the next Gerrit patch.
• Update UI to make use of the Menu Options: 'Settings' menu item.
• Logging should mute/silence all other outputs except from NFDService and relevant tags that are associated with NFDService.
• Color scheme of the console and logging should be redesigned and vetted. The current implementation of blue just looks weird.

Quick question about log output formatting: how is it defined? Is it logcat's options? In particular, one may want to see times for operations. In which place this should be implemented?

The formatting is defined through options to logcat. They can be one of the following:

• brief
• process
• tag
• thread
• raw
• time
• threadtime
• long

One way we could do it is to use the 'time' option, which is what is seen in Android Studio and Eclipse. This is a common option even when debugging from the terminal as well.

We could either implement it as a user selected preference in the next task or hard code it as a default. Let me know which you'd prefer :)

Just hard-code time for now and add a comment in the code how other things can be coded.

Roger that!

I've made the changes as requested in your comments and pushed them in patch 11: http://gerrit.named-data.net/#/c/1761/11

I'll also re-think the tags extraction as I now have a better idea of what you're getting at through your comments.

Thanks!

After looking into the code base of the PreferenceFragment and the automated way in which preferences are saved through the shared preference context, I think we should finalize how we'd want to dynamically add the tags (e.g. from a file) before we build the tags on the fly in the logger activity.

The shared context that PreferenceFragment uses makes it difficult to retrieve keys that are relevant only to the logging activity. It would be good if we say, have a file that lists all the tags we want to monitor, then dynamically load it as preferences for the user to choose the log level. Subsequently, with this file, we are able to retrieve the relevant keys from the shared preference easily.

One way I see about it is to setup a new issue that settles that. Let me know how you'd like to proceed.Thanks!

The tag list is easily obtainable from nfd. The only small missing piece is jni wrapper for that.

The ideal log config model for me is the following:

• there is only one hard-coded element: default log level
• user can add component from the list (obtained through jni call)
• for the added component, he can setlog level
• user can remove component, effectively making default log level for that component

I understand that this could include non-nfd related components in the log if the default level is too verbose. But I think that is not a not a big deal and wouldnt affect manh people.

I think it's clearer to me what you're getting at right now. Looks like we'll have to make some changes to the UI to facilitate the adding of these "new" tags that have been elicited from the jni call.

One way I see about it is to close this task, merge #1761 (http://gerrit.named-data.net/#/c/1761/) and create a new task that works on creating the UI for the user to dynamically add these tags that are taken from the jni call. These selected tags will then appear in the current log level setting activity that we have, which allows for granular selection of individual log levels.

Let me know how you'd like to proceed from here :)