summaryrefslogtreecommitdiff
path: root/java/src-debug/com
diff options
context:
space:
mode:
author Joshua Trask <joshtrask@google.com> 2023-02-10 16:25:01 +0000
committer Joshua Trask <joshtrask@google.com> 2023-02-10 19:40:04 +0000
commitb3240df7c525de985765e0cbbb094a0f7c83e440 (patch)
treecaa85adfad206fca83e71f5b279d6df80d93958b /java/src-debug/com
parent031a84bc72c2f8d5483fefc24539bb5ee08d5fdc (diff)
Clarify ResolverActivity inheritance contract.
This is a simple mechanical refactoring and (given everything still builds) it can't possibly have any side effects. The procedure for generating this change was as follows: 1. Add `final` to all `ResolverActivity` methods. 2. Build, and remove `final` from any of those methods that now break compilation. 3. Sort the `final` (and `static`) methods to the bottom of the source file / non-final to the top. 4. Build `IntentResolverUnitTests` and remove `final` from any `ResolverActivity` methods that broke test-only compilation. Replace with a comment `// @NonFinalForTesting` on these methods (referencing an annotation that isn't available in Android, but still worth noting. There are other patterns we can use to formalize our design requirements, but these lightweight comments are more appropriate while the API is in flux). 5. Sort these "non-final for testing" methods above the `final` methods but below any that are overridden by real clients (since they're still *really* just internal implementation details). 6. Build and test. (7. Go back through and remove `final` from any private methods, as requested by the linter. I'm not sure I agre3 with this rule in a language where these methods will be "open" by default if their visibility is ever changed, but c'est la vie...) This groups together the `ResolverActivity` "override surface," which roughly outlines the interface of a hypothetical delegate interface that could be injected as part of `ChooserActivity` configuration in order to avoid overriding any `ResolverActivity` methods. (That's left out of scope in this CL, because -- even though we *could* effect such a change via purely-mechanical transformations -- I suspect we'll want to apply *some* design discretion along the way.) Ultimately this will be an important step in decoupling our components from the `Activity` API (with benefits for code clarity, hypothetical "embedded Sharesheet" and "build-your-own chooser" APIs, etc). Test: `atest IntentResolverUnitTests` Bug: 202167050 Change-Id: Iffe340e1d6e3e3224fb6bd78005c349384716162
Diffstat (limited to 'java/src-debug/com')
0 files changed, 0 insertions, 0 deletions