Reputation: 522
I am designing a mobile application which gets server data through SOAP messages.
I wanted to know what is the best practice:
*PS:*user can have many vehicles and if I use second approach then web services will be called for every vehicle.
Upvotes: 6
Views: 1434
Reputation: 5790
On a mobile connection, I'd opt for larger responses because of the network latency. It's better to fetch a bunch of things in one go than to fetch each item in a new roundtrip. This will keep your app fast.
Even larger responses can be efficiently handled without needing to store those in memory if you use a library that can "stream" the response.
Upvotes: 2
Reputation: 5824
What sort of size responses are we talking about - min / max / typical?
There's no simple answer to this question as it depends on what triggers the web-service request e.g. is it in response to a user action, timed etc.
Latency is one of the killers over mobile networks (more important than low bandwidth) so in theory you should aim for a minimum number of requests.
but...
There's no point in making large requests if you don't need the data.
My guess is you're going to have to test with different response sizes to find the sweet spot.
Also don't forget to allow gzip/deflate in the request and compress the response from the server.
If possible I'd also go for a RESTful approach and ensure the GET responses are cacheable
Upvotes: 1
Reputation: 11230
Couple of points
As pointed out in the comment Use JSON instead of SOAP where ever possible, SOAP is very heavy weight and is not being recommended these days.( look at all the endpoints being exposed by Google and others - most of them use JSON )
If the xml size is becoming too large ( beyond few kilobytes) it is better to make multiple calls rather than loading a large object in memory.
Upvotes: 3