search

StylingAndroid / Rialto

Apache License 2.0
259 stars 10 forks source link

Rialto in TextView subclasses #5

Open ubuntudroid opened 5 years ago

ubuntudroid commented 5 years ago

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

ubuntudroid commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 .

ubuntudroid commented 5 years ago

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