I have read a good bit on the limitations of sending html email from android. All suggestions to send html email seem to be to just pass Html.fromHtml(yourHtmlString) to the intent as Intent.EXTRA_TEXT. This works for a few basic tags - bold, italic - but won't for anything like an html table.
It looks like you could try to extend some of the functionality of either Html or implement your own taghandler, but I am wondering if there is not a more fundamental limitation that will force you to do something completely different (like with the mail api or something).
The reason I suggest this is because, as far as the intent itself knows, Html.fromHtml(blah) is simply a charsequence, and if you call the methods on the charsequence interface on this object you don't see any html stuff (at least I didn't). All of the html/tag stuff seems to be wrapped up in the SpannableStringBuilder that Html.fromHtml actually returns... and I am wondering if the gmail app looks under the covers to see what the charsequence really is and then can handle a few tags, which means that there is no hope in doing anything on your app's side of things to get/trick the gmail app to handle anything more complicated than bold, italic, etc.
I have looked at the raw email the gmail app actually sends, and it automatically sends both a text/plain with no tags, and the text/html version with the limited number of tags. I even tried sticking in some escaped html tags that might ultimately get converted to actual tags in the text/html part of the email, but alas they stayed escaped... and that would of course be a bit hacky.
Anyway, for anyone who might have looked into this more, I wanted to do an additional confirmation that the default android "send html email" functionality will get you maddeningly close to what you might need, but in the end you've got to bite the bullet and implement a lot of lower level stuff yourself (such as Sending Email in Android using JavaMail API without using the default/built-in app , which means you've got to deal with the pw stuff, etc.).
Note (later): I wrapped the SpannableStringBuilder returned from Html.fromHtml with a custom class that extended SpannableStringBuilder and passed that to the intent to listen for calls to the Spanned interface. It turns out that when things are written to the parcel that is sent to the email intent, TextUtils.writeToParcel does some special checking to root out the bold/italic stuff by first checking if the CharSequence is an instance of Spanned, and then asking for the spans (via spanned.getSpans). Nevertheless, I see no obvious hope in making the modifications to get something as simple as table/td tags handled in there. And I even tried modifying the toString() of my subclass of SpannableStringBuilder to return some raw table html to see what would happen, but it gets escaped somewhere else down there in the parcel-writing process.
And More (Later): TextUtils.writeToParcel(CharSequence cs, Parcel p,...) will, if cs is an instance of "Spanned", write those spans only if they implement the "ParcelableSpan" interface... which is "A special kind of Parcelable for objects that will serve as text spans" and "can only be used by code in the framework; it is not intended for applications to implement their own Parcelable spans". So, even if you wanted to hook into this and write your own to handle table tags or whatever, it seems to be discouraged. Man I wish hackbod would weigh in here with something obvious I've missed.
That is a function of the email client, most likely. Not all email clients can author arbitrary HTML, on any platform. So, while Mozilla Thunderbird appears to let you create an HTML mail with a table, Gmail does not (leastways, I don't see an option for it in the message-compose window).
Unless you write your own email client, extending the several classes needed to allow
TextView
andEditText
to handle HTML tables (it's way more than just theHtml
class) will do you no good.TextView
andEditText
can "handle a few tags", lining up roughly with whatHtml
can parse/generate andSpannedString
can represent.None of that can handle an HTML table. Nor JavaScript. Nor CSS. Nor
iframe
or any number of other tags.I'd start by asking yourself whether sending HTML mail with tables from the phone directly is worth it. You could send HTML mail with tables from your server using a Web service interface, or you could send HTML mail sans tables from the phone. Neither of those would require you to collect "the pw stuff".