Cool, that would make a good addition to the compatibility library, as
I'd assume, it's fairly self-contained.
On Jun 5, 8:21 am, Dianne Hackborn hack...@android.com wrote:
On Mon, May 30, 2011 at 6:28 PM, Streets Of Boston
flyingdutc...@gmail.comwrote:
Personally, I would choose XML because
On 31 Maj, 03:28, Streets Of Boston flyingdutc...@gmail.com wrote:
I would make this argument instead: REST or SOAP?
That was prob. the question that the orignal poster wanted to ask.
A big part of creating a seamless experience on mobile devices is to be able
to handle* limited connectivity*
On Mon, May 30, 2011 at 6:28 PM, Streets Of Boston
flyingdutc...@gmail.comwrote:
Personally, I would choose XML because Android already includes pull and
push parsing of XML data from the server. Pull and push parsing allows you
to only read the parts of the REST response in which your app is
Hi,
I'm assuming you want to know what format the webservice should return data
in? JSON vs XML.
I think there are 3 things to consider.
1. Amount of data being sent over the web.
2. Processing required to de-serialise the data (speed).
3. Programming complexity.
I was thinking the same thing
I haven't tested JSON's performance on Android, but for XML, I found that
this was the fastest and most convenient (i needed a proper context for XML
elements, know where the XML element is in the document):
- Use android.sax.RootElement and related classes to listen only for
elements I'm
I would guess that, if XML parsing is faster than JSON parsing, it's
largely because the XML parsers are more highly optimized (due to it
being a more mature technology). From a purely mechanical standpoint
the amount of work that either needs to do is pretty much equivalent
on a per-byte basis.
Frankly, any sort of RPC scheme (which SOAP is to an extent) is
suspect -- it seems nice for very simple scenarios but very quickly it
gets messier than using a more message vs call paradigm.
(And as anyone with any sense knows, SOAP really means Symbolic
Optimizing Assembler Program and any
I entirely agree with DanH. SOAP for mobile devices is not the best choice
and does get messy quickly indeed.
--
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To
I'm Sorry Marcin Orlowski,
I meant JSON and XML and not JSON and SOAP
On 30 maio, 05:56, Marcin Orlowski webnet.andr...@gmail.com wrote:
On 30 May 2011 05:15, Migazan eni...@gmail.com wrote:
What better way to consume web services on android JSON or SOAP?
As other said it's not the same
Note that it's perfectly feasible to do pull parsing with JSON, and
I believe there are packages to do that. It's not done very often,
though, since the in-core representation of JSON is generally
several times more compact than the equivalent representation of XML,
so there's no need for it.
On
I see. We tried SOAP long time ago, and back then, it really wasn't any use for
us. Management was after it for having a cool new technology to sell our
product but we ended more or less to use plain Sockets at the end. But as said,
just wanted to hear your opinion. SOAP is something I never
JSON is not a replacement for SOAP. JSON is more of a replacement for
XML.
On May 30, 11:15 am, Migazan eni...@gmail.com wrote:
What better way to consume web services on android JSON or SOAP?
--
You received this message because you are subscribed to the Google
Groups Android Developers
On 2011-05-30 09:47, Zsolt Vasvari wrote:
JSON is not a replacement for SOAP. JSON is more of a replacement for
XML.
Agreed as such, but I'd still say that for MOST cases I've seen, JSON
will do what you need. SOAP is the opposite of lean in my experience,
so if you have the choice if
Some web services may give you the choice between SOAP and JSON
remote APIs. In such a case, whereas SOAP defines much of the
structure of requests and responses, and the conceptual protocols
involved, JSON (by itself) does not (it only defines the basic data
format), so additional info is
Hi Dan,
I was introduced to JSON only very recently and since you seem to
understand the difference between JSON and SOAP much better than I do,
I'm wondering is there really need for both? I mean JSON was very
flexible and easy to use. Only thing I can come up with is the lack of
binary data
SOAP has high-level functions that JSON doesn't (over and above the
simple protocol level differences). Not really necessary for simple
database queries and the like, but useful for more sophisticated
stuff. (Disclaimer -- I've never actually used SOAP -- it's always
been too complex for my
On 2011-05-30 15:16, DanH wrote:
SOAP has high-level functions that JSON doesn't (over and above the
simple protocol level differences). Not really necessary for simple
database queries and the like, but useful for more sophisticated
stuff. (Disclaimer -- I've never actually used SOAP -- it's
My 9 out of 10 comment was more with regard to XML -- there are
occasions where the ability to have tag attributes in XML makes for a
neater, more coherent interface than using JSON.
On May 30, 8:29 am, Jonas Petersson jonas.peters...@xms.se wrote:
On 2011-05-30 15:16, DanH wrote:
SOAP has
Please...
JSON should be compared to XML. Both is a way of serialize and
deserialize structured data (like converting between binary and text
representation).
SOAP is a way of calling services on other machines, to do RPC (kind
of) calls.
IF you want to compare SOAP with something using JSON,
I would make this argument instead: REST or SOAP?
A big part of creating a seamless experience on mobile devices is to be able
to handle* limited connectivity* (temporary loss of connection) and to have
*stateless* (remote) services available (user can access data directly
without going
Of course, if you're only going to read a small part of an XML
representation from a REST query, why did you have the unwanted info
transmitted in the first place??
On May 30, 8:28 pm, Streets Of Boston flyingdutc...@gmail.com wrote:
I would make this argument instead: REST or SOAP?
A big part
The original question wat about *consuming* web services, not necessarily
creating them. The answer to your question is:
- When you don't have control of server-side that provides the REST
services, and/or
- When the REST services are going to be accessed by more than just
22 matches
Mail list logo
