Conundrum in writing a Provider

Smack Smack Dev
1

Greetings!

I’m having an issue that I think is caused by the way the stanzas I have to parse are constructed. I’ve got a bug in to my devs to “do this more appropriately” but for now I still have to write the test appliances to deal with it.

In my , along with all the normal bits, we have a custom stanza tagged with our own xmlns. The trouble is there can be 0 to N of these elements and they are not contained by something like like good xml. These elements represent many different objects in our system so the bodies of these elements are a PITA to parse, but I digress.

I’ve written my own ContentExtension and Provider and that part is working. The trouble I have is due to the nature of the data and how XMLPullParser works. Because you have to leave the parser on the end tag of the element the Extension is parsing there is no way I can see to handle the case of ‘n’ content elements inside my message. For example, if I get something like:

…

… n content elments later …

…

I’m placed on the start of the first element. A pull parser can’t tell me how many there are. I can’t stop at the first end tag and I can’t scan all the way to the end tag for the message and then ‘back up’ to the last end tag for content to satisfy the interface. So if I go all the way to things are just hosed by the next guy to come down and get parsed.

There’s no inter-relationship between these content elements to leverage. The actually represent different objects so I still have to deal with returning multiple objects from the Extension and having multiple toXML paths.

I’m hoping someone has a holiday surprise for me! Short of getting my dev team to wrap this all up in a element or having to write my own extension for , is there any hope?

Thanks!

-Rich

2

I am not sure what the problem is. Your provider should get called for each instance of content and the final Message would then have a list of content obtained via getExtensions(). Unless you need to know how many there are during parsing, there shouldn’t be any problem.

A little tip, you may find the EmbeddedExtensionProvider useful.

3

The key was pointing out that the provider gets hit for each one; I didn’t suss that out from the docs and such. That should unstick me until my devs decide to inter-relate these elements.

It would be handy to have a getExtensions(name, namespace) that returned a set of extensions that match the pattern. Easy enough to implement locally.

The link in the response is a dead one (404) – but I’ll see if I can find that code through other means.

Thanks!

-Rich

4

I fixed the link.

I don’t think that method will be added as it is not a very typical case. I haven’t heard of anyone else formatting their stanza’s that way (but I think you already know that).

5

Thanks for fixing the link.

I haven’t seen many stanzas like that, either, but someone must have anticipated it since the provider can aggretate them. I’m still pushing for a container style xml or non-generic content elements. From our data standpoint, they are already non-generic and distinguised by their mime-type attribute but you have to get into parsing beyond namespace and element name to get there.

Cheers!

-Rich