08-09-2010 11:45 AM
I am working on a new application and I usually use XML to transfer data over HTTP. I want the opinion of the BlackBerry community.
1. Should I use XML or another protocol to transfer data?
2. Do I need to worry more about processing or connectivity?
Let me know what you guys think.
Thanks in advance.
PS: I want experts and beginners opinion
Solved! Go to Solution.
08-09-2010 11:56 AM
I've been using XML since it's pretty easy to grab and parse it and there are many ways to read it on a BlackBerry device (kxml or sax parsers etc).
Using things like tab-delimited or comma delimited data is a bit harder since splitting out the data is resource-intensive (from my experience).
I've also used JSON which made things more lightweight but support is based on a library that is hard to find. I do believe there is now support on BlackBerry 6 though.
In the end, you should use whatever you can maintain easiest then tweak performance as necessary.
08-09-2010 05:16 PM
It is very light weight and efficient as well as speedy. It is well used, I have seen a number of errors (unrelated to the kXML its self) on a couple of 3rd party applications by big names. I have used it for a good couple of years now and written a whole frame work around it. Also you need to only deploy once to a device as a library and you can refer to it again and again. Sure you could may be write your own but you would be most likely reinventing the wheel. It's very simple and does what it says on the can. The only issue is that documentation is sparse so you will most likely have to pick your way through Googled examples.
08-09-2010 05:33 PM - edited 08-09-2010 05:35 PM
XML allows pretty much unlimited flexibility. CSV is a pain to support...
I'd look at MXParser, it is faster than kXML. Both actually implement XmlPullParser interface, the documentation for which is not too bad. Both are open source so you can just find sources and compare each of them.
08-09-2010 05:58 PM
It takes two to tango.
Re the protocol, the first priority is whatever the Server or other end will cope with and/or generate easily.
I've used XML till now, but with a third party JSON support and built-in in OS 6.0, and Server's easily able to process JSON, I'd look seriously at that.
However regarding your first question, I'd say the bigger issue is connectivity, unless you are developing for the corporate market.
08-09-2010 09:57 PM
Thanks everyone for your opinions.
The server handles XML composing and parsing.
The only thing left is which XML package do I use:
I will have to research JSON. Also I will have to include a Library for prior 6.0 OS.
This will be a learning curve for me and I will eventually have to decide if it is worth it or not.
What you mean by developing for the corporate market? Are you talking about BIS and BES or being charged for data usage?
I try my best to minimize data size that is being transfered over the network even if it means a little more processing on the device and server. Devices have gotten much faster since the days of 3.6 - 4.3 OS devices.
The good thing is that everyone seems to agree that XML is the way to go instead of CSD. Which is what I prefer to use anyways. And of course compressing the XML will be part of the process as well, but that's not something that needs to be discussed.
BTW everyone gets "Kudos" from me for participating in this thread.
Again Thank You all. This communitty is great and I glad I am part of it.
08-10-2010 04:23 AM
"by developing for the corporate market?"
In the corporate world you can be comfortable that BES/MDS will work. Other environments, it is not so clear cut which connection method will work.
When processing XML, we use the SAX parser and build our own Objects based on the data. We actually use our own parser, written before XML support was included in the OS, and still continue to use it because it is faster than the built-in one. If you are compressing the data and it is not too big anyway, I would go with the standard parser - it takes away one of the headaches and you can swap to another parser if you find that it is causing you performance issues.