Improve performance of toHtml method by moving it to background thread #1092
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix
In this PR I'm introducing a new approach to
toHtml
method. Previously it would block the UI thread. The reason was that thetoHtml
would work with theEditable
object that represents the content of the editor. However, the object could change if the user would type anything. This is normally not an issue but since ourtoHtml
method is not the fastest, there would be times where the user would change the span at the same time when we were trying to read it and we would have crashes.The new approach introduced here is to make copy of the
Editable
object on the main thread and handle the processing from spannable to HTML on a background thread asynchronously. Since there is no standard way to make a copy of anEditable
object, I'm simply copying the string content and reapplying the spans again. I think this works well but we should watch carefully if there are any new crashes appearing.The libraries are upgraded because the app wouldn't let me run otherwise.
Test
Make sure strings will be translated:
strings.xml
as a part of the integration PR.