Rialto in TextView subclasses

[ubuntudroid]

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 as RialtoTextView is final I cannot subclass that one instead of plain TextView 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.

[StylingAndroid]

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.

[ubuntudroid]

@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.

[StylingAndroid]

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.

[ubuntudroid]

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?

[ubuntudroid]

Ah, strike that, that wouldn't work as

1. we would still have to inject the functionality into the subclass and
2. we only have the name to check whether this actually is a subclass.

So for now I am back to preferring making the Rialto View classes open.

[StylingAndroid]

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.

[ubuntudroid]

Sounds awesome, do let me know when you need a helping hand. 🙏

…

On Fri, Apr 26, 2019, 5:00 PM Mark Allison ***@***.***> 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 <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD65OZUZBTUXAGKXHC5OGLPSMKKRANCNFSM4HIVOXOA> .

[ubuntudroid]

☝️ Just in case we don't find a more generic solution.