Skip to content
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

textview not reword #27

Closed
ZhouBey opened this issue Mar 7, 2022 · 4 comments
Closed

textview not reword #27

ZhouBey opened this issue Mar 7, 2022 · 4 comments

Comments

@ZhouBey
Copy link

ZhouBey commented Mar 7, 2022

i can not reword text when i create a instance of TextView in Activity,alse i called setText(getString(...))

@B3nedikt
Copy link
Owner

B3nedikt commented Mar 7, 2022

@ZhouBey Yes, manually created views cannot get updated using this library, basically you need to updated their text manually using setText(...) whenever you change the Resources in any way. Support for manually created views out of the box is not something I have planned to support, it would be a pretty big change. Feel free to work on it though, I take PRs :)

@B3nedikt B3nedikt closed this as completed Mar 7, 2022
@ZhouBey
Copy link
Author

ZhouBey commented Mar 7, 2022

yeah, null of attrsTag by manually creating views,so is there any way to achieve it? or do you have any ideas?thank you.

@B3nedikt
Copy link
Owner

B3nedikt commented Mar 8, 2022

I think there are two approaches:

  • First it to set the attrsTag manually whenever setText is called. Basically add ViewCreators which replace views with custom views subclassed from the same view, which have the setText function overwritten to just set add the attrsTag manually. Notice that this change will require you to always use the setText which takes a resource string id as parameter.

  • Another approach would be to add a new function to register view updates to reword. Now you just need to keep the mapping of views to view update functions in memory and get and execute this function whenever Reword.reword encounters the corresponding view.

Both approaches will take considerate effort. I think you will be faster by just doing it manually, but if you want to contribute I would accept a PR for both approaches. I think the second one is preferably though. While less generic, it would be more transparent for the user of the lib how to use the feature.

@ZhouBey
Copy link
Author

ZhouBey commented Mar 11, 2022

I understand, thank you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants