Comments 19
Позвольте вопрос: зачем это, если TextView и TextEdit вполне съедает html-разметку?
В отличии от html разметки такой подход значительно выигрывает когда нужно, например, динамически менять стиль текста. Если вы будете делать это тегами, то вы, как минимум, офигеете туда-сюда менять теги в разметке. Так же, на сколько я помню, в Toast'ы нельзя пихать html. Хотя, может я и ошибаюсь. Может и ещё есть какие-нибудь плюсы?
Можно.
Toast.makeText(this, Html.fromHtml(«Hello world»), Toast.LENGTH_SHORT).show();
Только вот, другое дело, что сам класс Html занимается только тем, что парсит HTML-разметку и расставляет нужные Span'ы в нужных местах. Соответственно, если использовать Spannable напрямую, будет некоторый выигрыш в производительности, т.к. отпадает необходимость парсить HTML.
Toast.makeText(this, Html.fromHtml(«Hello world»), Toast.LENGTH_SHORT).show();
Только вот, другое дело, что сам класс Html занимается только тем, что парсит HTML-разметку и расставляет нужные Span'ы в нужных местах. Соответственно, если использовать Spannable напрямую, будет некоторый выигрыш в производительности, т.к. отпадает необходимость парсить HTML.
В Toast можно пихать все, что душе угодно. Метод setView там зачем?
Хорошо, тогда этот довод отпадает. Но первый — действительно стоящий, согласитесь?
А никто не сказал, что надо будет пинать сырую строку с html, можно использовать некий класс-контейнер, который в итоге будет генерировать строку. Хотя один хрен класс Html работает с тем же Spannable. Сам его использовал для отображения Markdown подобного синтаксиса, довольно мощный и удобный инструмент.
Например, можно подменять в тексте коды emoji картинками смайлов соответствующих, используя ImageSpan.
Если сохранять стилизирований текст (в ресурсах, базе данных), тогда использовать html-разметку будет лучший вариант, который реализован в пакете android. Если же у нас стоит задание стилизировать текст, который формуется динамически, тогда лучше использовать подход, который описан в статье.
UFO just landed and posted this here
Статья интересная, но мне кажется, что в современных андроид-проектах засорять код стилями не очень хорошо. Это удобнее делать в XML.
А в чем отличие современных проектов от До-современных? :)
Вопрос о том, засоряют ли стили код, тоже обсуждаемый!
Вопрос о том, засоряют ли стили код, тоже обсуждаемый!
XML не засоряет код потому что, как правило, находится в другом модуле. В ситуации когда быстродействие важно, все стили можно вынести в другой класс или модуль, и даже хорошо организовать локализацию. При этом стили ни коим случаем не будут засорять саму бизнес логику проекта.
Вы путаете код в примере с реальным приложением. Конечно, если работать с текстом, который определен ещё на этапе создания приложения, то нет сомнений — место ему в ресурсах и там сразу прописать оформление с помощью HTML-разметки. Но, когда приходится работать с текстом извне, то такое решение может быть достойной альтернативой встраиванию WebView в приложение.
Для себя счел пост интересным. Удивлен, что пропустил данную функциональность в своё время.
Для себя счел пост интересным. Удивлен, что пропустил данную функциональность в своё время.
Извините, но я не перепутал, и мой предыдущий комментарий не имеет много общего с кодом в примере.
Я имел ввиду что если для нашего приложения слишком затратно время парсинга html-разметки, но мы можем себе позволить дополнительное время при старте проекта, то, как альтернативу, можно использовать заранее созданные статические ресурсы в java классах. Этот подход не столь изящный, но имеет право на существование.
На счет данной функциональности, я тоже не новичок но узнал про нее относительно недавно, рад что пост Вам был интересен.
Я имел ввиду что если для нашего приложения слишком затратно время парсинга html-разметки, но мы можем себе позволить дополнительное время при старте проекта, то, как альтернативу, можно использовать заранее созданные статические ресурсы в java классах. Этот подход не столь изящный, но имеет право на существование.
На счет данной функциональности, я тоже не новичок но узнал про нее относительно недавно, рад что пост Вам был интересен.
Судя по расположению вашего комментария в дереве постов расценил его как ответ для @aleseevpg, к тому же в вашем ответе нет ни слова о производительности. Вот и расценил его как рассуждение о том, стоит ли использовать Spannable вообще для оформления текста.
Но это был ответ для Kalpazan, и о быстродействие там упоминается. Но спасибо Вас за рассуждения.
Перепутал ветку, уже перенес данный комментарий.
Sign up to leave a comment.
Использование RichText в Android. Spannable