-
Notifications
You must be signed in to change notification settings - Fork 912
Improve XRay implementation #614
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
base: main
Are you sure you want to change the base?
Conversation
| this.view = view | ||
| if (XRay.isEnabled()) { | ||
| XRay.apply(this, view) | ||
| XRay.apply(getName(), view) |
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.
Change this because it was leaking a this reference to a static function.
| /** Utility class that shows riblets name in its background. */ | ||
| class XRay private constructor() { | ||
| private var isEnabled = false | ||
| private var textPaint: Paint? = null |
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.
Changed textPaint to a lazy val.
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 it's all static info, why not immediately initialize it?
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.
Paint is a big object. I rather initialize it only if needed. WDYT?
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.
BTW, XRay is called in every ViewRouter constructor. So, I will initialize Paint every time. Even if we don't want to use XRay.
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.
@lucasnlm but this is a singleton object, right? So it will really only initialize once. There's only one instance of the XRay class, or am I misunderstanding it?
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 rather initialize it only if needed. WDYT?"
Ok this makes sense.
| } | ||
|
|
||
| /** Toggles state of XRay. */ | ||
| public fun toggle() { |
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.
toggle is still here to keep compatibility.
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 so, I suggest we deprecate it.
Is there a substituting method?
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.
Done.
| */ | ||
| @JvmStatic | ||
| fun apply(viewRouter: ViewRouter<*, *>, view: View) { | ||
| internal fun apply(routerName: String, view: View) { |
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.
viewRouter was used only to get its name.
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.
Good change
| /** Utility class that shows riblets name in its background. */ | ||
| class XRay private constructor() { | ||
| private var isEnabled = false | ||
| private var textPaint: Paint? = null |
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 it's all static info, why not immediately initialize it?
| */ | ||
| @JvmStatic | ||
| fun apply(viewRouter: ViewRouter<*, *>, view: View) { | ||
| internal fun apply(routerName: String, view: View) { |
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.
Good change
| companion object { | ||
| private val INSTANCE = XRay() |
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.
Consider changing the class to an object, if it's supposed to be a singleton after all. Then we can get rid of companion object
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.
Makes sense! I will do that.
| } | ||
|
|
||
| /** Toggles state of XRay. */ | ||
| public fun toggle() { |
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 so, I suggest we deprecate it.
Is there a substituting method?
| /** | ||
| * Configuration for XRay. | ||
| * | ||
| * @property enabled `true` to enable XRay. By default it is disabled. | ||
| * @property alphaEnabled `true` to enable alpha changes when XRay is enabled. | ||
| */ | ||
| public data class XRayConfig( | ||
| val enabled: Boolean = false, | ||
| val alphaEnabled: Boolean = true, | ||
| ) |
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.
This is so simple IMO it should live on XRay.kt file at the top level. No need for a new file
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.
Done
| @JvmStatic | ||
| fun toggle() { | ||
| INSTANCE.isEnabled = !INSTANCE.isEnabled | ||
| public fun setup(config: XRayConfig) { |
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.
Do we need thread-safety? If so, we must instead provide a way to atomically "read and write" -- an .update { } function, as below:
INSTANCE = AtomicReference<XRayConfig>(XRayConfig())
inline fun update(function: (current: T) -> T) {
INSTANCE.getAndUpdate(function)
}
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 think we don´t need thread-safety. At least I never had thread issues with XRay.
Is it ok for you if we let it as is?
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.
Yes it's ok, was just wondering.
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'd probably not make Paint lazy, as the XRay object itself will only be initialized first time it is called anyway, so by lazy in its property for those purposes feels redundant
Stamped though
|
@lucasnlm please build a version of RIBs with your change and make sure it works as expected using our apps, if so we can go ahead with landing |
|
@psteiger How can I do that? |
|
@lucasnlm I tagged on in internal comms with smoke test instructions |
I hope to test it this week. Thanks for the reminder. |
Description:
This PR adds
setup(),XRayConfigto RIBs XRay to allow setup it without rely on the existingtoggle()function.Problem it fixes
The current
toggle()function may be problematic because it changes a static boolean. Example: depending on where XRay is enabled or if it's as debug in a RIB used twice, it will enabled and disable immediately.XRayConfigadds the ability to enable XRay without change the Views alpha. The alpha change may be problematic when we have many RIBs attached due to the overlapping.