title: Socket vs HTTP for mobile application
body: <p>I am developing native mobile application ( Android, iOS ) with some VoIP and social network functionality. So the main parts of the overall applications are:</p>
  
  <ol>
  <li>Mobile app</li>
  <li>SIP Server ( for VoIP )</li>
  <li>Web Server</li>
  </ol>
  
  <p>Given that:</p>
  
  <ul>
  <li>there is already persistent socket connection ( for VoIP ) </li>
  <li>the Web Server can send some messages to the mobile app ( via SIP Server ) and vice versa</li>
  </ul>
  
  <p>What is the best way of communication  between mobile app and the web server, when the mobile application is in the foreground and user browses some social network functionality ( Like viewing images, texts, messages ). Mobile battery, performance, reliability, scalability and the development ease are the issues.</p>
  
  <p>Currently I can think of three ways:</p>
  
  <p>1) HTTP request/response - traditional &amp; reliable programming. In order to retrieve some data mobile app will need to make a http request ( and establish new connection ).
  But I am afraid, that this can kill the mobile battery.</p>
  
  <p>2) When the mobile app goes to foreground - open a socket to the web server. All interactions between mobile app and the web server will use this socket. When app goes to background - socket is closed. ( So two open sockets - in foreground, one in background, i.e only VoIP signaling socket stays )</p>
  
  <p>3) Use the VoIP signaling socket for everything. In this case the SIP server will be a mediator between a mobile app and web server, of course the SIP server might become a bottleneck.</p>