Skip to content
This repository has been archived by the owner on Mar 16, 2021. It is now read-only.

Feature: Add a LoggingInterceptor #80

Closed
wants to merge 10 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Apr 6, 2017

Adds a LoggingInterceptor which implements the BindViewInterceptor-Interface and can be used to monitor the method calls on a bound view.

This Class was originally implemented by @passsy and I made only a few changes:
instead of accessing the build config to determine if the logging should be enabled this is now controlled via the flag mEnableLogging which is set via the classes constructor.

…terface and can be used to monitor the method calls on a bound view.
@ghost ghost added the Ready for Review label Apr 6, 2017
@ghost ghost requested a review from passsy April 6, 2017 09:02

private final boolean mEnableLogging;

public LoggingInterceptor(final boolean enableLogging) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add constructor documentation with code sample.

// MyActivity extends TiActivity
public MyActivity() {
    addBindViewInterceptor(new LoggingInterceptor(BuildConfig.DEBUG));
}

return wrappedView;
}

private static String parseParams(Object[] a, int maxLenOfParam) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks pretty testable 😉

@passsy
Copy link
Contributor

passsy commented Apr 6, 2017

Should we put it in a separate module like okhttp-logging-interceptor? Does anyone has a option on this?

@StefMa
Copy link
Contributor

StefMa commented Apr 6, 2017

Yes, I've already thought about it.
It don't want such a Interceptor in the ThirtyInch codebase directly...
A separate module would be great... But.. I don't know if that is to much overhead for that single class. I don't know if they worth it :)

Pascal Welsch added 2 commits April 12, 2017 22:21
@passsy
Copy link
Contributor

passsy commented Apr 12, 2017

I added an updated version with improved logging I found in a stale branch. And added some tests :)

Copy link
Contributor

@StefMa StefMa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommend to add a test with a custom object...

And as I said already. Please lets move it to another module 👍

import static org.mockito.Mockito.never;
import static org.mockito.Mockito.verify;

public class LoggingInterceptorTest {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add @RunWith()

}

@Test
public void cropLongParams() throws Exception {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't we agree that all tests should start with testXXX? 🤔

return wrappedView;
}

private static String parseParams(Object[] methodParams, int maxLenOfParam) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be part of the MethodLoggingInvocationHandler.

}
}

private static final String TAG = MethodLoggingInvocationHandler.class.getSimpleName();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The TAG is wrong here.
Has to be LoggingInterceptor.class.getSimpleName()

throws Throwable {

try {
mLogger.log(Log.VERBOSE, TAG, toString(method, args));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This TAG is part of the LoggingInterceptor class...Is that expected? 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, the InvocationHandler is just a implementation detail. You add a LoggingInterceptor and you expect this interceptor to log something.


StringBuilder b = new StringBuilder();
for (int i = 0; ; i++) {
final Object arg = methodParams[i];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

arg is more a param

for (int i = 0; ; i++) {
final Object arg = methodParams[i];

final String param;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is more a paramAsString

int iMax = methodParams.length - 1;

StringBuilder b = new StringBuilder();
for (int i = 0; ; i++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need that infinite loop really?
Can't we use the condition i != iMax here?

We return then b.toString() after the loop and remove the last three characters?!
It sounds for me for a cleaner solution

@@ -99,6 +125,10 @@ public static void i(final String tag, final String msg) {
* </code>
*/
public static void setLogger(@Nullable final Logger logger) {
if (logger == TI_LOG) {
throw new IllegalArgumentException(
"Recursion warning: You can't use TI_LOG as Logger for TiLog");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we can't do it. Why do we have it then? 🤔
Can be removed? 🌮

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a implementation of this interface which can be used everywhere except for this location which would result in recursion.
I really like that the LoggingInterceptor logs to TiLog by default using the TiLog.TI_LOG.

public static Logger TI_LOG = new Logger() {
@Override
public void log(final int level, final String tag, final String msg) {
TiLog.log(level, tag, msg);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recomment to remove the "self login".
Instead i would add a System.out.print(level, tag, msg) (or smth)

@StefMa
Copy link
Contributor

StefMa commented Apr 25, 2017

Because it have some conflicts I've rebased it in #85 and changed a variable.
See #85 for now

@StefMa StefMa closed this Apr 25, 2017
@passsy passsy deleted the feature/add_logging_interceptor branch April 25, 2017 15:30
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

Successfully merging this pull request may close these issues.

2 participants