Improve XRay implementation #614
Conversation
|
|
| @@ -34,7 +34,7 @@ abstract class ViewRouter<V : View, I : Interactor<*, *>> : Router<I> { | |||
| ) : super(interactor, component) { | |||
| this.view = view | |||
| if (XRay.isEnabled()) { | |||
| XRay.apply(this, view) | |||
| XRay.apply(getName(), view) | |||
There was a problem hiding this comment.
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.
Changed textPaint to a lazy val.
There was a problem hiding this comment.
If it's all static info, why not immediately initialize it?
There was a problem hiding this comment.
Paint is a big object. I rather initialize it only if needed. WDYT?
There was a problem hiding this comment.
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.
@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.
"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.
toggle is still here to keep compatibility.
There was a problem hiding this comment.
If so, I suggest we deprecate it.
Is there a substituting method?
| * @param view a [View] to put the name behind. | ||
| */ | ||
| @JvmStatic | ||
| fun apply(viewRouter: ViewRouter<*, *>, view: View) { | ||
| internal fun apply(routerName: String, view: View) { |
There was a problem hiding this comment.
viewRouter was used only to get its name.
|
|
||
| /** 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.
If it's all static info, why not immediately initialize it?
| * @param view a [View] to put the name behind. | ||
| */ | ||
| @JvmStatic | ||
| fun apply(viewRouter: ViewRouter<*, *>, view: View) { | ||
| internal fun apply(routerName: String, view: View) { |
| companion object { | ||
| private val INSTANCE = XRay() |
There was a problem hiding this comment.
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
| } | ||
|
|
||
| /** Toggles state of XRay. */ | ||
| public fun toggle() { |
There was a problem hiding this comment.
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.
This is so simple IMO it should live on XRay.kt file at the top level. No need for a new file
| @JvmStatic | ||
| fun toggle() { | ||
| INSTANCE.isEnabled = !INSTANCE.isEnabled | ||
| public fun setup(config: XRayConfig) { |
There was a problem hiding this comment.
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.
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.
Yes it's ok, was just wondering.
|
@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.