gridstone / debugdrawer Goto Github PK

Hey thanks for release but I got this error. Is there smth wrong on release?
ERROR: Failed to resolve: au.com.gridstone.debugdrawer:debugdrawer-okhttp-logger:0.9.7

Hey, thanks for this awesome library!

Btw, we ran into the situation where we want to add a feature flag on the Drawerlayout and navigate the app to somewhere. The problem we ran into is how to programmatically close the Drawerlayout after the transition is completed.

Currently, workaround is kinda hacky like the following;

//inside the custom class that implements the DebugDrawerModule

activity.findViewById<DrawerLayout>(R.id.debugDrawerId).closeDrawers()

Do you have a better way to achieve this?

So Android Q's new gesture navigation makes it trickier to pull out a drawer from the right hand side. By default that gesture will now navigate back. One option we do have is to exclude part of the right hand side for gesture navigation, allowing us to continue opening the drawer. Maybe the top 50% of the right hand edge, since that's less likely to be used when navigating back? 🤷‍♂

At the moment the drawer only accounts for TOP window insets. This can lead to some funky rendering like this where content is below the navigation bar:

It's super weird. The deployment to Maven Central looked like it went smoothly, however the artefacts fail to resolve.

https://search.maven.org shows the latest version as 0.9.7:

However exploring the Maven directory structure doesn't show version 0.9.7:

Curiously, maven-metadata.xml shows that the latest version is indeed 0.9.7, and manually navigating to https://repo1.maven.org/maven2/au/com/gridstone/debugdrawer/debugdrawer/0.9.7/ resolves correctly.

Even weirder, it looks like debugdrawer-leakcanary is the only module that's actually working?

LeakCanary2 has the ability to be enabled or disabled at runtime. The debug drawer module should provide some sort of control for this option.

Not great, as it means users currently can't go into the source of components or view their documentation.

The no-op timber module that developers can include in their release builds is pretty lame. Leakcanary 2.0 shows a really cool way of getting around this by using a ContentProvider; an approach they stole from the Firebase team. Read more about it here.

I think we could employ the same strategy here to avoid the need for consuming apps to call LumberYard.install().

Debug drawer's leakcanary module seems to throw at runtime after bumping to kotlin 1.4.0

java.lang.IncompatibleClassChangeError: The method 'leakcanary.LeakCanary$Config leakcanary.LeakCanary.getConfig()' was expected to be of type virtual but instead was found to be of type static (declaration of 'au.com.gridstone.debugdrawer.leakcanary.LeakCanaryModule' appears in /data/app/au.com.gridstone.pscore.hkpf.demo.debug-75jz9orOwAlWJvXZnjgn6g==/base.apk)
        at au.com.gridstone.debugdrawer.leakcanary.LeakCanaryModule.onAttach(LeakCanaryModule.kt:21)
        at au.com.gridstone.debugdrawer.DebugDrawer$LifecycleListener.onActivityStarted(DebugDrawer.kt:218)
        at android.app.Application.dispatchActivityStarted(Application.java:406)
        at android.app.Activity.dispatchActivityStarted(Activity.java:1234)
        at android.app.Activity.onStart(Activity.java:1717)
        at androidx.fragment.app.FragmentActivity.onStart(FragmentActivity.java:536)
        at androidx.appcompat.app.AppCompatActivity.onStart(AppCompatActivity.java:210)
        at android.app.Instrumentation.callActivityOnStart(Instrumentation.java:1425)
        at android.app.Activity.performStart(Activity.java:7825)
        at android.app.ActivityThread.handleStartActivity(ActivityThread.java:3294)
        at android.app.servertransaction.TransactionExecutor.performLifecycleSequence(TransactionExecutor.java:221)
        at android.app.servertransaction.TransactionExecutor.cycleToPath(TransactionExecutor.java:201)
        at android.app.servertransaction.TransactionExecutor.executeLifecycleState(TransactionExecutor.java:173)
        at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:97)
        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2016)
        at android.os.Handler.dispatchMessage(Handler.java:107)
        at android.os.Looper.loop(Looper.java:214)
        at android.app.ActivityThread.main(ActivityThread.java:7356)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)

Hi! I am having problems to override styles from your library. I am not sure if declaring your styles as <public> is enough. I believe you have to add also some attrs and reference your styles through this method.

Something like that perhaps? https://stackoverflow.com/a/46697647/2776572

Anyways, adding detailed example on your paragraph where you mentions the following would help.

The debugdrawer dependency has a few publicly exported style resources. You can use these styles (such as Widget.DebugDrawer.RowTitle) to ensure your custom module maintains a consistent appearance with other modules in the drawer. Yes, this is a development tool, but developers can appreciate nice UIs too!

I'm of two minds about doing this now or waiting until PY takes it out of alpha. On one hand it'd be nice to wait until the API stabilises. On the other hand there're so many improvements in 2.0 that'd be great to take advantage of even while it's in alpha. (DebugDrawer itself isn't even 1.0 yet 😉).

One solution might be to make a new module for 2.0 and keep them separate? 🤷‍♂

A mechanism for adding debug actions to the dev drawer. An example of a debug action is "login" Typing out a lot of text,such as email password etc

The more I read about Jcenter the more worried I am about issues it might cause: https://twitter.com/jakewharton/status/1073102730443526144?lang=en

It also seems like this plugin might make the faff pushing to MC a bit easier: https://github.com/vanniktech/gradle-maven-publish-plugin

Can we add support for adding our own views?
I know I can add a new module to add new feature.

But lets say I just want to add a Crash button in the drawer to crash my application. Adding a module is too much for work for that.

Maybe adding kotlin dsl like this: https://github.com/antonKozyriatskyi/DevDrawer will be helpful.

At the moment all modules have the same package au.com.gridstone.debugdrawer. While the project compiles fine, Android Studio complains about unresolved references in R.*.

To address this each module should probably have its own package, such as au.com.gridstone.debugdrawer.retrofit to fix the collisions.

Hey Chris. In the HttpLogger is it possible to expose the setLevel method so that we can set the default to BODY? I find new starters get confused why they can't see network logs so would like to have it on by default with the option to turn it off or change log level.

Similarly, I'd like to be able to have Leak Canary switched off by default.

Please let me know if I'm missing something or if this could be an enhancement. Thanks!