Log filter times during form entry #6573
Conversation
|
@seadowg |
The summary is hard to describe without just repeating the text.
|
@grzesiek2010 done! |
androidshared/src/main/java/org/odk/collect/androidshared/ui/ToastUtils.kt
Outdated
Show resolved
Hide resolved
...pp/src/main/java/org/odk/collect/android/formmanagement/CollectFormEntryControllerFactory.kt
Outdated
Show resolved
Hide resolved
selfie-camera/src/test/java/org/odk/collect/selfiecamera/CaptureSelfieActivityTest.kt
Outdated
Show resolved
Hide resolved
selfie-camera/src/test/java/org/odk/collect/selfiecamera/CaptureSelfieActivityTest.kt
Outdated
Show resolved
Hide resolved
| it.addPostProcessor(EntityFormFinalizationProcessor()) | ||
|
|
||
| if (settings.getBoolean(ProjectKeys.KEY_DEBUG_FILTERS)) { |
There was a problem hiding this comment.
I don't think it's convenient for the QA team or us to enable that option every time we install a new version of the app, which might happen quite often. Wouldn't it be better to always use that strategy in debug mode?
There was a problem hiding this comment.
I've realized this actually gets a bit more complicated because QA usually test with selfSignedRelease (not debuggable) and we probably still want to be able to disable it if it's annoying for something like a demo. I also don't think we want it enabled in beta by default, but still want it available?
There was a problem hiding this comment.
So we can enable it by default for selfSignedRelease? I think that would be ok.
This adds a toast that shows the execution time for filters during form entry. The goal here is to allow developers and QA to quickly debug optimizations/changes to filter code without needing to reach for timers.
Why is this the best possible solution? Were any other approaches considered?
The biggest thing to discuss here is the change that removes
Applicationas an arg from theToastUtilshelpers. My goal here was to makeToastUtilsmore like Timber or Analytics, but I'm happy to discuss if that doesn't feel write!How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Not a lot to check here other than playing around with the new "Debug filters" setting in "Experimental".
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest(or./gradlew testLab) and confirmed all checks still passDateFormatsTest