Ok, now that I have your attention, it is time to get your mind out of the gutter and back on the topic at hand.  When you are building out native mobile applications you are undoubtedly going to communicate to some sort of back end server via some sort of Web Service (say WCF for example if building on top of the Windows Phone 7 platform).

When build these web service endpoints most developers will pay attention to the type and the amount of data which is being sent across the wire, but I would venture a guess that for the most part they are doing this for the wrong, yet still very valid, reason.   I know in the past when I have build out endpoints and the payloads they were going to be communicating I was solely focused on making sure that only the minimum data points which are needed by the consumer are being sent.  As valid as this is, you should also concern yourself with the actual payload size in kilobytes which is being sent.  Which in my opinion is the right reason to pay attention to the data being sent across the wire.

Why should you focus on the size of the message more so than the content of the message?  Well by focusing on the size you will be indirectly focusing on the content as well but you will be doing so from a different perspective. 

Things you can do to reduce the payload size?

• Use JSON rather than xml based web services:
  
  In my experience if you can encode (format) your payload as JSON you will see a size reduction of 40% or MORE in your payload.  And when we are talking about sending data across the wire (aka the cell network) this can and will have a huge impact on your applications performance.
• If you use XML, make sure you use concise property names:
  
  When you build out your object model try to use concise rather than verbose names for properties.  For example if you have an object called Customer there is no need to name a property CustomerFirstName but rather I would suggest you call it First.  First the ‘Customer’ prefix should be inferred from the object context and the suffix of name should also be inferred.  By removing Customer and Name you are actually saving 24 characters, not 12.  Remember w/ XML you have the closing tag so the serialized message will be <First>Something</First> rather than <CustomerFirstName>Something</CustomerFirstName>.
  
  If you pay attention to this convention you could see as much as a 20-25% reduction in your message.  But word to the wise, I would still prefer readability over a super reduction in size.  There are a few blog posts out there that would suggest you name the property something like ‘F’.  Personally I think this obfuscates the intent of the message too much and this trumps a smaller message, but each scenario is unique and maybe you need that level of reduction in size.
• If you use XML, make sure you control your namespaces of your objects:
  
  When you use WCF and DataContracts you have the ability to specify the namespace for each object.  In my experience the default namespace which is provided (the one of your physical object model) often times is very long.  In WCF you have the ability to specify a shorter namespace which can be used.  And when I specify this namespace I take the time to create it as a valid Uri rather than a object model namespace.  I have seen a 3-5% reduction in message size by doing this.  I know you are thinking that 3-5% is not much, but remember when talking about pushing data over networks such as Cell networks that can have a bit of an impact.

If you pay attention to your message from the size perspective and monitor this information you will be surprised by what type of performance gains you can receive.  This type of performance tuning is about the simplest and easiest you can perform and the ROI on it can be substantial.

Till next time,