when set custom property for Message, smack generates the following packet which lost red right angel bracket for properties, it will cause connection close.
chat…test1
0001-fix-not-well-format-packet-exception-when-set-proper.patch.zip (797 Bytes)
Good catch. Patch applied with afa4ce577
Uh and your example appears well formed to me or am I mistaken?
Thanks for reporting.
IMO this problem only shows that the approach with XmlStringBuilder / xml.rightAngelBracket(); is as error prone as the old String concatenation approach.
Flow, why don’t you use a proper XML writer library or DOM builder classes, which automatically take care of writing brackets, so that errors like this can’t occur?
IMO this problem only shows that the approach with XmlStringBuilder /xml.rightAngelBracket(); is as error prone as the old String concatenation approach.
And it shows that this part of Smacks functionality is not covered by unit tests.
Flow, why don’t you use a proper XML writer library or DOM builder classes, which automatically take care of writing brackets, so that errors like this can’t occur?
Because I don’t want to introduce another dependency. It’s already hard enough to target Java SE and Android-8. Every further depency just adds another piece of code that needs to be checked for Android compatiblity. And introduces the risk that this compatibilty breaks with future versions.
Using such a library, besides unit-testing where we already use it, is also against the leightweight design philosophy of Smack, which made it portable to Android in the first place. Plus, as long as you don’t use an XML serializer library that verifies well formedness while generating the XML or by static means, you will gain nearly nothing. And using a library that verifies well formedness means additional computation overhead, that could be avoided with a better unit test code coverage, which is the solution I prefer.
Smack has been doing fine for 11 years with the simple String concact approach. Now, for Smack 4.0, I decided to introduce XmlStringBuilder, mostly because to assure proper escaping of values. I am pretty confident that. besides a few minor bugs like this one, XmlStringBuilder will do a good job for Smack for the next decade or so. aSmack 0.9, which I use since a few weeks now, is using it and it’s doing fine so far.
Thanks for your explanation, seems to make sense (also your point about well-formed validation).
I remember you mentioned, that Android has a built-in XmlPullParser implementation. Doesn’t it have a similar thing for XML writing?