Open ubuntudroid opened 5 years ago
Probably the quickest work around for you is to look at the source of RialtoTextView and simply copy that behaviour in your subclass. It's actually TextViewDelegate that does all the work, and ~you can use that in your custom view~. Sorry, I lied - it's an internal
class so you can't use it.
There's no specific reason why RialtoTextView
is final other than classes are final by default in Kotlin. I never considered the use case where anyone would need to subclass it.
Yours is an interesting use-case though. I'll give some thought to how to handle subclasses of TextView
.
@StylingAndroid sounds good, let me know if I can help you. From what I can see just making RialtoTextView
(and its siblings) open
should work fine for the subclass case.
Yeah, but it would be far easier to use if Rialto could just deal with any class that subclasses TextView
. That would be the nicest way to solve it.
Agreed, but from what I can see right now Rialto makes use of extending AppCompatViewInflater
(in the appcompat case) and overriding the create...
methods there. And those are called from the switch-case in createView(View, String, Context, AttributeSet, boolean, boolean, boolean, boolean)
where there is no case for subclasses of TextView, EditText or Button.
I see one option there though: overriding createView(Context, String, AttributeSet)
which is called from the default case in createView(View, String, Context, AttributeSet, boolean, boolean, boolean, boolean)
and checking for subclasses there. What do you think?
Ah, strike that, that wouldn't work as
name
to check whether this actually is a subclass.So for now I am back to preferring making the Rialto View classes open.
I'm actually thinking of completely changing the implementation so that there are no Rialto*
subclasses of the AppCompat / Framework widgets. Instead leverage behaviour already built in to TextView
and let the Rialto magic happen that way. I'll need to tinker with some stuff first though, you may need to give me a week or two.
Sounds awesome, do let me know when you need a helping hand. 🙏
On Fri, Apr 26, 2019, 5:00 PM Mark Allison notifications@github.com wrote:
I'm actually thinking of completely changing the implementation so that there are no Rialto* subclasses of the AppCompat / Framework widgets. Instead leverage behaviour already built in to TextView and let the Rialto magic happen that way. I'll need to tinker with some stuff first though, you may need to give me a week or two.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/StylingAndroid/Rialto/issues/5#issuecomment-487088940, or mute the thread https://github.com/notifications/unsubscribe-auth/AAD65OZUZBTUXAGKXHC5OGLPSMKKRANCNFSM4HIVOXOA .
☝️ Just in case we don't find a more generic solution.
I have a class subclassing TextView. Using rialto does not seem to work there as string resource annotation processing isn't invoked there as the TextView subclass isn't converted to a
RialtoTextView
during View inflation. And asRialtoTextView
is final I cannot subclass that one instead of plainTextView
to make it work.Is there a specific reason why
RialtoTextView
is final?From what I can see this would also affect subclasses of Button and EditText.