I am trying to write a program in android that does a lot of string and xml parsing.
I need suggestion of which way to go :
Use JNI and implement parsing in C++ and use C++ xml SAX parsing (Android - NDk)
Go with java and parse xml with SAX
Have you considered a server-side component that could do the majority of the parsing, which then sends a stream to devices that is significantly easier for the device to parse? You could present a web interface in addition to a mobile interface. It would be easier to setup subscriptions for which you could charge a fee if you someday decided to.
I would suggest option 2.
It may not be worth it to go with the complexity of NDK just for the parsing purpose.
Related
Due to the importance of some legacy applications in my workplace, I was thinking if I could solve a problem in a VB6 app by doing the processing on a Java app instead, and then delivering the value back to VB6. For that, I'd need to run the Java app from inside the VB6 app, and then get a String back from it.
How would you suggest that I go about doing something like this?
Formal web services (I'm looking at you SOAP) have a tremendous amount of overhead and rigidity, and something like REST or plain old XML or JSON over HTTP don't save on that very much.
You might be far better off using TCP with a very thin protocol on top of it. Named Pipes would be better but VB6 has no native support for this. Anonymous pipes might be ideal but VB6 never got native support for async pipes of any variety.
So the quick and not-so-dirty solution might be TCP. You can add trivial framing such as a message length prefix or message termination delimiter, then design a payload format ranging from delimited text to fixed fields to XML or JSON or even a binary format.
Leave web services to their proper use case: cross-organizational interoperation over the Internet.
I know that XML can be used so that programs in different programming languages could communicate.
E.g. a Java server with C and Python clients.
Could JSON be used as an alternative? I mean also if it can should I go for it? Especially in a case where the clients are not controlled by me.
Would you feel that implementing such a client XML would be prefered?
Yes, you can. Just use appropriate Json libraries on both ends (e.g. JsonCPP on the C++ side, or jansson in C). And learn more about json-rpc.
The big advantage of JSON over XML is that it is simpler (to understand, to implement, to use) and probably less verbose (so shorter messages).
You could also consider YAML which seems less used, but is more "powerful".
Don't forget to document quite well your JSON protocol (i.e. messages).
Yes, you should JSON.
There are many libraries for JSON in nearly all well known languages. And a JSON file with the same content as a XML file is about 75% smaller. So you should use it :D
Per your question of should you do it, I think it's an appropriate use. In the end you simply need something that both ends of the conversation can handle. You could use XML or some other alternative, but I don't think it's any better/worse from a 'should you' perspective.
Sorry for the separate answer. Lacking the rep to comment...
You can, but you should not. Don't get me wrong, JSON is OK as data-interchange languages go, but the XML serialization packages for just about any language are much more mature than most JSON packages. Yes, XML is larger than JSON, and there's good reason - it carries a lot more descriptive information than JSON does. And the more diverse your "endpoints" are, the more that information can help in maintaining robust communication.
We have an internal library that uses the org.w3c.dom DOM API to read and write XML. When attempting to use this library on Android I found that it no longer works. It appears that Android implements only a subset of the DOM API. I don't know the reasons for this, and I know that it's fixed in Android 2.2, but I still need to target older devices.
I know a number of alternative DOM libraries for "regular" Java, such as XOM and Dom4j. Can anyone recommend a DOM library that meets the following goals?
It has to work on Android.
It should be small (since people pay per MB).
Ideally, it should be similar to the org.w3c.dom API since I need to rewrite the existing code.
It's probably impossible to meet all three goals, but with two I would already be happy. Also, out of curiosity, does anyone know why the DOM API is not fully supported? I can understand the reasons for not implementing Java Sound etc., but XML seems quite essential to me.
My general recommendation would be to stay well away from a DOM parser, because the performance is abysmal compared to using a direct parser. You would be much better off parsing with XmlPullParser or SAX.
I know, you already have code that uses DOM, and that is how you want to do it. But believe me, you should not be using this on a mobile device.
I have a java back-end that needs to expose services to clients running in the following environments :
J2ME
Windows Mobile
iPhone
I am looking for the best tool for each platform.
I do not search a technology that works everywhere.
I need something "light" adapted to low speed internet access.
Right now I am using SOAP. It is verbose and not easy to parse on the mobile. The problem is that I have not seen any real alternative.
Is there a format that works "out of the box" with one of these platforms ?
I would rather not use a bloated library that will increase tremendously the download time of the application.
Everybody seems to agree on JSON. Does anyone has implemented a solution based on JSON running with Objective-C, J2ME, Windows Mobile ?
Note : so far the best solution seems to be Hessian. It works well on Windows Mobile and Objective-C/iPhone . The big problem is J2ME. The J2ME implementation of Hessian has serious limitations. It does not support complex objects. I had written another question about it.
If you have any ideas, there are very welcome.
JSON is fairly compact, and supported by most frameworks. You can transfer data over HTTP using standard REST techniques.
There are JSON libraries for Java, Objective C, and many other languages (scroll down). You should have no problem finding framework support on the server side, because JSON is used for web applications.
Older alternatives include plain XML and XML-RPC (like SOAP, but much simpler, and with libraries for most languages).
Hessian. http://hessian.caucho.com. Implementations in multiple languages (including ObjC), super light weight, and doesn't require reliance on dom/xml parsers for translation from wire to object models. Once we found Hessian, we forgot we ever knew XML.
REST + XML or JSON would be a good alternative. It is making big strides in the RIA world and the beauty of it is in it's simplicity. It is very easy to use without needing any special tooling. SOAP has it's strong points, but it works best in an environment with strong tooling support for it. I'm guessing from your question that's not the case.
Seconding JSON. I ported the Stringtree JSON reader to J2ME. It's a single class JSON reader that compiles into a 5KB class file, and directly maps the JSON structure into native CLDC types like Hashtable and Vector. Now I can use the same server for both my desktop browser AJAX frontend and my J2ME client.
How about plain old XML (somewhat unfortunately referred to as POX)?
Another very useful option would be JSON. There are libraries for every single programming language out there.
Possibly, since you are working in an environment that is constrained in terms of both computing and networking resources, and with a statically typed language, Google’s protocol buffers would be preferrable for you. (Just disregard the RPC crud in there; RPC is an attractive nuisance, not a useful technology.)
The problem with your question is that you haven’t provided a whole lot of context about what kind of data this is and what your use cases are, so it’s hard to speak in anything but very vague generalities.
Can anyone recommend a good binary XML format? It's for a JavaME application, so it needs to be a) Easy to implement on the server, and b) Easy to write a low-footprint parser for on a low-end JavaME client device.
And it goes without saying that it needs to be smaller than XML, and faster to parse.
The data would be something akin to SVG.
You might want to take a look at wbxml (Wireless Binary XML) it is optimized for size, and often used on mobile phones, but it is not optimized for parsing speed.
Hessian might be an alternative worth looking at. It is a small protocol, well-suited for Java ME applications.
"Hessian is a binary web service protocol that makes web services usable without requiring a large framework, and without learning a new set of protocols. Because it is a binary protocol, it is well-suited to sending binary data without any need to extend the protocol with attachments."
More links:
Here
Here too
What kind of data are you planning to use? I would say, that if the server is also done in Java, easiest way for small footprint is to send/receive binary data in predefined format. Just write everything in known order into DataOutputStream.
But it would really depend, what what kind of data are you working on and can you define the format.
Actually you should evaluate, if this kind of optimization is even needed. Maybe you target devices are not so limited.
It very much depends on the target device. If you have JSR172 available, then you are done with the parsing, the runtime does it for you. And XML is mainly about making your own format. As was alredy stated if your goal is performance, than XML is probably not the best way to go and you will end up doing some binary stuff.