Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Using TCP sockets with your own protocol rolled down is quite better than HTTP especially with the nature of resources on the mobile devices. Erlang will do quite well, however lets start from your protocol. Erlang excels well at this especially with the <b><a href="http://www.erlang.org/documentation/doc-5.6/doc/programming_examples/bit_syntax.html" rel="nofollow noreferrer">Bit Syntax</a></b> expressions. However still, you could use plain text as you wish. JSON (would need a parser: <b>Mochijson2.erl</b> found in <b><a href="https://github.com/mochi/mochiweb" rel="nofollow noreferrer">Mochiweb library</a></b>) and XML (will need a parser: <b><a href="https://github.com/pugpharm/erlsom" rel="nofollow noreferrer">Erlsom</a></b>).</p> <p>I have personally worked on a project in which we were using raw TCP Sockets with our Erlang Servers and Mobile Devices. However, depending on the Port numbers you choose, Routers along the way would block/Drop packets depending on the security policies of service providers. However, i still think that HTTP can work. People chat on Facebook Mobile, send Twits e.t.c from their devices and am sure these social engines use some kind of Long Polling or Server Push or whatever but using HTTP. The mobile devices have advanced in capability of late.</p> <p>Rolling your own TCP Based protocol comes with a number of challenges: Port selection, Parsing of data both at the client and server, Security issues e.t.c. Using HTTP will let you think of the actual problem than spending time correcting protocol issues at client or server. The Devices you've mentioned above like Android and IOS (Ipad, Iphone e.t.c) are very capable of handling HTTP COMET (Long polling). Am sure when you follow the <b><a href="http://www.w3.org/2011/02/mobile-web-app-state.html" rel="nofollow noreferrer">standards for Web Applications on Mobile devices</a></b> as well as these <b><a href="http://www.w3.org/TR/mobile-bp/" rel="nofollow noreferrer">W3C Mobile Web Best Practices</a></b>, your app will function well using HTTP.</p> <p>Using HTTP methods will quicken the work and there are a lot of libraries on the SDKs of these Devices which would assist you prototype the solution you want as compared to the situation of rolling your own TCP-based plain text protocol. To back up this reasoning, look through these <b><a href="http://www.w3.org/standards/techs/mobileapp#w3c_all" rel="nofollow noreferrer">W3C findings</a></b>.</p> <p>Let me finally talk of the HTTP benefits on these Devices. If you are to use Web technologies for Mobile devices, such as <b><a href="http://dev.opera.com/articles/view/opera-widgets-sdk/" rel="nofollow noreferrer">Opera Widgets</a></b>, <b><a href="http://www.phonegap.com/" rel="nofollow noreferrer">Phone Gap</a></b>, <b><a href="http://www.sencha.com/products/touch/" rel="nofollow noreferrer">Sencha Touch</a></b>, and <b><a href="http://jquerymobile.com/" rel="nofollow noreferrer">JQuery Mobile</a></b>, their SDKs and Libraries have Optimizations already done for you or have well documented ways in which your app can be made efficient. Further still, these technologies have the APIs to access the native Devices' resources like Battery check, SMS, MMS, GSM broadcast channels, Contacts, Lighting, GPS , and Memory; all as APIs in the JavaScript classes. It would become hard (inflexible) if you use native programming languages like <b><a href="http://today.java.net/pub/a/today/2005/02/09/j2me1.html" rel="nofollow noreferrer">J2ME</a></b>, <b><a href="http://www.awaretek.com/pymo.html" rel="nofollow noreferrer">Mobile Python</a></b> or <b><a href="http://www.developer.nokia.com/Community/Wiki/Qt_overview" rel="nofollow noreferrer"> Symbian C++ / Qt</a></b> as compared to using Web technologies like CSS3, HTML5 and JavaScript tools mentioned above. Using the Web tools mentioned above will make your app easily distributable by say <b><a href="http://store.ovi.com/" rel="nofollow noreferrer">Ovi Store</a></b> or <b><a href="http://store.apple.com/us" rel="nofollow noreferrer">Apple Store</a></b>, from experience.</p> <p>Take note that if you use HTTP, testing will be easy. All you need is a public Domain so the Widgets on the mobile device locates your servers over the Internet. If you role your own TCP/IP protocol, the Network Routers may be disruptive against the Port number you use unless you plan on using port 80 or another well known port, but then still your Server IP would have to be made Public. There is a short cut to this: if you put your TCP Server behind the same ISP as your testing Mobile's Internet connection, the ISP routers will see both source and destination as behind its Network. But all in all, there are challenges with rolling your own protocol.</p> <p>Edit: Using HTTP, you will benefit from <b><a href="http://en.wikipedia.org/wiki/Representational_State_Transfer" rel="nofollow noreferrer">REST</a></b>. Web Servers implemented in Erlang (especially <b><a href="http://yaws.hyber.org/" rel="nofollow noreferrer">Yaws</a></b> and <b><a href="https://github.com/hibari/mochiweb" rel="nofollow noreferrer">Mochiweb</a></b>) excel at REST services. Look at this article: <b><a href="http://www.infoq.com/articles/vinoski-erlang-rest" rel="nofollow noreferrer">RESTFUL services with Yaws</a></b>. For mochiweb, there is an interesting article about: <b><a href="http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3" rel="nofollow noreferrer">A million User comet application using Mochiweb</a></b> which is broken into 3 parts. Further still, you could look at the <b><a href="https://stackoverflow.com/questions/6461427/is-there-an-erlang-module-that-supports-ajax/6466089#6466089">solution given to this question</a></b>.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload