The future of Smack development: Google Summer of Code Project - Target Android and JavaSE

Maybe it is possible to write an adapter for a XmlPullParser, i.e. a class which implements XMLStreamReader and gets an XmlPullParser in its constructor and then delegates the calls to the XmlPullParser.

I am sorry, but I don’t understand this approach nor the advantages.

I was thinking about an adapter class like this. Granted, there is no big advantage. But I’d feel more comfortable working with a “standard” (javax.xml) interface than wrapping both worlds into a third (Smack) interface. But that’s only my opinion.

For Android create an instance of XmlPullParserAdapter passing Androids XmlPullParser. For Java SE just use XmlInputFactory.newFactory().createXmlStreamReader().

Then work with XMLStreamReader.

public class XmlPullParserAdapter implements XMLStreamReader {

private final XmlPullParser xmlPullParser;

public XmlPullParserAdapter(XmlPullParser xmlPullParser) {

this.xmlPullParser = xmlPullParser;

}

@Override

public Object getProperty(String name) throws IllegalArgumentException {

return xmlPullParser.getProperty(name);

}

@Override

public int next() throws XMLStreamException {

try {

return xmlPullParser.next();

} catch (XmlPullParserException | IOException e) {

throw new XMLStreamException(e);

}

}

@Override

public void require(int type, String namespaceURI, String localName) throws XMLStreamException {

try {

xmlPullParser.require(type, namespaceURI, localName);

} catch (XmlPullParserException | IOException e) {

throw new XMLStreamException(e);

}

}

And if you provide your own (Smack) interface for Android or if you make javax.xml interface available there by including a “light” interface jar, should be no big difference.

public class XmlPullParserAdapter implements XMLStreamReader {
And where would XMLStreamReader be declared and defined in your scenario?

For Java SE it is included in the JRE. For Android, Smack would be delivered with stax-api-1.0.1.jar (or any other jar, which includes the interface) + the XmlPullParser library, obviously.

This adds a depedency to stax-api-*.jar for Android deployments that is not really needed, because Android already contains an pull parser. The advantage is of course that we don’t need to define an interface but could use the one from stax. But I really like to use the Android provided parser for performance reasons.

True. But it’s only a few interfaces. 25 KB. And probably it is possible to just include the single interface you need directly into Smack, if you worry about including the complete API.

On the other hand, you have your own interface which would be unecessarily included in normal Java SE environment.

It doesn’t really matter for both sides, because nobody cares for a few KBs on their system.

Performance wise, I don’t see your point. You would still use the Android parser. It’s just accessed through another interface. There’s no logic in the adapter class, just method delegation, and that’s no performance risk.

I didn’t knew that there was an interace only jar of the stax api. It seems small enough to add it as hard depenency then.

But I just compared XMLStreamReader with XMLPullParser from Android and found that they are not 100% equal. Which leaves us with two options: Use XMLStreamReader as interface for Smack and implement the missing Android methods as empty methods. Not really a good approach, because it’s error prone having an interface where not all methods are usable.

Or create a new interface that implements the interesection of the methods between the two interfaces. That is the option I would go with.

Performance wise, I don’t see your point. You would still use the Android parser. It’s just accessed through another interface.

There is a huge difference if you use the bytecode of a class that is distirbuted with your Android application or if you use the API provided by dalvik. You have to take for example JIT, optimization and caching effects into account.

There is a huge difference if you use the bytecode of a class that is distirbuted with your Android application or if you use the API provided by dalvik. You have to take for example JIT, optimization and caching effects into account.

Hm, ok, I can’t really follow this. I am not familiar with Android Java. But if you provided your own Smack interface for Xml parsing, wouldn’t it have the same performance issue?

But if you provided your own Smack interface for Xml parsing, wouldn’t it have the same performance issue?
No, because it’s just an interface not an implementation. If used on Android, the implementation provided by dalvik would be used, which is better then the same implementaiton provided as jar.

Or create a new interface that implements the interesection of the methods between the two interfaces. That is the option I would go with.

I wouldn’t take this approach as it forces users of Smack to learn a custom pull parsing API instead of using one of the existing standardized ones. If Stax can’t be made to work well on Android, then we are better off sticking with the pull parser that we use now.

If we were to wrap the Android pull parser implementation with the Stax API, I would just throw an UnsupportedOperationException on any operation that doesn’t match up and isn’t easily translated. Assuming of course that we can write providers without that functionality, which I assume we can since we don’t use it now.

Certainly for non Android usage, Stax would be preferable as it seems to have more momentum with several available implementations, including of course the one in the sun JDK. This also means available parsers that are being actively worked on and advanced.

I wouldn’t take this approach as it forces users of Smack to learn a custom pull parsing API instead of using one of the existing standardized ones. … If we were to wrap the Android pull parser implementation with the Stax API, I would just throw an UnsupportedOperationException on any operation that doesn’t match up and isn’t easily translated.

That would be a mistake, for the reasons I wrote explained here. It’s error prone to have an API where not all methods are usable, i.e. throw an UnsupportedOperationException. Instead I propose to define an API that defines the intersection of methods between the Android pull parser and stax. It is therefore not a new API that users have to learn, the methods and their contract stays the same, we just use only the ones that are available in both worlds. According to my research, the most important methods are available in both worlds, so this should no really be a problem.

just curious, is Smack stuck using StAX / XMLPullParser because Android does not come with a SAX implementation? To my knowledge, SAX is more performant that StAX, but StAX is simpler to use…

just curious, is Smack stuck using StAX / XMLPullParser because Android does not come with a SAX implementation?

Android does come with a SAX implementation. But using it for Smack would mean that every Provider needs to be rewritten to SAX, and honestly I see no one doing that in the future. I also see no need to switch to a different parsing technique because we have well tested Provider using XML pull parsing.

But if somebody offers a complete code rewrite, I would consider it.

To my knowledge, SAX is more performant that StAX, but StAX is simpler to use…

Such claims are usually worthless without some references. And it also depends on the conrecte implementation. Furthermore “simplier to use” is somewhat subjective.

it would depend on the use inside of Smack too, since you can’t “pause/resume” a sax parser I don’t think, nor write xml from it. was just curious on the stax use… I tend to reach for sax or jaxb depending on the scenario.

I did some research. Mainly I read http://www.ibm.com/developerworks/library/x-android/

Android supports SAX parser (as Flow already mentioned), DOM parsing and XmlPullParser.

The article says a StAX parser is more efficient because it does not read the whole XML and reading can therefore be finished, if you are done. But that probably isn’t significant.

I guess, if you want to do it right, you would use SAX parser to read XML and use DocumentBuilderFactory (DOM) to write XML.

This would work for Android and non-Android Java and would get rid of the extra dependency (org.xmlpull).

But it would also mean a complete rewrite…

So, probably a bad option.

I wasn’t trying to suggest Smack switch to another parser, I was only curious as-to why StAX was chosen (xml parsing can easily turn into a flame war lol)

You are correct, once SAX parser gets going, there’s no stopping it! It vomits out nodes! So, if all you’re after is a node or two from a giant xml, then SAX may not be as efficient since it must finish parsing the document.

There are other ways to write XML (good god, DOM is awful). JAXB is a nice one, it maps java objects to xml nodes and vice versa.

Hello Flow.

I see you have been doing a lot of work for asmack.

I tried using it in my android chat app but couldn’t find any advantage of asmack over smack. For example i used ConnectionConfiguration instead of AndroidConnectionConfiguration and found no issues.

Could you or actually any other member please point out the differences and advantages/disadvantages of smack/asmack.

I would be glad to read the docs related to asmack but couldn’t find any for it, even though i found javadocs for smack.

I tried using it in my android chat app but couldn’t find any advantage of asmack over smack.

AFAIK it’s impossible to get a **fully functional unmodified **Smack running on Android. Did you really test everything? For example SASL auth should not work, because Android is missing thing APIs from javax

For example i used ConnectionConfiguration instead of AndroidConnectionConfiguration and found no issues.

Both aSmack and Smack are open source. You can easily see additional work done by AndroidConnectionConfiguration if you look at the source.

Could you or actually any other member please point out the differences and advantages/disadvantages of smack/asmack.

android - What is the difference between Smack and aSmack? - Stack Overflow and-asmack

Also, please stay on-topic within this thread. So all further questions should get ask in an extra thread.

Ok flow. Sorry for being off-topic.

Thanks for replying though. Can’t believe answer was there on SO and still i couldn’t find it. I feel dumb right now.

And yes i did use patched smack and not pure smack for my app but was about to try with pure smack too.

I would start digging the source of asmack right away.

I would also suggest to reduce static blocks and methods number so that smack became more customizable and flexible. Currently due to the way smack handles extension managers and xml parsing I have to maintain my own fork with huge and ugly statical initializer (to have it working the way I want on Android as well. It also makes testing a more complicated task - you can’t do much dependency mocking with static class initializers for example.

So, If you are about to make good things happen to make smack more flexible and modularized, I’m in and ready to help.

See SMACK-314. If you have an proposal on how to replace the static intializers, then feel free to share (but maybe in the relavant discussion thread).

Please note that the primary goal of the GSOC is to modularize Smacks build system and target Java SE and Android. Any changes or improvements related to other functinoaly should get postponed until we have reached this goal.