-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow any type of ScannableView #137
base: main
Are you sure you want to change the base?
Conversation
@@ -29,7 +29,7 @@ public final class radiography/ScanScopes { | |||
public static final fun singleViewScope (Landroid/view/View;)Lradiography/ScanScope; | |||
} | |||
|
|||
public abstract class radiography/ScannableView { | |||
public abstract interface class radiography/ScannableView { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also worth noting this break backward compatibility (as you can't switch over ScannableView anymore) but I don't expect any consumer to be impacted.
If we really really want to avoid that we could keep ScannableView as abstract class and make it implement an interface. But then I don't know how to name that interface
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's possible to add direct subclasses to a sealed class in any way without technically breaking compatibility. Any consuming bytecode that assumes it has handled all the cases will be wrong.
Technically I think this means we need to bump the major version number.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand why unsealing the class has to be done together with removing thread checks.
And removing the threading guarantees seems like it could break stuff - remind me why we don't care?
@@ -15,17 +11,15 @@ import java.util.concurrent.TimeUnit.SECONDS | |||
|
|||
/** | |||
* Utility class to scan through a view hierarchy and pretty print it to a [String]. | |||
* Call [scan] or [View.scan]. | |||
* Call [scan] or [android.view.View.scan]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: the kotlin formatter should keep the import even if it's only used by kdoc.
if (windowTitle != null) { | ||
return "$classSimpleName in $windowTitle window-focus:${view.hasWindowFocus()}" | ||
} else { | ||
return classSimpleName |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not report focus in this case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there's no window title, then this isn't the root view for an attached window. In which case window focus doesn't make sense. Good question though, should add as comment.
Great questions! So I started with the unsealing but then realized that for any of this to make sense, I really wanted to decouple Radiography from requiring a dependency on Android. Hence the follow up commits that remove dependencies on Looper and then window manager. I can totally break those out in separate PRs, I was being lazy. That being said, I believe both changes are generally good + fixing tech debt remnants, here's why:
|
And so of course a follow up change prior to releasing would be to make the Android dependency optional and prove that it works. I'm thinking we might not actually need a separate module, which would be annoying as our default params in Radiogaphy.scan are Android centric. I believe the main use case is still mostly Android so I don't want to make that harder. But if I provide all the params then I'm hoping there will be no attempt to load the android specific classes and this can run on a JVM. Need to confirm though. Another option might be to make a new entry point but I'm not sure how it'd be different. Unless we go with same name an API and you have to choose your artifact, and the only difference is in the defaults? Or we could get rid of the defaults (major version bump) but that seems like it'd make the core use case harder. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I think I was missing the hint that this was just prep for removing the Android dependency. Thanks for splitting up the commits.
Note: there's more work to make this not Android dependent. Notably refs to the WindowManager which likely belong to displayName for Views instead (?)