Я много читал об ограничениях отправки электронной почты в формате html с Android. Все предложения по отправке html электронной почты, по-видимому, состоят в том, чтобы просто передать Html.fromHtml (yourHtmlString) в намерение как Intent.EXTRA_TEXT. Это работает для нескольких основных тегов - полужирный, курсив - но не для таких, как таблица HTML.
Похоже, вы могли бы попытаться расширить некоторые функции либо HTML, либо реализовать свой собственный обработчик тегов, но мне интересно, нет ли более фундаментального ограничения, которое заставит вас сделать что-то совершенно другое (например, с почтой API или что-то).
Причина, по которой я предлагаю это, заключается в том, что, насколько известно само намерение, Html.fromHtml (blah) - просто последовательность символов, и если вы вызываете методы в интерфейсе charsequence этого объекта, вы не видите html. вещи (по крайней мере, я не сделал). Все html / теги, кажется, обернуты в SpannableStringBuilder, который на самом деле возвращает Html.fromHtml ... и мне интересно, смотрит ли приложение gmail под крышками, чтобы увидеть, что на самом деле представляет собой последовательность символов, а затем может обработать несколько тегов Это означает, что нет никакой надежды сделать что-либо на стороне вашего приложения, чтобы заставить приложение gmail справиться с чем-то более сложным, чем полужирный, курсив и т. д.
Я посмотрел на необработанное электронное письмо, которое фактически отправляет приложение gmail, и оно автоматически отправляет как текст / обычный текст без тегов, так и текстовую / html версию с ограниченным количеством тегов. Я даже пытался вставить некоторые экранированные html-теги, которые в конечном итоге могли бы быть преобразованы в реальные теги в текстовой / html-части электронной почты, но, увы, они остались экранированными ... и это, конечно, было бы немного глупо.
В любом случае, для тех, кто мог бы заняться этим больше, я хотел бы сделать дополнительное подтверждение того, что стандартная функция android «отправить html электронную почту» по умолчанию сделает вас невероятно близкими к тому, что вам может понадобиться, но в конце концов вы Нужно укусить пулю и самостоятельно реализовать множество вещей более низкого уровня (таких как Отправка электронной почты в Android с помощью JavaMail API без использования встроенного в приложение по умолчанию , что означает, что вам придется иметь дело с и т.д.).
Примечание (позже):
Я обернул SpannableStringBuilder, возвращенный из Html.fromHtml, с помощью пользовательского класса, который расширил SpannableStringBuilder, и передал его намерению прослушивать вызовы интерфейса Spanned. Оказывается, что когда что-то записывается в посылку, которая отправляется по электронной почте, TextUtils.writeToParcel выполняет некоторую специальную проверку, чтобы искоренить жирный / курсивный материал, сначала проверив, является ли CharSequence экземпляром Spanned, а затем запросив промежутки (через spanned.getSpans). Тем не менее, я не вижу очевидной надежды на внесение изменений, чтобы получить что-то столь же простое, как теги table / td. И я даже попытался изменить toString () моего подкласса SpannableStringBuilder, чтобы он возвратил какой-то необработанный html таблицы, чтобы посмотреть, что произойдет, но в процессе написания посылки ему удалось избежать чего-то еще там внизу.
И еще (позже):
TextUtils.writeToParcel (CharSequence cs, Parcel p, ...) будет, если cs является экземпляром «Spanned», записывать эти промежутки, только если они реализуют интерфейс «ParcelableSpan» ... который представляет собой «Специальный вид Parcelable для объекты, которые будут служить текстовыми интервалами "и" могут использоваться только кодом в платформе; он не предназначен для приложений для реализации своих собственных интервалов Parcelable ". Таким образом, даже если вы хотите подключиться к этому и написать свой собственный для обработки табличных тегов или чего-то еще, это не рекомендуется. Парень, я бы хотел, чтобы хакбод весил здесь с чем-то очевидным, что я пропустил.